From nobody Sun May 3 19:29:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798871A907E; Sun, 3 May 2015 19:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AR99nv_0mPq; Sun, 3 May 2015 19:29:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD671A9071; Sun, 3 May 2015 19:29:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> Date: Sun, 03 May 2015 19:29:05 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:29:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : DHCPv6/SLAAC Interaction Problems on Address Auto-configuration Authors : Bing Liu Sheng Jiang Xiangyang Gong Wendong Wang Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt Pages : 13 Date : 2015-05-03 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating which auto-configuration mechanisms are available to on- link hosts. These are the M, O and A flags. The M and O flags are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also describes operational problems that divergent behaviors might cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 3 19:31:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7E1A9084 for ; Sun, 3 May 2015 19:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYQOGAPUKDkd for ; Sun, 3 May 2015 19:30:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310141A907F for ; Sun, 3 May 2015 19:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3025; q=dns/txt; s=iport; t=1430706660; x=1431916260; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W8Gcw9tfLBau1ZPiBXpTZi6Gc3zmSCoCoeAbVEoVQB8=; b=Hy05t1Rdw//Mt5pZiW124RB0vEIrshna8DikkxtOvqJR+EriaYoGYGCK P/31v2kRP09/3yDphZ1YoXSr6H4g2Bd0Mt/PWZdpDiQ1KYrKlo9Vq9wc0 nLDxK3FnckmsP9nxp/dYfe7ZpI/cJe9K7KYq85MGdBYx2waBEnJ5GNGMG Y=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQCT2UZV/4UNJK1cgwxTXAXHNwyGAgKBREwBAQEBAQGBC4QgAQEBAwEBAQFrEAsCAQgYLicLJQIEEw6IFQgNxEUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizmFDIMXgRYFkg2BfIE5XIZBgSQ9gxWRKCODdG+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,363,1427760000"; d="asc'?scan'208";a="413632204" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 04 May 2015 02:30:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t442UePO022931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 May 2015 02:30:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.147]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Sun, 3 May 2015 21:30:40 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt Thread-Index: AQHQhhJPy8m/9XA00UKuvrHAwvL4Gg== Date: Mon, 4 May 2015 02:30:40 +0000 Message-ID: References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> In-Reply-To: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.66.224] Content-Type: multipart/signed; boundary="Apple-Mail=_05DFAFDE-3E54-444C-B5B3-7661607C1402"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:31:01 -0000 --Apple-Mail=_05DFAFDE-3E54-444C-B5B3-7661607C1402 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Observing the posting, let me invite commentary on it. > On May 3, 2015, at 7:29 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : DHCPv6/SLAAC Interaction Problems on Address = Auto-configuration > Authors : Bing Liu > Sheng Jiang > Xiangyang Gong > Wendong Wang > Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt > Pages : 13 > Date : 2015-05-03 >=20 > Abstract: > The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router > Advertisement (RA) message. The RA message contains three flags, > indicating which auto-configuration mechanisms are available to on- > link hosts. These are the M, O and A flags. The M and O flags are > advisory, not prescriptive. >=20 > This document describes divergent host behaviors observed in popular > operating systems. It also describes operational problems that > divergent behaviors might cause. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem-= 04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_05DFAFDE-3E54-444C-B5B3-7661607C1402 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVUbZzp9ieig10VPpAQKJAgf/SuALJAyjGkgCXnUC6vTwv2opO9MfYLEs V9xKsjX/blyrq5n0GXqSLtUgECrQiqOhy4uKIbdh6da5K5E+s6oaPQYd/R8hyM7e PFmPolH+57Wch3HnCwpzIJM76LS7UsF2SuedlMiiYv4lo/X6x11s1KT+OBtKS/8x kollpqCYzwk2Kz6Xxtj9TKAlC+IvcZUwlgq5184x3CoLjlrx3CGhVShNlMWzteaL PGDrtf6cJBwIFfCiEvMjM+x1N975uwxRdEHy5xl1vss1UwZX7f+8WY1+Jt96GKBh iIYb8F3Wk8JaVtQ2LljQ68BUZSwRnVWyOVVcRtoN119AaTYYkIvUgg== =XCVg -----END PGP SIGNATURE----- --Apple-Mail=_05DFAFDE-3E54-444C-B5B3-7661607C1402-- From nobody Sun May 3 19:31:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0821A908F; Sun, 3 May 2015 19:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKaRdN9KLG64; Sun, 3 May 2015 19:31:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE511A908E; Sun, 3 May 2015 19:31:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> Date: Sun, 03 May 2015 19:31:08 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:31:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Considerations For Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-recommendations-05.txt Pages : 16 Date : 2015-05-03 Abstract: This document provides considerations for using IPv6 Unique Local Addresses (ULAs). It identifies cases where ULA addresses are helpful as well as potential problems that their use could introduce, based on an analysis of different ULA usage scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommendations-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 3 19:33:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC601A9092 for ; Sun, 3 May 2015 19:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzPXis3xtcXw for ; Sun, 3 May 2015 19:33:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFE51A908E for ; Sun, 3 May 2015 19:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2835; q=dns/txt; s=iport; t=1430706795; x=1431916395; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=81B4tLZugQFjbctLvOwJKZodm7o/f9Il+42QRipYj0Q=; b=bWzIj/E3q+e4c/kX0q/5Z9UsZ5vbu5YrQrEtdFo+ZqdF27xKNNdXqg51 i2HV1fOrP+TWc7t4f4ElbVi8wXqDfoY7ZsFcc6Py7rLoVrnuAF3GVyqxc FtlHKQpxQYPqie39v8YLleR8MeTD0QEuFXP6NF6i234fDIRZL2lGFUGeD Q=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDV2UZV/5xdJa1cgwxTXAXHNAyGAgKBREwBAQEBAQGBC4QgAQEBAwEBAQFrEAsCAQgYLicLJQIEEwkFiBUIDcRFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s5hQcFgxeBFgWSDYF8gTlchkGBJD2DFYpPhlkjg3RvAYFDgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,363,1427760000"; d="asc'?scan'208";a="416826421" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 04 May 2015 02:33:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t442XDjS021016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 May 2015 02:33:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.147]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 3 May 2015 21:33:13 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt Thread-Index: AQHQhhKq2jWWcePivU6tz+PZa79BKQ== Date: Mon, 4 May 2015 02:33:12 +0000 Message-ID: References: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> In-Reply-To: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.66.224] Content-Type: multipart/signed; boundary="Apple-Mail=_4AB0ADFF-1CC9-4239-867C-E7698A512491"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:33:16 -0000 --Apple-Mail=_4AB0ADFF-1CC9-4239-867C-E7698A512491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii May as well discuss this one too :-) > On May 3, 2015, at 7:31 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Considerations For Using Unique Local = Addresses > Authors : Bing Liu > Sheng Jiang > Filename : = draft-ietf-v6ops-ula-usage-recommendations-05.txt > Pages : 16 > Date : 2015-05-03 >=20 > Abstract: > This document provides considerations for using IPv6 Unique Local > Addresses (ULAs). It identifies cases where ULA addresses are > helpful as well as potential problems that their use could = introduce, > based on an analysis of different ULA usage scenarios. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendation= s/ >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-recommendat= ions-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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 --Apple-Mail=_4AB0ADFF-1CC9-4239-867C-E7698A512491 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVUbaZ59ieig10VPpAQJRqAf/bYVL6iMhkE+JSs3wKLsIQhL/MtubVHbK T9+OIFCOzkC3ucQkWCHaZ0H5Ku9/PqZjScfe/ZzD2Weu7Yd+owzFWT0wxVYsfdiq al+zQwOJ6hHXkUVGJIff6FntD7d65/auNa305MO3KHp3LfYuzpPYQ8bK9uZPyQv5 ILANHimWASgZWudp2ncT37bk/Y+YqcTs6iSRUwp8a4EC56UopSxr2zYEuVBvxm6s KcBkeQCqKP5KIIMH35XlS+9/18o1m5s7wOzV6dzbPRvzNvt+uDVRtnCGpkWhZTlJ X75vSowmDvbWJR7c0WiTThyELRORtjX7IegL164VGiMo8hAjvUCzQw== =6k8E -----END PGP SIGNATURE----- --Apple-Mail=_4AB0ADFF-1CC9-4239-867C-E7698A512491-- From nobody Sun May 3 19:35:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91E1A9092 for ; Sun, 3 May 2015 19:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX3Rv-AvsFtX for ; Sun, 3 May 2015 19:35:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319BA1A908F for ; Sun, 3 May 2015 19:35:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVP41893; Mon, 04 May 2015 02:35:05 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 03:35:04 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 4 May 2015 10:35:01 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt Thread-Index: AQHQhhK2O8WU2g5mp0SPfE9GNoj6H51rGWCg Date: Mon, 4 May 2015 02:35:01 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDC1C@nkgeml506-mbx.china.huawei.com> References: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:35:09 -0000 Hi Fred & all, Thanks for noting this. This is only a keep-alive update. I'll do the conte= nt update later. Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Monday, May 04, 2015 10:33 AM > To: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-ula-usage-recommendations-05.txt >=20 > May as well discuss this one too :-) >=20 > > On May 3, 2015, at 7:31 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations Working Group of the I= ETF. > > > > Title : Considerations For Using Unique Local > Addresses > > Authors : Bing Liu > > Sheng Jiang > > Filename : > draft-ietf-v6ops-ula-usage-recommendations-05.txt > > Pages : 16 > > Date : 2015-05-03 > > > > Abstract: > > This document provides considerations for using IPv6 Unique Local > > Addresses (ULAs). It identifies cases where ULA addresses are > > helpful as well as potential problems that their use could introduce, > > based on an analysis of different ULA usage scenarios. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommenda > > tions/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations > > -05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-recommen= d > > ations-05 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > 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 nobody Sun May 3 19:51:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6981A90EF for ; Sun, 3 May 2015 19:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zkcr9BG7UFO for ; Sun, 3 May 2015 19:51:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D111A8BC4 for ; Sun, 3 May 2015 19:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3496; q=dns/txt; s=iport; t=1430707872; x=1431917472; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oMvHSlRSCfp7boxZC5HhtbhXb8Izi6v4IfIJZuEL5C4=; b=jdN7ZOHvGDsRWSS6zGVFO85SZKpgCzQiUYyPhvMR7Pnc1SG169OTA14T gY88CdVElQlNzGP5rln27pI0kz41TZeDLcep2eW24jbLJfPkFqoAryjDQ 2I6gUUeOhZYRg5vpAWqxJhplubVWUXyjYFCvy587X2tjGTxh5c00RywEG M=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBAAb3kZV/5ldJa1cgwxTXAXFXwmBTAqGBAKBRDgUAQEBAQEBAYEKhCABAQEDAQEBAWsLBQcEAgEIEQQBAQEnBycLFAkIAgQOBQkFiBUIDcRHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s5hQUCBQYDgw6BFgWSDYF8gTlchkGBJD2DFYlyXYZZI4N0bwGBQ4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,363,1427760000"; d="asc'?scan'208";a="146726400" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 04 May 2015 02:51:11 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t442pAuV015081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 02:51:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.147]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sun, 3 May 2015 21:51:10 -0500 From: "Fred Baker (fred)" To: "Liubing (Leo)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt Thread-Index: AQHQhhUsfqYuyw1J1kWarChEDpiZ9A== Date: Mon, 4 May 2015 02:51:09 +0000 Message-ID: References: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDC1C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDC1C@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.66.224] Content-Type: multipart/signed; boundary="Apple-Mail=_6D71D535-6914-4E44-A86C-D0288B354315"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:51:13 -0000 --Apple-Mail=_6D71D535-6914-4E44-A86C-D0288B354315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is that true for both drafts? > On May 3, 2015, at 7:35 PM, Liubing (Leo) = wrote: >=20 > Hi Fred & all, >=20 > Thanks for noting this. This is only a keep-alive update. I'll do the = content update later. >=20 > Best regards, > Bing >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker = (fred) >> Sent: Monday, May 04, 2015 10:33 AM >> To: v6ops@ietf.org WG >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-ula-usage-recommendations-05.txt >>=20 >> May as well discuss this one too :-) >>=20 >>> On May 3, 2015, at 7:31 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>>=20 >>> Title : Considerations For Using Unique Local >> Addresses >>> Authors : Bing Liu >>> Sheng Jiang >>> Filename : >> draft-ietf-v6ops-ula-usage-recommendations-05.txt >>> Pages : 16 >>> Date : 2015-05-03 >>>=20 >>> Abstract: >>> This document provides considerations for using IPv6 Unique Local >>> Addresses (ULAs). It identifies cases where ULA addresses are >>> helpful as well as potential problems that their use could = introduce, >>> based on an analysis of different ULA usage scenarios. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommenda >>> tions/ >>>=20 >>> There's also a htmlized version available at: >>> = https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations >>> -05 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-recommend >>> ations-05 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at = tools.ietf.org. >>>=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 --Apple-Mail=_6D71D535-6914-4E44-A86C-D0288B354315 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVUbenJ9ieig10VPpAQL9eAf/bG0hh1pYblCHtQCUMoVcif/3C/hjTUSS TerYEv9jaDF0ct1JRcOC47w6YMmXQE7zLRt3U/759WT5mAqZTfPjnbn2jaxpKiUl mPq6O05q96BoGTBXPFeeLmO8E79oemTw0bkAN042W3gR778Fa/pWhZNJropt9Fdp xG+TvJo1VeUMED3Ngpf9WqAKEdm72aKEYNkPSyU8DpA2TCgcinjfwhVrE0Oz1hef 6c+H1cBy/X5RehAwpE7TIS2wLPpaQPkV08WqH0kxZytXXoaDKWwKIIyfhhxj0QPt 51Luvsw6m+8M7+EoCV/lcRaKnC5dGdwg9xcFgWDGnzTcAJhaaZJTvg== =d6WA -----END PGP SIGNATURE----- --Apple-Mail=_6D71D535-6914-4E44-A86C-D0288B354315-- From nobody Sun May 3 19:54:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5088C1A9111 for ; Sun, 3 May 2015 19:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZnvIxnbZ3l4 for ; Sun, 3 May 2015 19:54:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9081A9121 for ; Sun, 3 May 2015 19:54:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVP42944; Mon, 04 May 2015 02:54:43 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 03:54:43 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 4 May 2015 10:54:40 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt Thread-Index: AQHQhhK2O8WU2g5mp0SPfE9GNoj6H51rGWCg//9+toCAAIZAsA== Date: Mon, 4 May 2015 02:54:38 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDC44@nkgeml506-mbx.china.huawei.com> References: <20150504023108.11944.78655.idtracker@ietfa.amsl.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDC1C@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 02:54:49 -0000 Hi Fred, It's only about the ULA draft.=20 I've done some content update for the DHCPv6/SLAAC, and I'm about to initia= te discussion on it. Best regards, Bing > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Monday, May 04, 2015 10:51 AM > To: Liubing (Leo) > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-ula-usage-recommendations-05.txt >=20 > Is that true for both drafts? >=20 > > On May 3, 2015, at 7:35 PM, Liubing (Leo) > wrote: > > > > Hi Fred & all, > > > > Thanks for noting this. This is only a keep-alive update. I'll do the c= ontent > update later. > > > > Best regards, > > Bing > > > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > >> (fred) > >> Sent: Monday, May 04, 2015 10:33 AM > >> To: v6ops@ietf.org WG > >> Subject: Re: [v6ops] I-D Action: > >> draft-ietf-v6ops-ula-usage-recommendations-05.txt > >> > >> May as well discuss this one too :-) > >> > >>> On May 3, 2015, at 7:31 PM, internet-drafts@ietf.org wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the IPv6 Operations Working Group of the > IETF. > >>> > >>> Title : Considerations For Using Unique Local > >> Addresses > >>> Authors : Bing Liu > >>> Sheng Jiang > >>> Filename : > >> draft-ietf-v6ops-ula-usage-recommendations-05.txt > >>> Pages : 16 > >>> Date : 2015-05-03 > >>> > >>> Abstract: > >>> This document provides considerations for using IPv6 Unique Local > >>> Addresses (ULAs). It identifies cases where ULA addresses are > >>> helpful as well as potential problems that their use could > >>> introduce, based on an analysis of different ULA usage scenarios. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommen > >>> da > >>> tions/ > >>> > >>> There's also a htmlized version available at: > >>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendatio > >>> ns > >>> -05 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-recomm= e > >>> nd > >>> ations-05 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>> > >>> 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 nobody Mon May 4 04:08:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF4A1AD2DF for ; Mon, 4 May 2015 04:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b5XBJWz9Gmy for ; Mon, 4 May 2015 04:08:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952A11AD2D5 for ; Mon, 4 May 2015 04:08:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVQ14910; Mon, 04 May 2015 11:08:20 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 12:08:19 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 4 May 2015 19:08:11 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Thread-Topic: DHCPv6/SLAAC draft question for the WG-//RE: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt Thread-Index: AQHQhhIsrmVcKMcySUitbChD26jFFJ1qkl4AgACHXWA= Date: Mon, 4 May 2015 11:08:11 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEDE99@nkgeml506-mbx.china.huawei.com> References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] DHCPv6/SLAAC draft question for the WG-//RE: I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 11:08:23 -0000 Hi Fred & all, This draft was launched WGLC when the last version submitted. The main prob= lem raised was that a couple of people didn't think the problems described = in the draft were very essential.=20 Besides, there were also a couple of people thought the test result part of= the document were interesting and valuable, and the whole document should = focus on the test report. We considered these comments carefully, and now we tend to follow this way: 1. This document does NOT intend to invoke 6man to solve the problems in pr= otocol design. We do not judge the problems are essential or just corner ca= ses; this might depend on more IPv6 practices in the future. The document a= nalyzes all the explicit and implicit ambiguities, points out possible dive= rgent behaviors and identifies some divergent behaviors do happen among mai= nstream operating systems through testing. We believe these are valuable in= formation for administrators caution. 2. The test result of various operating systems are valuable, but we though= t maybe it's good to leave it in the appendix. Because the operating system= s are updating all the time, the behaviors documented might probably change= d in future operating system versions. The documented behaviors are only fo= r proving the analyzed divergence could probably happen in real implementat= ions. So, we mainly did some editorial revision in this new version: 1. Moved the ambiguity analysis content back to the main text from the appe= ndix (with a bit revision). 2. Changed the title to make it clearer that the document focuses on addres= s auto-configuration aspect of DHCPv6/SLAAC interaction. 3. Adjusted the structure. So, with the explanation, may I ask the WG, do you think it's a proper way = to move forward the draft? Or we need to do some extra work? Any comments would be appreciated a lot! Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Monday, May 04, 2015 10:31 AM > To: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt >=20 > Observing the posting, let me invite commentary on it. >=20 > > On May 3, 2015, at 7:29 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations Working Group of the I= ETF. > > > > Title : DHCPv6/SLAAC Interaction Problems on > Address Auto-configuration > > Authors : Bing Liu > > Sheng Jiang > > Xiangyang Gong > > Wendong Wang > > Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt > > Pages : 13 > > Date : 2015-05-03 > > > > Abstract: > > The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router > > Advertisement (RA) message. The RA message contains three flags, > > indicating which auto-configuration mechanisms are available to on- > > link hosts. These are the M, O and A flags. The M and O flags are > > advisory, not prescriptive. > > > > This document describes divergent host behaviors observed in popular > > operating systems. It also describes operational problems that > > divergent behaviors might cause. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem > > / > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-probl= e > > m-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon May 4 10:27:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440411A86FE for ; Mon, 4 May 2015 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x142-sCLqcUq for ; Mon, 4 May 2015 10:27:27 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137C21A86FD for ; Mon, 4 May 2015 10:27:27 -0700 (PDT) Received: by iejt8 with SMTP id t8so135509416iej.2 for ; Mon, 04 May 2015 10:27:26 -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:message-id:subject :from:to:cc:content-type; bh=m+yKq9Hq4CREt5sac6N8uXKHod6tA2yU+7sqwA16FN4=; b=S8jKJ31wgElac+PU+TVFHpbztwPAfvi9E3nkYdBWrUeDMvO4AZsDyD3oZb6j6EPMav 2nEZZrS+12xAnadCM5yBgRQ1OHwGNLASPhhuBkF4T7kYPLSs2elGv/1jO69E1w3X1Pr0 Ws3Y0VFdSG7SMeX38HJKEcUFCm03pH4FF6+rxNcn2BZ83kTsRn949mbaJVYKGAsaOrU1 IESXPWziYWhe/t7h9WrAQGzdbWmfP/GbLVvCzLFpcmu4Iup9rIJq5Kg8J0qXfmDHo2PZ zC4C3XvS2IvwB/2F/B9RVS0XU38l178lPtRg9bMoW4KEJjRSjDtg2zyjvgp5sI5HcAKD XAoA== MIME-Version: 1.0 X-Received: by 10.50.178.138 with SMTP id cy10mr14442058igc.3.1430760446393; Mon, 04 May 2015 10:27:26 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.50.80 with HTTP; Mon, 4 May 2015 10:27:26 -0700 (PDT) In-Reply-To: References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> Date: Mon, 4 May 2015 10:27:26 -0700 X-Google-Sender-Auth: ygdSpvSOQT3FY3N8KdmBGH-6K8Y Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:27:28 -0000 At Mon, 4 May 2015 02:30:40 +0000, "Fred Baker (fred)" wrote: > Observing the posting, let me invite commentary on it. It seems that the main points of my previous comments - http://www.ietf.org/mail-archive/web/v6ops/current/msg20179.html - http://www.ietf.org/mail-archive/web/v6ops/current/msg20200.html still apply. So my conclusion is the same: "I personally don't think it worth publishing in its current form, although I wouldn't be opposed to it if the wg thinks it's useful." -- JINMEI, Tatuya From nobody Mon May 4 20:29:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEA51B2CD2 for ; Mon, 4 May 2015 20:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGMdz1DomR2Q for ; Mon, 4 May 2015 20:29:45 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6A41A90D5 for ; Mon, 4 May 2015 20:29:45 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so181324126pdb.0 for ; Mon, 04 May 2015 20:29:45 -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=F9vLVfTUL0sHDRgP77XZyXnke/S++uSkUbj+YwdIQ/Q=; b=rR21znjEiYZs+FLhZnxceRLRozOKqbT/ubsApi1ZJFN73K5nDZKbfrQjhYAub6xJyL AWy12aws/nvkkrhPVZm4u+T5ov577nZ7I92qI7s69DQood7LGxyT30/zzzOK4rIaviZI ZkZfvAMWqDBLe2Q5TzduFYLg9s/PO8/NKL4n3Vku+L4h29JXwvqEQzUycAoK5PQY+BHt eWA/ehgIo3c1JXv5ktmFaIumP3SWt1r3VV4jp/REJSuDS6a/WKc07OCk6YoodDwoZgsZ B9TBcAfwvNDuw+f20nlmJk4eVh1+SNOonnJOcJ3ggN+wbIRON0GDiBLkItF9Fn3gNxV3 lkvw== X-Received: by 10.67.30.65 with SMTP id kc1mr46984880pad.91.1430796585387; Mon, 04 May 2015 20:29:45 -0700 (PDT) Received: from [172.19.57.92] ([131.203.112.133]) by mx.google.com with ESMTPSA id zs5sm14286266pac.11.2015.05.04.20.29.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 20:29:43 -0700 (PDT) Message-ID: <55483921.40605@gmail.com> Date: Tue, 05 May 2015 15:29:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Fred Baker (fred)" References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 03:29:47 -0000 Hi, On 05/05/2015 05:27, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 4 May 2015 02:30:40 +0000, > "Fred Baker (fred)" wrote: >=20 >> Observing the posting, let me invite commentary on it. >=20 > It seems that the main points of my previous comments > - http://www.ietf.org/mail-archive/web/v6ops/current/msg20179.html So, one of your comments was this: >> Actually, I guess there should be more pragmatic examples of >> operational issues because of the described divergence That would be fine, but surely the underlying point is that if you have a heterogeneous network and you repeat certain events (like a power fail/restart, or a temporary cable cut, or automated renumbering) the end state may be different in different cases, because of race conditions and the divergent behaviour of different devices. Now maybe we accept that as OK, but at least we should document how it can happen. Another comment you made: >>> The M, O and A >>> flags are advisory, not prescriptive. >>=20 >> In my understanding, the A flag is quite prescriptive. If a host >> implementation doesn't perform SLAAC for a prefix information option= >> with A flag on, that implementation would be considered >> non-compliant. I agree that this should be clarified. But RFC 4862 does not seem clear, because it only covers the opposite case: "a) If the Autonomous flag is not set, silently ignore the Prefix Information option." Similarly, RFC 4861 is not presecriptive: " A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [ADDRCONF]." and RFC 6434 does not mention this issue. Personally I'd like to see a statement that a host that receives a PIO with A=3D1 MUST perform SLAAC, but that really doesn't seem to be specified anywhere. > - http://www.ietf.org/mail-archive/web/v6ops/current/msg20200.html > still apply. >=20 > So my conclusion is the same: "I personally don't think it worth > publishing in its current form, although I wouldn't be opposed to it > if the wg thinks it's useful." I think it's useful information for operators. Brian From nobody Tue May 5 11:05:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11341ABD3D for ; Tue, 5 May 2015 11:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIw9RA7f065l for ; Tue, 5 May 2015 11:05:37 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B0D1A9025 for ; Tue, 5 May 2015 11:05:16 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so83468989igb.0 for ; Tue, 05 May 2015 11:05:16 -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:message-id:subject :from:to:cc:content-type; bh=NZ1S4n70EpKSH/rviKSGslxmq16XRIXkIuKqIxI2u14=; b=a4nZ7K2FLvAsJM3/yNLcXVurdLwBI5Fe7GX05WF3oBemE8MPnp90G9w+gjL3Pi9jRg v9wwjq1uNPmua2bYGXsyutKodCAcfk4zBv4YMGhtLON/mXXqV5AltLYnRV/3SlJ37AlS w5IRcsI5AO3ewSnWnUpscHFjnpMSfQN2r0YGkbnoRNqkp9Tp0P57iEpLP57YiqHCE00f IAA0Uy+h9FqOY+IF1GLfAtXGHKVfs8ADnxkcGYKPodYzxqSA715RSahBouneiN+031GG jHGI63MKOOoiMl9uvwmTmXIyQSfUftQ16NIpPl3QT+F9FOCl1Narsnq5YaAudtK2tx/M 9uXw== MIME-Version: 1.0 X-Received: by 10.107.10.201 with SMTP id 70mr35786102iok.0.1430849116137; Tue, 05 May 2015 11:05:16 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.50.80 with HTTP; Tue, 5 May 2015 11:05:16 -0700 (PDT) In-Reply-To: <55483921.40605@gmail.com> References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> <55483921.40605@gmail.com> Date: Tue, 5 May 2015 11:05:16 -0700 X-Google-Sender-Auth: Tqe5DaukRv3dnFANii9Zi11UPe0 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:05:39 -0000 At Tue, 05 May 2015 15:29:37 +1200, Brian E Carpenter wrote: > >> Actually, I guess there should be more pragmatic examples of > >> operational issues because of the described divergence > > That would be fine, but surely the underlying point is that if > you have a heterogeneous network and you repeat certain events > (like a power fail/restart, or a temporary cable cut, or automated > renumbering) the end state may be different in different cases, > because of race conditions and the divergent behaviour of different > devices. Now maybe we accept that as OK, but at least we should > document how it can happen. Personally, I'd expect to see some actual and practical troubles in such a case for a document about it to be sufficiently useful as something formal like an RFC. An observation of the divergent behavior may be somewhat interesting, but IMO not substantial enough. But, as I (hope) already said I'm not insisting my view is the only possible position. I guess you and I just have different expectations on what's worth documenting in RFCs. That's fine for me, and if many others in the wg share your expectation, I have no problem with publishing it. > Another comment you made: > > >>> The M, O and A > >>> flags are advisory, not prescriptive. > >> > >> In my understanding, the A flag is quite prescriptive. If a host > >> implementation doesn't perform SLAAC for a prefix information option > >> with A flag on, that implementation would be considered > >> non-compliant. > > I agree that this should be clarified. But RFC 4862 does not seem clear, > because it only covers the opposite case: > "a) If the Autonomous flag is not set, silently ignore the Prefix > Information option." > Similarly, RFC 4861 is not presecriptive: > " A 1-bit autonomous address-configuration flag. When > set indicates that this prefix can be used for > stateless address configuration as specified in > [ADDRCONF]." > and RFC 6434 does not mention this issue. > > Personally I'd like to see a statement that a host that > receives a PIO with A=1 MUST perform SLAAC, but that really > doesn't seem to be specified anywhere. That would make things super clearer and nicer, but I simply didn't see the critical need for it. In fact, from a quick re-read of the appendices of the draft, all tested implementations in all scenarios perform SLAAC if they receive a PIO with A=1. It seems to be an evidence that this point is already clear enough in practice. -- JINMEI, Tatuya From nobody Wed May 6 14:06:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692A41B2F58 for ; Wed, 6 May 2015 14:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEtSEj3LZaU8 for ; Wed, 6 May 2015 14:06:39 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42EF1B2F55 for ; Wed, 6 May 2015 14:06:38 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Yq6WX-00036p-Kk; Wed, 06 May 2015 23:06:34 +0200 Message-ID: <554A8253.7060806@gont.com.ar> Date: Wed, 06 May 2015 18:06:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150423184705.31382.56349.idtracker@ietfa.amsl.com> In-Reply-To: <20150423184705.31382.56349.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" Subject: [v6ops] IPv6 EHs in Real World (Re: I-D Action: draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 21:06:41 -0000 Folks, A summary of the changes from draft-gont to the first draft-ietf version of this document: * We have added this text to the Intro: This document presents real-world data regarding the extent to which packets containing IPv6 Extension Headers are filtered in the Internet, as measured in August 2014 (pending operational advice in this area). The results presented in this document indicate that in the scenarios where the corresponding measurements were performed, the use of IPv6 extension headers can lead to packet drops. We note that, in particular, packet drops occurring at transit networks are undesirable, and it is hoped and expected that this situation will improve over time. .. making it clear that the drops are undesirable, etc. * We have changed the notation fo the best-case and worst-case scenarios (from "X%-Y%" to "X%/Y%"), since folks noted that this results in improved clarity (we're representing to values, as opposed to a "range"). * Miscellaneous edits (fixed typos, etc.) Thanks! Best regards, Fernando On 04/23/2015 03:47 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Observations on IPv6 EH Filtering in the Real World > Authors : Fernando Gont > J. Linkova > Tim Chown > Will(Shucheng) Liu > Filename : draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt > Pages : 16 > Date : 2015-04-21 > > Abstract: > This document presents real-world data regarding the extent to which > packets with IPv6 extension headers are filtered in the Internet (as > measured in August 2014), and where in the network such filtering > occurs. The aforementioned results serve as a problem statement that > is expected to trigger operational advice on the filtering of IPv6 > packets carrying IPv6 Extension Headers, so that the situation > improves over time. This document also explains how the > aforementioned results were obtained, such that the corresponding > measurements can be reproduced by other members of the community. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed May 6 14:13:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E31B2F79 for ; Wed, 6 May 2015 14:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOiEamd3mvIU for ; Wed, 6 May 2015 14:13:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2831AD08F for ; Wed, 6 May 2015 14:13:28 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Yq6d7-00037j-1d; Wed, 06 May 2015 23:13:21 +0200 Message-ID: <554A83E3.4050503@gont.com.ar> Date: Wed, 06 May 2015 18:13:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 21:13:30 -0000 Folks, Question to the wg: Folks keep bringing up the reasons for which operators filter IPv6 packets with EHs (the reasons have been discussed on this mailing-list a few times already). Something along these lines was present in Section 3 of but we removed that section in later revisions (prior to the wg call for adoption of this document). A number of folks have argued that we should reincorporate that section. Me, I think it would be useful, but can live without reincorporating that section... It would be nice to hear from the wg about this. Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed May 6 17:07:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B581A8927 for ; Wed, 6 May 2015 17:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBLTZxqwVj2L for ; Wed, 6 May 2015 17:07:53 -0700 (PDT) Received: from nm50-vm7.bullet.mail.gq1.yahoo.com (nm50-vm7.bullet.mail.gq1.yahoo.com [67.195.87.247]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FE81A8931 for ; Wed, 6 May 2015 17:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1430957271; bh=wJnp8f9yqJwTpA051qturk02RAB6LFlVuOzxO/rdR+E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OmERiaxjysKEa4I7mP3tMUo6oYyICjgQMQGJg14fGwaWyePauMJClzEzoBPO2r1utK0BnbpCD/mLRZAmvLQR9f1A43k0WO0F69XQAHzbtkJrmco0Rp5QHvGaF3ZhUhn2Zzy8aVqNiiUzh7iIPuHBoWWfd+NuxFjxNmY/82hbue1SwW0j2yZnemdTNye5oUe/FzJm4ZrdxJy55JL2YKcy+v9DBztwZ1hfwvn0UkxsseadAMs2E4WvkmmOP5+1xu9HyNAe8mCKTHHcUiUTMEK/l7D3+T0Iv18CKeU1pPNRLKpV5L7Mb3bAlavwMDYU7tvYpipp5lSsP0d1D9wn5k3a1A== Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 07 May 2015 00:07:51 -0000 Received: from [98.137.12.60] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 07 May 2015 00:05:02 -0000 Received: from [98.139.170.179] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 07 May 2015 00:05:02 -0000 Received: from [98.139.212.205] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 00:05:01 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 07 May 2015 00:05:01 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 822951.99260.bm@omp1014.mail.bf1.yahoo.com X-YMail-OSG: urdpRUIVM1npG_QufzjSp.lgdO1DYytHwmVSesvWsfFsHFAaBexFLL5rQjy_eoo Rw8nquyhVsLz.qePgVVSPYyNYZ0POS.BPVZam4v32pcTWXkApIHyD41cY9rR2nZrkg84MudrygMf um319gKN9mysc_BY2Q4pRtvflpISAmT3K6A1slDdn_RHay2Zzof3vsCu9kNhtUYWV_EWzraQX.zS cYDE293pjha5PNP16NPXoPIr0WHz4PpYpzSb4.741VatGRZ_0K.7KEEgVpx2.Xaf1GQfFlOdB3rS xxy_awQpz94kIie6X5M5j7HDvXHKDjoXr6.TjMHPxM2nlI9nNK3JfEuCX14OKeoiRorApMZbr4JJ 6uhYsOLbbn9MOPZDWQJuIE5vEjbHT7cLOhOaqCC_huDra4HQcNXF5zZJPk2dv1L2mdSJ3_9YjtCm ctaZV8j_BPpMbLh4G0Ult6X2thYG4cpmeL.ZeyotCNHRvB13ndDH3202lohP6uv3h7TATQiBTqV6 oab_EpSd3cKGaZmAkLr5XHB3j4Ro8z1iFghpF9oa1Llm.kf.t_FVk0UmgQiK4 Received: by 66.196.81.107; Thu, 07 May 2015 00:05:01 +0000 Date: Thu, 7 May 2015 00:05:00 +0000 (UTC) From: Mark ZZZ Smith To: Fernando Gont , "v6ops@ietf.org" Message-ID: <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <554A83E3.4050503@gont.com.ar> References: <554A83E3.4050503@gont.com.ar> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1947632_122450897.1430957100739" Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 00:07:55 -0000 ------=_Part_1947632_122450897.1430957100739 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I don't have a strong opinion on whether it should be reincorporated or not= , as I haven't kept up with that discussion. However, if it does get included, I think the following statement needs mor= e clarification: "Many IPv6 router implementations suffer from a negative performance=C2=A0 = =C2=A0impact when IPv6 Extension Headers are employed." Is this really the case? It seems to me that this is saying that "Many IPv6= router implementations" are inspecting EHs by default, which then means ma= ny routers are vulnerable to the EH based DoSes and other issues mentioned = by default. I'd expect routers by default to have just processed/forwarded IPv6 packets= based on the fixed IPv6 header fields, ignoring EHs and allowing fast path= forwarding, and to only start looking at EHs if configured to via ACLs etc= . I think the above statement is effectively implying that fast path forwardi= ng of IPv6 isn't a default in many IPv6 router implementations, and I'd be = quite surprised if that is true, which is why I think more clarification wo= uld be useful. Regards,Mark. From: Fernando Gont To: "v6ops@ietf.org" =20 Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 Sent: Thursday, 7 May 2015, 7:13 Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-i= pv6-ehs-in-real-world) =20 Folks, Question to the wg: Folks keep bringing up the reasons for which operators filter IPv6 packets with EHs (the reasons have been discussed on this mailing-list a few times already). Something along these lines was present in Section 3 of but we removed that section in later revisions (prior to the wg call for adoption of this document). A number of folks have argued that we should reincorporate that section. Me, I think it would be useful, but can live without reincorporating that section... It would be nice to hear from the wg about this. Thoughts? Thanks! Best regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_1947632_122450897.1430957100739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't have a strong= opinion on whether it should be reincorporated or not, as I haven't kept u= p with that discussion.

However, = if it does get included, I think the following statement needs more clarifi= cation:

"Many IPv6 router = implementations suffer from a negative performance
   imp= act when IPv6 Extension Headers are employed."

Is this= really the case? It seems to me that this is saying that "Many IPv6 router= implementations" are inspecting EHs by default, which then means many rout= ers are vulnerable to the EH based DoSes and other issues mentioned by defa= ult.

I'd expect routers by default to have just proces= sed/forwarded IPv6 packets based on the fixed IPv6 header fields, ignoring = EHs and allowing fast path forwarding, and to only start looking at EHs if = configured to via ACLs etc.

I think the above statemen= t is effectively implying that fast path forwarding of IPv6 isn't a default= in many IPv6 router implementations, and I'd be quite surprised if that is= true, which is why I think more clarification would be useful.
Regards,
Mark.

From: Fe= rnando Gont <fernando@gont.com.ar>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Cc: "draft-ietf-v6ops-ipv6-= ehs-in-real-world@tools.ietf.org" <draft-ietf-v6ops-ipv6-ehs-in-real-wor= ld@tools.ietf.org>; V6ops Chairs <v6ops-chairs@tools.ietf.org>; Me= rike Kaeo <merike@doubleshotsecurity.com>
Sent: Thursday, 7 May 2015, 7:13
Subject: [v6ops] Next steps for IP= v6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
 =

Folks,

Question to the wg:

Folks keep bringing up the r= easons for which operators filter IPv6
packets with EHs (the reasons hav= e been discussed on this mailing-list a
few times already). Something al= ong these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01= >
but we removed that section in later revisions (prior to the wg= call for
adoption of this document).

A number of folks have argu= ed that we should reincorporate that section.
Me, I think it would be us= eful, but can live without reincorporating
that section...

It wou= ld be nice to hear from the wg about this. Thoughts?

Thanks!

= Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar<= /a> || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E = 45C7 F1C9 3945 96EE A9EF D076 FFF1



_________________________= ______________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops


<= /body> ------=_Part_1947632_122450897.1430957100739-- From nobody Wed May 6 17:29:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D833B1B2CED for ; Wed, 6 May 2015 17:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVToNgl-FFgg for ; Wed, 6 May 2015 17:29:43 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B38F1B2AA1 for ; Wed, 6 May 2015 17:29:43 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so24694769pdb.1 for ; Wed, 06 May 2015 17:29:42 -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=eJwh4qcJSOizSgATrMD+vvRGaIqtVFPCA5hr8eeqjn0=; b=pzkQAQNS62hJdB3gExh5RZ/k0S6cIyRZjq0VppPT2+puS3bYBIZThWM+SZZi74akrb 01uGZLceFQIhE2vdgNb7/QKwj4bFUWygHcborfAZvv0UO/w2fVUM3CkDNsnYbQKhtbaQ e168E8mOAK8GujsvkuORis/f2eiFMziIfDwvgTAEiz6j5dhY06OZv76a/+ZiQcGyk+nz On0kzBsNqrLSqkqLnSiVzesjQX6ymD7DhZ+srug5jF8GnMIeVi8N0v8n7O5A+gRUI5IL LAwopG8MWIyTXz2pvSTKE1cFzeW7ufkmQFT3CavTMMWwQjCSFwmoUcAmDVKGPl+AMwE9 dxYg== X-Received: by 10.70.42.104 with SMTP id n8mr2230217pdl.88.1430958582809; Wed, 06 May 2015 17:29:42 -0700 (PDT) Received: from [10.177.231.214] ([175.103.25.98]) by mx.google.com with ESMTPSA id ge4sm205049pbc.52.2015.05.06.17.29.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 17:29:41 -0700 (PDT) Message-ID: <554AB1F4.70802@gmail.com> Date: Thu, 07 May 2015 12:29:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Fernando Gont , "v6ops@ietf.org" References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 00:29:45 -0000 On 07/05/2015 12:05, Mark ZZZ Smith wrote: > Hi, > I don't have a strong opinion on whether it should be reincorporated or not, as I haven't kept up with that discussion. > However, if it does get included, I think the following statement needs more clarification: > "Many IPv6 router implementations suffer from a negative performance impact when IPv6 Extension Headers are employed." > Is this really the case? I'm guessing that a more accurate statement would be "Many IPv6 router implementations that also include some firewall functionality suffer..." but I agree that it should be better substantiated. My feeling is that describing the objective reasons why some routers behave this way is a good idea. Otherwise, the reader is left with a mystery to solve. Brian >It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many routers are vulnerable to the EH based DoSes and other issues mentioned by default. > I'd expect routers by default to have just processed/forwarded IPv6 packets based on the fixed IPv6 header fields, ignoring EHs and allowing fast path forwarding, and to only start looking at EHs if configured to via ACLs etc. > I think the above statement is effectively implying that fast path forwarding of IPv6 isn't a default in many IPv6 router implementations, and I'd be quite surprised if that is true, which is why I think more clarification would be useful. > Regards,Mark. > From: Fernando Gont > To: "v6ops@ietf.org" > Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo > Sent: Thursday, 7 May 2015, 7:13 > Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) > > Folks, > > Question to the wg: > > Folks keep bringing up the reasons for which operators filter IPv6 > packets with EHs (the reasons have been discussed on this mailing-list a > few times already). Something along these lines was present in Section > 3 of > > but we removed that section in later revisions (prior to the wg call for > adoption of this document). > > A number of folks have argued that we should reincorporate that section. > Me, I think it would be useful, but can live without reincorporating > that section... > > It would be nice to hear from the wg about this. Thoughts? > > Thanks! > > Best regards, > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed May 6 18:41:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DABF1B3038 for ; Wed, 6 May 2015 18:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvC1INhmZ3JC for ; Wed, 6 May 2015 18:41:29 -0700 (PDT) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF741B303B for ; Wed, 6 May 2015 18:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1430962888; bh=0K3BodzWz/NhJiNKEo+/LPcOIzDAMGm+ow9yMydMLZc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UEY/uvZ4Fvgac03IUz6G47IQ4vd8dZwaspPXIAPwtnVWxKQtJBmp92gLcZCay/Fzw3S6ZXtKEMTA/dvF9sKQhoCb043OGNKQaIaaJDKkDfXrnndu6ZOzFatXc2cFMKIl69ei2rxMeBkZNCasKgMmuH6jVIPKl2pma3yMBl1H8yxcxvLK9xWzBCxGYt8k5qOx/2yvGXAoDTKb7ufw2AOZaz0Ma1Ap3R+fB+Jn/oF63yOB+9n5rHMLTZ3sy1WbKOu8AlNGVHq78P32Em1z3psruuYgk9PGsBmnitrilI9omRDORIxq/hlp4ZSb0LPCxorh2Tdtxc7c6sqsNG4aZFwJFA== Received: from [98.139.215.142] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 01:41:28 -0000 Received: from [98.139.212.195] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 01:41:28 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 07 May 2015 01:41:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 373645.65828.bm@omp1004.mail.bf1.yahoo.com X-YMail-OSG: d4CYaygVM1l7WowBh3ARVFjhvZ9S1OckmJdtM.5gsbN7EpWjToRCoTC.ivHxXWG 5r9UGfLEGzOKiX0ioMb9Uk4ps.N_Jh5PnfgcE37SDulqw.Hv0uR5MT8tKaQAcvreMvW4mBxL3nF2 VkAxSGactattF_RXZt0IsnM21PuhG.TKU3hw87iASlLGSvP2k1CLkgDDZA.IoAf2ouYJNy5RCWOV ntrdZIAHbm52OhqcKG6iuCecDVWc7v7sNR1GDYag6rPKKlRgGSIDt4xib5R7lE.IcswlwXnr9xTY vIRQKPLK3N2ge57ippuSd2_h3QWhxzWmfcx9gNBYWj31JyoMxYjohJIdcoM9cjxw8BZYjP9bffN8 wD_bp9X5F7GpFTnFVUWmaqp1AgWXln0IpNjUaeTMK0vr3JW8NNH9f8J53UCnzp4wchThmWBN1iR1 LUo0pZnvbOLW3pwSPnt3a29bsqDu0CJg.12RW9WoPkMljLT6.sCqy0DKeIJe9CqMh_r.4P6cX6OW _ibSMAxbRVXGH9_3SQcvG6lspiAYkuGjrTAhPYtdX9rzI50SJ7w-- Received: by 76.13.26.159; Thu, 07 May 2015 01:41:27 +0000 Date: Thu, 7 May 2015 01:41:27 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , Fernando Gont , "v6ops@ietf.org" Message-ID: <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <554AB1F4.70802@gmail.com> References: <554AB1F4.70802@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1977001_362032071.1430962887451" Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 01:41:31 -0000 ------=_Part_1977001_362032071.1430962887451 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, From: Brian E Carpenter To: Mark ZZZ Smith ; Fernando Gont ; "v6ops@ietf.org" =20 Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 Sent: Thursday, 7 May 2015, 10:29 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6o= ps-ipv6-ehs-in-real-world) =20 On 07/05/2015 12:05, Mark ZZZ Smith wrote: > Hi, > I don't have a strong opinion on whether it should be reincorporated or n= ot, as I haven't kept up with that discussion. > However, if it does get included, I think the following statement needs m= ore clarification: > "Many IPv6 router implementations suffer from a negative performance=C2= =A0 impact when IPv6 Extension Headers are employed." > Is this really the case?=20 I'm guessing that a more accurate statement would be "Many IPv6 router implementations that also include some firewall functiona= lity suffer..." but I agree that it should be better substantiated. / I don't think I've come across a router that doesn't have some sort of fi= rewall functionality (i.e., basic packet filters/ACLs), so I'm in particula= r interested in default behaviour. / My expectation is that hardware forwarding platforms forward IPv6 packets= at the same rate out of the box, regardless of which EHs are present in th= e IPv6 packet, and would only resort to slow path processing of EHs if I co= nfigure the router to look beyond what is necessary to forward the IPv6 pac= ket. That would usually only apply to a subset of packets, specified by sou= rce and/or destination IPv6 address, meaning that the majority of IPv6 pack= ets will still be fast path forwarded. The above seems to be implying the d= efault is the opposite of my expectation in many cases.=C2=A0 / Regards,Mark.=C2=A0 My feeling is that describing the objective reasons why some routers behave this way is a good idea. Otherwise, the reader is left with a mystery to so= lve. =C2=A0 Brian >It seems to me that this is saying that "Many IPv6 router implementations"= are inspecting EHs by default, which then means many routers are vulnerable to the EH based DoSes and other issues mentioned by = default. > I'd expect routers by default to have just processed/forwarded IPv6 packe= ts based on the fixed IPv6 header fields, ignoring EHs and allowing fast pa= th forwarding, and to only start looking at EHs if configured to via ACLs e= tc. > I think the above statement is effectively implying that fast path forwar= ding of IPv6 isn't a default in many IPv6 router implementations, and I'd b= e quite surprised if that is true, which is why I think more clarification = would be useful. > Regards,Mark. >=C2=A0 =C2=A0 =C2=A0 From: Fernando Gont >=C2=A0 To: "v6ops@ietf.org" =20 > Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 >=C2=A0 Sent: Thursday, 7 May 2015, 7:13 >=C2=A0 Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-= v6ops-ipv6-ehs-in-real-world) >=C2=A0 =C2=A0=20 > Folks, >=20 > Question to the wg: >=20 > Folks keep bringing up the reasons for which operators filter IPv6 > packets with EHs (the reasons have been discussed on this mailing-list a > few times already). Something along these lines was present in Section > 3 of > > but we removed that section in later revisions (prior to the wg call for > adoption of this document). >=20 > A number of folks have argued that we should reincorporate that section. > Me, I think it would be useful, but can live without reincorporating > that section... >=20 > It would be nice to hear from the wg about this. Thoughts? >=20 > Thanks! >=20 > Best regards, >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 ------=_Part_1977001_362032071.1430962887451 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

From: Brian = E Carpenter <brian.e.carpenter@gmail.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au&= gt;; Fernando Gont <fernando@gont.com.ar>; "v6ops@ietf.org" <v6ops= @ietf.org>
Cc: "dra= ft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-ietf-v6ops-i= pv6-ehs-in-real-world@tools.ietf.org>; V6ops Chairs <v6ops-chairs@too= ls.ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>
= Sent: Thursday, 7 May 2015, 1= 0:29
Subject: Re: [v6o= ps] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-rea= l-world)

On 07/05/2015 12:05, Mark ZZZ Smith = wrote:
> Hi,
> I don't have a str= ong opinion on whether it should be reincorporated or not, as I haven't kep= t up with that discussion.
> However, if it does get i= ncluded, I think the following statement needs more clarification:
> "Many IPv6 router implementations suffer from a negative per= formance  impact when IPv6 Extension Headers are employed."
> Is this really the case?

I'm guessing that a more accurate statement would be
"= Many IPv6 router implementations that also include some firewall functional= ity suffer..."
but I agree that it should be better subst= antiated.

/ I don't think I've come across a router t= hat doesn't have some sort of firewall functionality (i.e., basic packet fi= lters/ACLs), so I'm in particular interested in default behaviour.

/ My expectation is that hardware forwarding platforms= forward IPv6 packets at the same rate out of the box, regardless of which = EHs are present in the IPv6 packet, and would only resort to slow path proc= essing of EHs if I configure the router to look beyond what is necessary to= forward the IPv6 packet. That would usually only apply to a subset of pack= ets, specified by source and/or destination IPv6 address, meaning that the = majority of IPv6 packets will still be fast path forwarded. The above seems= to be implying the default is the opposite of my expectation in many cases= . 

/ Regards,
Mark. 
=


My feeling is that describing the objective reasons why some rou= ters behave
this way is a good idea. Otherwise, the reade= r is left with a mystery to solve.

  Brian




>It seems to me that this is saying that "Many IPv6 router implem= entations" are inspecting EHs by default, which then means many
routers are vulnerable to the EH based DoSes and other issues mentio= ned by default.
> I'd expect routers by default to hav= e just processed/forwarded IPv6 packets based on the fixed IPv6 header fiel= ds, ignoring EHs and allowing fast path forwarding, and to only start looki= ng at EHs if configured to via ACLs etc.
> I think the= above statement is effectively implying that fast path forwarding of IPv6 = isn't a default in many IPv6 router implementations, and I'd be quite surpr= ised if that is true, which is why I think more clarification would be usef= ul.
> Regards,Mark.
>   = ;   From: Fernando Gont <fernando@gont.com.ar<= /a>>
>  To: "v6ops@ietf.org" <<= a shape=3D"rect" ymailto=3D"mailto:v6ops@ietf.org" href=3D"mailto:v6ops@iet= f.org">v6ops@ietf.org>
> Cc: "dra= ft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <d= raft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>; V6ops Chairs= <v6ops-chairs@tools.ietf.org>= ; Merike Kaeo <merike@doubleshotse= curity.com>
>  Sent: Thursday, 7 May 2015= , 7:13
>  Subject: [v6ops] Next steps for IPv6 EH= s in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
>   
> Folks,
> > Question to the wg:
>
> Folks keep bringing up the reasons for which operators filte= r IPv6
> packets with EHs (the reasons have been discu= ssed on this mailing-list a
> few times already). Some= thing along these lines was present in Section
> 3 of<= br clear=3D"none">> <https:/= /tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>
> but we removed that section in later revisions (prior t= o the wg call for
> adoption of this document).
>
> A number of folks have argued that= we should reincorporate that section.
> Me, I think i= t would be useful, but can live without reincorporating
&= gt; that section...
>
> It would= be nice to hear from the wg about this. Thoughts?
> <= br clear=3D"none">> Thanks!
>
&g= t; Best regards,
>
>
>
> ____________________________________= ___________
> v6ops mailing list
>= ; v6ops@ietf.org
> https://= www.ietf.org/mailman/listinfo/v6ops
>


------=_Part_1977001_362032071.1430962887451-- From nobody Wed May 6 22:53:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964511ACEA7 for ; Wed, 6 May 2015 22:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UQx5di1kfPv for ; Wed, 6 May 2015 22:53:55 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 34FEB1ACEAA for ; Wed, 6 May 2015 22:53:53 -0700 (PDT) Received: (qmail 48073 invoked from network); 7 May 2015 05:53:51 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 May 2015 05:53:51 -0000 Date: Thu, 07 May 2015 07:53:51 +0200 (CEST) Message-Id: <20150507.075351.74706970.sthaug@nethelp.no> To: markzzzsmith@yahoo.com.au From: sthaug@nethelp.no In-Reply-To: <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> References: <554AB1F4.70802@gmail.com> <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.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 Archived-At: Cc: v6ops@ietf.org, merike@doubleshotsecurity.com, fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:53:57 -0000 > My expectation is that hardware forwarding platforms forward IPv6 > packets at the same rate out of the box, regardless of which EHs are > present in the IPv6 packet, and would only resort to slow path > processing of EHs if I configure the router to look beyond what is > necessary to forward the IPv6 packet. Note that there are hardware forwarding platforms which don't have a "slow path". A packet is either forwarded in hardware, or it is not forwarded at all (i.e. dropped). Steinar Haug, AS 2116 From nobody Thu May 7 00:16:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB91B2A64 for ; Thu, 7 May 2015 00:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw5my7BGRkQv for ; Thu, 7 May 2015 00:16:29 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FEA1B2A59 for ; Thu, 7 May 2015 00:16:28 -0700 (PDT) Received: by pdea3 with SMTP id a3so33401717pde.3 for ; Thu, 07 May 2015 00:16:28 -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=hL2iFXErIoPIOmgg48Z9bZldYBgQDbi42mVyKtA3DyM=; b=Szd1SJWrKxJ4KBCPIfjSvCr7glI2JZL9Y+DS4XVJvz7/zOhNeniB9Gs38f9+GCnhN9 TQroAfcfkk9aYYjaIZk3O51nfhQWX7n5N9ZQQrgR3wYCiTbg4IL3rDriqlWsk8faEGZV YGbSepXnTEniYEoxodKGHoH53I9Sc2DJAKcnnod8RLNz2EtB7jnMNpbkv9Ix6ob4MeRk As9Q+tSI3OmlgqkX26MLOXYRP4IMQG6eQn8o375Es+QGTS3hFB3f8yqulSsbBPUbect7 iRAqDEzyB9BKPjxHYJHx+/1ZiPJ/Y/AR/iuRZOZIfKl8jvqLEn8mH6ITziFryXPOYVo/ gheA== X-Received: by 10.70.138.70 with SMTP id qo6mr4329675pdb.163.1430982988644; Thu, 07 May 2015 00:16:28 -0700 (PDT) Received: from [10.177.231.214] ([175.103.25.98]) by mx.google.com with ESMTPSA id d3sm1093675pbu.93.2015.05.07.00.16.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 00:16:27 -0700 (PDT) Message-ID: <554B1149.5030005@gmail.com> Date: Thu, 07 May 2015 19:16:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Fernando Gont , "v6ops@ietf.org" References: <554AB1F4.70802@gmail.com> <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:16:31 -0000 Hi Mark, On 07/05/2015 13:41, Mark ZZZ Smith wrote: > Hi, > From: Brian E Carpenter > To: Mark ZZZ Smith ; Fernando Gont ; "v6ops@ietf.org" > Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo > Sent: Thursday, 7 May 2015, 10:29 > Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) > > On 07/05/2015 12:05, Mark ZZZ Smith wrote: >> Hi, >> I don't have a strong opinion on whether it should be reincorporated or not, as I haven't kept up with that discussion. >> However, if it does get included, I think the following statement needs more clarification: >> "Many IPv6 router implementations suffer from a negative performance impact when IPv6 Extension Headers are employed." >> Is this really the case? > > I'm guessing that a more accurate statement would be > "Many IPv6 router implementations that also include some firewall functionality suffer..." > but I agree that it should be better substantiated. > > / I don't think I've come across a router that doesn't have some sort of firewall functionality (i.e., basic packet filters/ACLs), But there's a big difference between those two. ACLs = just look at the addresses basic packet filters = look at the 5-tuple, and the whole problem here is that extracting the 5-tuple becomes hard with EH present, and impossible with unknown EH present. But I agree that the default is what needs to be right (see RFC 7045 again). Brian > so I'm in particular interested in default behaviour. > / My expectation is that hardware forwarding platforms forward IPv6 packets at the same rate out of the box, regardless of which EHs are present in the IPv6 packet, and would only resort to slow path processing of EHs if I configure the router to look beyond what is necessary to forward the IPv6 packet. That would usually only apply to a subset of packets, specified by source and/or destination IPv6 address, meaning that the majority of IPv6 packets will still be fast path forwarded. The above seems to be implying the default is the opposite of my expectation in many cases. > / Regards,Mark. > > > My feeling is that describing the objective reasons why some routers behave > this way is a good idea. Otherwise, the reader is left with a mystery to solve. > > > Brian > > > >> It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many > routers are vulnerable to the EH based DoSes and other issues mentioned by default. >> I'd expect routers by default to have just processed/forwarded IPv6 packets based on the fixed IPv6 header fields, ignoring EHs and allowing fast path forwarding, and to only start looking at EHs if configured to via ACLs etc. >> I think the above statement is effectively implying that fast path forwarding of IPv6 isn't a default in many IPv6 router implementations, and I'd be quite surprised if that is true, which is why I think more clarification would be useful. >> Regards,Mark. >> From: Fernando Gont >> To: "v6ops@ietf.org" >> Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo >> Sent: Thursday, 7 May 2015, 7:13 >> Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) >> >> Folks, >> >> Question to the wg: >> >> Folks keep bringing up the reasons for which operators filter IPv6 >> packets with EHs (the reasons have been discussed on this mailing-list a >> few times already). Something along these lines was present in Section >> 3 of >> >> but we removed that section in later revisions (prior to the wg call for >> adoption of this document). >> >> A number of folks have argued that we should reincorporate that section. >> Me, I think it would be useful, but can live without reincorporating >> that section... >> >> It would be nice to hear from the wg about this. Thoughts? >> >> Thanks! >> >> Best regards, >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > From nobody Thu May 7 00:45:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDB1B2AAD for ; Thu, 7 May 2015 00:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvEX1bs3mF3B for ; Thu, 7 May 2015 00:45:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CD51B2A99 for ; Thu, 7 May 2015 00:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15345; q=dns/txt; s=iport; t=1430984744; x=1432194344; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wShD6m48aSO/LspsiloqBeiRAFsp12bPyLf3Z382ovA=; b=PbmFP8xqSMBpJPXRvbnKndq0bGSMlsmHnkxFNw/de5FkCUlkO/A0blMv XgikVzPLr//+OrD2YqawLIlKLQKHbRo2psolFD1V+wQNfORec8fdsqQ84 y8TbFfs3YCiajqEr2k/zsFcDsl5707TTAY6Co1cOWHfZ/bUixAQGHr2d9 I=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQAMF0tV/4YNJK1SCoJFR1ReBoMYtiaNbQEJhgUCgSdMAQEBAQEBgQuEIAEBAQMBAQEBGgZLCwULAgEIEQQBAQEnAwICJwsUCQgCBA4FDogJAwoIDbFJky8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs5gk2BWzMmBAYBgmgvgRYFhTwKijGCMYF9gTtchHWBT49QhmkjgWZTgT1vgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,383,1427760000"; d="asc'?scan'208,217";a="417755041" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 07 May 2015 07:45:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t477jhtC016032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 07:45:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.147]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 7 May 2015 02:45:43 -0500 From: "Fred Baker (fred)" To: Mark ZZZ Smith Thread-Topic: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) Thread-Index: AQHQiJnR15BNHQW4Aku+NajzAlJ9uQ== Date: Thu, 7 May 2015 07:45:42 +0000 Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.254.251] Content-Type: multipart/signed; boundary="Apple-Mail=_E7239FE9-C510-46E8-A8EE-6DF8BCD918D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , V6ops Chairs , Fernando Gont , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:45:47 -0000 --Apple-Mail=_E7239FE9-C510-46E8-A8EE-6DF8BCD918D9 Content-Type: multipart/alternative; boundary="Apple-Mail=_734CB4AE-B601-46EA-A698-F64098ADDC40" --Apple-Mail=_734CB4AE-B601-46EA-A698-F64098ADDC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 7, 2015, at 12:05 PM, Mark ZZZ Smith = wrote: >=20 > Hi, >=20 > I don't have a strong opinion on whether it should be reincorporated = or not, as I haven't kept up with that discussion. >=20 > However, if it does get included, I think the following statement = needs more clarification: >=20 > "Many IPv6 router implementations suffer from a negative performance > impact when IPv6 Extension Headers are employed." >=20 > Is this really the case? It seems to me that this is saying that "Many = IPv6 router implementations" are inspecting EHs by default, which then = means many routers are vulnerable to the EH based DoSes and other issues = mentioned by default. If it is the case, I think we need a list of those routers that by = default violate RFC 2460 by inspecting past the HbH header when they are = not the destination of the packet. What I have been trying to get Fernando to do is identify under what = conditions that might be true, rather than paint all equipment from all = vendors under all conditions with slime. If the router has a filter = (ACL) that forces it to parse the headers to find a TCP header, and the = parsing is dumped to a slower path, that would be an example, and would = be a valid example to bring out. But I don=E2=80=99t accept sliming all = equipment from all vendors under all circumstances. It=E2=80=99s not the = case. > I'd expect routers by default to have just processed/forwarded IPv6 = packets based on the fixed IPv6 header fields, ignoring EHs and allowing = fast path forwarding, and to only start looking at EHs if configured to = via ACLs etc. >=20 > I think the above statement is effectively implying that fast path = forwarding of IPv6 isn't a default in many IPv6 router implementations, = and I'd be quite surprised if that is true, which is why I think more = clarification would be useful. >=20 > Regards, > Mark. >=20 > From: Fernando Gont > To: "v6ops@ietf.org" > Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" = ; V6ops Chairs = ; Merike Kaeo = > Sent: Thursday, 7 May 2015, 7:13 > Subject: [v6ops] Next steps for IPv6 EHs in Real World = (draft-ietf-v6ops-ipv6-ehs-in-real-world) >=20 > Folks, >=20 > Question to the wg: >=20 > Folks keep bringing up the reasons for which operators filter IPv6 > packets with EHs (the reasons have been discussed on this mailing-list = a > few times already). Something along these lines was present in Section > 3 of > = > > but we removed that section in later revisions (prior to the wg call = for > adoption of this document). >=20 > A number of folks have argued that we should reincorporate that = section. > Me, I think it would be useful, but can live without reincorporating > that section... >=20 > It would be nice to hear from the wg about this. Thoughts? >=20 > Thanks! >=20 > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || = fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_734CB4AE-B601-46EA-A698-F64098ADDC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:

Hi,

I don't have a strong = opinion on whether it should be reincorporated or not, as I haven't kept = up with that discussion.

However, if it does = get included, I think the following statement needs more = clarification:

"Many IPv6 = router implementations suffer from a negative performance
   impact when IPv6 Extension Headers are = employed."

Is this really the case? It seems to me that this is saying = that "Many IPv6 router implementations" are inspecting EHs by default, = which then means many routers are vulnerable to the EH based DoSes and = other issues mentioned by = default.

If it is the case, I think we need a list of those routers = that by default violate RFC 2460 by inspecting past the HbH header when = they are not the destination of the packet.

What I have been trying to get Fernando to do is identify = under what conditions that might be true, rather than paint all = equipment from all vendors under all conditions with slime. If the = router has a filter (ACL) that forces it to parse the headers to find a = TCP header, and the parsing is dumped to a slower path, that would be an = example, and would be a valid example to bring out. But I don=E2=80=99t = accept sliming all equipment from all vendors under all circumstances. = It=E2=80=99s not the case.

I'd expect routers by default to have just = processed/forwarded IPv6 packets based on the fixed IPv6 header fields, = ignoring EHs and allowing fast path forwarding, and to only start = looking at EHs if configured to via ACLs etc.

I= think the above statement is effectively implying that fast path = forwarding of IPv6 isn't a default in many IPv6 router implementations, = and I'd be quite surprised if that is true, which is why I think more = clarification would be useful.

Regards,
Mark.

From: Fernando Gont <fernando@gont.com.ar>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" = <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>;= V6ops Chairs <v6ops-chairs@tools.ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>
Sent: = Thursday, 7 May 2015, 7:13
Subject: [v6ops] Next steps for IPv6 EHs in Real = World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
 =

Folks,

Question to the wg:

Folks keep bringing up the reasons for which operators filter = IPv6
packets with EHs (the reasons have been discussed on = this mailing-list a
few times already). Something along = these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-w= orld-01>
but we removed that section in later = revisions (prior to the wg call for
adoption of this = document).

A number of folks have argued = that we should reincorporate that section.
Me, I think it = would be useful, but can live without reincorporating
that = section...

It would be nice to hear from = the wg about this. Thoughts?

Thanks!

Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar = || fgont@si6networks.com
PGP Fingerprint: 7809 = 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



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


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

= --Apple-Mail=_734CB4AE-B601-46EA-A698-F64098ADDC40-- --Apple-Mail=_E7239FE9-C510-46E8-A8EE-6DF8BCD918D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVUsYIp9ieig10VPpAQKlcQgAmzy6RaTP4g8Kwr2IIMnHxyN8L//Gvu2A /5aCTGGeaBmkP01bFMthpG9MXqnw2ZTPeiVfWPg9YEEolie2JLAyJd2b2Y1tMoLU mMY0YM29F0slMsQmX/jToq8SN9BryeuO2Xap7ghCC+hw8xvn2XGIcYiCINp0FCeW BGslDQnPv6pWauEyQsoCGvPc0NjtIdK1c5VJU94Br348LsROAE82AvyduIK67wvf 09YSQzwbEQGzZiKOmqM/M1qMW/03BUyeLS16Q1KJE9QdE56A3v2c2LK/hcm0neGu hW3HcqOzxv9GTzj53QbM1VZc2T+jgbwzr0ScdqoOxYyOSzWGyNxoPA== =bc6b -----END PGP SIGNATURE----- --Apple-Mail=_E7239FE9-C510-46E8-A8EE-6DF8BCD918D9-- From nobody Thu May 7 00:58:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719701B2D60 for ; Thu, 7 May 2015 00:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryCCm6VnX-83 for ; Thu, 7 May 2015 00:58:56 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id B460F1B2CC4 for ; Thu, 7 May 2015 00:58:55 -0700 (PDT) Received: (qmail 50622 invoked from network); 7 May 2015 07:58:53 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 May 2015 07:58:53 -0000 Date: Thu, 07 May 2015 09:58:53 +0200 (CEST) Message-Id: <20150507.095853.104079668.sthaug@nethelp.no> To: fred@cisco.com From: sthaug@nethelp.no In-Reply-To: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-2 Content-Transfer-Encoding: 7bit Archived-At: Cc: merike@doubleshotsecurity.com, v6ops@ietf.org, fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:58:58 -0000 > > "Many IPv6 router implementations suffer from a negative performance > > impact when IPv6 Extension Headers are employed." > > > > Is this really the case? It seems to me that this is saying that "Many IPv6 router implementations" are inspecting EHs by default, which then means many routers are vulnerable to the EH based DoSes and other issues mentioned by default. > > If it is the case, I think we need a list of those routers that by default violate RFC 2460 by inspecting past the HbH header when they are not the destination of the packet. > > What I have been trying to get Fernando to do is identify under what conditions that might be true, rather than paint all equipment from all vendors under all conditions with slime. If the router has a filter (ACL) that forces it to parse the headers to find a TCP header, and the parsing is dumped to a slower path, that would be an example, and would be a valid example to bring out. But I don$,1ry(Bt accept sliming all equipment from all vendors under all circumstances. It$,1ry(Bs not the case. Having argued for the need to inspect/skip past EHs to find TCP/UDP headers: In my experience this is very much *explicitly configured* behavior, not something the routers do by default. Steinar Haug, AS 2116 From nobody Thu May 7 01:20:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33971AD079 for ; Thu, 7 May 2015 01:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqayGOU8A5-6 for ; Thu, 7 May 2015 01:20:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4591ACDCA for ; Thu, 7 May 2015 01:20:26 -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 t478K2bo030469; Thu, 7 May 2015 09:20:02 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t478K2bo030469 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1430986803; bh=oQMZJVD8taNo0WyRFckxA98WVmw=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=08i6pZ9v1nUkAJFf7B62sSki8tnLMv1FGJNQKCeB4UZuC4acZxjOWId9DHb3Jeyx3 0j2BgkZK+bDESOrRNjqM7agcORZp0Uj4wq4tEDZ+CoTO9kHT+L/eKZAD1pO81KQtQb vPxBOgptqtkz8aTvF37IxRjr15NfsrKV7ey0HXdE= 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 r469K21206302148pe ret-id none; Thu, 07 May 2015 09:20:03 +0100 Received: from [10.1.11.13] ([194.82.140.195]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t478Jxol032472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2015 09:19:59 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D8B7B7B0-C253-42A6-8C14-487C2618D6E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Tim Chown In-Reply-To: Date: Thu, 7 May 2015 09:20:00 +0100 Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.2098) X-smtpf-Report: sid=r469K2120630214800; tid=r469K21206302148pe; client=relay,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t478K2bo030469 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: Merike Kaeo , "v6ops@ietf.org" , Fernando Gont , "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:20:30 -0000 --Apple-Mail=_D8B7B7B0-C253-42A6-8C14-487C2618D6E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_055D86E6-3A76-475F-8C24-3E190E4B4873" --Apple-Mail=_055D86E6-3A76-475F-8C24-3E190E4B4873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 7 May 2015, at 08:45, Fred Baker (fred) wrote: >=20 >=20 >> On May 7, 2015, at 12:05 PM, Mark ZZZ Smith = > wrote: >>=20 >> Hi, >>=20 >> I don't have a strong opinion on whether it should be reincorporated = or not, as I haven't kept up with that discussion. >>=20 >> However, if it does get included, I think the following statement = needs more clarification: >>=20 >> "Many IPv6 router implementations suffer from a negative performance >> impact when IPv6 Extension Headers are employed." >>=20 >> Is this really the case? It seems to me that this is saying that = "Many IPv6 router implementations" are inspecting EHs by default, which = then means many routers are vulnerable to the EH based DoSes and other = issues mentioned by default. >=20 > If it is the case, I think we need a list of those routers that by = default violate RFC 2460 by inspecting past the HbH header when they are = not the destination of the packet. >=20 > What I have been trying to get Fernando to do is identify under what = conditions that might be true, rather than paint all equipment from all = vendors under all conditions with slime. If the router has a filter = (ACL) that forces it to parse the headers to find a TCP header, and the = parsing is dumped to a slower path, that would be an example, and would = be a valid example to bring out. But I don=E2=80=99t accept sliming all = equipment from all vendors under all circumstances. It=E2=80=99s not the = case. The original point of the draft, which has perhaps been lost somewhat as = discussion has drifted, was to handwave to an observable problem, to = implicitly note there was an impact on applications/protocols using EHs, = and to encourage more measurement/investigation of the problem. I think the discussion we=E2=80=99re on now would be better put into a = follow-up text, so we can ship the original problem statement. I suspect = the follow-up will be more heavily debated, witness the (lack of) = progression of = https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 = , but my = preference would be to stop tinkering, to ship, and focus on a new = document. Tim >=20 >> I'd expect routers by default to have just processed/forwarded IPv6 = packets based on the fixed IPv6 header fields, ignoring EHs and allowing = fast path forwarding, and to only start looking at EHs if configured to = via ACLs etc. >>=20 >> I think the above statement is effectively implying that fast path = forwarding of IPv6 isn't a default in many IPv6 router implementations, = and I'd be quite surprised if that is true, which is why I think more = clarification would be useful. >>=20 >> Regards, >> Mark. >>=20 >> From: Fernando Gont > >> To: "v6ops@ietf.org " > >> Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org = " = >; V6ops = Chairs >; Merike Kaeo = > >> Sent: Thursday, 7 May 2015, 7:13 >> Subject: [v6ops] Next steps for IPv6 EHs in Real World = (draft-ietf-v6ops-ipv6-ehs-in-real-world) >>=20 >> Folks, >>=20 >> Question to the wg: >>=20 >> Folks keep bringing up the reasons for which operators filter IPv6 >> packets with EHs (the reasons have been discussed on this = mailing-list a >> few times already). Something along these lines was present in = Section >> 3 of >> = > >> but we removed that section in later revisions (prior to the wg call = for >> adoption of this document). >>=20 >> A number of folks have argued that we should reincorporate that = section. >> Me, I think it would be useful, but can live without reincorporating >> that section... >>=20 >> It would be nice to hear from the wg about this. Thoughts? >>=20 >> Thanks! >>=20 >> Best regards, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || = fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops = >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_055D86E6-3A76-475F-8C24-3E190E4B4873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

On 7 May 2015, at 08:45, Fred = Baker (fred) <fred@cisco.com> wrote:


On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:

Hi,

I don't have a strong = opinion on whether it should be reincorporated or not, as I haven't kept = up with that discussion.

However, if it does = get included, I think the following statement needs more = clarification:

"Many IPv6 = router implementations suffer from a negative performance
   impact when IPv6 Extension Headers are = employed."

Is this really the case? It seems to me that this is saying = that "Many IPv6 router implementations" are inspecting EHs by default, = which then means many routers are vulnerable to the EH based DoSes and = other issues mentioned by = default.

If it is the case, I think we need a list of those routers = that by default violate RFC 2460 by inspecting past the HbH header when = they are not the destination of the packet.

What I have been trying to get Fernando to do is identify = under what conditions that might be true, rather than paint all = equipment from all vendors under all conditions with slime. If the = router has a filter (ACL) that forces it to parse the headers to find a = TCP header, and the parsing is dumped to a slower path, that would be an = example, and would be a valid example to bring out. But I don=E2=80=99t = accept sliming all equipment from all vendors under all circumstances. = It=E2=80=99s not the = case.

The original point of the draft, which has perhaps been = lost somewhat as discussion has drifted, was to handwave to an = observable problem, to implicitly note there was an impact on = applications/protocols using EHs, and to encourage more = measurement/investigation of the problem.

I think the discussion we=E2=80=99re on now would = be better put into a follow-up text, so we can ship the original problem = statement. I suspect the follow-up will be more heavily debated, witness = the (lack of) progression of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02,= but my preference would be to stop tinkering, to ship, and focus on a = new document.

Tim


I'd expect routers by default to have just = processed/forwarded IPv6 packets based on the fixed IPv6 header fields, = ignoring EHs and allowing fast path forwarding, and to only start = looking at EHs if configured to via ACLs etc.

I= think the above statement is effectively implying that fast path = forwarding of IPv6 isn't a default in many IPv6 router implementations, = and I'd be quite surprised if that is true, which is why I think more = clarification would be useful.

Regards,
Mark.

From: Fernando Gont <fernando@gont.com.ar>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" = <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>;= V6ops Chairs <v6ops-chairs@tools.ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>
Sent: = Thursday, 7 May 2015, 7:13
Subject: [v6ops] Next steps for IPv6 EHs in Real = World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
 =

Folks,

Question to the wg:

Folks keep bringing up the reasons for which operators filter = IPv6
packets with EHs (the reasons have been discussed on = this mailing-list a
few times already). Something along = these lines was present in Section
3 of
<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-w= orld-01>
but we removed that section in later = revisions (prior to the wg call for
adoption of this = document).

A number of folks have argued = that we should reincorporate that section.
Me, I think it = would be useful, but can live without reincorporating
that = section...

It would be nice to hear from = the wg about this. Thoughts?

Thanks!

Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar = || fgont@si6networks.com
PGP Fingerprint: 7809 = 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



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


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


= --Apple-Mail=_055D86E6-3A76-475F-8C24-3E190E4B4873-- --Apple-Mail=_D8B7B7B0-C253-42A6-8C14-487C2618D6E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVSyAwAAoJEFoq8u2Gfpfe+BcH/ittJdGX/Aq6oI3eXK0H4mq/ 4g7UD6dIKeBviSBEqKw4O8WvJpAGpZJAJ1nkuUfqEDm2U+hKVj+/aPrX8VKW7YKH ubQzcufM9VGS0Thb3kAanxTpF4wWTGrjJzw4FZp7MZrISw33e6VDGmQiQuxyjR6U pUxgWjhnNJUTRYLO3zHAacQXcb6fpF2vLAKvtzQU6T20l3WBr6YiqPXzYezaETCg hHiueOMFU98FR4euCuhhF2T25PDhxlwYq/HaIjXNRHPpQzaEggaatJjqMbMEFuMJ BpnydQSfnZKJ2J0vV+IbENb3M8Djwp58SmVacwo5if+6VrtLyfVs66IQkNJhxDg= =wHTm -----END PGP SIGNATURE----- --Apple-Mail=_D8B7B7B0-C253-42A6-8C14-487C2618D6E6-- From nobody Thu May 7 03:49:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AE31A1B4A for ; Thu, 7 May 2015 03:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIFuPLyJxgE4 for ; Thu, 7 May 2015 03:49:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B5D1A00DB for ; Thu, 7 May 2015 03:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1430995794; x=1432205394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xKRwJuSiVemdDfZ2il6KUiJFsPVhGvIAaq8pcXQqFGE=; b=ja9I76Ynt0d05hOZZwOwO5NB4O3YVSY7Zw45PBc7spApOoF926v2R4mB qKjzAQoQS9GdivMvMKCetE2jYk1b0bYLBwYLB79fgPV1/xUO2WkEk4JBR uORIZpTxYQVk1BieBuKl7YNvKwsE2kaBaJ0xZXTJJEct96R4PECi+2BBt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CzBAD5QktV/4wNJK1cgwxUXgaDGMI/CYFWhgUCHIEROBQBAQEBAQEBgQqEIQEBBB0GEToLEAIBCBoCJgICAjAVEAIEAQ0FiCwNsg2TLAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKGIRSMweCaIFFBZIohBSGRJY5I4I5gT1vgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="147906454" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 May 2015 10:49:53 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t47Anr5w023674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 10:49:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.104]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 7 May 2015 05:49:53 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "v6ops@ietf.org" Thread-Topic: Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) Thread-Index: AQHQiEGH+yaFV1SCaUixeBGEsoGRGp1wy/OA Date: Thu, 7 May 2015 10:49:52 +0000 Message-ID: References: <554A83E3.4050503@gont.com.ar> In-Reply-To: <554A83E3.4050503@gont.com.ar> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.68] Content-Type: text/plain; charset="utf-8" Content-ID: <22D2752B9C92F84F9B7B28FBB63F3745@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 10:49:56 -0000 SSB3b3VsZCBrZWVwIHRoZSAncmVhc29ucy9leHBsYW5hdGlvbnMnIGluIGEgc2VwYXJhdGUgZG9j dW1lbnQgYW5kIGtlZXANCnRoZSAnZmFjdHMvbWVhc3VyZW1lbnRzJyBpbiB0aGlzIEktRC4NCg0K T24gNi8wNS8xNSAyMzoxMywgIkZlcm5hbmRvIEdvbnQiIDxmZXJuYW5kb0Bnb250LmNvbS5hcj4g d3JvdGU6DQoNCj5Gb2xrcywNCj4NCj5RdWVzdGlvbiB0byB0aGUgd2c6DQo+DQo+Rm9sa3Mga2Vl cCBicmluZ2luZyB1cCB0aGUgcmVhc29ucyBmb3Igd2hpY2ggb3BlcmF0b3JzIGZpbHRlciBJUHY2 DQo+cGFja2V0cyB3aXRoIEVIcyAodGhlIHJlYXNvbnMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBvbiB0 aGlzIG1haWxpbmctbGlzdCBhDQo+ZmV3IHRpbWVzIGFscmVhZHkpLiBTb21ldGhpbmcgYWxvbmcg dGhlc2UgbGluZXMgd2FzIHByZXNlbnQgaW4gU2VjdGlvbg0KPjMgb2YNCj48aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC0w MT4NCj5idXQgd2UgcmVtb3ZlZCB0aGF0IHNlY3Rpb24gaW4gbGF0ZXIgcmV2aXNpb25zIChwcmlv ciB0byB0aGUgd2cgY2FsbCBmb3INCj5hZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50KS4NCj4NCj5B IG51bWJlciBvZiBmb2xrcyBoYXZlIGFyZ3VlZCB0aGF0IHdlIHNob3VsZCByZWluY29ycG9yYXRl IHRoYXQgc2VjdGlvbi4NCj5NZSwgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwsIGJ1dCBjYW4g bGl2ZSB3aXRob3V0IHJlaW5jb3Jwb3JhdGluZw0KPnRoYXQgc2VjdGlvbi4uLg0KPg0KPkl0IHdv dWxkIGJlIG5pY2UgdG8gaGVhciBmcm9tIHRoZSB3ZyBhYm91dCB0aGlzLiBUaG91Z2h0cz8NCj4N Cj5UaGFua3MhDQo+DQo+QmVzdCByZWdhcmRzLA0KPi0tIA0KPkZlcm5hbmRvIEdvbnQNCj5lLW1h aWw6IGZlcm5hbmRvQGdvbnQuY29tLmFyIHx8IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KPlBHUCBG aW5nZXJwcmludDogNzgwOSA4NEY1IDMyMkUgNDVDNyBGMUM5IDM5NDUgOTZFRSBBOUVGIEQwNzYg RkZGMQ0KPg0KPg0KPg0KDQo= From nobody Thu May 7 04:26:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF051A854D for ; Thu, 7 May 2015 04:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mcKOyl-8LD1 for ; Thu, 7 May 2015 04:26:12 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0265E1A7D80 for ; Thu, 7 May 2015 04:26:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6386BA2; Thu, 7 May 2015 13:26:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1430997964; bh=jvHyzYZfE3Rb090gLBV/WjvIPo1a/TzfjOgTBcotmRM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e0hfBL0/NJsLvXllczlWQvR2i71bKvpjA2gp+Ons2rnlujudN8FlNrfu/GfEnhPSj v51y3mDdjgWazCWxBMCddc7LLnY27FvVbCjkhbie8Pp70wF/uVJKNT9CjH9hgvFZsr Rm4xycMKVIgttP/OorFBEMjsTSvcgPVM/G2kybBQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5C58FA1; Thu, 7 May 2015 13:26:04 +0200 (CEST) Date: Thu, 7 May 2015 13:26:04 +0200 (CEST) From: Mikael Abrahamsson To: sthaug@nethelp.no In-Reply-To: <20150507.095853.104079668.sthaug@nethelp.no> Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 11:26:14 -0000 On Thu, 7 May 2015, sthaug@nethelp.no wrote: > Having argued for the need to inspect/skip past EHs to find TCP/UDP > headers: In my experience this is very much *explicitly configured* > behavior, not something the routers do by default. As stated before, all Cisco 6500/7600 with SUP720/RSP720 will as far as I know, slow-path packets with fragmentation header by default. As far as I know, fragmentation header is an extension header. As per what Fernando wrote again initially, I still object to the word "filter" being used. Filter for me (still) conveys intent, which as far as I can tell, at least in the above case isn't the case. So we need to be very much granular in our language. All extension headers are most likely not treated equaly, the length of the header chain might change how they are treated etc. So basically, I want the entire document changed so that "filtering" is replaced by "being dropped" or similar wording that doesn't convey intent on behalf of the people running the device. So, for instance, I would like the abstract to be changed to: Abstract This document presents real-world data regarding the extent to which packets with IPv6 extension headers are dropped in the Internet (as measured in August 2014), and where in the network such drops occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the packet handling of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community. and just to be clear. I want EHs to work on the Internet. I support this document in all other aspects. I am just tired of all blame being historically put on "stupid ISPs" or "stupid administrators" who intentionally configure their equipment to do bad things, like drop "all ICMP packets", when in at least some cases, the ICMPs were not making it to the destination because of load balancers or ECMP routing would send the ICMP packet to the wrong place. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu May 7 04:54:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C51A8765 for ; Thu, 7 May 2015 04:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omj6AwZOy6XO for ; Thu, 7 May 2015 04:53:57 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5E81A8757 for ; Thu, 7 May 2015 04:53:57 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 09781DA0098; Thu, 7 May 2015 11:53:57 +0000 (UTC) Received: from [10.0.20.206] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 7 May 2015 04:53:56 -0700 References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> MIME-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <155B08CF-3D07-4AE5-8F31-230354C9EFA1@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Thu, 7 May 2015 07:53:55 -0400 To: Mikael Abrahamsson X-Originating-IP: [71.233.43.215] Archived-At: Cc: "" , "" , "" , "" Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 11:53:59 -0000 On May 7, 2015, at 7:26 AM, Mikael Abrahamsson wrote: >=20 > So basically, I want the entire document changed so that "filtering" is re= placed by "being dropped" or similar wording that doesn't convey intent on b= ehalf of the people running the device. +1!= From nobody Thu May 7 05:09:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE9B1A88BC for ; Thu, 7 May 2015 05:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWslsukruPWJ for ; Thu, 7 May 2015 05:09:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632131A88A6 for ; Thu, 7 May 2015 05:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4590; q=dns/txt; s=iport; t=1431000542; x=1432210142; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jdooCarvDNoJM36cUqDOULY+z4gFr9d6cPi+Da8/syw=; b=WcefItcKWnd4kahWvsjioV7GdDwuGKVGu7/w0kfbwDv70CM1jNgZUrA8 2SISB8+GNzZfl8y0ou+8y/XoDqsmoF2+No0+VPNuvXYaoyugjj7IAZcZ2 6SK62idoWAFzsb7GmCSONGVr9m05AcjDmLeptRJQwlX6JdlJRJrrc+vol 4=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxBAAGVUtV/5tdJa1cgwxUXgaDGMI/CYFahgECgS04FAEBAQEBAQGBCoQgAQEBAwEjVgULAgEIDgoqAgIyJQIEDgUOC4gLCA2yIpMtAQEBAQEBAQEBAQEBAQEBAQEBGos5hQUHgmgvgRYFkiiBfYE7hyCBJIZOjkcjgWYfHxWBPW8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="asc'?scan'208";a="147834621" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 07 May 2015 12:09:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t47C91mu009917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 12:09:01 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.147]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 7 May 2015 07:09:01 -0500 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) Thread-Index: AQHQiL6a15BNHQW4Aku+NajzAlJ9uQ== Date: Thu, 7 May 2015 12:09:01 +0000 Message-ID: <416464EE-40E7-4B95-9EDD-FD73918094A3@cisco.com> References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.254.251] Content-Type: multipart/signed; boundary="Apple-Mail=_59226FB3-2B27-4E95-91BE-9B67EA93FA82"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org WG" , V6ops Chairs , "fernando@gont.com.ar" Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 12:09:05 -0000 --Apple-Mail=_59226FB3-2B27-4E95-91BE-9B67EA93FA82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 7, 2015, at 11:26 PM, Mikael Abrahamsson = wrote: >=20 > As stated before, all Cisco 6500/7600 with SUP720/RSP720 will as far = as I know, slow-path packets with fragmentation header by default. As = far as I know, fragmentation header is an extension header. Even when it is not addressed to the router and no ACL is involved? I = think you=E2=80=99ll find that the question doesn=E2=80=99t come up = unless it is required to process the header chain. Fernando=E2=80=99s statement "Many IPv6 router implementations suffer from a negative = performance impact when IPv6 Extension Headers are employed.=E2=80=9D is hard to read as other than a blanket statement - "add an extension = header, take the slow path". That statement means that routers are = processing extension headers beyond the hop-by-hop header in every = circumstance. I=E2=80=99m sorry, I can=E2=80=99t imagine why they would. = In some cases (firewall functionality, ACLs, and packets addressed to = the router), yes, but not every packet forwarded; doing so would be a = violation of RFC 2460 and would be a waste of effort. That is what I = have objected to. I would like to see an accurate statement, if there is = going to be one. I=E2=80=99ll note Tim Chown=E2=80=99s comment in = passing. SUP720 is, by the way, beyond its shelf life. That doesn=E2=80=99t mean = they aren=E2=80=99t out there, of course, but they=E2=80=99re not = current product. On SUP720 extension header processing: per = http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html, dated 2006: "Because the Hop-by-Hop EH must be fully processed, it is handled by the = CPU and the IPv6 traffic that contains a Hop-by-Hop EH will go through = the slow forwarding path. This rule applies to all vendors. Hardware = forwarding is not feasible in this case." = http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html#wp9000161 (same paper, table 2), states that = IPv6 with EH other than Hop-by-Hop, in the presence of an ACL looking at = higher layer headers, is processed in hardware unless "Note: If the = length of the extension header chain (sum of the lengths of all EH in = the chain) is larger than the resources allocated in hardware, the = packet is punted to the software path as explained later in this = section.=E2=80=9D on the length issue: "Due to the potential combinations and lengths of extension headers, the = overall size of the chain will vary. In Cisco routers, when the size of = the EH chain exceeds the resources allocated in HW and upper layer = protocol filters are applied, the IPv6 traffic will be software switched = by the Line-Card CPU. The packet shown in Figure 4 has a 72 bytes long = EH chain, which means that a hardware forwarding platform that was = designed to handle 64 bytes of EH data will have to software switch this = packet. With the current IPv6 applications and services however, this = would be an infrequent event. Moreover, packets with very long EH chains = are generally control plane packets (such as the one depicted in Figure = 4) which have a very low rate, so the impact on the router is not = significant." You can argue the rate implication. But the extension header had to be = longer than 64 bytes to make it a question. So, yes, there are cases in which it will need to software-switch a = packet. It=E2=80=99s an end-of-life product, and "there are cases" is = quite a bit different from "every packet" --Apple-Mail=_59226FB3-2B27-4E95-91BE-9B67EA93FA82 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVUtV259ieig10VPpAQKgOwf/biMXyZAWCZtTYm3QvTECXO+MWkDX7TLR iifVGdaQ+w74nf9KnkZ38mVjw42Y8IP6FXIdhiHfvyCMt0VF2DDXZyT9jn+wF4O/ k3u1hOX7ZNg/ZRrpAA6W7G3vNrds+2utGSHC+oKlWuzOG5A5WBFJ2aWYvIPAhMOl CpdMaiT3/wwnVZjmZCgvOA6S6MtYrBaG3xDy/QKHEjukBwDbwza/r5GLx23Z+j2y FvbwcGyLrh8yDhpWpJd2BzeXKDWDPEloLi2Er1ha3OHCJnc7XugDbheQFtzDqQe1 Ttjl6cENoVuU0IAY85RzuZN1pF+GEbEE71xTxRCU5DuklCDr2SFJcg== =MHFe -----END PGP SIGNATURE----- --Apple-Mail=_59226FB3-2B27-4E95-91BE-9B67EA93FA82-- From nobody Thu May 7 05:58:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923C71A8A70 for ; Thu, 7 May 2015 05:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjCaQmqZkw8E for ; Thu, 7 May 2015 05:58:27 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CB81A6EFB for ; Thu, 7 May 2015 05:58:26 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t47CwMMb098231 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2015 13:58:22 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <554B616E.1090208@foobar.org> Date: Thu, 07 May 2015 13:58:22 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> <416464EE-40E7-4B95-9EDD-FD73918094A3@cisco.com> In-Reply-To: <416464EE-40E7-4B95-9EDD-FD73918094A3@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 12:58:29 -0000 On 07/05/2015 13:09, Fred Baker (fred) wrote: > So, yes, there are cases in which it will need to software-switch a > packet. Its an end-of-life product, and "there are cases" is quite a > bit different from "every packet" this has been extensively discussed in various places, including here. PFC3 based products are basically broken in this regard and there is a global configuration option on IOS to either forward all packets with EHs unilaterally, drop them unilaterally or else punt them unilaterally - no exceptions, and this will override anything defined in an ACL. PFC3 cards are EoL, but as you correctly point out, there are still a great many of them in operation on the internet. Other routers will have similar issues, but in edge cases rather than for all EH packets. Packet forwarding on routers is generally handled by inspection of the first N bytes of a packet and making a decision on that. If the EH falls within this N bytes, then the router will probably be able to make a decision about the EH. If it doesn't fall within this N bytes, then it won't be able to take that EH into account. The issue here is to what degree can you have your cake and eat it, i.e. rfc1925, section 7. It is certainly possible to design hardware which will inspect up to 65536 bytes of packet, but it will be expensive and there may be performance implications in iterating through large numbers of EHs. The router vendors generally seem to have made a choice to build hardware which can inspect up to a certain depth (e.g. 128 / 256 / 384 bytes), but no further. From an engineering stand-point, this is an acceptable compromise for my requirements. Other people may have different opinions. Nick From nobody Thu May 7 06:42:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6FF1A906D for ; Thu, 7 May 2015 06:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBNPNXmmza5F for ; Thu, 7 May 2015 06:42:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8D1A904F for ; Thu, 7 May 2015 06:42:05 -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 t47DfskL010086; Thu, 7 May 2015 14:41:54 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t47DfskL010086 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1431006117; bh=RlijGjsa6WGGpxogZeqLEf/peAM=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=enSy2KHofHjTzg3u1c0HbAn263rywpEK+yRgbOY8BeJ0BPloI6W1Q3Gqw7bB1pE6v d4gTmtOTYxJob9BXr+dQAP+DzajsL4cgwcgzq0HMmob67DzlFLp0uZgkNg6IdoFtDn xF3d5phmedkl8+fWyOmPHSZkBkVOL06MCB9uWMsI= 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 r46Efs12063070728B ret-id none; Thu, 07 May 2015 14:41:57 +0100 Received: from [10.1.11.13] ([194.82.140.195]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t47DfrJw030106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2015 14:41:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Tim Chown In-Reply-To: <155B08CF-3D07-4AE5-8F31-230354C9EFA1@nominum.com> Date: Thu, 7 May 2015 14:41:53 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> <155B08CF-3D07-4AE5-8F31-230354C9EFA1@nominum.com> <000D8E1D-64F9-4590-B798-F3BECC7D255A@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.2098) X-smtpf-Report: sid=r46Efs120630707200; tid=r46Efs12063070728B; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t47DfskL010086 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: "" , "" , "" , "" Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:42:14 -0000 > On 7 May 2015, at 12:53, Ted Lemon wrote: >=20 > On May 7, 2015, at 7:26 AM, Mikael Abrahamsson = wrote: >>=20 >> So basically, I want the entire document changed so that "filtering" = is replaced by "being dropped" or similar wording that doesn't convey = intent on behalf of the people running the device. >=20 > +1! That=E2=80=99s a very good suggestion. Tim From nobody Thu May 7 08:13:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8559E1A004E for ; Thu, 7 May 2015 08:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iae9e0wfugQ4 for ; Thu, 7 May 2015 08:13:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040401A912C for ; Thu, 7 May 2015 08:11:15 -0700 (PDT) Received: from mb-aye.local ([74.125.57.120]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t47F9jL5028611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 May 2015 15:09:47 GMT (envelope-from joelja@bogus.com) To: sthaug@nethelp.no, markzzzsmith@yahoo.com.au references: <554AB1F4.70802@gmail.com> <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> <20150507.075351.74706970.sthaug@nethelp.no> From: joel jaeggli message-id: <554B8033.9080807@bogus.com> Date: Thu, 7 May 2015 16:09:39 +0100 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <20150507.075351.74706970.sthaug@nethelp.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B0xFREcgg55wo0Lq2vtJiLcnjKRF9STif" Archived-At: Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org, fernando@gont.com.ar, merike@doubleshotsecurity.com Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:13:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B0xFREcgg55wo0Lq2vtJiLcnjKRF9STif Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/7/15 6:53 AM, sthaug@nethelp.no wrote: >> My expectation is that hardware forwarding platforms forward IPv6 >> packets at the same rate out of the box, regardless of which EHs are >> present in the IPv6 packet, and would only resort to slow path >> processing of EHs if I configure the router to look beyond what is >> necessary to forward the IPv6 packet. >=20 > Note that there are hardware forwarding platforms which don't have a > "slow path". A packet is either forwarded in hardware, or it is not > forwarded at all (i.e. dropped). fast path or no path is in fact pretty common. slow path if it exists is a trivial dos vector. > Steinar Haug, AS 2116 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --B0xFREcgg55wo0Lq2vtJiLcnjKRF9STif Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVLgDMACgkQ8AA1q7Z/VrLGEgCcCmD2Ja40l0DSks+rsEXklgKF z6cAoImY+dcBeh1tk1EWhECr18Lh4OSf =9yKs -----END PGP SIGNATURE----- --B0xFREcgg55wo0Lq2vtJiLcnjKRF9STif-- From nobody Thu May 7 09:33:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7EA1ACD91 for ; Thu, 7 May 2015 09:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFhf9QKle_qQ for ; Thu, 7 May 2015 09:33:51 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B021B1A1A02 for ; Thu, 7 May 2015 09:33:50 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 279A3A2; Thu, 7 May 2015 18:33:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1431016429; bh=lDHRdWCKjDT53n0C3vqXuy00htJk1idkUXZEN/37apw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=r5brgOpfTjS6opbtQeL9yDMIp977E3zpSG5WKbO5stF845lFIsBlC0OLousFh4ZzN u8GOx/0f5JTwh3apvOXhkiNqU9J+7Jnz9+V0O9wRUlMfbemiy2d1k7QRi6wZCLVkuH uVaVNor0ZmDZ0W/vGY5UOu+HUkPrU7YW0aCVO7fc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F550A1; Thu, 7 May 2015 18:33:49 +0200 (CEST) Date: Thu, 7 May 2015 18:33:49 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <416464EE-40E7-4B95-9EDD-FD73918094A3@cisco.com> Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> <416464EE-40E7-4B95-9EDD-FD73918094A3@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1990705001-1431016429=:32169" Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org WG" , V6ops Chairs , "fernando@gont.com.ar" Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:33:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1990705001-1431016429=:32169 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 7 May 2015, Fred Baker (fred) wrote: > >> On May 7, 2015, at 11:26 PM, Mikael Abrahamsson wrote: >> >> As stated before, all Cisco 6500/7600 with SUP720/RSP720 will as far as I know, slow-path packets with fragmentation header by default. As far as I know, fragmentation header is an extension header. > > Even when it is not addressed to the router and no ACL is involved? I think you’ll find that the question doesn’t come up unless it is required to process the header chain. Yes, ALWAYS. At least that's my experience with SUP720. We didn't have any ACLs on the device where I saw the drops. Oh, and reading http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html I might be wrong and RSP720 isn't affected. This is only a single example of devices that behave like that. I don't have experience with a lot of platforms so I don't know what other bad behaving platforms there are out there. > is hard to read as other than a blanket statement - "add an extension > header, take the slow path". That statement means that routers are > processing extension headers beyond the hop-by-hop header in every > circumstance. I’m sorry, I can’t imagine why they would. In some cases > (firewall functionality, ACLs, and packets addressed to the router), > yes, but not every packet forwarded; doing so would be a violation of > RFC 2460 and would be a waste of effort. That is what I have objected > to. I would like to see an accurate statement, if there is going to be > one. I’ll note Tim Chown’s comment in passing. > > SUP720 is, by the way, beyond its shelf life. That doesn’t mean they aren’t out there, of course, but they’re not current product. Fair enough, but people are still using them. > On SUP720 extension header processing: per http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html, dated 2006: > > "Because the Hop-by-Hop EH must be fully processed, it is handled by the > CPU and the IPv6 traffic that contains a Hop-by-Hop EH will go through > the slow forwarding path. This rule applies to all vendors. Hardware > forwarding is not feasible in this case." > > http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html#wp9000161 (same paper, table 2), states that IPv6 with EH other than Hop-by-Hop, in the presence of an ACL looking at higher layer headers, is processed in hardware unless "Note: If the length of the extension header chain (sum of the lengths of all EH in the chain) is larger than the resources allocated in hardware, the packet is punted to the software path as explained later in this section.” > > on the length issue: > > "Due to the potential combinations and lengths of extension headers, the > overall size of the chain will vary. In Cisco routers, when the size of > the EH chain exceeds the resources allocated in HW and upper layer > protocol filters are applied, the IPv6 traffic will be software switched > by the Line-Card CPU. The packet shown in Figure 4 has a 72 bytes long > EH chain, which means that a hardware forwarding platform that was > designed to handle 64 bytes of EH data will have to software switch this > packet. With the current IPv6 applications and services however, this > would be an infrequent event. Moreover, packets with very long EH chains > are generally control plane packets (such as the one depicted in Figure > 4) which have a very low rate, so the impact on the router is not > significant." > > You can argue the rate implication. But the extension header had to be longer than 64 bytes to make it a question. > > So, yes, there are cases in which it will need to software-switch a > packet. It’s an end-of-life product, and "there are cases" is quite a > bit different from "every packet" >From my 2011 email: #platform ipv6 acl fragment hardware ? drop Drop IPv6 fragments at hardware forward Forward IPv6 fragments at hardware As far as I can tell, the default is to slow-path, then you can configure it to either drop or forward without looking. I don't have access to SUP720, but if you can get someone in the Cisco lab to verify that packets are not dropped when there is no ACL, I'll concede that point as a mistake on my part. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1990705001-1431016429=:32169-- From nobody Thu May 7 09:36:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82A71A1A1C for ; Thu, 7 May 2015 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbRoYQjnDAIw for ; Thu, 7 May 2015 09:36:53 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055521ACD31 for ; Thu, 7 May 2015 09:36:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 87366A1; Thu, 7 May 2015 18:36:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1431016610; bh=e8ET/eVM5ie2aBKBASW/N66N9JdrrQXVtofVJ72VowQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fsQ5bqeMDKSJcriOpmQ32bh92envZHPJWeJ6fs3JqOWlyiNwUb9RATzPwD0NrbwUu iKLVaUOwCJSxwUsJSZiCp6f2b/TROKo9tAz06ZFECipbZJowRkFZksp6MAqPbFa1P6 OoWY7xfMhkUUxQAGEtwV05uk0P5mra1nPiQktiNc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6C0919F; Thu, 7 May 2015 18:36:50 +0200 (CEST) Date: Thu, 7 May 2015 18:36:50 +0200 (CEST) From: Mikael Abrahamsson To: joel jaeggli In-Reply-To: <554B8033.9080807@bogus.com> Message-ID: References: <554AB1F4.70802@gmail.com> <1715332514.1977002.1430962887480.JavaMail.yahoo@mail.yahoo.com> <20150507.075351.74706970.sthaug@nethelp.no> <554B8033.9080807@bogus.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: merike@doubleshotsecurity.com, v6ops@ietf.org, fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:36:55 -0000 On Thu, 7 May 2015, joel jaeggli wrote: > On 5/7/15 6:53 AM, sthaug@nethelp.no wrote: >>> My expectation is that hardware forwarding platforms forward IPv6 >>> packets at the same rate out of the box, regardless of which EHs are >>> present in the IPv6 packet, and would only resort to slow path >>> processing of EHs if I configure the router to look beyond what is >>> necessary to forward the IPv6 packet. >> >> Note that there are hardware forwarding platforms which don't have a >> "slow path". A packet is either forwarded in hardware, or it is not >> forwarded at all (i.e. dropped). > > fast path or no path is in fact pretty common. slow path if it exists is > a trivial dos vector. Well, on some platforms slow path means it hits a control plane policer and might/will be dropped if the punted traffic is too high. That was the case when I experienced this, we had CoPP configured, so anything apart from a few megabit/s of IPv6 slow-pathed traffic was just dropped in hardware, meaning we threw away tens of megabits per second of IPv6 packets with fragmentation headers (I discovered when I started looking into it). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu May 7 10:11:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3085E1A1A04 for ; Thu, 7 May 2015 10:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbkgCJzOjKgc for ; Thu, 7 May 2015 10:11:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111191A1A10 for ; Thu, 7 May 2015 10:11:36 -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 t47HBZYE007264 for ; Thu, 7 May 2015 19:11:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D65E02059D5 for ; Thu, 7 May 2015 19:13:21 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C507E20240E for ; Thu, 7 May 2015 19:13:21 +0200 (CEST) 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 t47HBYPK004640 for ; Thu, 7 May 2015 19:11:34 +0200 Message-ID: <554B9CC6.3090906@gmail.com> Date: Thu, 07 May 2015 19:11:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <554A83E3.4050503@gont.com.ar> In-Reply-To: <554A83E3.4050503@gont.com.ar> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 17:11:39 -0000 Le 06/05/2015 23:13, Fernando Gont a crit : > Folks, > > Question to the wg: > > Folks keep bringing up the reasons for which operators filter IPv6 > packets with EHs (the reasons have been discussed on this mailing-list a > few times already). Something along these lines was present in Section > 3 of > > but we removed that section in later revisions (prior to the wg call for > adoption of this document). > > A number of folks have argued that we should reincorporate that section. > Me, I think it would be useful, but can live without reincorporating > that section... > > It would be nice to hear from the wg about this. Thoughts? > > Thanks! > > Best regards, > I can live without reincorporating it as well. But if you do, please tell that certain networks block protocol Mobile IPv6. This is not a good thing. Why defining and implementing protocols if they are blocked on such large scale. Alex From nobody Thu May 7 11:02:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17711A1B27 for ; Thu, 7 May 2015 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyNQRHEhKIC5 for ; Thu, 7 May 2015 11:02:44 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076921A1AAD for ; Thu, 7 May 2015 11:02:44 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 969A96221; Thu, 7 May 2015 11:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=uCbuvdDS27jHRf7a8a0wzVIRDPg=; b= Z2ZJ95F9+i7NBVkFKb0ubNuafrHOFSKZEaS5nzrA4LjmwGCHkc/XfXZ7K08io6n1 kvKgVCqPoyUV9e3n33iTt+nvxYoCXKmF7sy+Y+BM27o9tX/I0kNbS0IKA476Jq+l AkSEIKkf8HlN2ow6h4AY2d1K+XjceKcBrfjMUj9r2h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=Ys7Js+b+7CajGh/njde4DI3n17 DF4JBeOecwOINFb+uTSRgaw9JovPuktWGskV3bM+1nx6TFPps6jcAViEZqm8wo3o fmHgKhDrRi5aT6NH+ShuyaWXr0F64vpc9GTje1CWQO0mOt7JQnG5i3HbKMtImhNV Ov7QybL3elQw+HIKk= Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4E7EF620C; Thu, 7 May 2015 11:02:42 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id C68A84475687; Thu, 7 May 2015 20:02:39 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B55524AE-198D-40D4-96BB-0D3685687431"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Ole Troan In-Reply-To: Date: Thu, 7 May 2015 20:02:38 +0200 Message-Id: <2AF6E484-575F-4153-ACC0-01160E0FFE05@employees.org> References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> <20150507.095853.104079668.sthaug@nethelp.no> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org, fernando@gont.com.ar Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 18:02:45 -0000 --Apple-Mail=_B55524AE-198D-40D4-96BB-0D3685687431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > and just to be clear. I want EHs to work on the Internet. I support = this document in all other aspects. I am just tired of all blame being = historically put on "stupid ISPs" or "stupid administrators" who = intentionally configure their equipment to do bad things, like drop "all = ICMP packets", when in at least some cases, the ICMPs were not making it = to the destination because of load balancers or ECMP routing would send = the ICMP packet to the wrong place. I suspect there are both, misguided operators in some cases and broken = gear in others. let=E2=80=99s hear from the handful of operators that are identified as = dropping EHs in transit and hear which one of those it is. cheers, Ole --Apple-Mail=_B55524AE-198D-40D4-96BB-0D3685687431 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVS6i/AAoJEFuJXizso86gVs0IALUeNk6lzTlOVK514OQV3Ln7 XtMmejuTsrP4+RF5kE3lNerZYzwE2ecyG4bOWt7kDIlxgd+zryDSxo93Thcy7fO8 tZiUAUC4qpghX1GjlxYaYw3TVaNv03QnPhVFR+2tiRVmrbQ5LFSV5cu3P0Zyb21h DUPP0LE0BuH1usuEDxbYfBUMdzgj/hfwh3ITbrjr+P9Z2gkkMHAxBSMt4YKfwmV3 lYlrJQcve5kY8j3SHUWqNxIOOmF8+uQI0Sjl4aSzaP3/+yZd2wpIn2L0njddnsk0 6DDorm4FArZmPkJZBnp4hTFpS6qecIac6uRJK4PR5147EoXFfvbANhYuZTaGGj0= =Fg5k -----END PGP SIGNATURE----- --Apple-Mail=_B55524AE-198D-40D4-96BB-0D3685687431-- From nobody Thu May 7 16:53:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA321B2CA2 for ; Thu, 7 May 2015 16:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoSro2AurqzH for ; Thu, 7 May 2015 16:53:51 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C831B2CA3 for ; Thu, 7 May 2015 16:53:51 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 079391FCA9F; Thu, 7 May 2015 23:53:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4B7CB160081; Thu, 7 May 2015 23:54:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2C77C160082; Thu, 7 May 2015 23:54:02 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yoqB9VMsFIFi; Thu, 7 May 2015 23:54:02 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id D5068160081; Thu, 7 May 2015 23:54:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D07B22DE9AE5; Fri, 8 May 2015 09:53:42 +1000 (EST) To: Alexandru Petrescu From: Mark Andrews References: <554A83E3.4050503@gont.com.ar> <554B9CC6.3090906@gmail.com> In-reply-to: Your message of "Thu, 07 May 2015 19:11:34 +0200." <554B9CC6.3090906@gmail.com> Date: Fri, 08 May 2015 09:53:41 +1000 Message-Id: <20150507235342.D07B22DE9AE5@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:53:53 -0000 In message <554B9CC6.3090906@gmail.com>, Alexandru Petrescu writes: > Le 06/05/2015 23:13, Fernando Gont a =E9crit : > > Folks, > > > > Question to the wg: > > > > Folks keep bringing up the reasons for which operators filter IPv6 > > packets with EHs (the reasons have been discussed on this mailing-list a > > few times already). Something along these lines was present in Section > > 3 of > > > > but we removed that section in later revisions (prior to the wg call for > > adoption of this document). > > > > A number of folks have argued that we should reincorporate that section. > > Me, I think it would be useful, but can live without reincorporating > > that section... > > > > It would be nice to hear from the wg about this. Thoughts? > > > > Thanks! > > > > Best regards, > > > > I can live without reincorporating it as well. > > But if you do, please tell that certain networks block protocol Mobile > IPv6. This is not a good thing. > > Why defining and implementing protocols if they are blocked on such > large scale. Because things change over time. EDNS packets when they were introduce in 1999 were rejected almost 100% of the time. Now, 15+ years later, they are almost never rejected. We are about to start added a EDNS option to every DNS request sent. [1] About 10-15% of nameserver mishandle unknown EDNS options [2] despite explicit instructions on how to handle them. [3] Doing a EDNS version bump is even worse 20-40% of nameservers mishandle EDNS packets with a unknown version. A lot of that is stupid firewall defaults and broken DDoS filtering services in front of the nameservers. When the packets get through to the nameserver there is a similar level of mishandling as EDNS options. [2] Despite these figures the next major release of named will be sending EDNS queries with a EDNS option and we will ride out the misbehaviour. I believe other nameserver vendors also intend to do similar. [1] https://tools.ietf.org/html/draft-ietf-dnsop-cookies-01 [2] http://users.isc.org/~marka/summary.html [3] http://tools.ietf.org/html/rfc6891#section-6.1.2 Mark > Alex > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 7 17:17:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA81A1BBD for ; Thu, 7 May 2015 17:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH471oCxCc7b for ; Thu, 7 May 2015 17:17:48 -0700 (PDT) Received: from nm34-vm2.bullet.mail.gq1.yahoo.com (nm34-vm2.bullet.mail.gq1.yahoo.com [98.136.216.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB4F1B2D02 for ; Thu, 7 May 2015 17:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431044267; bh=pmr1Fy3385K3zw8rrVuFNGWF353PV2rpjnxQTRaICsM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kCNIb9r/SRM4fZfGiry3/gLTTd9OLuFVPts/5YknM5LkcJpRJ9ABrT+wVC1l8uiD6j/BQETnmBsLzI+zYSEC1O57qgfdAbfU1gbdJ1xeQcB80qV1AOurCE8flekMrt2yhen5SCgPQ1xIS2ulmBC11WG4b4TrZiTaYpFw4+5JZ7R7w2lnVuUSJP7UJr3Tiu60+yhT6usR3rz8u+jICYHZRbqTF1H0rlXQdsEbvQOhk7KHP16tZk4+nyRRtVg7OiamBNjCT1wLHiersbdVMrO5Oot95JUnMbmPdvy9fr9YDZ+izmhbZWE2GvJBhU4kUTNA1wwGLJS2fhT4XRmgIk0+7Q== Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 08 May 2015 00:17:47 -0000 Received: from [216.39.60.183] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 08 May 2015 00:14:49 -0000 Received: from [98.139.170.180] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 08 May 2015 00:14:49 -0000 Received: from [98.139.212.248] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 00:14:48 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 08 May 2015 00:14:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 707438.29845.bm@omp1057.mail.bf1.yahoo.com X-YMail-OSG: HMNpT8YVM1kOmg55efAPg.XczHb_ni8st0wwLjtodkQc7Qq6VxlLoEk9UGW_jBe Oq.UK44yDEQhCndAJuJVO9bkFNCpWS6j9Xsw1md.jxVaWvcifEXPRDWBbiErIsyZqfDuTjfkja2E SdGAh3O_lg3YfpOaryFaDYXqK3vrHlyrmIpkj0V24YlvTLM1PVvtk9E205CeSmKnKOsqazT43DL4 kA3XUg8exnnWa6PbKQnkJ_1yljVbTbB8jxOn5iDyPdaySLPAfuTj0nmJK5nLTkfpV8AStv7vCn09 XBX9OGgJVZpZ7_6P7Mh28KIZ398bSxZZilDSM819RgFc0LRTDLp.ogTmGs96Z_6qjQHQigwpu_ud UBqubne1BeKDDtTTdnqU9bE40EhN7T8BICCS8P0s0LBEG1skgF8sFreCrsImV0mpzp6uHTX29x0U WtSetujvy0Pe2CC6qe0XCIKsggjx76wPzseyiWRpw6qQDYNuJbnVOXwMa6p6QNXD2Mw8meAlZUrb m4OPFm37eeaod4L39C9Qr60OL_HRM.mMNe4VDLvDI_QxS.cVQ0_oZ2RAHPv6j Received: by 66.196.80.144; Fri, 08 May 2015 00:14:48 +0000 Date: Fri, 8 May 2015 00:14:46 +0000 (UTC) From: Mark ZZZ Smith To: "Fred Baker (fred)" Message-ID: <339780752.2949885.1431044086250.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2949884_557424427.1431044086239" Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops@ietf.org" , V6ops Chairs , Fernando Gont , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 00:17:50 -0000 ------=_Part_2949884_557424427.1431044086239 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, From: Fred Baker (fred) To: Mark ZZZ Smith =20 Cc: Fernando Gont ; "v6ops@ietf.org" = ; "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 Sent: Thursday, 7 May 2015, 17:45 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6o= ps-ipv6-ehs-in-real-world) =20 On May 7, 2015, at 12:05 PM, Mark ZZZ Smith wro= te: Hi, I don't have a strong opinion on whether it should be reincorporated or not= , as I haven't kept up with that discussion. However, if it does get included, I think the following statement needs mor= e clarification: "Many IPv6 router implementations suffer from a negative performance=C2=A0 = =C2=A0impact when IPv6 Extension Headers are employed." Is this really the case? It seems to me that this is saying that "Many IPv6= router implementations" are inspecting EHs by default, which then means ma= ny routers are vulnerable to the EH based DoSes and other issues mentioned = by default. If it is the case, I think we need a list of those routers that by default = violate RFC 2460 by inspecting past the HbH header when they are not the de= stination of the packet. What I have been trying to get Fernando to do is identify under what condit= ions that might be true, rather than paint all equipment from all vendors u= nder all conditions with slime. If the router has a filter (ACL) that force= s it to parse the headers to find a TCP header, and the parsing is dumped t= o a slower path, that would be an example, and would be a valid example to = bring out. But I don=E2=80=99t accept sliming all equipment from all vendor= s under all circumstances. It=E2=80=99s not the case. / I definitely think describing the circumstances where this might happen f= or some implementations would be useful. / Thinking more about it, I think TCP and UDP headers are effectively theor= etical EHs too, as their presence values are encoded in the same Next Heade= r fields as normal EHs, and they can appear in the same packet locations as= normal EHs. I'd be interested to know if fast path forwarding (hardware) m= ight be doing more complex processing than just a HBH EH value check on the= IPv6 Header Next Header field. / For example, the TCP and UDP headers are usually the ones people want to = look at in more detail, so a simplistic implementation would punt all first= EH HBH, TCP and UDP to slow path and fast path everything else. Of course,= TCP and UDP traffic are the dominant types, so slow pathing TCP/UDP traffi= c by default would be non-optimal. I'd expect routers by default to have just processed/forwarded IPv6 packets= based on the fixed IPv6 header fields, ignoring EHs and allowing fast path= forwarding, and to only start looking at EHs if configured to via ACLs etc= . I think the above statement is effectively implying that fast path forwardi= ng of IPv6 isn't a default in many IPv6 router implementations, and I'd be = quite surprised if that is true, which is why I think more clarification wo= uld be useful. Regards,Mark. From: Fernando Gont To: "v6ops@ietf.org" =20 Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 Sent: Thursday, 7 May 2015, 7:13 Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-i= pv6-ehs-in-real-world) =20 Folks, Question to the wg: Folks keep bringing up the reasons for which operators filter IPv6 packets with EHs (the reasons have been discussed on this mailing-list a few times already). Something along these lines was present in Section 3 of but we removed that section in later revisions (prior to the wg call for adoption of this document). A number of folks have argued that we should reincorporate that section. Me, I think it would be useful, but can live without reincorporating that section... It would be nice to hear from the wg about this. Thoughts? Thanks! Best regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_2949884_557424427.1431044086239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

=
From: Fred Baker (fred) <fred@cisco.com>
= To: Mark ZZZ Smith <markzz= zsmith@yahoo.com.au>
Cc: Fernando Gont <fernando@gont.com.ar>; "v6ops@ietf.org" <v6op= s@ietf.org>; "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" &l= t;draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>; V6ops Chairs = <v6ops-chairs@tools.ietf.org>; Merike Kaeo <merike@doubleshotsecur= ity.com>
Sent: = Thursday, 7 May 2015, 17:45
<= span style=3D"font-weight: bold;" id=3D"yui_3_16_0_1_1431043215262_4729">Su= bject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-= ietf-v6ops-ipv6-ehs-in-real-world)


<= div class=3D"yiv8694422609">On May 7, 2015, at 12:05 PM, Mark ZZZ Smith <= ;markzzzsmith@yahoo.com.au> wrote:

=
Hi,
<= br clear=3D"none" class=3D"yiv8694422609">
I don't have a strong opinion on whether it should be reincorporated o= r not, as I haven't kept up with that discussion.

However, if it does get included, = I think the following statement needs more clarification:

"Many IPv6 router = implementations suffer from a negative performance
   impact when IPv6 Extension Headers are employed."

=
Is this really the case? It seems to me = that this is saying that "Many IPv6 router implementations" are inspecting = EHs by default, which then means many routers are vulnerable to the EH base= d DoSes and other issues mentioned by default.

If it is the case, I think we need a l= ist of those routers that by default violate RFC 2460 by inspecting past th= e HbH header when they are not the destination of the packet.

What I have been trying to get Fernando to do is id= entify under what conditions that might be true, rather than paint all equi= pment from all vendors under all conditions with slime. If the router has a= filter (ACL) that forces it to parse the headers to find a TCP header, and= the parsing is dumped to a slower path, that would be an example, and woul= d be a valid example to bring out. But I don=E2=80=99t accept sliming all e= quipment from all vendors under all circumstances. It=E2=80=99s not the cas= e.


/ I definitely think describing the= circumstances where this might happen for some implementations would be us= eful.

/ Thinking more about it, I think TCP and UDP headers are effectively= theoretical EHs too, as their presence values are encoded in the same Next= Header fields as normal EHs, and they can appear in the same packet locati= ons as normal EHs. I'd be interested to know if fast path forwarding (hardw= are) might be doing more complex processing than just a HBH EH value check = on the IPv6 Header Next Header field.
/ For example, the TCP and UDP headers = are usually the ones people want to look at in more detail, so a simplistic= implementation would punt all first EH HBH, TCP and UDP to slow path and f= ast path everything else. Of course, TCP and UDP traffic are the dominant t= ypes, so slow pathing TCP/UDP traffic by default would be non-optimal.


=
I'd expect routers by de= fault to have just processed/forwarded IPv6 packets based on the fixed IPv6= header fields, ignoring EHs and allowing fast path forwarding, and to only= start looking at EHs if configured to via ACLs etc.

I think the above statement is effectively implying that fas= t path forwarding of IPv6 isn't a default in many IPv6 router implementatio= ns, and I'd be quite surprised if that is true, which is why I think more c= larification would be useful.

Regard= s,
Mark.

From: Fernando Gont= <fernando@gont.com.ar>
To: "v6ops@ietf.org" &l= t;v6ops@= ietf.org>
Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-worl= d@tools.ietf.org" <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.o= rg>; V6ops Chairs <v6ops-chairs@tools.ietf.org<= /a>>; Merike Kaeo <merike@doubleshotsecurity.co= m>
Sent: Thursday, 7 May 2015, 7:13
= Subject: [v6ops] Next st= eps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)

Folks,

Question to t= he wg:

Folks keep bringing up the reasons for which operators f= ilter IPv6
packets with EHs (the = reasons have been discussed on this mailing-list a
few times already). Something along these lines was pres= ent in Section
3 of
<https://tools.ietf.org/html/draft= -gont-v6ops-ipv6-ehs-in-real-world-01>
but we removed that section in later revisions (prior to the w= g call for
adoption of this docum= ent).

A number of folks have argued that we should reincorporate = that section.
Me, I think it woul= d be useful, but can live without reincorporating
that section...

It would be nice to hear from = the wg about this. Thoughts?

Thanks!

Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945= 96EE A9EF D076 FFF1


<= br clear=3D"none" class=3D"yiv8694422609">_________________________________= ______________
v6ops mailing list=
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


______________= _________________________________
v6ops mailing list
v6ops@ietf.orghttps://www.ietf.org/mailman/listin= fo/v6ops



------=_Part_2949884_557424427.1431044086239-- From nobody Thu May 7 20:29:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA301A890E for ; Thu, 7 May 2015 20:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CLha3IIOkYL for ; Thu, 7 May 2015 20:28:56 -0700 (PDT) Received: from nm46-vm10.bullet.mail.bf1.yahoo.com (nm46-vm10.bullet.mail.bf1.yahoo.com [216.109.114.203]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EBA1A8931 for ; Thu, 7 May 2015 20:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431055734; bh=O/inEFWgBSMq1GT4iRJkfWin+w477I2auU9Etm2Mu0k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=g+17xSGmos/VeQ9/N5CAGNQLD9ZMkzefUkqR68j1B+X2ZSxUrJAvicSIFqwgGLaAqSF2Bg8kvBRr5b7g9oNzKiuEfQtK6RonPMtJzC0QTlWyQvRCjM31HJ7RDPC/c9fF19FHkon1uyOPfOdLCXMWifqjQNlvH/mr1sz8q7f9FdZN+xb3Jt+fsWujFCL3mKwD+0zZvMYp7aYT0E7Z/qWoIIlGll3VDXtR+/CNx+qdW9iqj2qMn33tjgIEkNB9tA8L+/OpRgFLAX1fPgUBnGqFWiIaKPQ/934VbgZMk86Y3nTfdeqR7psevaah7N3FfznudfB9cGA2/3Uodf9dddMXWw== Received: from [98.139.170.182] by nm46.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 03:28:54 -0000 Received: from [98.139.212.233] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 03:28:54 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 08 May 2015 03:28:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 992256.30092.bm@omp1042.mail.bf1.yahoo.com X-YMail-OSG: o13TXfkVM1nMMlrsZD67tvxXwKhCxwwUKYQBEFZ.50AxwGJydJJbhTpSO1Faews J.v5qBLyOkAMe.jvplcNTpctxN1FGi_NfwwXZ3btlRxYAC1oq1W7gcNHIvejwhvxmB4o0JJeNuT7 kk2I3uq3uUcIktzZIeLaCnuc1NwihUy8xtZa4vBVBqSmcsqHJ8uFPrP.9QqDRMCCeZznS17IEBgl iQfHpyMmSEvSzNpba_TiP4VYVNcUi3f_HuL3qAD1a7OQkF7_bPRSDbX.GzjUQ2n9yME8rUyzMXEW w3kizgMpJ1gId5_a0SHBDX2W20P_sDey7pPbbTHg_58qYBPkPEgzoYE35dVIsFaF_M2TgxkL6QQT xghfFHMep.2SnnHkJEIs35_i5iUX2g8S8tkdgtQE7XLrSCdcbskv.vYxIQdk.5jll6gatUhY_kN1 MjTMeGocxPlVBH2bb3EpZ6piLtqGjSO.U5ZHVfkRsHZ7WD3LSeue82BdEs.A0WdcNlSNzhu.pXnp AImEq1kb9i1xJJhU6m0NJfI7k6HiHXSCpMpp4sp23HsKOPq6K1g-- Received: by 66.196.81.105; Fri, 08 May 2015 03:28:53 +0000 Date: Fri, 8 May 2015 03:28:53 +0000 (UTC) From: Mark ZZZ Smith To: "sthaug@nethelp.no" Message-ID: <735339660.2989870.1431055733036.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150507.075351.74706970.sthaug@nethelp.no> References: <20150507.075351.74706970.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2989869_1120806299.1431055733030" Archived-At: Cc: "v6ops@ietf.org" , "merike@doubleshotsecurity.com" , "fernando@gont.com.ar" , "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 03:28:58 -0000 ------=_Part_2989869_1120806299.1431055733030 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit From: "sthaug@nethelp.no" To: markzzzsmith@yahoo.com.au Cc: brian.e.carpenter@gmail.com; fernando@gont.com.ar; v6ops@ietf.org; draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org; v6ops-chairs@tools.ietf.org; merike@doubleshotsecurity.com Sent: Thursday, 7 May 2015, 15:53 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) > My expectation is that hardware forwarding platforms forward IPv6 > packets at the same rate out of the box, regardless of which EHs are > present in the IPv6 packet, and would only resort to slow path > processing of EHs if I configure the router to look beyond what is > necessary to forward the IPv6 packet. Note that there are hardware forwarding platforms which don't have a "slow path". A packet is either forwarded in hardware, or it is not forwarded at all (i.e. dropped). / Agree, that sort of hardware in part is why I'm curious for more detail. Steinar Haug, AS 2116 ------=_Part_2989869_1120806299.1431055733030 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: "sthaug@nethelp= .no" <sthaug@nethelp.no>
To= : markzzzsmith@yahoo.com.au
Cc: brian.e.carpenter@gmail.com; fernando@gont.com.ar; v6o= ps@ietf.org; draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org; v6ops-= chairs@tools.ietf.org; merike@doubleshotsecurity.com
Sent: Thursday, 7 May 2015, 15:53
Subject: Re: [v6ops] Next steps= for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world)
<= /font>



> My expectation is that hardware forwarding= platforms forward IPv6
> packets at the same rate out= of the box, regardless of which EHs are
> present in = the IPv6 packet, and would only resort to slow path
> = processing of EHs if I configure the router to look beyond what is
> necessary to forward the IPv6 packet.


Note that there are hardware forwarding platforms whic= h don't have a
"slow path". A packet is either forwarded = in hardware, or it is not
forwarded at all (i.e. dropped)= .

/ Agree, that sort of hardware in part is why I'm c= urious for more detail.

Steinar Haug, AS 2116



------=_Part_2989869_1120806299.1431055733030-- From nobody Thu May 7 21:12:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34A11A1F70 for ; Thu, 7 May 2015 21:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8UjBpnlOzG0 for ; Thu, 7 May 2015 21:12:37 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200221A1BFC for ; Thu, 7 May 2015 21:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431058356; bh=bunbTVMXgKcj+y2csFM9c88ipjUZ7AvmiqV6nJMwo+Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=keTK2I1e0RbqnHU/niw+FAatjAxHKPceg2slXlYMTKjAbVRQZLEm+CW7xjWRljEz8BSlnzvFntCjkRR469Zo598REoAOA5J6YO6EXeXs5ilUQitJsY1TbLP5Mzu8AfmPlw9x3MVP9F4JtumtasBmx0GXZG3iaaTjjENHBWvRiMDG4ZcxppNKmjQ7QHvsOR+9bJAvXIEGciOpLwJzGr/eircz8ZAc7de3CC+bin/OV/4wpyHy+uF6Exuj3x5Jdd4YyND5iYhFoNcQ1/nsTohTZjMLLFJt3r1DduyiwXZa+Q/4GqZDKFLCfPqWFJPC2+Y42Up48xbnpQKbUAZHuNjyCA== Received: from [98.139.215.141] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 04:12:36 -0000 Received: from [98.139.212.242] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 04:12:36 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 08 May 2015 04:12:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 33652.90080.bm@omp1051.mail.bf1.yahoo.com X-YMail-OSG: ccYSP3EVM1k9uCXWq2d0JDUaFMAErBQLtQ1DQE8uVQlRjTJa5_kcp..s4wTsLHc WBKjU8Nppzc7_LbyG13M02lPyROU.LlRP3Kfez86b7YTsjDqnpCRcBCvb_AcxSwIskQbHtL03qMt 3LzTnNo2VGhH6jT0aeeDhJIRWX1iIuEndKNAlBw_1m03C8Cwug42jVatrfGZLNFPgLaB9nGExPfE U72.._HGcywezxKZMjBGkYyd0JNetsMB76xOgrjhozO5ENgZ8sJRj31G55QxPAQsAus5Kosi_vOE wxpuAgvYw5eJQvZB23OWCxKnziWeC.a80N2u1mUIkqTCmIno6usjq8Fj3fgFzJZm7G__BHYJyYLb 0F3erakJyTK8mAAqPi2Y_jQ9Q.zPoa5_cMNJY9urq10LWl19zOFIsPm9dnzYtqDJVXPmuK2khypY UyODb58DprXA21UQeWfboupybMi.2vBhTFxv6v6CRXuWxZZIbQssbzB8KYE2mRjgVwNqqin4kUUs 48dmviYdVxyIbZ2C9Zps90lpijI7Osg8pCBzlet14aa5zUN3Sxg-- Received: by 76.13.26.109; Fri, 08 May 2015 04:12:35 +0000 Date: Fri, 8 May 2015 04:12:19 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , Fernando Gont , "v6ops@ietf.org" Message-ID: <605024354.3022656.1431058339210.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <554B1149.5030005@gmail.com> References: <554B1149.5030005@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3022655_503948304.1431058339197" Archived-At: Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , Merike Kaeo Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:12:39 -0000 ------=_Part_3022655_503948304.1431058339197 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, From: Brian E Carpenter To: Mark ZZZ Smith ; Fernando Gont ; "v6ops@ietf.org" =20 Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 Sent: Thursday, 7 May 2015, 17:16 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6o= ps-ipv6-ehs-in-real-world) =20 Hi Mark, On 07/05/2015 13:41, Mark ZZZ Smith wrote: > Hi, >=C2=A0 =C2=A0 =C2=A0 From: Brian E Carpenter >=C2=A0 To: Mark ZZZ Smith ; Fernando Gont ; "v6ops@ietf.org" =20 > Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 >=C2=A0 Sent: Thursday, 7 May 2015, 10:29 >=C2=A0 Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-i= etf-v6ops-ipv6-ehs-in-real-world) >=C2=A0 =C2=A0=20 > On 07/05/2015 12:05, Mark ZZZ Smith wrote: >> Hi, >> I don't have a strong opinion on whether it should be reincorporated or = not, as I haven't kept up with that discussion. >> However, if it does get included, I think the following statement needs = more clarification: >> "Many IPv6 router implementations suffer from a negative performance=C2= =A0 impact when IPv6 Extension Headers are employed." >> Is this really the case?=20 >=20 > I'm guessing that a more accurate statement would be > "Many IPv6 router implementations that also include some firewall functio= nality suffer..." > but I agree that it should be better substantiated. >=20 > / I don't think I've come across a router that doesn't have some sort of = firewall functionality (i.e., basic packet filters/ACLs),=20 But there's a big difference between those two. ACLs =3D just look at the addresses / In my experience, "ACLs" have been capable of doing both levels of matchi= ng (in some implementations there are simple ACLs which only do addresses a= nd 'extended' ACLs which can also do 5-tuple etc. matches.) I don't think I= 've come across a platform that just does address level ACLs. basic packet filters =3D look at the 5-tuple, and the whole problem here is that extracting the 5-tuple becomes hard with EH present, and impossible with unknown EH present. / Agree, that is the hard problem. / I think that while the control plane is reachable in-band by possibly mal= icious traffic sources, it is fundamentally impossible to completely protec= t it from various attacks from those malicious traffic sources. Even if ACL= s/packet filters are used to validate addresses and upper layer protocol nu= mbers, they won't protect against possible exploits in the protocol or impl= ementations. That's certainly pretty obvious, I think the thing we need to = remember is that "perfect protection" of the control plane is impossible to= achieve in this situation. But I agree that the default is what needs to be right (see RFC 7045 again)= . =C2=A0 Brian > so I'm in particular interested in default behaviour. > / My expectation is that hardware forwarding platforms forward IPv6 packe= ts at the same rate out of the box, regardless of which EHs are present in = the IPv6 packet, and would only resort to slow path processing of EHs if I = configure the router to look beyond what is necessary to forward the IPv6 p= acket. That would usually only apply to a subset of packets, specified by s= ource and/or destination IPv6 address, meaning that the majority of IPv6 pa= ckets will still be fast path forwarded. The above seems to be implying the= default is the opposite of my expectation in many cases.=20 > / Regards,Mark.=20 >=20 >=20 > My feeling is that describing the objective reasons why some routers beha= ve > this way is a good idea. Otherwise, the reader is left with a mystery to = solve. >=20 >=20 >=C2=A0 Brian >=20 >=20 >=20 >> It seems to me that this is saying that "Many IPv6 router implementation= s" are inspecting EHs by default, which then means many > routers are vulnerable to the EH based DoSes and other issues mentioned b= y default. >> I'd expect routers by default to have just processed/forwarded IPv6 pack= ets based on the fixed IPv6 header fields, ignoring EHs and allowing fast p= ath forwarding, and to only start looking at EHs if configured to via ACLs = etc. >> I think the above statement is effectively implying that fast path forwa= rding of IPv6 isn't a default in many IPv6 router implementations, and I'd = be quite surprised if that is true, which is why I think more clarification= would be useful. >> Regards,Mark. >>=C2=A0 =C2=A0 =C2=A0 From: Fernando Gont >>=C2=A0 To: "v6ops@ietf.org" =20 >> Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" ; V6ops Chairs ; Merike Kaeo =20 >>=C2=A0 Sent: Thursday, 7 May 2015, 7:13 >>=C2=A0 Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf= -v6ops-ipv6-ehs-in-real-world) >>=C2=A0 =C2=A0=20 >> Folks, >> >> Question to the wg: >> >> Folks keep bringing up the reasons for which operators filter IPv6 >> packets with EHs (the reasons have been discussed on this mailing-list a >> few times already). Something along these lines was present in Section >> 3 of >> >> but we removed that section in later revisions (prior to the wg call for >> adoption of this document). >> >> A number of folks have argued that we should reincorporate that section. >> Me, I think it would be useful, but can live without reincorporating >> that section... >> >> It would be nice to hear from the wg about this. Thoughts? >> >> Thanks! >> >> Best regards, >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=C2=A0=20 >=20 =C2=A0 ------=_Part_3022655_503948304.1431058339197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,
=
From: Brian E Carpenter <brian.e.carpenter@gmail= .com>
To: Mark ZZZ = Smith <markzzzsmith@yahoo.com.au>; Fernando Gont <fernando@gont.co= m.ar>; "v6ops@ietf.org" <v6ops@ietf.org>
Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@to= ols.ietf.org" <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>= ;; V6ops Chairs <v6ops-chairs@tools.ietf.org>; Merike Kaeo <merike= @doubleshotsecurity.com>
Sent= : Thursday, 7 May 2015, 17:16
Subject: Re: [v6ops] Next steps for IPv6 EHs in Real Wor= ld (draft-ietf-v6ops-ipv6-ehs-in-real-world)
Hi Mark,
On 07/05/2015 13:41, Mark ZZZ Smith wrote:
> Hi,
>      From: Br= ian E Carpenter <brian.e.carpenter@gma= il.com>
>  To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>; Fernando Gont <= fernando@gont.com.ar>; "v6ops@ietf.org" <v6ops@ietf.org>
> Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org>; V6o= ps Chairs <v6ops-chairs@tools.ietf.org= >; Merike Kaeo <merike@doubleshotsecurity.com>
>  Sent: Thursday, 7 May 2015, 10:29
&g= t;  Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-= ietf-v6ops-ipv6-ehs-in-real-world)
>   
> On 07/05/2015 12:05, Mark ZZZ Smith wrote:
>> Hi,
>> I don't have a strong opinion= on whether it should be reincorporated or not, as I haven't kept up with t= hat discussion.
>> However, if it does get included= , I think the following statement needs more clarification:
>> "Many IPv6 router implementations suffer from a negative perfor= mance  impact when IPv6 Extension Headers are employed."
>> Is this really the case?
>
> I'm guessing that a more accurate statement would be
> "Many IPv6 router implementations that also include some fir= ewall functionality suffer..."
> but I agree that it s= hould be better substantiated.
>
&g= t; / I don't think I've come across a router that doesn't have some sort of= firewall functionality (i.e., basic packet filters/ACLs),

But there's a big difference between those two.

ACLs =3D just look at the addresses

/ In my experience, "ACLs" have been capable of doing both l= evels of matching (in some implementations there are simple ACLs which only= do addresses and 'extended' ACLs which can also do 5-tuple etc. matches.) = I don't think I've come across a platform that just does address level ACLs= .

basic packet filters =3D look at the 5-tuple, and t= he whole problem here
is that extracting the 5-tuple beco= mes hard with EH present, and impossible
with unknown EH = present.

/ Agree, that is the hard problem.

/ I think that while the control plane is reachable in-= band by possibly malicious traffic sources, it is fundamentally impossible = to completely protect it from various attacks from those malicious traffic = sources. Even if ACLs/packet filters are used to validate addresses and upp= er layer protocol numbers, they won't protect against possible exploits in = the protocol or implementations. That's certainly pretty obvious, I think t= he thing we need to remember is that "perfect protection" of the control pl= ane is impossible to achieve in this situation.



But I agree that the default is what needs to be r= ight (see RFC 7045 again).




  Brian


&= gt; so I'm in particular interested in default behaviour.
> / My expectation is that hardware forwarding platforms forward IPv6 p= ackets at the same rate out of the box, regardless of which EHs are present= in the IPv6 packet, and would only resort to slow path processing of EHs i= f I configure the router to look beyond what is necessary to forward the IP= v6 packet. That would usually only apply to a subset of packets, specified = by source and/or destination IPv6 address, meaning that the majority of IPv= 6 packets will still be fast path forwarded. The above seems to be implying= the default is the opposite of my expectation in many cases.
> / Regards,Mark.
>
> =
> My feeling is that describing the objective reasons= why some routers behave
> this way is a good idea. Ot= herwise, the reader is left with a mystery to solve.
>=
>
>  Brian
>
>
>
>> It seems to me that this is saying that "Many IPv6 router implem= entations" are inspecting EHs by default, which then means many
> routers are vulnerable to the EH based DoSes and other issues m= entioned by default.
>> I'd expect routers by defau= lt to have just processed/forwarded IPv6 packets based on the fixed IPv6 he= ader fields, ignoring EHs and allowing fast path forwarding, and to only st= art looking at EHs if configured to via ACLs etc.
>>= ; I think the above statement is effectively implying that fast path forwar= ding of IPv6 isn't a default in many IPv6 router implementations, and I'd b= e quite surprised if that is true, which is why I think more clarification = would be useful.
>> Regards,Mark.
>>      From: Fernando Gont <= fernando@gont.com.ar>
>>  To: "v6ops@ietf.org" <v6ops@ietf.org>
= >> Cc: "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ie= tf.org" <draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.= ietf.org>; V6ops Chairs <v6ops-= chairs@tools.ietf.org>; Merike Kaeo <merike@doubleshotsecurity.com>
>>=   Sent: Thursday, 7 May 2015, 7:13
>>  = Subject: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ip= v6-ehs-in-real-world)
>>   
>> Folks,
>>
>>= ; Question to the wg:
>>
>>= Folks keep bringing up the reasons for which operators filter IPv6
>> packets with EHs (the reasons have been discussed on th= is mailing-list a
>> few times already). Something = along these lines was present in Section
>> 3 of>> <https= ://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01>>> but we removed that section in later revisions (p= rior to the wg call for
>> adoption of this documen= t).
>>
>> A number of folks= have argued that we should reincorporate that section.
&= gt;> Me, I think it would be useful, but can live without reincorporatin= g
>> that section...
>>
>> It would be nice to hear from the wg about this. Th= oughts?
>>
>> Thanks!
>>
>> Best regards,
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> = v6ops@ietf.org
>> https://www.iet= f.org/mailman/listinfo/v6ops
>>
>
>
> 
>


 
------=_Part_3022655_503948304.1431058339197-- From nobody Sat May 9 13:47:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDBD1ACEF7 for ; Sat, 9 May 2015 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHujNrpMBaNF for ; Sat, 9 May 2015 13:46:59 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFF61ACF1A for ; Sat, 9 May 2015 13:46:58 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so77737324pab.2 for ; Sat, 09 May 2015 13:46:57 -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=AWz6do/7MqLHBBCbCqoAJRNCzzbBfkL/yaDRH2JVxdk=; b=sguJCZvggaSOi5NAoLPLQnUsnk9JfjvMU8bSFLkpGLr91tsCXti2R4J56W2GxSXCbv +LPha3leXn3jJia3K/t34cQQzMFtR1XHriOR9aw7Z7cPiDUOXq0UclxaNaYvPkpqHT7P gIB0rj9Y+ozA8stVnKoTglb8EhP2u8ESXVrcUy0JkHWz+CEgOeY+FEXVnY34ls/lHJgy bISA3GUk3YvKozHTv/oNd7VvECC3ADlPVu/XvEuv84bDgKbbPJMqj/yPHnB7uODanCMQ v/ho8NEZFm1TYEaYa+cDtnj/JaKTzfwzcC46ZX39QboDxva6ZBh2HCZ9517lygtRguxw i21Q== X-Received: by 10.66.243.69 with SMTP id ww5mr7051147pac.106.1431204417799; Sat, 09 May 2015 13:46:57 -0700 (PDT) Received: from ?IPv6:2406:e007:6595:1:28cc:dc4c:9703:6781? ([2406:e007:6595:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id cl11sm8780188pdb.36.2015.05.09.13.46.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2015 13:46:56 -0700 (PDT) Message-ID: <554E723B.2080708@gmail.com> Date: Sun, 10 May 2015 08:46:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> <55483921.40605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 20:47:00 -0000 Comment at the end... On 06/05/2015 06:05, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 05 May 2015 15:29:37 +1200, > Brian E Carpenter wrote: >=20 >>>> Actually, I guess there should be more pragmatic examples of >>>> operational issues because of the described divergence >> >> That would be fine, but surely the underlying point is that if >> you have a heterogeneous network and you repeat certain events >> (like a power fail/restart, or a temporary cable cut, or automated >> renumbering) the end state may be different in different cases, >> because of race conditions and the divergent behaviour of different >> devices. Now maybe we accept that as OK, but at least we should >> document how it can happen. >=20 > Personally, I'd expect to see some actual and practical troubles in > such a case for a document about it to be sufficiently useful as > something formal like an RFC. An observation of the divergent > behavior may be somewhat interesting, but IMO not substantial enough. > But, as I (hope) already said I'm not insisting my view is the only > possible position. I guess you and I just have different expectations > on what's worth documenting in RFCs. That's fine for me, and if many > others in the wg share your expectation, I have no problem with > publishing it. >=20 >> Another comment you made: >> >>>>> The M, O and A >>>>> flags are advisory, not prescriptive. >>>> >>>> In my understanding, the A flag is quite prescriptive. If a host >>>> implementation doesn't perform SLAAC for a prefix information opti= on >>>> with A flag on, that implementation would be considered >>>> non-compliant. >> >> I agree that this should be clarified. But RFC 4862 does not seem clea= r, >> because it only covers the opposite case: >> "a) If the Autonomous flag is not set, silently ignore the Prefix >> Information option." >> Similarly, RFC 4861 is not presecriptive: >> " A 1-bit autonomous address-configuration flag. When >> set indicates that this prefix can be used for >> stateless address configuration as specified in >> [ADDRCONF]." >> and RFC 6434 does not mention this issue. >> >> Personally I'd like to see a statement that a host that >> receives a PIO with A=3D1 MUST perform SLAAC, but that really >> doesn't seem to be specified anywhere. >=20 > That would make things super clearer and nicer, but I simply didn't > see the critical need for it. In fact, from a quick re-read of the > appendices of the draft, all tested implementations in all scenarios > perform SLAAC if they receive a PIO with A=3D1. It seems to be an > evidence that this point is already clear enough in practice. If somebody implements a new stack ten years from now, will it be clear to them? There's no emergency here, but maybe the next version of Node Requirements should add this point. Brian From nobody Sat May 9 17:44:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4050F1B2BC1; Sat, 9 May 2015 17:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Iu_DklJ0qXR; Sat, 9 May 2015 17:44:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD21A875E; Sat, 9 May 2015 17:44:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150510004402.20090.2720.idtracker@ietfa.amsl.com> Date: Sat, 09 May 2015 17:44:02 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-siit-eam-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 00:44:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Explicit Address Mappings for Stateless IP/ICMP Translation Authors : Tore Anderson Alberto Leiva Popper Filename : draft-ietf-v6ops-siit-eam-00.txt Pages : 17 Date : 2015-05-09 Abstract: This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-siit-eam-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 9 22:36:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09B1A012D for ; Sat, 9 May 2015 22:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSs_2Q856nLS for ; Sat, 9 May 2015 22:36:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD771A0127 for ; Sat, 9 May 2015 22:36:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVV96926; Sun, 10 May 2015 05:36:42 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 10 May 2015 06:36:41 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.195]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Sun, 10 May 2015 13:36:36 +0800 From: "Liushucheng (Will)" To: Tim Chown , "Fred Baker (fred)" Thread-Topic: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) Thread-Index: AQHQiEGEN8bXWSA+mkaX+eo0I1MLdZ1vHEsAgACAuACAAAmWAIAFDnRA Date: Sun, 10 May 2015 05:36:36 +0000 Message-ID: References: <554A83E3.4050503@gont.com.ar> <605643879.1947633.1430957100748.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.105] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB600D92C6SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Merike Kaeo , "v6ops@ietf.org" , Fernando Gont , "draft-ietf-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] Next steps for IPv6 EHs in Real World (draft-ietf-v6ops-ipv6-ehs-in-real-world) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 05:36:52 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB600D92C6SZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggVGltIGhlcmUuDQpUbyBiZSBtb3JlIGNvbmNlbnRyYXRl ZCwgSSB0aGluayBpdOKAmXMgYmV0dGVyIHRvIGtlZXAgdGhlIG1haW4gZm9jdXMgb2YgdGhpcyBk b2N1bWVudCBvbiB0aGUgb2JzZXJ2ZWQgZmFjdHMsIHRoZW4gbGVhdmUgdGhlIHJlc3QgdG8gYW5v dGhlciBkb2N1bWVudCBhcyBhIGZvbGxvdy11cC4NCg0KUmVnYXJkcywNCldpbGwgKFNodWNoZW5n IExJVSkNCg0KRnJvbTogVGltIENob3duIFttYWlsdG86dGpjQGVjcy5zb3Rvbi5hYy51a10NClNl bnQ6IFRodXJzZGF5LCBNYXkgMDcsIDIwMTUgNDoyMCBQTQ0KVG86IEZyZWQgQmFrZXIgKGZyZWQp DQpDYzogTWFyayBaWlogU21pdGg7IEZlcm5hbmRvIEdvbnQ7IHY2b3BzQGlldGYub3JnOyBkcmFm dC1pZXRmLXY2b3BzLWlwdjYtZWhzLWluLXJlYWwtd29ybGRAdG9vbHMuaWV0Zi5vcmc7IFY2b3Bz IENoYWlyczsgTWVyaWtlIEthZW8NClN1YmplY3Q6IFJlOiBbdjZvcHNdIE5leHQgc3RlcHMgZm9y IElQdjYgRUhzIGluIFJlYWwgV29ybGQgKGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1laHMtaW4tcmVh bC13b3JsZCkNCg0KSGksDQoNCk9uIDcgTWF5IDIwMTUsIGF0IDA4OjQ1LCBGcmVkIEJha2VyIChm cmVkKSA8ZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0K T24gTWF5IDcsIDIwMTUsIGF0IDEyOjA1IFBNLCBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRo QHlhaG9vLmNvbS5hdTxtYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4+IHdyb3RlOg0K DQpIaSwNCg0KSSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gb24gd2hldGhlciBpdCBzaG91 bGQgYmUgcmVpbmNvcnBvcmF0ZWQgb3Igbm90LCBhcyBJIGhhdmVuJ3Qga2VwdCB1cCB3aXRoIHRo YXQgZGlzY3Vzc2lvbi4NCg0KSG93ZXZlciwgaWYgaXQgZG9lcyBnZXQgaW5jbHVkZWQsIEkgdGhp bmsgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgbmVlZHMgbW9yZSBjbGFyaWZpY2F0aW9uOg0KDQoi TWFueSBJUHY2IHJvdXRlciBpbXBsZW1lbnRhdGlvbnMgc3VmZmVyIGZyb20gYSBuZWdhdGl2ZSBw ZXJmb3JtYW5jZQ0KICAgaW1wYWN0IHdoZW4gSVB2NiBFeHRlbnNpb24gSGVhZGVycyBhcmUgZW1w bG95ZWQuIg0KDQpJcyB0aGlzIHJlYWxseSB0aGUgY2FzZT8gSXQgc2VlbXMgdG8gbWUgdGhhdCB0 aGlzIGlzIHNheWluZyB0aGF0ICJNYW55IElQdjYgcm91dGVyIGltcGxlbWVudGF0aW9ucyIgYXJl IGluc3BlY3RpbmcgRUhzIGJ5IGRlZmF1bHQsIHdoaWNoIHRoZW4gbWVhbnMgbWFueSByb3V0ZXJz IGFyZSB2dWxuZXJhYmxlIHRvIHRoZSBFSCBiYXNlZCBEb1NlcyBhbmQgb3RoZXIgaXNzdWVzIG1l bnRpb25lZCBieSBkZWZhdWx0Lg0KDQpJZiBpdCBpcyB0aGUgY2FzZSwgSSB0aGluayB3ZSBuZWVk IGEgbGlzdCBvZiB0aG9zZSByb3V0ZXJzIHRoYXQgYnkgZGVmYXVsdCB2aW9sYXRlIFJGQyAyNDYw IGJ5IGluc3BlY3RpbmcgcGFzdCB0aGUgSGJIIGhlYWRlciB3aGVuIHRoZXkgYXJlIG5vdCB0aGUg ZGVzdGluYXRpb24gb2YgdGhlIHBhY2tldC4NCg0KV2hhdCBJIGhhdmUgYmVlbiB0cnlpbmcgdG8g Z2V0IEZlcm5hbmRvIHRvIGRvIGlzIGlkZW50aWZ5IHVuZGVyIHdoYXQgY29uZGl0aW9ucyB0aGF0 IG1pZ2h0IGJlIHRydWUsIHJhdGhlciB0aGFuIHBhaW50IGFsbCBlcXVpcG1lbnQgZnJvbSBhbGwg dmVuZG9ycyB1bmRlciBhbGwgY29uZGl0aW9ucyB3aXRoIHNsaW1lLiBJZiB0aGUgcm91dGVyIGhh cyBhIGZpbHRlciAoQUNMKSB0aGF0IGZvcmNlcyBpdCB0byBwYXJzZSB0aGUgaGVhZGVycyB0byBm aW5kIGEgVENQIGhlYWRlciwgYW5kIHRoZSBwYXJzaW5nIGlzIGR1bXBlZCB0byBhIHNsb3dlciBw YXRoLCB0aGF0IHdvdWxkIGJlIGFuIGV4YW1wbGUsIGFuZCB3b3VsZCBiZSBhIHZhbGlkIGV4YW1w bGUgdG8gYnJpbmcgb3V0LiBCdXQgSSBkb27igJl0IGFjY2VwdCBzbGltaW5nIGFsbCBlcXVpcG1l bnQgZnJvbSBhbGwgdmVuZG9ycyB1bmRlciBhbGwgY2lyY3Vtc3RhbmNlcy4gSXTigJlzIG5vdCB0 aGUgY2FzZS4NCg0KVGhlIG9yaWdpbmFsIHBvaW50IG9mIHRoZSBkcmFmdCwgd2hpY2ggaGFzIHBl cmhhcHMgYmVlbiBsb3N0IHNvbWV3aGF0IGFzIGRpc2N1c3Npb24gaGFzIGRyaWZ0ZWQsIHdhcyB0 byBoYW5kd2F2ZSB0byBhbiBvYnNlcnZhYmxlIHByb2JsZW0sIHRvIGltcGxpY2l0bHkgbm90ZSB0 aGVyZSB3YXMgYW4gaW1wYWN0IG9uIGFwcGxpY2F0aW9ucy9wcm90b2NvbHMgdXNpbmcgRUhzLCBh bmQgdG8gZW5jb3VyYWdlIG1vcmUgbWVhc3VyZW1lbnQvaW52ZXN0aWdhdGlvbiBvZiB0aGUgcHJv YmxlbS4NCg0KSSB0aGluayB0aGUgZGlzY3Vzc2lvbiB3ZeKAmXJlIG9uIG5vdyB3b3VsZCBiZSBi ZXR0ZXIgcHV0IGludG8gYSBmb2xsb3ctdXAgdGV4dCwgc28gd2UgY2FuIHNoaXAgdGhlIG9yaWdp bmFsIHByb2JsZW0gc3RhdGVtZW50LiBJIHN1c3BlY3QgdGhlIGZvbGxvdy11cCB3aWxsIGJlIG1v cmUgaGVhdmlseSBkZWJhdGVkLCB3aXRuZXNzIHRoZSAobGFjayBvZikgcHJvZ3Jlc3Npb24gb2Yg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRheWxvci12Nm9wcy1mcmFnZHJvcC0w MiwgYnV0IG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gc3RvcCB0aW5rZXJpbmcsIHRvIHNoaXAs IGFuZCBmb2N1cyBvbiBhIG5ldyBkb2N1bWVudC4NCg0KVGltDQoNCg0KDQpJJ2QgZXhwZWN0IHJv dXRlcnMgYnkgZGVmYXVsdCB0byBoYXZlIGp1c3QgcHJvY2Vzc2VkL2ZvcndhcmRlZCBJUHY2IHBh Y2tldHMgYmFzZWQgb24gdGhlIGZpeGVkIElQdjYgaGVhZGVyIGZpZWxkcywgaWdub3JpbmcgRUhz IGFuZCBhbGxvd2luZyBmYXN0IHBhdGggZm9yd2FyZGluZywgYW5kIHRvIG9ubHkgc3RhcnQgbG9v a2luZyBhdCBFSHMgaWYgY29uZmlndXJlZCB0byB2aWEgQUNMcyBldGMuDQoNCkkgdGhpbmsgdGhl IGFib3ZlIHN0YXRlbWVudCBpcyBlZmZlY3RpdmVseSBpbXBseWluZyB0aGF0IGZhc3QgcGF0aCBm b3J3YXJkaW5nIG9mIElQdjYgaXNuJ3QgYSBkZWZhdWx0IGluIG1hbnkgSVB2NiByb3V0ZXIgaW1w bGVtZW50YXRpb25zLCBhbmQgSSdkIGJlIHF1aXRlIHN1cnByaXNlZCBpZiB0aGF0IGlzIHRydWUs IHdoaWNoIGlzIHdoeSBJIHRoaW5rIG1vcmUgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSB1c2VmdWwu DQoNClJlZ2FyZHMsDQpNYXJrLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI8bWFpbHRvOmZlcm5hbmRv QGdvbnQuY29tLmFyPj4NClRvOiAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3Jn PiIgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpDYzogImRyYWZ0LWll dGYtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkQHRvb2xzLmlldGYub3JnPiIgPGRy YWZ0LWlldGYtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkQHRvb2xzLmlldGYub3Jn Pj47IFY2b3BzIENoYWlycyA8djZvcHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzp2Nm9w cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+PjsgTWVyaWtlIEthZW8gPG1lcmlrZUBkb3VibGVzaG90 c2VjdXJpdHkuY29tPG1haWx0bzptZXJpa2VAZG91Ymxlc2hvdHNlY3VyaXR5LmNvbT4+DQpTZW50 OiBUaHVyc2RheSwgNyBNYXkgMjAxNSwgNzoxMw0KU3ViamVjdDogW3Y2b3BzXSBOZXh0IHN0ZXBz IGZvciBJUHY2IEVIcyBpbiBSZWFsIFdvcmxkIChkcmFmdC1pZXRmLXY2b3BzLWlwdjYtZWhzLWlu LXJlYWwtd29ybGQpDQoNCkZvbGtzLA0KDQpRdWVzdGlvbiB0byB0aGUgd2c6DQoNCkZvbGtzIGtl ZXAgYnJpbmdpbmcgdXAgdGhlIHJlYXNvbnMgZm9yIHdoaWNoIG9wZXJhdG9ycyBmaWx0ZXIgSVB2 Ng0KcGFja2V0cyB3aXRoIEVIcyAodGhlIHJlYXNvbnMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBvbiB0 aGlzIG1haWxpbmctbGlzdCBhDQpmZXcgdGltZXMgYWxyZWFkeSkuIFNvbWV0aGluZyBhbG9uZyB0 aGVzZSBsaW5lcyB3YXMgcHJlc2VudCBpbiBTZWN0aW9uDQozIG9mDQo8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZC0wMT4N CmJ1dCB3ZSByZW1vdmVkIHRoYXQgc2VjdGlvbiBpbiBsYXRlciByZXZpc2lvbnMgKHByaW9yIHRv IHRoZSB3ZyBjYWxsIGZvcg0KYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCkuDQoNCkEgbnVtYmVy IG9mIGZvbGtzIGhhdmUgYXJndWVkIHRoYXQgd2Ugc2hvdWxkIHJlaW5jb3Jwb3JhdGUgdGhhdCBz ZWN0aW9uLg0KTWUsIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsLCBidXQgY2FuIGxpdmUgd2l0 aG91dCByZWluY29ycG9yYXRpbmcNCnRoYXQgc2VjdGlvbi4uLg0KDQpJdCB3b3VsZCBiZSBuaWNl IHRvIGhlYXIgZnJvbSB0aGUgd2cgYWJvdXQgdGhpcy4gVGhvdWdodHM/DQoNClRoYW5rcyENCg0K QmVzdCByZWdhcmRzLA0KLS0NCkZlcm5hbmRvIEdvbnQNCmUtbWFpbDogZmVybmFuZG9AZ29udC5j b20uYXI8bWFpbHRvOmZlcm5hbmRvQGdvbnQuY29tLmFyPiB8fCBmZ29udEBzaTZuZXR3b3Jrcy5j b208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbT4NClBHUCBGaW5nZXJwcmludDogNzgwOSA4 NEY1IDMyMkUgNDVDNyBGMUM5IDM5NDUgOTZFRSBBOUVGIEQwNzYgRkZGMQ0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcg bGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCg0K --_000_C9B5F12337F6F841B35C404CF0554ACB600D92C6SZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIFRpbSBoZXJlLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UbyBiZSBtb3JlIGNvbmNlbnRyYXRlZCwgSSB0aGlu ayBpdOKAmXMgYmV0dGVyIHRvIGtlZXAgdGhlIG1haW4gZm9jdXMgb2YgdGhpcyBkb2N1bWVudCBv biB0aGUgb2JzZXJ2ZWQgZmFjdHMsIHRoZW4gbGVhdmUgdGhlIHJlc3QgdG8gYW5vdGhlciBkb2N1 bWVudA0KIGFzIGEgZm9sbG93LXVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XaWxsIChTaHVjaGVuZyBMSVUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBUaW0gQ2hvd24gW21haWx0bzp0amNAZWNzLnNvdG9uLmFjLnVrXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBNYXkgMDcsIDIwMTUgNDoyMCBQTTxicj4NCjxiPlRvOjwvYj4gRnJlZCBC YWtlciAoZnJlZCk8YnI+DQo8Yj5DYzo8L2I+IE1hcmsgWlpaIFNtaXRoOyBGZXJuYW5kbyBHb250 OyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxk QHRvb2xzLmlldGYub3JnOyBWNm9wcyBDaGFpcnM7IE1lcmlrZSBLYWVvPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIE5leHQgc3RlcHMgZm9yIElQdjYgRUhzIGluIFJlYWwgV29ybGQg KGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13b3JsZCk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiA3IE1heSAyMDE1LCBhdCAwODo0NSwgRnJlZCBCYWtlciAoZnJl ZCkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSI+ZnJlZEBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1heSA3LCAyMDE1LCBhdCAxMjowNSBQTSwgTWFy ayBaWlogU21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAeWFob28uY29tLmF1 Ij5tYXJrenp6c21pdGhAeWFob28uY29tLmF1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBp ZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQz MDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDMwOTU1Mzc1ODQ3XzYyNjAi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHdoZXRo ZXIgaXQgc2hvdWxkIGJlIHJlaW5jb3Jwb3JhdGVkIG9yIG5vdCwgYXMgSSBoYXZlbid0IGtlcHQg dXAgd2l0aCB0aGF0IGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2 XzBfMV8xNDMwOTU1Mzc1ODQ3XzYyNjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIsIGlmIGl0 IGRvZXMgZ2V0IGluY2x1ZGVkLCBJIHRoaW5rIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IG5lZWRz IG1vcmUgY2xhcmlmaWNhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Inl1aV8zXzE2XzBfMV8xNDMwOTU1Mzc1ODQ3XzYyNjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8x XzE0MzA5NTUzNzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7TWFueSBJUHY2IHJv dXRlciBpbXBsZW1lbnRhdGlvbnMgc3VmZmVyIGZyb20gYSBuZWdhdGl2ZSBwZXJmb3JtYW5jZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5 NTUzNzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO2ltcGFjdCB3aGVu IElQdjYgRXh0ZW5zaW9uIEhlYWRlcnMgYXJlIGVtcGxveWVkLiZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjI2 MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JcyB0aGlzIHJlYWxseSB0aGUgY2FzZT8gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIGlz IHNheWluZyB0aGF0ICZxdW90O01hbnkgSVB2NiByb3V0ZXIgaW1wbGVtZW50YXRpb25zJnF1b3Q7 IGFyZSBpbnNwZWN0aW5nIEVIcyBieSBkZWZhdWx0LCB3aGljaCB0aGVuIG1lYW5zDQogbWFueSBy b3V0ZXJzIGFyZSB2dWxuZXJhYmxlIHRvIHRoZSBFSCBiYXNlZCBEb1NlcyBhbmQgb3RoZXIgaXNz dWVzIG1lbnRpb25lZCBieSBkZWZhdWx0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlf M18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiBpdCBpcyB0 aGUgY2FzZSwgSSB0aGluayB3ZSBuZWVkIGEgbGlzdCBvZiB0aG9zZSByb3V0ZXJzIHRoYXQgYnkg ZGVmYXVsdCB2aW9sYXRlIFJGQyAyNDYwIGJ5IGluc3BlY3RpbmcgcGFzdCB0aGUgSGJIIGhlYWRl ciB3aGVuIHRoZXkgYXJlIG5vdCB0aGUNCiBkZXN0aW5hdGlvbiBvZiB0aGUgcGFja2V0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUz NzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5XaGF0IEkgaGF2ZSBiZWVuIHRyeWluZyB0byBnZXQgRmVybmFuZG8gdG8g ZG8gaXMgaWRlbnRpZnkgdW5kZXIgd2hhdCBjb25kaXRpb25zIHRoYXQgbWlnaHQgYmUgdHJ1ZSwg cmF0aGVyIHRoYW4gcGFpbnQgYWxsIGVxdWlwbWVudCBmcm9tIGFsbCB2ZW5kb3JzDQogdW5kZXIg YWxsIGNvbmRpdGlvbnMgd2l0aCBzbGltZS4gSWYgdGhlIHJvdXRlciBoYXMgYSBmaWx0ZXIgKEFD TCkgdGhhdCBmb3JjZXMgaXQgdG8gcGFyc2UgdGhlIGhlYWRlcnMgdG8gZmluZCBhIFRDUCBoZWFk ZXIsIGFuZCB0aGUgcGFyc2luZyBpcyBkdW1wZWQgdG8gYSBzbG93ZXIgcGF0aCwgdGhhdCB3b3Vs ZCBiZSBhbiBleGFtcGxlLCBhbmQgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlIHRvIGJyaW5nIG91 dC4gQnV0IEkgZG9u4oCZdCBhY2NlcHQNCiBzbGltaW5nIGFsbCBlcXVpcG1lbnQgZnJvbSBhbGwg dmVuZG9ycyB1bmRlciBhbGwgY2lyY3Vtc3RhbmNlcy4gSXTigJlzIG5vdCB0aGUgY2FzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG9yaWdpbmFs IHBvaW50IG9mIHRoZSBkcmFmdCwgd2hpY2ggaGFzIHBlcmhhcHMgYmVlbiBsb3N0IHNvbWV3aGF0 IGFzIGRpc2N1c3Npb24gaGFzIGRyaWZ0ZWQsIHdhcyB0byBoYW5kd2F2ZSB0byBhbiBvYnNlcnZh YmxlIHByb2JsZW0sIHRvIGltcGxpY2l0bHkgbm90ZSB0aGVyZSB3YXMgYW4gaW1wYWN0IG9uIGFw cGxpY2F0aW9ucy9wcm90b2NvbHMgdXNpbmcgRUhzLCBhbmQNCiB0byBlbmNvdXJhZ2UgbW9yZSBt ZWFzdXJlbWVudC9pbnZlc3RpZ2F0aW9uIG9mIHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGUgZGlzY3Vzc2lvbiB3 ZeKAmXJlIG9uIG5vdyB3b3VsZCBiZSBiZXR0ZXIgcHV0IGludG8gYSBmb2xsb3ctdXAgdGV4dCwg c28gd2UgY2FuIHNoaXAgdGhlIG9yaWdpbmFsIHByb2JsZW0gc3RhdGVtZW50LiBJIHN1c3BlY3Qg dGhlIGZvbGxvdy11cCB3aWxsIGJlIG1vcmUgaGVhdmlseSBkZWJhdGVkLCB3aXRuZXNzIHRoZSAo bGFjayBvZikgcHJvZ3Jlc3Npb24gb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdGF5bG9yLXY2b3BzLWZyYWdkcm9wLTAyIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGF5bG9yLXY2b3BzLWZyYWdkcm9wLTAyPC9hPiwNCiBidXQgbXkg cHJlZmVyZW5jZSB3b3VsZCBiZSB0byBzdG9wIHRpbmtlcmluZywgdG8gc2hpcCwgYW5kIGZvY3Vz IG9uIGEgbmV3IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGltPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjI2MCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8x NDMwOTU1Mzc1ODQ3XzYyNjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkknZCBleHBlY3Qgcm91dGVycyBi eSBkZWZhdWx0IHRvIGhhdmUganVzdCBwcm9jZXNzZWQvZm9yd2FyZGVkIElQdjYgcGFja2V0cyBi YXNlZCBvbiB0aGUgZml4ZWQgSVB2NiBoZWFkZXIgZmllbGRzLCBpZ25vcmluZyBFSHMgYW5kIGFs bG93aW5nIGZhc3QgcGF0aA0KIGZvcndhcmRpbmcsIGFuZCB0byBvbmx5IHN0YXJ0IGxvb2tpbmcg YXQgRUhzIGlmIGNvbmZpZ3VyZWQgdG8gdmlhIEFDTHMgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjI2MCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J IHRoaW5rIHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgZWZmZWN0aXZlbHkgaW1wbHlpbmcgdGhhdCBm YXN0IHBhdGggZm9yd2FyZGluZyBvZiBJUHY2IGlzbid0IGEgZGVmYXVsdCBpbiBtYW55IElQdjYg cm91dGVyIGltcGxlbWVudGF0aW9ucywgYW5kIEknZA0KIGJlIHF1aXRlIHN1cnByaXNlZCBpZiB0 aGF0IGlzIHRydWUsIHdoaWNoIGlzIHdoeSBJIHRoaW5rIG1vcmUgY2xhcmlmaWNhdGlvbiB3b3Vs ZCBiZSB1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlf M18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDMwOTU1 Mzc1ODQ3XzYyNjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182MjYwIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5NYXJrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDMwOTU1Mzc1ODQ3XzY0MjYiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5 NTUzNzU4NDdfNjQyNSI+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182NDI3 Ij4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiIGlkPSJ5 dWlfM18xNl8wXzFfMTQzMDk1NTM3NTg0N182NzgyIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4NCiBGZXJuYW5kbyBHb250ICZsdDs8YSBocmVmPSJtYWlsdG86ZmVybmFu ZG9AZ29udC5jb20uYXIiPmZlcm5hbmRvQGdvbnQuY29tLmFyPC9hPiZndDs8YnI+DQo8YiBpZD0i eXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjc4NSI+VG86PC9iPiAmcXVvdDs8YSBocmVmPSJt YWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8 YiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjc4NyI+Q2M6PC9iPiAmcXVvdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkQHRvb2xz LmlldGYub3JnIj5kcmFmdC1pZXRmLXY2b3BzLWlwdjYtZWhzLWluLXJlYWwtd29ybGRAdG9vbHMu aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi12Nm9wcy1p cHY2LWVocy1pbi1yZWFsLXdvcmxkQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXY2b3BzLWlw djYtZWhzLWluLXJlYWwtd29ybGRAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OzsNCiBWNm9wcyBDaGFp cnMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnY2b3Bz LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4mZ3Q7OyBNZXJpa2UgS2FlbyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1lcmlrZUBkb3VibGVzaG90c2VjdXJpdHkuY29tIj5tZXJpa2VAZG91Ymxlc2hvdHNl Y3VyaXR5LmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIDcgTWF5IDIw MTUsIDc6MTM8YnI+DQo8YiBpZD0ieXVpXzNfMTZfMF8xXzE0MzA5NTUzNzU4NDdfNjc4OSI+U3Vi amVjdDo8L2I+IFt2Nm9wc10gTmV4dCBzdGVwcyBmb3IgSVB2NiBFSHMgaW4gUmVhbCBXb3JsZCAo ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkKTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Inl1aV8zXzE2XzBfMV8xNDMwOTU1Mzc1ODQ3XzY0MjQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCkZvbGtzLDxicj4NCjxicj4NClF1ZXN0aW9uIHRvIHRoZSB3 Zzo8YnI+DQo8YnI+DQpGb2xrcyBrZWVwIGJyaW5naW5nIHVwIHRoZSByZWFzb25zIGZvciB3aGlj aCBvcGVyYXRvcnMgZmlsdGVyIElQdjY8YnI+DQpwYWNrZXRzIHdpdGggRUhzICh0aGUgcmVhc29u cyBoYXZlIGJlZW4gZGlzY3Vzc2VkIG9uIHRoaXMgbWFpbGluZy1saXN0IGE8YnI+DQpmZXcgdGlt ZXMgYWxyZWFkeSkuIFNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lcyB3YXMgcHJlc2VudCBpbiBT ZWN0aW9uPGJyPg0KMyBvZjxicj4NCiZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ29udC12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkLTAxIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnQtdjZvcHMtaXB2 Ni1laHMtaW4tcmVhbC13b3JsZC0wMTwvYT4mZ3Q7PGJyPg0KYnV0IHdlIHJlbW92ZWQgdGhhdCBz ZWN0aW9uIGluIGxhdGVyIHJldmlzaW9ucyAocHJpb3IgdG8gdGhlIHdnIGNhbGwgZm9yPGJyPg0K YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCkuPGJyPg0KPGJyPg0KQSBudW1iZXIgb2YgZm9sa3Mg aGF2ZSBhcmd1ZWQgdGhhdCB3ZSBzaG91bGQgcmVpbmNvcnBvcmF0ZSB0aGF0IHNlY3Rpb24uPGJy Pg0KTWUsIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsLCBidXQgY2FuIGxpdmUgd2l0aG91dCBy ZWluY29ycG9yYXRpbmc8YnI+DQp0aGF0IHNlY3Rpb24uLi48YnI+DQo8YnI+DQpJdCB3b3VsZCBi ZSBuaWNlIHRvIGhlYXIgZnJvbSB0aGUgd2cgYWJvdXQgdGhpcy4gVGhvdWdodHM/PGJyPg0KPGJy Pg0KVGhhbmtzITxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQotLSA8YnI+DQpGZXJuYW5k byBHb250PGJyPg0KZS1tYWlsOiA8YSBocmVmPSJtYWlsdG86ZmVybmFuZG9AZ29udC5jb20uYXIi PmZlcm5hbmRvQGdvbnQuY29tLmFyPC9hPiB8fCA8YSBocmVmPSJtYWlsdG86ZmdvbnRAc2k2bmV0 d29ya3MuY29tIj4NCmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT48YnI+DQpQR1AgRmluZ2VycHJp bnQ6IDc4MDkgODRGNSAzMjJFIDQ1QzcgRjFDOSAzOTQ1IDk2RUUgQTlFRiBEMDc2IEZGRjE8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C9B5F12337F6F841B35C404CF0554ACB600D92C6SZXEMA509MBSchi_-- From nobody Sun May 10 01:51:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A971A1A99 for ; Sun, 10 May 2015 01:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_-b0v_XoJq7 for ; Sun, 10 May 2015 01:51:00 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A23F1A1A76 for ; Sun, 10 May 2015 01:50:59 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::3] (port=42204 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YrMwq-0008Pm-Ol; Sun, 10 May 2015 10:50:56 +0200 Date: Sun, 10 May 2015 10:50:56 +0200 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150510105056.032937ad@envy.fud.no> In-Reply-To: <20150510004402.20090.2720.idtracker@ietfa.amsl.com> References: <20150510004402.20090.2720.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-siit-eam-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 08:51:02 -0000 * internet-drafts@ietf.org > https://tools.ietf.org/html/draft-ietf-v6ops-siit-eam-00 Hello WG, This new version has a new file name in order to reflect the WG adoption that happened in Dallas. Noteworthy changes since draft-anderson-v6ops-siit-eam-03: * New co-author: Alberto Leiva Popper, NIC M=C3=A9xico * Added a section discussing hairpinning of traffic between IPv6 nodes * Additional examples in the appendix describing hairpinned packets I hope you'll take the time to read the draft and send any comments you might have to the v6ops list or to the authors directly. Tore From nobody Sun May 10 04:47:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E611A88F2 for ; Sun, 10 May 2015 04:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm4zCuU3FFnV for ; Sun, 10 May 2015 04:47:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD171A87B2 for ; Sun, 10 May 2015 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125; q=dns/txt; s=iport; t=1431258424; x=1432468024; h=date:from:message-id:to:subject:cc; bh=RLl2hlwcj+IMvcF/D8dUVOCCWlRapV4Tde5PWfz/fOk=; b=VXUU9CNky6NqQRdwEi2jhnxNSW67PZBt5synoV+HJj5iSE+7RQ4Bltbv nycQ2pI3++wM2KwvKl9eQuzeieM09jzhEJOhyJoTuZkXnbnzQLZOwigzR MaPUAk3MivmPQkw5Bgu39VNb50mfdtwheeguYB5nkspX/WK4F+RUOkCRh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DUBQDNRE9V/4MNJK1cgw9UX7YxAZARhXwJgRtMAQEBAQEBgQuEI308NIkMAQ3GOQELAR+LOYUFHYQXBYwbikCHaT6DHJFZI4QXgxUBAQE X-IronPort-AV: E=Sophos;i="5.13,401,1427760000"; d="scan'208";a="418464055" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 10 May 2015 11:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4ABl3pi028035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2015 11:47:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t4ABl2gS001374; Sun, 10 May 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t4ABl1li001372; Sun, 10 May 2015 04:47:01 -0700 Date: Sun, 10 May 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201505101147.t4ABl1li001372@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-siit-eam@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-siit-eam X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-siit-eam. Please take a look at it and comment. From nobody Sun May 10 17:51:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060491A901F for ; Sun, 10 May 2015 17:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.7 X-Spam-Level: ** X-Spam-Status: No, score=2.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzhwA5A-vLoL for ; Sun, 10 May 2015 17:51:17 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F951A8A7B for ; Sun, 10 May 2015 17:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431305476; bh=VUXBhSm3XUzjuNboYvDRrcyWgKdCOAaZ+auQE31Cw5g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qcnwfUL0okMgVYy7pcyQIMPOPu3wShO/RQE7fLZhqHy4WX5+PRzA718KOWjpe+e4eEJKYxrSxVtmc7Z2proo1mO/JLPfzXSiZO9qGZy6EmN5ZeLRBgnomPGKPoT+tCKyejn09H40vuWq6SyydIGkwvw4v9UyFiBGyloLErHbpdx829LaKGSGErIGY/s3Gr13AgGnJcHfFTN+dmH+DZ3EtsSs5PFaVuR0YoAueBnQgiQL/u9vFzeEm/mC7ZZEuVZS3TPmb/WRdU8ud01aJJdAJ//jDE6Z7YPRB9NpNSHymoIENN8L3OoVb6qngiqS3UQncWFkEZRTkWDBjUn+xj/44Q== Received: from [98.139.170.179] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2015 00:51:16 -0000 Received: from [98.139.215.228] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2015 00:51:16 -0000 Received: from [127.0.0.1] by omp1068.mail.bf1.yahoo.com with NNFMP; 11 May 2015 00:51:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 835208.62086.bm@omp1068.mail.bf1.yahoo.com X-YMail-OSG: tbpzOesVM1ksH0lWM7y83UwkCLEacsfWDHGd9vLQQnVNxK3J9F._I3L0blKGZf8 SZLKZ38heEXzlFgytMw1YgI1urm0FQhm0.z_ndSYuFafdyVtYTqpP4dg.3qJ8hLvztNuoqhJmFgp ms2TqDmtUWSG_ZqulxtM91QCqWaqxVPO2VbFBJfRH5MwbmC0gpXUmb2iRtBlG8vCDLKmK.FywfFn gXcmoylXIicUT0zj1TAZSefIuehWhHaxqfSdHTtR_BK3DXoS08.V5lbZsgDIlGQhQ31bGHA.PV5a qoIIPOxDyXWnDJ56K_Z48Mm3GjL83ZfhMvxRRL8AiKN4yMMi1dqqYmhqoH71VDiPRPmDid4NmAaZ rm94L3eMTmQTk0wb.HTeVjpL2Np6xCy0kK7zxmrYY5FbDOvm8OOW2htqTb77tUaYtl8ONB8x6Zdf _x9FVcacyTL3mzMCcoaKlTXSdlOM2xeue6uUCY0eTo2JedQFP2ngg0u16.bTGIZG4BljfxS8QiXR Mw.rRGb1hAQlh6OcODPlXPGDXshAb6ptbulYNPtW9mcS.29gBzA-- Received: by 66.196.80.124; Mon, 11 May 2015 00:51:16 +0000 Date: Mon, 11 May 2015 00:51:15 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , =?UTF-8?B?56We5piO6YGU5ZOJ?= Message-ID: <1698191846.4634200.1431305475826.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <554E723B.2080708@gmail.com> References: <554E723B.2080708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 00:51:19 -0000 Hi, > > That would make things super clearer and nicer, but I simply didn't > see the critical need for it. In fact, from a quick re-read of the > appendices of the draft, all tested implementations in all scenarios > perform SLAAC if they receive a PIO with A=1. It seems to be an > evidence that this point is already clear enough in practice. If somebody implements a new stack ten years from now, will it be clear to them? There's no emergency here, but maybe the next version of Node Requirements should add this point. / I think there might be value in publishing it, because I think it shows clear misunderstanding of a few IPv6 addressing concepts that are different to or might tightly coupled together in IPv4: / - address/IID value generation is separate from / - address configuration, which is separate from / - address expiry/ageing / I think the some of the problems identified are due to coupling/binding together the last two, when I think in IPv6 they're nearly or completely independent. / Regards, Mark. Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun May 10 18:59:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F0A1A0049 for ; Sun, 10 May 2015 18:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ozy4OoVnogp for ; Sun, 10 May 2015 18:59:41 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78DC1A003A for ; Sun, 10 May 2015 18:59:41 -0700 (PDT) Received: by oign205 with SMTP id n205so93978107oig.2 for ; Sun, 10 May 2015 18:59:41 -0700 (PDT) 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; bh=gihpMPhZubHAKO9Bn5wOpvaIONr/YiDng7tsmfK+6l4=; b=m+u9nyE5NvecKbWl/dlcIKpJ0Z9NfkboULEaxi0Jh2WAxEen7g3GPqQ6DkZ5U5DpGB nHSZrgkQEcyWEdToYdM2O5DfsaRRnoeZV+NoQ5jkrhXY42IoFeamR4r/2xZX+YNix47M FsJjRAfI0rCKi70w9S9flpdB3IKDWTZsEXXKfmFlUEPM+lK6VqpDImzZ5NMJJBK+wWhn zckSRs+xWcDZP7r7ELAoQUQ/uk9i0HVF0/5Sxb3/3taMAecmOLglyOEEqwEN6Cid9rsU +e1Qezct4RaeRE/jNUmoFhvZ7KZ1RIq0jvdbS94Xzl22gWvWzeS6CTJf9fLTgPhOlc0a Bc6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gihpMPhZubHAKO9Bn5wOpvaIONr/YiDng7tsmfK+6l4=; b=NhMoEZLJ78GxbXaT3ZkqTt+Y54SdywvvtWYkBPW+C03sRZVUi03wheZu2nsqvdOOn1 lwncuMWD/G7nr2gdwRQ0PSW/qjTuyJpwVNhGXQu5if9kckWsYbhqUpI8xzDc69wXPXj9 vzkkcfeBzZRpWtXv9DEtkAj0xYbrGzXwmUgDf+n0qFRaNZD3Tcd1thrXgnxBKTHN/Ro5 YiWm1Z3ToJ/o04v32q2EbPm/iWgrIe+zo+HDIGhSSq7aRQYc7w/FSJp8zi/8WZv3gACl V95PdDD2BWg+7OJ+AqvN+RfxSB/6KM0EgtLAr/Bb2tPKixSoC5Cd+kis1to3n5YsW5Jn cXyA== X-Gm-Message-State: ALoCoQlbDXfNBIUXiUtrryqPfx0BKG+BcegibO8SO7vHoFO8p3XIX3XALoLPzwrDE82NA5Sok96U X-Received: by 10.202.201.3 with SMTP id z3mr5999426oif.130.1431309580872; Sun, 10 May 2015 18:59:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.160.65 with HTTP; Sun, 10 May 2015 18:59:20 -0700 (PDT) In-Reply-To: References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 11 May 2015 10:59:20 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a1134e9a021e3c90515c4bbb9 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 01:59:43 -0000 --001a1134e9a021e3c90515c4bbb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2015 at 2:27 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > Observing the posting, let me invite commentary on it. > > It seems that the main points of my previous comments > - http://www.ietf.org/mail-archive/web/v6ops/current/msg20179.html > - http://www.ietf.org/mail-archive/web/v6ops/current/msg20200.html > still apply. > > So my conclusion is the same: What he said. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem= -04.txt shows that there are no changes in this document except that the text from appendix B moved to section 3 and some minor editorial changes. I don't see why such minor changes should materially change the WG's position on this document. --001a1134e9a021e3c90515c4bbb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 5, 2015 at 2:27 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
> Observing t= he posting, let me invite commentary on it.

It seems that the main points of my previous comments
- http://www.ietf.org/mail-archive/web/v6ops/current/ms= g20179.html
- http://www.ietf.org/mail-archive/web/v6ops/current/ms= g20200.html
still apply.

So my conclusion is the same:
=C2=A0
What he sai= d. https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6o= ps-dhcpv6-slaac-problem-04.txt shows that there are no changes in this = document except that the text from appendix B moved to section 3 and some m= inor editorial changes. I don't see why such minor changes should mater= ially change the WG's position on this document.
--001a1134e9a021e3c90515c4bbb9-- From nobody Sun May 10 23:44:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8D1A1B45 for ; Sun, 10 May 2015 23:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-yXGHXmbT8T for ; Sun, 10 May 2015 23:44:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45501A1B0E for ; Sun, 10 May 2015 23:44:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVW74323; Mon, 11 May 2015 06:44:18 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 May 2015 07:44:17 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 11 May 2015 14:44:12 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt Thread-Index: AQHQhhIsrmVcKMcySUitbChD26jFFJ1qkl4AgAD6jgCACf0DAIAAyagQ Date: Mon, 11 May 2015 06:44:12 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEF7B2@nkgeml506-mbx.china.huawei.com> References: <20150504022905.7563.62204.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F457CEEF7B2nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 06:44:22 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F457CEEF7B2nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQuDQoNCkkgdGhpbmsgbXkgYW5v dGhlciBtYWlsIHJpZ2h0IGFmdGVyIHRoZSBkcmFmdC1wb3N0ZWQgbWFpbCBtaWdodCBhbnN3ZXIg eW91ciBxdWVzdGlvbiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3Bz L2N1cnJlbnQvbXNnMjIwNDcuaHRtbCkuIFBsZWFzZSBhbGxvdyBtZSB0byBpdGVyYXRlIG91ciB0 aG91Z2h0cyBicmllZmx5Og0KDQoxKSAgICAgIFRoZSBXR+KAmXMgcG9zaXRpb24gb24gbGFzdCBX R0xDIHZhcmllZC4gQW5kIGVhY2ggb2YgdGhlIHZpZXdwb2ludCBoYWQgb25seSBmZXcgcGVvcGxl LCBzbyBJIGNvdWxkbuKAmXQgZmlndXJlIG91dCB3aGljaCByZXByZXNlbnRlZCB0aGUgbWFpbiB2 b2ljZSBvZiB0aGUgV0cuDQoNCi0gICAgICAgIHNvbWUgc3VwcG9ydGVkIHRvIG1vdmUgZm9yd2Fy ZA0KDQotICAgICAgICBzb21lIHRob3VnaHQgdGhlIHByb2JsZW1zIHdlcmUgbm90IGNyaXRpY2Fs DQoNCi0gICAgICAgIHNvbWUgc3VnZ2VzdGVkIHRvIHNoYXBlIGl0IHRvIGEgdGVzdCByZXBvcnQN Cg0KDQoyKSAgICAgIFdlIGNoYW5nZWQgb3VyIHBvc2l0aW9uIHRvIE5PVCBtYWtlIHRoZSBkcmFm dCBhcyBhIGZvcm1hbCBQcm9ibGVtIFN0YXRlbWVudCB0byBraWNrIG9mZiBhIHByb3RvY29sIHJl dmlzaW9uIHdvcmsgaW4gNm1hbi4gU28gd2UgcmUtcGhyYXNlZCB0aGUgdGl0bGUgdG8gbW92ZSB0 aGUga2V5IHdvcmRzIOKAnFByb2JsZW0gU3RhdGVtZW504oCdLg0KDQoNCjMpICAgICAgV2UgdGhv dWdodCBtYXliZSBpdCdzIGdvb2QgdG8gbGVhdmUgdGhlIHRlc3QgcmVzdWx0cyBpbiB0aGUgYXBw ZW5kaXggcmF0aGVyIHRoYW4gbWFraW5nIGl0IGFzIHRoZSBtYWluIGNvbnRlbnQuIEJlY2F1c2Ug dGhlIG9wZXJhdGluZyBzeXN0ZW1zIGFyZSB1cGRhdGluZyBhbGwgdGhlIHRpbWUsIHRoZSBiZWhh dmlvcnMgZG9jdW1lbnRlZCBtaWdodCBwcm9iYWJseSBjaGFuZ2VkIGluIGZ1dHVyZSBvcGVyYXRp bmcgc3lzdGVtIHZlcnNpb25zLiBUaGUgZG9jdW1lbnRlZCBiZWhhdmlvcnMgYXJlIG9ubHkgZm9y IHByb3ZpbmcgdGhlIGFuYWx5emVkIGRpdmVyZ2VuY2UgY291bGQgcHJvYmFibHkgaGFwcGVuIGlu IHJlYWwgaW1wbGVtZW50YXRpb25zLg0KDQpTbywgdGhpcyByZXZpc2lvbiB3YXMgbm90IGludGVu ZCB0byBkaXJlY3RseSBmb3IgYW5vdGhlciBXR0xDLCBidXQgdG8gY29uZmlybSB3aGV0aGVyIG91 ciBXRyBhZ3JlZSBvdXIgdGhvdWdodHMuIFdpdGggdGhlIGFib3ZlIGV4cGxhbmF0aW9uLCBkb2Vz IGl0IGFkZHJlc3MgeW91ciBjb25jZXJuPw0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCkZyb206 IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVu em8gQ29saXR0aQ0KU2VudDogTW9uZGF5LCBNYXkgMTEsIDIwMTUgOTo1OSBBTQ0KVG86IOelnuaY jumBlOWTiQ0KQ2M6IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtLTA0LnR4dA0KDQpP biBUdWUsIE1heSA1LCAyMDE1IGF0IDI6MjcgQU0sIOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUu YWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4gd3JvdGU6DQo+IE9ic2VydmluZyB0aGUg cG9zdGluZywgbGV0IG1lIGludml0ZSBjb21tZW50YXJ5IG9uIGl0Lg0KDQpJdCBzZWVtcyB0aGF0 IHRoZSBtYWluIHBvaW50cyBvZiBteSBwcmV2aW91cyBjb21tZW50cw0KLSBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cyMDE3OS5odG1sDQotIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzIwMjAw Lmh0bWwNCnN0aWxsIGFwcGx5Lg0KDQpTbyBteSBjb25jbHVzaW9uIGlzIHRoZSBzYW1lOg0KDQpX aGF0IGhlIHNhaWQuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDQudHh0IHNob3dzIHRoYXQgdGhlcmUgYXJl IG5vIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCBleGNlcHQgdGhhdCB0aGUgdGV4dCBmcm9tIGFw cGVuZGl4IEIgbW92ZWQgdG8gc2VjdGlvbiAzIGFuZCBzb21lIG1pbm9yIGVkaXRvcmlhbCBjaGFu Z2VzLiBJIGRvbid0IHNlZSB3aHkgc3VjaCBtaW5vciBjaGFuZ2VzIHNob3VsZCBtYXRlcmlhbGx5 IGNoYW5nZSB0aGUgV0cncyBwb3NpdGlvbiBvbiB0aGlzIGRvY3VtZW50Lg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F457CEEF7B2nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NjA1NDMyNTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU4NDUyMTM0MiAxMDY0NjIwMTE2IDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjExOTkwNTA1NzI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xNDY2OTUxMTIyIDEyNzEwNTEwNDggNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNS4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxOTc5OTE3NjMzOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc3ODYyMjI4MiAxNjI0NjU2MTUy IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBM b3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlv dXIgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBt eSBhbm90aGVyIG1haWwgcmlnaHQgYWZ0ZXIgdGhlIGRyYWZ0LXBvc3RlZCBtYWlsIG1pZ2h0IGFu c3dlciB5b3VyIHF1ZXN0aW9uIChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv djZvcHMvY3VycmVudC9tc2cyMjA0Ny5odG1sKS4NCiBQbGVhc2UgYWxsb3cgbWUgdG8gaXRlcmF0 ZSBvdXIgdGhvdWdodHMgYnJpZWZseTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFdH4oCZcyBwb3NpdGlvbiBvbiBsYXN0 IFdHTEMgdmFyaWVkLiBBbmQgZWFjaCBvZiB0aGUgdmlld3BvaW50IGhhZCBvbmx5IGZldyBwZW9w bGUsIHNvIEkgY291bGRu4oCZdCBmaWd1cmUgb3V0IHdoaWNoIHJlcHJlc2VudGVkIHRoZQ0KIG1h aW4gdm9pY2Ugb2YgdGhlIFdHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjUuMnB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNvbWUgc3VwcG9ydGVkIHRvIG1v dmUgZm9yd2FyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjUuMnB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNvbWUgdGhvdWdodCB0aGUgcHJvYmxlbXMgd2Vy ZSBub3QgY3JpdGljYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI1LjJwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5zb21lIHN1Z2dlc3RlZCB0byBzaGFwZSBp dCB0byBhIHRlc3QgcmVwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBjaGFuZ2VkIG91 ciBwb3NpdGlvbiB0byBOT1QgbWFrZSB0aGUgZHJhZnQgYXMgYSBmb3JtYWwgUHJvYmxlbSBTdGF0 ZW1lbnQgdG8ga2ljayBvZmYgYSBwcm90b2NvbCByZXZpc2lvbiB3b3JrIGluIDZtYW4uIFNvIHdl IHJlLXBocmFzZWQNCiB0aGUgdGl0bGUgdG8gbW92ZSB0aGUga2V5IHdvcmRzIOKAnFByb2JsZW0g U3RhdGVtZW504oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldlIHRob3VnaHQgbWF5YmUgaXQncyBnb29kIHRvIGxlYXZlIHRoZSB0ZXN0 IHJlc3VsdHMgaW4gdGhlIGFwcGVuZGl4IHJhdGhlciB0aGFuIG1ha2luZyBpdCBhcyB0aGUgbWFp biBjb250ZW50LiBCZWNhdXNlIHRoZSBvcGVyYXRpbmcNCiBzeXN0ZW1zIGFyZSB1cGRhdGluZyBh bGwgdGhlIHRpbWUsIHRoZSBiZWhhdmlvcnMgZG9jdW1lbnRlZCBtaWdodCBwcm9iYWJseSBjaGFu Z2VkIGluIGZ1dHVyZSBvcGVyYXRpbmcgc3lzdGVtIHZlcnNpb25zLiBUaGUgZG9jdW1lbnRlZCBi ZWhhdmlvcnMgYXJlIG9ubHkgZm9yIHByb3ZpbmcgdGhlIGFuYWx5emVkIGRpdmVyZ2VuY2UgY291 bGQgcHJvYmFibHkgaGFwcGVuIGluIHJlYWwgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgdGhpcyByZXZpc2lvbiB3YXMgbm90IGludGVuZCB0 byBkaXJlY3RseSBmb3IgYW5vdGhlciBXR0xDLCBidXQgdG8gY29uZmlybSB3aGV0aGVyIG91ciBX RyBhZ3JlZSBvdXIgdGhvdWdodHMuIFdpdGggdGhlIGFib3ZlIGV4cGxhbmF0aW9uLCBkb2VzDQog aXQgYWRkcmVzcyB5b3VyIGNvbmNlcm4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMTEsIDIwMTUgOTo1OSBBTTxicj4NCjxiPlRvOjwv Yj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7npZ7mmI7pgZTlk4k8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5DYzo8 L2I+IHY2b3BzQGlldGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDQudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g VHVlLCBNYXkgNSwgMjAxNSBhdCAyOjI3IEFNLCA8L3NwYW4+56We5piO6YGU5ZOJPHNwYW4gbGFu Zz0iRU4tVVMiPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIiB0YXJnZXQ9 Il9ibGFuayI+amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBPYnNl cnZpbmcgdGhlIHBvc3RpbmcsIGxldCBtZSBpbnZpdGUgY29tbWVudGFyeSBvbiBpdC48YnI+DQo8 YnI+DQpJdCBzZWVtcyB0aGF0IHRoZSBtYWluIHBvaW50cyBvZiBteSBwcmV2aW91cyBjb21tZW50 czxicj4NCi0gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2 b3BzL2N1cnJlbnQvbXNnMjAxNzkuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjAxNzkuaHRtbDwvYT48 YnI+DQotIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9w cy9jdXJyZW50L21zZzIwMjAwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzIwMjAwLmh0bWw8L2E+PGJy Pg0Kc3RpbGwgYXBwbHkuPGJyPg0KPGJyPg0KU28gbXkgY29uY2x1c2lvbiBpcyB0aGUgc2FtZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IGhlIHNhaWQuIDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZv cHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDQudHh0Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0tMDQudHh0 PC9hPiBzaG93cyB0aGF0IHRoZXJlIGFyZSBubyBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgZXhj ZXB0IHRoYXQgdGhlIHRleHQgZnJvbSBhcHBlbmRpeCBCIG1vdmVkIHRvIHNlY3Rpb24gMyBhbmQg c29tZSBtaW5vciBlZGl0b3JpYWwgY2hhbmdlcy4gSSBkb24ndCBzZWUgd2h5IHN1Y2ggbWlub3Ig Y2hhbmdlcw0KIHNob3VsZCBtYXRlcmlhbGx5IGNoYW5nZSB0aGUgV0cncyBwb3NpdGlvbiBvbiB0 aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F457CEEF7B2nkgeml506mbxchi_-- From nobody Mon May 11 08:38:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4377B1ACC85 for ; Mon, 11 May 2015 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGWkr7FtSnIz for ; Mon, 11 May 2015 08:38:16 -0700 (PDT) Received: from tor-smtp-02.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88B1A9058 for ; Mon, 11 May 2015 08:38:14 -0700 (PDT) Received: from [24.114.82.201] (helo=[172.20.10.4]) by tor-smtp-02.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YrpmX-0001Hh-Cm; Mon, 11 May 2015 11:38:13 -0400 From: Philip Matthews Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 May 2015 11:38:11 -0400 Message-Id: To: v6ops list Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.82.201] Archived-At: Subject: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:38:21 -0000 Folks: Victor and I have been talking with the chairs about the Design Choices = draft, and have convinced us act on a request from Michael Ackermann to = extend the Design Choices draft to cover EIGRP. To do this, we are looking for information on dual-stack networks that = run EIGRP. Specifically we want to get feedback on production dual-stack networks = that run EIGRP. We are interested in any of the following combinations: * EIGRP for both IPv4 and IPv6 * EIGRP for IPv4 and OSPF/ISIS for IPv6 * OSPF/ISIS for IPv4 and EIGRP for IPv6 If you know of any such networks, then please email either Victor or = myself. (If you are concerned about doing this, then you could email one = of the chairs instead). Our goal is to get answers to the following questions: 1) Is this combination known to work well -- in other words, have = multiple production networks used it without problems? 2) Why was this particular dual-stack combination chosen?=20 3) Any comments or pieces of advice that you would like to pass on? Philip From nobody Mon May 11 13:36:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF11A902A for ; Mon, 11 May 2015 13:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wprIoSkF7RYF for ; Mon, 11 May 2015 13:36:42 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92EB1A9022 for ; Mon, 11 May 2015 13:36:41 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so118606485pab.2 for ; Mon, 11 May 2015 13:36:41 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lMH0FeFBvG31Qx9gliINiHne4G5TBHhHCPooQIVeSZk=; b=KAvHFI8QiCtojfQEzq7x3pn1YZTR1mIV7GNfJT/tqI3hmQHjilWk+gFid6XMApenVF kFlVtcjzjUuUm5zlAwIXoV3OYLAv+P1xMAx1uCGaelDQ9UTkX7JYz6+fj1+KrYBq5nKt hEwM0LHS5xIRxYxmynIl2jLJxx1bujhH9nUEU3c3332yiEAp3vgTwOFdxAlzHEKPYKdH J84ckjCB8WayJbloDb5TGFn97/ia2CDpi5bwvoJMl+m6J/6a7qUdPpVvsxKmA2igwt41 EI5a4hSqZ5ylBLR4sEBGBz8TRe1Vkljarm4m93XrWEKq6Tq4M+CNT4G2fsNFCLw0ack/ BALg== X-Received: by 10.68.205.226 with SMTP id lj2mr21645739pbc.52.1431376601450; Mon, 11 May 2015 13:36:41 -0700 (PDT) Received: from ?IPv6:2406:e007:54d7:1:28cc:dc4c:9703:6781? ([2406:e007:54d7:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id gj5sm13949904pbb.22.2015.05.11.13.36.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 13:36:40 -0700 (PDT) Message-ID: <555112D8.3000008@gmail.com> Date: Tue, 12 May 2015 08:36:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Philip Matthews , v6ops list References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 20:36:43 -0000 On 12/05/2015 03:38, Philip Matthews wrote: > Folks: > > Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP. If I'm not mistaken, that's a proprietary protocol that isn't even described in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I think you need to explain *why* it's appropriate to do this in an IETF stream draft. If you go ahead, I would suggest putting this topic in an appendix. Brian From nobody Mon May 11 16:17:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766001AC3A2 for ; Mon, 11 May 2015 16:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZNZ8p628T7x for ; Mon, 11 May 2015 16:17:51 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1767F1AC39C for ; Mon, 11 May 2015 16:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431386270; bh=pepE3gW9MsXuOQ6wCLRAu3AJCRpkCIl6hd0/k9ArLaE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qCd8yWp3VxrpWoqfeZVFTbw8FcpgY/50qsoP7XBHHtRIVNVE/Fzlve7H/Grj+bKcoGGK89yryl58kbw53Jsj8g+AcpphDCCU9hxYwemJhDTjr4JU08nrl7ajmUprKsadblTt6m1HiJrE49411T4lwEQTpeqt2MYYXXyO2UyJwhvF2V2SrOrUk6tWWo0vnwhvSXMheIMev9kgTl7ORAt5Pkw0ga5Kj02R24ZgJNKVvREs/A0Kp6PHX93u/F49IqT7Xp+76eGnRg9GMH82FOxd4ELRI7LNOq/sePINDzH42opLnAUmuLSYLSttYmZomUA3d/9akPFWCycGrwiR5GbVTA== Received: from [98.139.215.142] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2015 23:17:50 -0000 Received: from [98.139.212.234] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2015 23:17:45 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 11 May 2015 23:17:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 995883.69701.bm@omp1043.mail.bf1.yahoo.com X-YMail-OSG: CHI6Aw0VM1ksXsq6qJtahyLcrEFvjKZ7Px1sc5E1FB2jNeQjqCuwkPbZL0Q.6PX zTdFp6LOUIg0wXDYCUeuCs9qzOck7VdtmMWL_C9fspk8MA4zqC8PLM6u3yO8K19b9QTv2ROLZjHc uk3vv1BBq1Uv_91tzOPllw7gh3I2gxrrAqWCbpclxSVRIpi_D0MNg4d5XrhJbN8e1oDz8hUHkeC5 RB7kYU_GWpUSN7cvBK6CHqEvGKHcs6Dzjdb1GM8fRMhTv4fJkTnBY8hNJcm34eT0EVKAaN2RTtub Kij_o0AUrDiEgzWTqPatZGatRY63L69n0StSwWmaRz5yPZ0xPePiVUA90ZQhrvqc8.7vLuLAuRFZ 7dR2vYOvLqzZnZwBSD2s6aYmbKgMdxDq1Jpnx82X8zsOpWst4Xj_vdgxO6Zpf6Iz0WJ7zot0oxYR eQGwHf6X3Qsq8LyeBVqgTfNO6v22VgSj7zvI6lqRyCSjVvnIW2aHLCLajpSISvv3lD.jk9OU0KeZ _RWcPx08iGcG50MOG85WUdQjEZ0IZ4sNCNKGm3Tj3.lGNI3x_sA-- Received: by 76.13.27.48; Mon, 11 May 2015 23:17:44 +0000 Date: Mon, 11 May 2015 23:17:43 +0000 (UTC) From: Mark ZZZ Smith To: Brian E Carpenter , Philip Matthews , v6ops list Message-ID: <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <555112D8.3000008@gmail.com> References: <555112D8.3000008@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_113934_1478568983.1431386263757" Archived-At: Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:17:52 -0000 ------=_Part_113934_1478568983.1431386263757 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Brian E Carpenter To: Philip Matthews ; v6ops list =20 Sent: Tuesday, 12 May 2015, 6:36 Subject: Re: [v6ops] EIGRP and the Design Choices draft =20 On 12/05/2015 03:38, Philip Matthews wrote: > Folks: >=20 > Victor and I have been talking with the chairs about the Design Choices d= raft, and have convinced us act on a request from Michael Ackermann to exte= nd the Design Choices draft to cover EIGRP. If I'm not mistaken, that's a proprietary protocol that isn't even describe= d in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I = think you need to explain *why* it's appropriate to do this in an IETF stream dra= ft. If you go ahead, I would suggest putting this topic in an appendix. / Regardless of whether or not EIGRP makes it into the draft, it could be w= orth mentioning that the deployment of IPv6 is also an good opportunity to = deploy a non-proprietary IGP, and perhaps at a later date migrate IPv4 to u= sing the new IGP too if it supports multiple protocol families. =C2=A0 =C2=A0 Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_113934_1478568983.1431386263757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= hr size=3D"1"> From: Brian E= Carpenter <brian.e.carpenter@gmail.com>
To: Philip Matthews <philip_matthews@magma.ca&g= t;; v6ops list <v6ops@ietf.org>
Sent: Tuesday, 12 May 2015, 6:36
Subject: Re: [v6ops] EIGRP and the Design Choic= es draft

On 12/05/2015 03:38, Philip Matthews wrote:
> Folks:
>
> V= ictor and I have been talking with the chairs about the Design Choices draf= t, and have convinced us act on a request from Michael Ackermann to extend = the Design Choices draft to cover EIGRP.

If I'm not mistaken, that's a proprietary protocol that isn't even descr= ibed in an
RFC (although there seems to be a stalled draf= t under consideration as an
Independent Submission RFC). = While I don't object to describing reality, I think
you n= eed to explain *why* it's appropriate to do this in an IETF stream draft.
If you go ahead, I would suggest puttin= g this topic in an appendix.

/ Regardless of whether = or not EIGRP makes it into the draft, it could be worth mentioning that the= deployment of IPv6 is also an good opportunity to deploy a non-proprietary= IGP, and perhaps at a later date migrate IPv4 to using the new IGP too if = it supports multiple protocol families.

   = Brian




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


------=_Part_113934_1478568983.1431386263757-- From nobody Mon May 11 17:27:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A031B2AB6 for ; Mon, 11 May 2015 17:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fas4vLjBQ1J for ; Mon, 11 May 2015 17:26:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9581B2AB2 for ; Mon, 11 May 2015 17:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1431390412; x=1432600012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H9hN9GlTKCObbfp4tCWhgHxITuw4PcJHOtvXfeSRTRs=; b=b/3KwKUQK9gpi7JGK5u+hdR4xQ9nV1EAqpyio6qPZFjgui1CMrLhsMyp kXYgjxYjB+EbolQPHQe2n6fzc3LyvqgaO6KfCphoP35Xwqnsb4aFqJJ2v 8WhSozpzi60inlDWg6XyRxzp0QrgtokhXKcN9/3lAU1zCTmGCmpBsHnlX c=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBACiR1FV/5xdJa1cgw9UXgbEeAmBVIYJAoE5OBQBAQEBAQEBgQqEIAEBAQMBeQULAgEIGC4hESUCBA4FDogJAwoIDcNnDYURAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYJNgjgHgxeBFgWSPYIFgTxdhHCBVYEkhlaHbYZwI2GBJR+BUm8BgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,411,1427760000"; d="asc'?scan'208";a="149199733" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 12 May 2015 00:26:52 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4C0QpvD015848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 00:26:52 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.148]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 11 May 2015 19:26:51 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjEpXjlt1NCr7O0ao6Uml7l8H1Q== Date: Tue, 12 May 2015 00:26:51 +0000 Message-ID: <4E8599FE-FF80-4556-9434-4E62BEB8501F@cisco.com> References: <555112D8.3000008@gmail.com> In-Reply-To: <555112D8.3000008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: multipart/signed; boundary="Apple-Mail=_E528745B-038E-4DAE-9DB9-EC63974B017B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:26:58 -0000 --Apple-Mail=_E528745B-038E-4DAE-9DB9-EC63974B017B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 11, 2015, at 1:36 PM, Brian E Carpenter = wrote: > On 12/05/2015 03:38, Philip Matthews wrote: >> Folks: >>=20 >> Victor and I have been talking with the chairs about the Design = Choices draft, and have convinced us act on a request from Michael = Ackermann to extend the Design Choices draft to cover EIGRP. >=20 > If I'm not mistaken, that's a proprietary protocol that isn't even = described in an > RFC (although there seems to be a stalled draft under consideration as = an > Independent Submission RFC). While I don't object to describing = reality, I think > you need to explain *why* it's appropriate to do this in an IETF = stream draft. How would you characterize Babel? Read the header on page 1 of RFC 6126 = before responding. This difference, as near as I can tell, is that the = draft made it through the ISE to RFC. That and the fact that a whole lot = more people use EIGRP (enough to have it requested during a WGLC = discussion) than use Babel. draft-boutier-babel-source-specific-00.txt draft-chroboczek-babel-doesnt-care-00.txt draft-chroboczek-babel-extension-mechanism-04.txt draft-chroboczek-babel-security-considerations-00.txt draft-mrw-homenet-rtg-comparison-02.txt https://tools.ietf.org/html/rfc6126 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT=3D99833 bytes) (Updated by RFC7298) (Status: EXPERIMENTAL) https://tools.ietf.org/html/rfc7298 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication. D. Ovsienko. July 2014. (Format: TXT=3D128503 = bytes) (Updates RFC6126) (Status: EXPERIMENTAL) --Apple-Mail=_E528745B-038E-4DAE-9DB9-EC63974B017B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVVFIyJ9ieig10VPpAQKPfQgAqc8i7RjiWgWz6dBEP0db3FN0j7M4wiPs VGTBsNQDXs8nk6zkNJ45Rb8ezqQfjSucDu/TnP2ISU8VRUti87v8wUOPU+PsyNnW lrlxwpZsuHr42QvdnjrmAJLdZJadhxTZN6KUlgNF3cH+boj/PpDlRfvRA5ovnez9 qbslpXozCQfeXP/lbGQ09Et4zFHkHumgrf1N1shJhRbKmS8eRoxFZQhEYkpZPgQ/ CFAK9yqu0bLJQWyXiY0RSOP8DLT8ubPmK9jhJ8V6EzeZQN6POPSL7b7IEEgLYH0h M/xoNmTL5h1XiQph4BugjXTn8XTJcR++rAdhzZXK59m99alW/YxGMQ== =/dpd -----END PGP SIGNATURE----- --Apple-Mail=_E528745B-038E-4DAE-9DB9-EC63974B017B-- From nobody Mon May 11 17:30:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263961B2ABA for ; Mon, 11 May 2015 17:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56N_zrOR_yw2 for ; Mon, 11 May 2015 17:30:50 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FB61B2AB5 for ; Mon, 11 May 2015 17:30:50 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CED33DA006F; Tue, 12 May 2015 00:30:49 +0000 (UTC) Received: from [192.168.1.67] (67.184.177.30) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 11 May 2015 17:30:49 -0700 References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 (1.0) In-Reply-To: <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Mon, 11 May 2015 20:30:47 -0400 To: Mark ZZZ Smith X-Originating-IP: [67.184.177.30] Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:30:51 -0000 To put an even finer point on it, one of the big problems with EIGRP at this= point is that although that are many interoperating implementations, they w= ere implemented using a reference implementation, not a spec, so there is no= spec that got the kind of interop testing that multiple independent impleme= ntations would have given us. Getting to that now would be very difficult, s= ince there's no real incentive for anybody to do a complete new implementati= on now. So while indeed it might be good to write down the spec for posteri= ty and the benefit of sharing experience, I don't think it'd make a lot of s= ense as an IETF standard.=20= From nobody Mon May 11 17:33:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD01B2AB2 for ; Mon, 11 May 2015 17:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZVQUNBs6kDk for ; Mon, 11 May 2015 17:33:37 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48AD1B2AA9 for ; Mon, 11 May 2015 17:33:37 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id AEC7EDA006F; Tue, 12 May 2015 00:33:37 +0000 (UTC) Received: from [192.168.1.67] (67.184.177.30) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 11 May 2015 17:33:37 -0700 References: <555112D8.3000008@gmail.com> <4E8599FE-FF80-4556-9434-4E62BEB8501F@cisco.com> MIME-Version: 1.0 (1.0) In-Reply-To: <4E8599FE-FF80-4556-9434-4E62BEB8501F@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <44120D6A-2F95-4996-8F91-CE5DD890A300@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Mon, 11 May 2015 20:33:36 -0400 To: "Fred Baker (fred)" X-Originating-IP: [67.184.177.30] Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:33:39 -0000 On May 11, 2015, at 8:26 PM, Fred Baker (fred) wrote: >=20 > How would you characterize Babel? Read the header on page 1 of RFC 6126 be= fore responding. This difference, as near as I can tell, is that the draft m= ade it through the ISE to RFC. That and the fact that a whole lot more peopl= e use EIGRP (enough to have it requested during a WGLC discussion) than use B= abel. Babel has two interoperating implementations that were done independently, t= he first of which produced RFC 6126, and the second of which interoperates w= ith it after being implemented using RFC 6126 as a specification. So from an= IETF perspective it is actually farther along, despite the fact that what y= ou say about EIGRP is quite true.=20= From nobody Mon May 11 17:36:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C781A89D3 for ; Mon, 11 May 2015 17:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNKhIrnOGuAv for ; Mon, 11 May 2015 17:36:34 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4136D1B2AB2 for ; Mon, 11 May 2015 17:36:34 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 6AC3D28209B for ; Mon, 11 May 2015 19:36:33 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id DCDF3281FF2; Mon, 11 May 2015 19:36:32 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 36944128002; Mon, 11 May 2015 20:30:32 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva1.bcbsm.com (Postfix) with ESMTP id 1FF91128001; Mon, 11 May 2015 20:30:32 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000; Mon, 11 May 2015 20:36:32 -0400 From: "Ackermann, Michael" To: Brian E Carpenter , Philip Matthews , v6ops list Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjACI6mlqkVb91Eq8+ObxWWjWPJ13f2sA///NoHA= Date: Tue, 12 May 2015 00:36:31 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CDD4E69@PWN401EA160.ent.corp.bcbsm.com> References: <555112D8.3000008@gmail.com> In-Reply-To: <555112D8.3000008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.83.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 75b8b657-030b-41a1-851c-d497906cc4e7 X-VPM-MSG-ID: fda18297-fac2-4769-adbe-78d7b41c6ced X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:36:39 -0000 As perhaps one of the individuals responsible for this idea. I realize = EIGRP is proprietary protocol and therefore possibly not appropriate for = IETF consideration. =20 But the reason I would even ask, is that EIGRP deployment within = Enterprise/Corporate Networks, is nearly ubiquitous. These are the same = large networks that need guidance and motivation to get serious about IPv6 = deployment. Optimal configuration of the primary routing protocol, in = dual stack environments, is likely to be a significant success factor. = Providing related information and experiences could give us E/C Networks = one less reason to delay IPv6 deployments, which is what most of us are = doing currently. =20 So although I understand the potential inappropriateness, please consider = this a call for help from those of us trying to evangelize IPv6 in = corporate networks. =20 -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Brian E = Carpenter Sent: Monday, May 11, 2015 4:37 PM To: Philip Matthews; v6ops list Subject: Re: =5Bv6ops=5D EIGRP and the Design Choices draft On 12/05/2015 03:38, Philip Matthews wrote: > Folks: >=20 > Victor and I have been talking with the chairs about the Design Choices = draft, and have convinced us act on a request from Michael Ackermann to = extend the Design Choices draft to cover EIGRP. If I'm not mistaken, that's a proprietary protocol that isn't even = described in an RFC (although there seems to be a stalled draft under = consideration as an Independent Submission RFC). While I don't object to = describing reality, I think you need to explain *why* it's appropriate to = do this in an IETF stream draft. If you go ahead, I would suggest putting this topic in an appendix. Brian _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Mon May 11 17:43:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321D1A1BE7 for ; Mon, 11 May 2015 17:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsFKmLDaHggN for ; Mon, 11 May 2015 17:43:42 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E265F1B2AD4 for ; Mon, 11 May 2015 17:43:40 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.13,411,1427774400"; d="scan'208,217";a="685156358" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 May 2015 20:25:44 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 11 May 2015 20:43:39 -0400 From: "Howard, Lee" To: Mark ZZZ Smith , Brian E Carpenter , Philip Matthews , v6ops list Date: Mon, 11 May 2015 20:43:38 -0400 Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AdCMTLA1ITk8olWGRvGEQcvNqFt0cw== Message-ID: References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D176C39EB15C6LeeHowardtwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:43:44 -0000 --_000_D176C39EB15C6LeeHowardtwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Mark ZZZ Smith > Reply-To: Mark ZZZ Smith > Date: Monday, May 11, 2015 at 7:17 PM To: Brian Carpenter >, Philip Matthews >, 'IPv6 Operations' > Subject: Re: [v6ops] EIGRP and the Design Choices draft ________________________________ From: Brian E Carpenter > To: Philip Matthews >; v6ops list > Sent: Tuesday, 12 May 2015, 6:36 Subject: Re: [v6ops] EIGRP and the Design Choices draft On 12/05/2015 03:38, Philip Matthews wrote: > Folks: > > Victor and I have been talking with the chairs about the Design Choices d= raft, and have convinced us act on a request from Michael Ackermann to exte= nd the Design Choices draft to cover EIGRP. If I'm not mistaken, that's a proprietary protocol that isn't even describe= d in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I = think you need to explain *why* it's appropriate to do this in an IETF stream dra= ft. IETF documents talk about lots of things that aren=92t IETF protocols. The= re have been requests in the WG to include consideration of this protocol. = So, as you say, let=92s describe reality. Why do we need to explain why thi= s protocol is being included, and not explain why all others are (or aren= =92t) being included? If you go ahead, I would suggest putting this topic in an appendix. / Regardless of whether or not EIGRP makes it into the draft, it could be w= orth mentioning that the deployment of IPv6 is also an good opportunity to = deploy a non-proprietary IGP, and perhaps at a later date migrate IPv4 to u= sing the new IGP too if it supports multiple protocol families. Please clarify. What makes EIGRP a poor design choice for an IPv6 network? Lee Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_D176C39EB15C6LeeHowardtwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Date: Monday, May 11, 2015 at 7:17 = PM
To: Brian Carpenter <brian.e.carpenter@gmail.com>, Ph= ilip Matthews <philip_matthe= ws@magma.ca>, 'IPv6 Operations' <v6ops@ietf.org>
Subject: Re: [v6ops] EIGRP and the = Design Choices draft


= From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Philip Matthews <philip_matthews@magma.ca>;= v6ops list <v6ops@ietf.org>
Sent: Tuesday, 12 May 2015= , 6:36
Subject: Re: [v6ops] EIGRP= and the Design Choices draft

On 12/05/2015 03:38, Philip Matthews wrote:
> Folks:
>
> Victor and I have been talking with the chairs about the Design Choice= s draft, and have convinced us act on a request from Michael Ackermann to e= xtend the Design Choices draft to cover EIGRP.

If I'm not mistaken, that's a proprietary protocol that isn't even describe= d in an
RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I = think
you need to explain *why* it's appropriate to do this in an IETF stream dra= ft.

<hat off>
IETF documents talk about lots of things that aren=92t IETF protocols.=  There have been requests in the WG to include consideration of this = protocol. So, as you say, let=92s describe reality. Why do we need to expla= in why this protocol is being included, and not explain why all others are (or aren=92t) being included?



If you go ahead, I would suggest putting this topic in an appendix.

/ Regardless of whether or not EIGRP makes it into the draft, it could be w= orth mentioning that the deployment of IPv6 is also an good opportunity to = deploy a non-proprietary IGP, and perhaps at a later date migrate IPv4 to u= sing the new IGP too if it supports multiple protocol families.

Please clarify. What makes EIGRP a poor design choice for an IPv6 netw= ork?

</hat off>

Lee



    Brian




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



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_D176C39EB15C6LeeHowardtwcablecom_-- From nobody Mon May 11 17:44:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E351B2AE1 for ; Mon, 11 May 2015 17:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU5wmHJWfQk6 for ; Mon, 11 May 2015 17:44:56 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FB81A1BE7 for ; Mon, 11 May 2015 17:44:56 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4C01CDA006F; Tue, 12 May 2015 00:44:56 +0000 (UTC) Received: from [192.168.1.67] (67.184.177.30) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 11 May 2015 17:44:55 -0700 References: MIME-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Mon, 11 May 2015 20:44:54 -0400 To: Philip Matthews X-Originating-IP: [67.184.177.30] Archived-At: Cc: v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:44:58 -0000 On May 11, 2015, at 11:38 AM, Philip Matthews wro= te: >=20 > Victor and I have been talking with the chairs about the Design Choices dr= aft, and have convinced us act on a request from Michael Ackermann to extend= the Design Choices draft to cover EIGRP. Based on the conversation thus far, I have to ask: is this the homenet routi= ng design team document, or some other document I hadn't heard of before? If= it's for homenet, I think asking about corporate infrastructure choices is a= bit off topic. If it's for something else, then I tend to agree that the q= uestion about EIGRP is worth asking, although my observations about its appr= opriateness as a future IETF standard still stand.= From nobody Mon May 11 17:47:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DD1B2ACD for ; Mon, 11 May 2015 17:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3wV-uL6pvRF for ; Mon, 11 May 2015 17:47:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766B61B2ACB for ; Mon, 11 May 2015 17:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2349; q=dns/txt; s=iport; t=1431391629; x=1432601229; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pL5v3zpJ+EwvFURou9iLdIgqRJzYcxGeVy2wp/lY8iw=; b=cAR+leRlqnvXEaB88CtFU+aQMXR5qNrgarQcF92TCXcS5jT5jI/TBrNH lvd8h1ckrL7+r4XHE+2UnCkBZECAdr5EOetTnudXvuphWCcpXAsSeGQxD 1U0SxPS6T5QnHshzOm7NYM/LItrAq/ChJfUuhl7RSp5luPMIqA7HPl9Uh A=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQDmTFFV/5tdJa1cgw9UXgaDGMNDhgUCgTlMAQEBAQEBgQuEIAEBAQMBI1YFCwIBCBgqAgIyJQIEDgUOiBYIDbUKk24BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs5hQUHgmgvgRYFkkCCBYE8XYZGllojYYMWb4FFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,411,1427760000"; d="asc'?scan'208";a="418904826" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 May 2015 00:47:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4C0l8Ld029905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 00:47:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.148]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 11 May 2015 19:47:08 -0500 From: "Fred Baker (fred)" To: Ted Lemon Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjE0sYrn2GrJMIUulEDsLaGATPg== Date: Tue, 12 May 2015 00:47:08 +0000 Message-ID: References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> In-Reply-To: <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: multipart/signed; boundary="Apple-Mail=_414E8EBE-67E8-4219-8020-1F6617B485EF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:47:11 -0000 --Apple-Mail=_414E8EBE-67E8-4219-8020-1F6617B485EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 11, 2015, at 5:30 PM, Ted Lemon wrote: >=20 > To put an even finer point on it, one of the big problems with EIGRP = at this point is that although that are many interoperating = implementations, they were implemented using a reference implementation, = not a spec, so there is no spec that got the kind of interop testing = that multiple independent implementations would have given us. Getting = to that now would be very difficult, since there's no real incentive for = anybody to do a complete new implementation now. So while indeed it = might be good to write down the spec for posterity and the benefit of = sharing experience, I don't think it'd make a lot of sense as an IETF = standard. My point on RFC 6126 is that it=E2=80=99s not an IETF standard either, = yet homenet appears to be deciding to standardize on it. I don=E2=80=99t know the status of Donnie Savage=E2=80=99s draft = (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the = EIGRP data formats are well known, the algorithms are well known, and if = the vector metric patent and the DUAL patent haven=E2=80=99t expired, = they're about to. As you say, there are multiple implementations around. = What I=E2=80=99m looking at is a request for commentary in a draft = making comments on the operational use of routing protocols. --Apple-Mail=_414E8EBE-67E8-4219-8020-1F6617B485EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVVFNiZ9ieig10VPpAQIa6wf9ENwY3wa5OWeny3+1f4TWiU8t1NR0wcOe +NSjTVOyL0fXOHCICNQ5r+L6DBrE1LcnXgAAjrSsnjQkPJBRnopAgA8Q11kOigTQ kDwdK3XiWJJ9zIw3gYT6uHMpUe4Bsbp4Vl1vOtuczcOH8iQ4Rh1eeEK0QWj2vrXu ag/o75qV1T8IzAJ5fMZbsL8wD+ipIyP4HxazyNsJedXlWBuYxu/cShU7KTeUF0Mo fbLT5YSGdi5OYp/lRPT6jP4mZpsRfN6fqqDiOt5Y+VTK5Rh+Ro2StZeT/y11w3wz L/jdU/RqFvZMM8RDPSIMhkgSKrEzg7DcWJTrH43Pprhwdbo2Xh2KFw== =OW0D -----END PGP SIGNATURE----- --Apple-Mail=_414E8EBE-67E8-4219-8020-1F6617B485EF-- From nobody Mon May 11 17:49:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077761B2ACF for ; Mon, 11 May 2015 17:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfCy3tbeoaxK for ; Mon, 11 May 2015 17:49:39 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851161B2AC4 for ; Mon, 11 May 2015 17:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1427; q=dns/txt; s=iport; t=1431391780; x=1432601380; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RJaOhhe+q0+kXvhJYyMSxgCsWEr6Hx34QBawbo00x8g=; b=Pd+sPeX2a6jHpflkC7pwf0uDAjgZGuwsWO9ceUy2I0M8FZJFmZzcwU27 tbtsQf6X+3kml4mjKrDVI3w+LmJsmJ7DLXYVMFU60Ew1DPkTlMNx3jJAM bG5BaZZ1JB9iOyttLjWWIRSxEh6uJhlXb+s7xagUKhttm4VDS/EMBK+Os g=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQCXTVFV/4QNJK1cgw9UXgbFBIFahgMCgTk6EgEBAQEBAQGBCoQgAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFggNyHcBAQEBAQEBAQEBAQEBAQEBAQEaizmFBQeDF4EWBZJAggWBPIcjllojYYMWbwGBRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,411,1427760000"; d="asc'?scan'208";a="149060570" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 12 May 2015 00:49:39 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4C0ncWK030513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 00:49:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.148]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 11 May 2015 19:49:38 -0500 From: "Fred Baker (fred)" To: "Ackermann, Michael" Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjE2FYrn2GrJMIUulEDsLaGATPg== Date: Tue, 12 May 2015 00:49:37 +0000 Message-ID: References: <555112D8.3000008@gmail.com> <4FC37E442D05A748896589E468752CAA0CDD4E69@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDD4E69@PWN401EA160.ent.corp.bcbsm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.124] Content-Type: multipart/signed; boundary="Apple-Mail=_8B0E81BA-0BAC-4AA7-A69C-3179C34090B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:49:41 -0000 --Apple-Mail=_8B0E81BA-0BAC-4AA7-A69C-3179C34090B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 11, 2015, at 5:36 PM, Ackermann, Michael = wrote: >=20 > But the reason I would even ask, is that EIGRP deployment within = Enterprise/Corporate Networks, is nearly ubiquitous. These are the = same large networks that need guidance and motivation to get serious = about IPv6 deployment. A web page dated 2008: = http://www.techtutorials.net/articles/ipv6_training_cisco_how_to_enable_ip= v6_eigrp.html --Apple-Mail=_8B0E81BA-0BAC-4AA7-A69C-3179C34090B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVVFOHp9ieig10VPpAQI19wf/Tqyj2brsfx9De3TnQ6fQjxQ8UByhZ6ZD cmd+sLNT5w76Z1HIsCsWPv+kV1WdbwwCU7OeBov3DB3Ky4Mo3AcJ82Y9OJ9AQCl3 XgXpnVFDyFNJHDhinVL5oxNL9qYpyRU3GDZzI8+/kF91d+Zo8GI+1HPklwSZoe2y h3p1UOxxt492tq6+k8lXdYR6y73eiSzkA1y2f1AizgPUPboqOeOy1K9BE4MREo8Q 3/rKWON0K4ZFg9zR5tE8Tquyf7Rbovog5d8XDLIzk/5ZXGcWpkF3jCEqWN0N4Qnp 2ZnKbLhZMb/ebA1Bg036PBvCqcpL8cSdfQu5nRJ9WCcvGDzZyEQYWQ== =3qrN -----END PGP SIGNATURE----- --Apple-Mail=_8B0E81BA-0BAC-4AA7-A69C-3179C34090B9-- From nobody Mon May 11 18:06:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889E01B2B02 for ; Mon, 11 May 2015 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg6fM6MiIm64 for ; Mon, 11 May 2015 18:06:40 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769481B2AF7 for ; Mon, 11 May 2015 18:06:40 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so124403809pac.0 for ; Mon, 11 May 2015 18:06:40 -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=Es7vnv4EZpnRxVbA+Yqqfllj0P0RmPvvi4M0ys6tJFM=; b=i5lOVcDaEBrVwZFnRkSamiZmEPOyT5APgeOOiQ0ck3PjJ4nf3xoZmZSTv3Xz0MvSEi sP2+5/+MBCOAmQMf/6R6BOZnHceUuN7dlBoFKihK9o8pUjSziYMcNG8gkYZqH8Bv0RJT 9MbNlhaTeyUcj/9YVCAxqWSUd7hMBgRfeKrhxF/7//dkCGDmMiAyPpTtd+cWyLczRfWu WwYA38+Tgu/6ozrCTVjkJUqmMKKnEsvd1hYxFqxtf2OusTcQMzLug++s6ii3bhya7abn pQz08xWO+qMgYE63GYO/R5c9oA1XOS4/UDltgTPZ7KoX4Fosv5rtTjmG1dOkR0wcA2Ea lkOQ== X-Received: by 10.69.15.132 with SMTP id fo4mr23517764pbd.57.1431392800159; Mon, 11 May 2015 18:06:40 -0700 (PDT) Received: from ?IPv6:2406:e007:54d7:1:28cc:dc4c:9703:6781? ([2406:e007:54d7:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ff10sm14318674pab.13.2015.05.11.18.06.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 18:06:38 -0700 (PDT) Message-ID: <5551521E.9070804@gmail.com> Date: Tue, 12 May 2015 13:06:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Ted Lemon References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:06:42 -0000 On 12/05/2015 12:47, Fred Baker (fred) wrote: >=20 >> On May 11, 2015, at 5:30 PM, Ted Lemon wrote: >> >> To put an even finer point on it, one of the big problems with EIGRP a= t this point is that although that are many interoperating implementation= s, they were implemented using a reference implementation, not a spec, so= there is no spec that got the kind of interop testing that multiple inde= pendent implementations would have given us. Getting to that now would be= very difficult, since there's no real incentive for anybody to do a comp= lete new implementation now. So while indeed it might be good to write d= own the spec for posterity and the benefit of sharing experience, I don't= think it'd make a lot of sense as an IETF standard. >=20 > My point on RFC 6126 is that it=E2=80=99s not an IETF standard either, = yet homenet appears to be deciding to standardize on it. Well yes, but it's open source and there has been a serious discussion ab= out moving it to the standards track, with Alia describing to the homenet WG what th= at would involve. Again: I'm not against documenting reality, with reasonable justification= =2E But it has to be carefully positioned vs standardised solutions. That's w= hy I suggested an appendix. So we'd end up with something like 2.3.1. IGP Choice One of the main decisions for an IPv6 implementer is the choice of IGP (Interior Gateway Protocol) within the network. The primary options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308], though some operators may consider RIP [RFC2080] or non-standardized protocols. Here we limit our discussion to the pros and cons of OSPF vs. IS-IS. Appendix A discusses the widely used non-standardized EIGRP protocol. Brian >=20 > I don=E2=80=99t know the status of Donnie Savage=E2=80=99s draft (https= ://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the EIGRP data= formats are well known, the algorithms are well known, and if the vector= metric patent and the DUAL patent haven=E2=80=99t expired, they're about= to. As you say, there are multiple implementations around. What I=E2=80=99= m looking at is a request for commentary in a draft making comments on th= e operational use of routing protocols. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon May 11 18:36:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47F1B2B2D for ; Mon, 11 May 2015 18:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2n1CsOUiFGD for ; Mon, 11 May 2015 18:36:00 -0700 (PDT) Received: from tor-smtp-03.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id 50D221ACE01 for ; Mon, 11 May 2015 18:36:00 -0700 (PDT) Received: from bas5-ottawa10-3096711390.dsl.bell.ca ([184.148.16.222] helo=[10.0.1.23]) by tor-smtp-03.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1Yrz70-0004N3-QT; Mon, 11 May 2015 21:35:59 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Philip Matthews In-Reply-To: <5551521E.9070804@gmail.com> Date: Mon, 11 May 2015 21:35:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <484105B3-6A82-4084-89F4-129595D2AE27@magma.ca> References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <5551521E.9070804@gmail.com> To: Brian E Carpenter , "Fred Baker (fred)" , Ted Lemon X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-3096711390.dsl.bell.ca ([10.0.1.23]) [184.148.16.222] Archived-At: Cc: v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:36:02 -0000 In response to Brian's suggestion, I thought I should let everyone know = what the authors' current plan is for the IGP section of the Design = Choices draft: 1) Include EIGRP in the table in section 2.3.1 2) Gather deployment data for all combinations of the three protocols = (EIGRP, ISIS, OSPF) and use this to drive the "known-to-work-well" = column of the table (*) 3) Gather deployment data on the use of RIP and RIPng and document this = in a new section (**) 4) Gather comments on gotchas and similar, and consider adding these to = the draft. (*) This addresses another WGLC comment (from Mikael Abrahamsson). Right = now, a combination is flagged as "known to work well" if Victor or I = have heard of someone using that combination. But we did not make a = significant effort to gather this information and did not consider "how = significant" the usage was. We now plan to do that. (**) RIP is not as dead as some might think. My company (Alcatel-Lucent) = recently added support for RIPng due to customer requests. Victor and I = plan to to gather info on who is using RIP and RIPng and where, and = then add this to the draft. Brian has proposed a slight different approach. See his email below. Comments on the two approaches are welcome. Philip On 2015-05-11, at 21:06 , Brian E Carpenter wrote: > On 12/05/2015 12:47, Fred Baker (fred) wrote: >>=20 >>> On May 11, 2015, at 5:30 PM, Ted Lemon = wrote: >>>=20 >>> To put an even finer point on it, one of the big problems with EIGRP = at this point is that although that are many interoperating = implementations, they were implemented using a reference implementation, = not a spec, so there is no spec that got the kind of interop testing = that multiple independent implementations would have given us. Getting = to that now would be very difficult, since there's no real incentive for = anybody to do a complete new implementation now. So while indeed it = might be good to write down the spec for posterity and the benefit of = sharing experience, I don't think it'd make a lot of sense as an IETF = standard. >>=20 >> My point on RFC 6126 is that it=92s not an IETF standard either, yet = homenet appears to be deciding to standardize on it. >=20 > Well yes, but it's open source and there has been a serious discussion = about moving > it to the standards track, with Alia describing to the homenet WG what = that would > involve. >=20 > Again: I'm not against documenting reality, with reasonable = justification. > But it has to be carefully positioned vs standardised solutions. = That's why > I suggested an appendix. So we'd end up with something like >=20 > 2.3.1. IGP Choice >=20 > One of the main decisions for an IPv6 implementer is the choice of > IGP (Interior Gateway Protocol) within the network. The primary > options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308], > though some operators may consider RIP [RFC2080] or non-standardized > protocols. Here we limit our discussion to the pros and cons of = OSPF > vs. IS-IS. Appendix A discusses the widely used non-standardized > EIGRP protocol. >=20 > Brian >=20 >>=20 >> I don=92t know the status of Donnie Savage=92s draft = (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the = EIGRP data formats are well known, the algorithms are well known, and if = the vector metric patent and the DUAL patent haven=92t expired, they're = about to. As you say, there are multiple implementations around. What = I=92m looking at is a request for commentary in a draft making comments = on the operational use of routing protocols. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon May 11 19:04:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65D11B2B60 for ; Mon, 11 May 2015 19:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPbbLKMZBCv4 for ; Mon, 11 May 2015 19:04:00 -0700 (PDT) Received: from tor-smtp-06.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA71B2B5F for ; Mon, 11 May 2015 19:03:59 -0700 (PDT) Received: from bas5-ottawa10-3096711390.dsl.bell.ca ([184.148.16.222] helo=[10.0.1.23]) by tor-smtp-06.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1YrzY6-0005yy-Jc; Mon, 11 May 2015 22:03:58 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Philip Matthews In-Reply-To: <5551521E.9070804@gmail.com> Date: Mon, 11 May 2015 22:03:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <5551521E.9070804@gmail.com> To: Brian E Carpenter , "Fred Baker (fred)" , Ted Lemon , Michael Ackermann X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - bas5-ottawa10-3096711390.dsl.bell.ca ([10.0.1.23]) [184.148.16.222] Archived-At: Cc: v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:04:01 -0000 Let me add a additional comment on this discussion as an author of the = document. =46rom the perspective of updating the document, the fact that EIGRP is = not standardized is not really a problem. The authors simply plan to = gather data on how it is deployed. We didn't really "use" the fact that = OSPF and ISIS are standardized when writing the current version of the = draft. So I think the only question is whether it is "appropriate" to include = EIGRP in the document. I personally don't know of any IETF document that = says "thou shall only discuss standardized protocols in IETF documents". = But perhaps others do. Or perhaps this is something that can be left to = "WG discretion". We certainly have a number of people with some = heavy-duty IETF experience in on this thread. - Philip On 2015-05-11, at 21:06 , Brian E Carpenter wrote: > On 12/05/2015 12:47, Fred Baker (fred) wrote: >>=20 >>> On May 11, 2015, at 5:30 PM, Ted Lemon = wrote: >>>=20 >>> To put an even finer point on it, one of the big problems with EIGRP = at this point is that although that are many interoperating = implementations, they were implemented using a reference implementation, = not a spec, so there is no spec that got the kind of interop testing = that multiple independent implementations would have given us. Getting = to that now would be very difficult, since there's no real incentive for = anybody to do a complete new implementation now. So while indeed it = might be good to write down the spec for posterity and the benefit of = sharing experience, I don't think it'd make a lot of sense as an IETF = standard. >>=20 >> My point on RFC 6126 is that it=92s not an IETF standard either, yet = homenet appears to be deciding to standardize on it. >=20 > Well yes, but it's open source and there has been a serious discussion = about moving > it to the standards track, with Alia describing to the homenet WG what = that would > involve. >=20 > Again: I'm not against documenting reality, with reasonable = justification. > But it has to be carefully positioned vs standardised solutions. = That's why > I suggested an appendix. So we'd end up with something like >=20 > 2.3.1. IGP Choice >=20 > One of the main decisions for an IPv6 implementer is the choice of > IGP (Interior Gateway Protocol) within the network. The primary > options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308], > though some operators may consider RIP [RFC2080] or non-standardized > protocols. Here we limit our discussion to the pros and cons of = OSPF > vs. IS-IS. Appendix A discusses the widely used non-standardized > EIGRP protocol. >=20 > Brian >=20 >>=20 >> I don=92t know the status of Donnie Savage=92s draft = (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the = EIGRP data formats are well known, the algorithms are well known, and if = the vector metric patent and the DUAL patent haven=92t expired, they're = about to. As you say, there are multiple implementations around. What = I=92m looking at is a request for commentary in a draft making comments = on the operational use of routing protocols. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 12 01:10:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5899D1A1E0E for ; Tue, 12 May 2015 01:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4FYdtt3KNfp for ; Tue, 12 May 2015 01:10:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002FC1A1DE1 for ; Tue, 12 May 2015 01:10:33 -0700 (PDT) Authentication-Results: magma.ca; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 12 May 2015 08:08:39 +0000 Message-ID: <007501d08c8a$98b4b6e0$4001a8c0@gateway.2wire.net> From: t.petch To: Philip Matthews , Brian E Carpenter , "Fred Baker (fred)" , Ted Lemon , Michael Ackermann References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <5551521E.9070804@gmail.com> Date: Tue, 12 May 2015 09:06:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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: [81.151.162.168] X-ClientProxiedBy: DB3PR05CA0019.eurprd05.prod.outlook.com (25.160.41.147) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Forefront-PRVS: 0574D4712B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(51704005)(377424004)(479174004)(19580395003)(86362001)(19580405001)(50466002)(87976001)(84392001)(23746002)(50226001)(14496001)(76176999)(81686999)(81816999)(92566002)(50986999)(47776003)(5001770100001)(46102003)(33646002)(66066001)(93886004)(5001960100002)(189998001)(44716002)(62236002)(5001920100001)(61296003)(15975445007)(62966003)(40100003)(77096005)(122386002)(77156002)(42186005); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2015 08:08:39.5831 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 08:10:41 -0000 ----- Original Message ----- From: "Philip Matthews" To: "Brian E Carpenter" ; "Fred Baker (fred)" ; "Ted Lemon" ; "Michael Ackermann" Sent: Tuesday, May 12, 2015 3:03 AM Let me add a additional comment on this discussion as an author of the document. >From the perspective of updating the document, the fact that EIGRP is not standardized is not really a problem. The authors simply plan to gather data on how it is deployed. We didn't really "use" the fact that OSPF and ISIS are standardized when writing the current version of the draft. So I think the only question is whether it is "appropriate" to include EIGRP in the document. I personally don't know of any IETF document that says "thou shall only discuss standardized protocols in IETF documents". But perhaps others do. Or perhaps this is something that can be left to "WG discretion". We certainly have a number of people with some heavy-duty IETF experience in on this thread. EIGRP is indeed very widely used in the Enterprise arena and I let out a small cheer when I saw the I-D about it; and Ivery much hope that that I-D becomes an RFC. As to its inclusion in the Design Choices, I think the answer will stem from the question that prompted this thread. If enough people mail in their experiences, then we have the data to include it in that I-D. If we do not get the response, then we are not qualified to do so and so should, at most, make a passing reference to its existence (and that EIGRP I-D/RFC). Since there is, in general, no IPv6 available in my small, offshore island, I can offer no experience myself:-( Tom Petch - Philip On 2015-05-11, at 21:06 , Brian E Carpenter wrote: > On 12/05/2015 12:47, Fred Baker (fred) wrote: >> >>> On May 11, 2015, at 5:30 PM, Ted Lemon wrote: >>> >>> To put an even finer point on it, one of the big problems with EIGRP at this point is that although that are many interoperating implementations, they were implemented using a reference implementation, not a spec, so there is no spec that got the kind of interop testing that multiple independent implementations would have given us. Getting to that now would be very difficult, since there's no real incentive for anybody to do a complete new implementation now. So while indeed it might be good to write down the spec for posterity and the benefit of sharing experience, I don't think it'd make a lot of sense as an IETF standard. >> >> My point on RFC 6126 is that its not an IETF standard either, yet homenet appears to be deciding to standardize on it. > > Well yes, but it's open source and there has been a serious discussion about moving > it to the standards track, with Alia describing to the homenet WG what that would > involve. > > Again: I'm not against documenting reality, with reasonable justification. > But it has to be carefully positioned vs standardised solutions. That's why > I suggested an appendix. So we'd end up with something like > > 2.3.1. IGP Choice > > One of the main decisions for an IPv6 implementer is the choice of > IGP (Interior Gateway Protocol) within the network. The primary > options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308], > though some operators may consider RIP [RFC2080] or non-standardized > protocols. Here we limit our discussion to the pros and cons of OSPF > vs. IS-IS. Appendix A discusses the widely used non-standardized > EIGRP protocol. > > Brian > >> >> I dont know the status of Donnie Savages draft (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the EIGRP data formats are well known, the algorithms are well known, and if the vector metric patent and the DUAL patent havent expired, they're about to. As you say, there are multiple implementations around. What I m looking at is a request for commentary in a draft making comments on the operational use of routing protocols. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 12 05:15:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D31A92B5 for ; Tue, 12 May 2015 05:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwadDET817r5 for ; Tue, 12 May 2015 05:15:02 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1976C1ACC82 for ; Tue, 12 May 2015 05:14:55 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 0C813DA007A; Tue, 12 May 2015 12:14:55 +0000 (UTC) Received: from [10.0.1.40] (205.178.35.126) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 12 May 2015 05:14:49 -0700 References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> MIME-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Message-ID: <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Tue, 12 May 2015 08:14:48 -0400 To: "Fred Baker (fred)" X-Originating-IP: [205.178.35.126] Archived-At: Cc: Philip Matthews , v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:15:03 -0000 On May 11, 2015, at 8:47 PM, Fred Baker (fred) wrote: >=20 > My point on RFC 6126 is that it=A1=AFs not an IETF standard either, yet ho= menet appears to be deciding to standardize on it. I did actually speak to that, and notice that you haven't disputed what I sa= id, yet don't seem to agree with my conclusion. That said, if we are talking= about homenet, the proponents of Babel there have two really specific reaso= n for preferring babel to EIGRP. The first is the one I have:it is not an op= en standard, and isn't likely to become one. The second is that it doesn't m= eet their requirements, particularly with respect to its handling of lossy l= inks. It would be good to document that it doesn't meet their requirements, b= ut doesn't seem a likely candidate whether it is specifically analyzed in th= e document or not.=20 It is also worth noting that homenet isn't appearing to decide on a routing p= rotocol, and that's why we have a design team. There are participants in hom= enet who have stated good reasons for using Babel, but the working group as a= whole does not have consensus on the question.=20= From nobody Tue May 12 05:21:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E211ACCDF for ; Tue, 12 May 2015 05:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuW7XnNSXOAk for ; Tue, 12 May 2015 05:21:46 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177831A1A62 for ; Tue, 12 May 2015 05:21:46 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id EE840DA007A; Tue, 12 May 2015 12:21:45 +0000 (UTC) Received: from [10.0.1.40] (205.178.35.126) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 12 May 2015 05:21:45 -0700 References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> MIME-Version: 1.0 (1.0) In-Reply-To: <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <5BA159E6-F019-497E-96D7-11FD512C375F@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Tue, 12 May 2015 08:21:44 -0400 To: Ted Lemon X-Originating-IP: [205.178.35.126] Archived-At: Cc: Philip Matthews , v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:21:46 -0000 On May 12, 2015, at 8:14 AM, Ted Lemon wrote: >=20 > The first is the one I have:it is not an open standard, and isn't likely t= o become one. That was supposed to say "have already explained." Typing on the iPad is di= fficult due to registration issues. :/= From nobody Tue May 12 05:26:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067891ACD0D for ; Tue, 12 May 2015 05:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UePkQZewiBju for ; Tue, 12 May 2015 05:26:56 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D7F1ACD09 for ; Tue, 12 May 2015 05:26:55 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id f81f1555.2b6af403f940.4045280.00-2449.11349152.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 12 May 2015 12:26:55 +0000 (UTC) X-MXL-Hash: 5551f18f0c581f54-d8c5b8e05c27a54e3c92657a91f0f32f6702ee87 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id e81f1555.0.4045277.00-2309.11349119.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 12 May 2015 12:26:55 +0000 (UTC) X-MXL-Hash: 5551f18f679a3042-2323d54dddcc87f87d6f02493826edceb36beb49 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4CCQrD4028443; Tue, 12 May 2015 08:26:54 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4CCQk0Y028422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 May 2015 08:26:50 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 12 May 2015 12:26:33 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.168]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0224.002; Tue, 12 May 2015 08:26:32 -0400 From: "STARK, BARBARA H" To: Ted Lemon , "Fred Baker (fred)" Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjACNux2KUONiXECSYNX4GNUcGZ13f2sAgAAs/4CAABRqgIAABJEAgADAIgD//74hwA== Date: Tue, 12 May 2015 12:26:33 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130FF2B42@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> In-Reply-To: <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.247.135] 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-AnalysisOut: [v=2.0 cv=Id0wrxWa c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=C4nbiDwpsDIA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h1PgugrvaO0A:10 a=e1gdrVnHO] X-AnalysisOut: [N_SV2tnMgUA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:26:57 -0000 > That said, if we are talking about > homenet ... I don't see that draft-ietf-v6ops-design-choices has any applicability to h= omenet. The design-choices draft states up front that the applicable networ= k is one being designed (i.e., "managed") by someone "who is knowledgeable = about best current practices around IPv4 network design, and wishes to lear= n the corresponding practices for IPv6". That puts homenet way, way out of = scope. IMO, it's really about enterprise networks. Barbara From nobody Tue May 12 05:47:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEFA1B2C25 for ; Tue, 12 May 2015 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoTcER-f0lLB for ; Tue, 12 May 2015 05:47:47 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427261B2C1F for ; Tue, 12 May 2015 05:47:47 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 107D4DA007A; Tue, 12 May 2015 12:47:47 +0000 (UTC) Received: from [10.0.1.40] (205.178.35.126) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 12 May 2015 05:47:41 -0700 References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130FF2B42@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 (1.0) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130FF2B42@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <11A10C29-5374-4B42-BA7E-29618E0463BE@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Tue, 12 May 2015 08:47:40 -0400 To: "STARK, BARBARA H" X-Originating-IP: [205.178.35.126] Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:47:48 -0000 On May 12, 2015, at 8:26 AM, STARK, BARBARA H wrote: >=20 > I don't see that draft-ietf-v6ops-design-choices has any applicability to h= omenet. The design-choices draft states up front that the applicable network= is one being designed (i.e., "managed") by someone "who is knowledgeable ab= out best current practices around IPv4 network design, and wishes to learn t= he corresponding practices for IPv6". That puts homenet way, way out of scop= e. IMO, it's really about enterprise networks. Great, thanks for answering that. I couldn't get the context from the subjec= t line.=20= From nobody Tue May 12 12:45:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399F41A88C5; Tue, 12 May 2015 12:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AriEgNxaTwbc; Tue, 12 May 2015 12:45:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C32BC1A7034; Tue, 12 May 2015 12:45:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512194530.19587.76587.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 12:45:30 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Benoit Claise's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:45:32 -0000 Benoit Claise has entered the following ballot position for draft-ietf-v6ops-cidr-prefix-02: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I never realized this was not documented. So thanks for this document. From nobody Tue May 12 13:19:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239FD1AD064 for ; Tue, 12 May 2015 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sumG1kly4Th for ; Tue, 12 May 2015 13:19:06 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385FB1A87E8 for ; Tue, 12 May 2015 13:19:06 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so25751141pdb.1 for ; Tue, 12 May 2015 13:19:05 -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=UzqfxPp5AQ1Hqwb5n5Gjh1hcr0XZySvuq5F4fTg2MZE=; b=ZabTYqBYYPuLuo08IDjkUdna/jszMcaOPXx6xfSvEAw7q4ZBWWXPaI4FSx4NrsowDD A5nlJjIeEhHHaLcFS2l61awwEm+F2b//DkAvWQC00fK4rg6I6+71XyDixcbMcumXUcPC Zjd5zo9zKDAmel+fqhN7ncG0GfZf5b7SaXvo4Lw8UyDyOxVwoehUnsSSWfIA0zzWgztD k1tHExG2OVkH0oYIWyh+h7eHMhLqRl/bSpkaNjVRarwXNL+l8AUgFsTB5J+Punfaz/rP Jmmerq7SrJ9LyMlxb7vg1TqnXn1nSLJxGimSjD0dWGt9cAeJW5a7LJi6KjJ/cZwx/nZw B+Og== X-Received: by 10.68.209.227 with SMTP id mp3mr30985414pbc.100.1431461945818; Tue, 12 May 2015 13:19:05 -0700 (PDT) Received: from ?IPv6:2406:e007:6c7e:1:28cc:dc4c:9703:6781? ([2406:e007:6c7e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id k4sm17075976pdg.87.2015.05.12.13.19.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 13:19:04 -0700 (PDT) Message-ID: <55526039.2060403@gmail.com> Date: Wed, 13 May 2015 08:19:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "t.petch" , Philip Matthews , "Fred Baker (fred)" , Ted Lemon , Michael Ackermann References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <5551521E.9070804@gmail.com> <007501d08c8a$98b4b6e0$4001a8c0@gateway.2wire.net> In-Reply-To: <007501d08c8a$98b4b6e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:19:08 -0000 On 12/05/2015 20:06, t.petch wrote: > ----- Original Message ----- > From: "Philip Matthews" > To: "Brian E Carpenter" ; "Fred Baker > (fred)" ; "Ted Lemon" ; "Michael= > Ackermann" > Sent: Tuesday, May 12, 2015 3:03 AM >=20 >=20 > Let me add a additional comment on this discussion as an author of the > document. >=20 >>From the perspective of updating the document, the fact that EIGRP is > not standardized is not really a problem. The authors simply plan to > gather data on how it is deployed. We didn't really "use" the fact that= > OSPF and ISIS are standardized when writing the current version of the > draft. >=20 > So I think the only question is whether it is "appropriate" to include > EIGRP in the document. I personally don't know of any IETF document tha= t > says "thou shall only discuss standardized protocols in IETF documents"= =2E And I very carefully didn't say that, because it isn't true. What I suggested is: put discussion of a non-standardized proprietary sol= ution in an appendix, to recognize and document reality without endorsing it. > But perhaps others do. Or perhaps this is something that can be left to= > "WG discretion".=20 Well, the WG can propose what it wants, and it's the IETF Last Call that verifies. Brian > We certainly have a number of people with some > heavy-duty IETF experience in on this thread. >=20 > >=20 > EIGRP is indeed very widely used in the Enterprise arena and I let out = a > small cheer when I saw the I-D about it; and Ivery much hope that that > I-D becomes an RFC. >=20 > As to its inclusion in the Design Choices, I think the answer will stem= > from the question that prompted this thread. If enough people mail in > their experiences, then we have the data to include it in that I-D. If= > we do not get the response, then we are not qualified to do so and so > should, at most, make a passing reference to its existence (and that > EIGRP I-D/RFC). >=20 > Since there is, in general, no IPv6 available in my small, offshore > island, I can offer no experience myself:-( >=20 > Tom Petch >=20 >=20 > - Philip >=20 >=20 > On 2015-05-11, at 21:06 , Brian E Carpenter wrote: >=20 >> On 12/05/2015 12:47, Fred Baker (fred) wrote: >>> >>>> On May 11, 2015, at 5:30 PM, Ted Lemon > wrote: >>>> >>>> To put an even finer point on it, one of the big problems with EIGRP= > at this point is that although that are many interoperating > implementations, they were implemented using a reference implementation= , > not a spec, so there is no spec that got the kind of interop testing > that multiple independent implementations would have given us. Getting > to that now would be very difficult, since there's no real incentive fo= r > anybody to do a complete new implementation now. So while indeed it > might be good to write down the spec for posterity and the benefit of > sharing experience, I don't think it'd make a lot of sense as an IETF > standard. >>> >>> My point on RFC 6126 is that it=E2=80=99s not an IETF standard either= , yet > homenet appears to be deciding to standardize on it. >> >> Well yes, but it's open source and there has been a serious discussion= > about moving >> it to the standards track, with Alia describing to the homenet WG what= > that would >> involve. >> >> Again: I'm not against documenting reality, with reasonable > justification. >> But it has to be carefully positioned vs standardised solutions. > That's why >> I suggested an appendix. So we'd end up with something like >> >> 2.3.1. IGP Choice >> >> One of the main decisions for an IPv6 implementer is the choice of >> IGP (Interior Gateway Protocol) within the network. The primary >> options are OSPF [RFC2328] [RFC5340] or IS-IS [RFC5120] [RFC5308], >> though some operators may consider RIP [RFC2080] or non-standardized= >> protocols. Here we limit our discussion to the pros and cons of > OSPF >> vs. IS-IS. Appendix A discusses the widely used non-standardized >> EIGRP protocol. >> >> Brian >> >>> >>> I don=E2=80=99t know the status of Donnie Savage=E2=80=99s draft > (https://datatracker.ietf.org/doc/draft-savage-eigrp/). However, the > EIGRP data formats are well known, the algorithms are well known, and i= f > the vector metric patent and the DUAL patent haven=E2=80=99t expired, t= hey're > about to. As you say, there are multiple implementations around. What I= =E2=80=99 > m looking at is a request for commentary in a draft making comments on > the operational use of routing protocols. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 From nobody Tue May 12 14:05:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500141AD151 for ; Tue, 12 May 2015 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-ZpUu_g3O8s for ; Tue, 12 May 2015 14:05:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E739F1A92B2 for ; Tue, 12 May 2015 14:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5964; q=dns/txt; s=iport; t=1431464740; x=1432674340; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WvXtlSfwV9jJ7QUjlNGTF+1iPBPIrgUPq44ff9MEGsM=; b=X90ib1OJHN7x089OZg/4S5HahcewtYl+uB4fXuvayMUaCtiseayyx1UW e+q42UzubMWWMnZib0O/HWThNiC4ELKlwL7JIeoNXfYql6J2JorvPJuGI 1NzWXYPlt27HSmS+wzWF4E5Kdl4qklFtHnTQzfp5lIhTzrdcSGy3hP4aO 8=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CNBADIalJV/4QNJK1cgw9UXgaDGMIMCYFYhgUCgUA4FAEBAQEBAQGBCoQgAQEBAwEjVgULAgEIGCoCAjIlAgQBDQUOiBYIDbY7k2kBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs5hQUHgmgvgRYFhmKLbIIKgT5dhD2CCYE3lTYjYYElAxyBUm+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,417,1427760000"; d="asc'?scan'208";a="149361448" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 12 May 2015 21:05:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4CL5e3u029209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 21:05:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.148]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 12 May 2015 16:05:39 -0500 From: "Fred Baker (fred)" To: Ted Lemon , Brian E Carpenter Thread-Topic: [v6ops] EIGRP and the Design Choices draft Thread-Index: AQHQjPdmghiDgCTYx0qUI/TpfAUh/w== Date: Tue, 12 May 2015 21:05:39 +0000 Message-ID: References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> In-Reply-To: <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_7F5D7195-DD60-406E-93F9-257575695760"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:05:43 -0000 --Apple-Mail=_7F5D7195-DD60-406E-93F9-257575695760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 12, 2015, at 5:14 AM, Ted Lemon wrote: >=20 >> My point on RFC 6126 is that it=E2=80=99s not an IETF standard = either, yet homenet appears to be deciding to standardize on it. >=20 > I did actually speak to that, and notice that you haven't disputed = what I said, yet don't seem to agree with my conclusion. That said, if = we are talking about homenet, the proponents of Babel there have two = really specific reason for preferring babel to EIGRP. I'm not disputing Babel. I'm not disputing Homenet. The conversation is = about neither. We have a request on the table for a document being developed in v6ops = about routing deployment to comment on a routing protocol that is widely = used in enterprise networks. Brian is pushing back because the protocol = is not on the IETF standards track and is not an RFC. I can tell you = that it was posted as an Internet Draft, and that = https://datatracker.ietf.org/doc/draft-savage-eigrp says it is in ISE = review. Babel came up because it followed exactly that path to = (experimental) RFC publication. Why draft-savage-eigrp is not an RFC is = something I don't know. Ask Nevil. I do know that there is an internet draft, and the multiple = implementations of the protocol were done from a book written about it = before the draft was written (available from Amazon). To me, that is = largely comparable to the Babel experience, which is why I brought it = up. I'm questioning the ferocity behind Brian's pushback. I think it is = unwarranted. If we're documenting deployment experience with common routing = protocols, it's one of them. Is this about the purity of the RFC series, = or the relevance to operational networks? If it is about routing in = operational networks, why would we exclude discussion of protocols in = current use in operational networks? As to Brian's suggestion of putting EIGRP into an appendix, I'm not the = author, but if I were, I would wonder how he wanted me to do that. The = request is to add one or more rows (the current draft mentions "RIP = [RFC2080] or non-standardized protocols") to +--------+--------+---------+---------+------------+----------------+ | Option | IGP | IGP for | Known | Hard | Similar | | | for | IPv6 | to work | separation | configuration | | | IPv4 | | well | | possible | +--------+--------+---------+---------+------------+----------------+ | | | | | | | +--------+--------+---------+---------+------------+----------------+ | a | IS-IS | IS-IS | YES | - | YES | +--------+--------+---------+---------+------------+----------------+ | b | IS-IS | OSPFv3 | - | YES | - | +--------+--------+---------+---------+------------+----------------+ | | | | | | | +--------+--------+---------+---------+------------+----------------+ | c | OSPFv2 | IS-IS | YES | YES | - | +--------+--------+---------+---------+------------+----------------+ | d | OSPFv2 | OSPFv3 | YES | YES | YES | +--------+--------+---------+---------+------------+----------------+ | | | | | | | +--------+--------+---------+---------+------------+----------------+ | e | OSPFv3 | IS-IS | - | YES | - | +--------+--------+---------+---------+------------+----------------+ | f | OSPFv3 | OSPFv3 | - | - | YES | +--------+--------+---------+---------+------------+----------------+ = . along the lines of +--------+--------+---------+---------+------------+----------------+ | g | RIPv2 | RIPng | - | YES | YES | +--------+--------+---------+---------+------------+----------------+ | h | EIGRP | EIGRP | YES | - | YES | +--------+--------+---------+---------+------------+----------------+ = . and a bibliographic reference (presumably to either the book or the = internet draft, if we can=E2=80=99t get it published as an RFC) = indicating what the acronym EIGRP stood for. https://tools.ietf.org/html/rfc2080 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=3D47534 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc2453 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=3D98462 bytes) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) (Status: INTERNET STANDARD) https://datatracker.ietf.org/doc/draft-savage-eigrp https://tools.ietf.org/html/draft-savage-eigrp Enhanced Interior Gateway Routing Protocol. D Savage, 2014-10-13 --Apple-Mail=_7F5D7195-DD60-406E-93F9-257575695760 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVVJrIp9ieig10VPpAQLdeQgAqMotF9UkZ6Hz9+pqHjjx+Gp+wbyKGQGu N+9rqq0bLyLMwmvvwTUDUHydeRVMAz6nN/mh0J6N5x/BcI9UrJsbmwXF5bs5l0/C 6vfSsryWlnzc9ZY9S819Klsv2r8YyXtcjoH0w61RuYvQCYyiHRbvC2Nd7OWdpEXm g/AL9V5YcrOK9JrYbG+NSw21kKiWvNd4+lpeODnHoCV3gCInveHaVAtozTlxUwxv WREBkM7W5g2+0ajPM2KhK5B/nobHVBFmpjxTKxUZJG+JZUCVdiGKSsusAM/fDF2Y x1pea124bWAEe7X2oplQEcfPA9ePrMc2kpWeQmuWREP6SDacXr8FYQ== =7Qo4 -----END PGP SIGNATURE----- --Apple-Mail=_7F5D7195-DD60-406E-93F9-257575695760-- From nobody Tue May 12 15:11:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079981A905D for ; Tue, 12 May 2015 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAm9_4nELbGy for ; Tue, 12 May 2015 15:11:11 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6191A9070 for ; Tue, 12 May 2015 15:11:10 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so27927393pab.3 for ; Tue, 12 May 2015 15:11:10 -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=nSfotXXtBdaC8d1WdqfHRPrgYN9a67etGLKJ/LMdmzk=; b=RAZWb6u+Sa4wHks34KbSYkDurXm+C98CN2HzzTaeaiDtzDJQKc0aBWQ8S/zJ7cuJtH n2fQADY8Gr3Zm6fZ1IV9JMA2s7FU5LM5E1eXoG9tFjGGmcowtPJ7O3SifwBWnZGef8MU P0WKXz+2ySKGvCfxtzmI1WEX0sn8Gj4ro7mvfV5vi5wtrVJ52528hy7kSCMOd8EOzvvj /QkKXAtT813rQiBFQYmqEZPPb7hte0qMa85dLuSivvb6y+k/PqovXzJcyJ2n5LSmszeK vmk4dRSFBpkc0FUEkmUhiz2FTizkOsINV9WUzhq2pAbhJSgKkyF/5pg48D2anfhSqefL V0fw== X-Received: by 10.70.24.130 with SMTP id u2mr32128294pdf.147.1431468670308; Tue, 12 May 2015 15:11:10 -0700 (PDT) Received: from ?IPv6:2406:e007:6c7e:1:28cc:dc4c:9703:6781? ([2406:e007:6c7e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wx8sm17202589pbc.1.2015.05.12.15.11.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 15:11:08 -0700 (PDT) Message-ID: <55527A7D.6090809@gmail.com> Date: Wed, 13 May 2015 10:11:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , Ted Lemon References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:11:13 -0000 Fred, On 13/05/2015 09:05, Fred Baker (fred) wrote: >=20 >> On May 12, 2015, at 5:14 AM, Ted Lemon wrote: >> >>> My point on RFC 6126 is that it=E2=80=99s not an IETF standard either= , yet homenet appears to be deciding to standardize on it. >> >> I did actually speak to that, and notice that you haven't disputed wha= t I said, yet don't seem to agree with my conclusion. That said, if we ar= e talking about homenet, the proponents of Babel there have two really sp= ecific reason for preferring babel to EIGRP. >=20 > I'm not disputing Babel. I'm not disputing Homenet. The conversation is= about neither. >=20 > We have a request on the table for a document being developed in v6ops = about routing deployment to comment on a routing protocol that is widely = used in enterprise networks. Brian is pushing back because the protocol i= s not on the IETF standards track and is not an RFC. I can tell you that = it was posted as an Internet Draft, and that https://datatracker.ietf.org= /doc/draft-savage-eigrp says it is in ISE review. Babel came up because i= t followed exactly that path to (experimental) RFC publication. Why draft= -savage-eigrp is not an RFC is something I don't know. Ask Nevil. >=20 > I do know that there is an internet draft, and the multiple implementat= ions of the protocol were done from a book written about it before the dr= aft was written (available from Amazon). To me, that is largely comparabl= e to the Babel experience, which is why I brought it up. I'm questioning = the ferocity behind Brian's pushback. I think it is unwarranted. I didn't intend to be ferocious ;-). Let's see a draft with this added. If there's no support for it being in = an appendix, I lose. But I would like to see some words recording as a matter of fact = that EIGRP isn't an IETF protocol. We all know how marketing people use RFCs. Brian > If we're documenting deployment experience with common routing protocol= s, it's one of them. Is this about the purity of the RFC series, or the r= elevance to operational networks? If it is about routing in operational n= etworks, why would we exclude discussion of protocols in current use in o= perational networks? >=20 > As to Brian's suggestion of putting EIGRP into an appendix, I'm not the= author, but if I were, I would wonder how he wanted me to do that. The r= equest is to add one or more rows (the current draft mentions "RIP [RFC20= 80] or non-standardized protocols") to > +--------+--------+---------+---------+------------+----------------= + > | Option | IGP | IGP for | Known | Hard | Similar = | > | | for | IPv6 | to work | separation | configuration = | > | | IPv4 | | well | | possible = | > +--------+--------+---------+---------+------------+----------------= + > | | | | | | = | > +--------+--------+---------+---------+------------+----------------= + > | a | IS-IS | IS-IS | YES | - | YES = | > +--------+--------+---------+---------+------------+----------------= + > | b | IS-IS | OSPFv3 | - | YES | - = | > +--------+--------+---------+---------+------------+----------------= + > | | | | | | = | > +--------+--------+---------+---------+------------+----------------= + > | c | OSPFv2 | IS-IS | YES | YES | - = | > +--------+--------+---------+---------+------------+----------------= + > | d | OSPFv2 | OSPFv3 | YES | YES | YES = | > +--------+--------+---------+---------+------------+----------------= + > | | | | | | = | > +--------+--------+---------+---------+------------+----------------= + > | e | OSPFv3 | IS-IS | - | YES | - = | > +--------+--------+---------+---------+------------+----------------= + > | f | OSPFv3 | OSPFv3 | - | - | YES = | > +--------+--------+---------+---------+------------+----------------= + . >=20 > along the lines of >=20 > +--------+--------+---------+---------+------------+----------------= + > | g | RIPv2 | RIPng | - | YES | YES = | > +--------+--------+---------+---------+------------+----------------= + > | h | EIGRP | EIGRP | YES | - | YES = | > +--------+--------+---------+---------+------------+----------------= + . >=20 > and a bibliographic reference (presumably to either the book or the int= ernet draft, if we can=E2=80=99t get it published as an RFC) indicating w= hat the acronym EIGRP stood for. >=20 > https://tools.ietf.org/html/rfc2080 > 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: > TXT=3D47534 bytes) (Status: PROPOSED STANDARD) >=20 > https://tools.ietf.org/html/rfc2453 > 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=3D98462 > bytes) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) > (Status: INTERNET STANDARD) >=20 > https://datatracker.ietf.org/doc/draft-savage-eigrp > https://tools.ietf.org/html/draft-savage-eigrp > Enhanced Interior Gateway Routing Protocol. D Savage, 2014-10-13 >=20 From nobody Tue May 12 19:15:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B841A9038 for ; Tue, 12 May 2015 19:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gnITyhFk-Zm for ; Tue, 12 May 2015 19:15:47 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D491A8FD2 for ; Tue, 12 May 2015 19:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431483346; bh=Qm3vOZlyPz28DnjZPVSw0bSRyigqOOaegbhY2DOymyU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=l0kBHwii0lQjVZazSFHzQC2JcEyMJ7AZ8MIZVLiUS1HPJKhzWI1B+2kjNFez7CweVtLVrGEc88c5AH0k4qWvwtSiB+J5Oyxt16UhVsrrCvf5PxUQ8vcv51DbpVkaZC1u84QI8hSZtpKfMKlAkvi1exh69vITz7dqJu3acu6i4oBKr8wHAZwci48Pi3Crcu7sPx4gqeZpJDJsGt0EKnU5TPuj03QOoQWIZXVPlifa1/j/LXSjZ3dK2w16zP24P/YkB1oL2bOiqSb1b3My8r80dM6OjgqJsUWWKtBaCTQ9w0hT+KcD8UWJoDF1j0I9hzfbp9q7K1/ZD7xBb0T8V6Fd7Q== Received: from [66.196.81.171] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2015 02:15:46 -0000 Received: from [98.139.212.219] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2015 02:15:46 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 13 May 2015 02:15:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 237736.26983.bm@omp1028.mail.bf1.yahoo.com X-YMail-OSG: jUZI7M0VM1kNeGCGI20Q4ggtWvPFFZlLGqfEm5DKU6w3DKlw6qEj68cUa7sXP7R eXn7mhJo4ELM1uwFhKtrwF7pxOkYXV89V_hRRnpCIU78h83mSa9_pWVwO4SprrH6xvv32PZGZ8y8 8384B6kmDQpsXj_SHfl.nH0fSGKqHv4rwtBZ_VTH8AVQ8MEaw_KkOXdm8sCReYAM_kYHInAgVZDf ZKCQR0Q1uqPeOndi1j8c_PaAQPvmALHGYcqdYHcrIOr3D69Ns54JcMgFnx3aG.kRXeP0XjcE.HNI gWme9DYeESUG0MpyCpuFSPeLzX0dKhXq9NXs88ApAvnoI95LxUwuHi_HBePdygs1VKDRt5aW6IOG WulqhNsYFLuToFsNlgARNS7w2VSJhMAb0AJPFydtDlkG6duOxicY9WmBUSW9dArH5iKQGrAYGNZ. wvmagEctuIjYhaxvkEisI4ticHLKWiSRX4s_Eoi0VGvXkwmnxccNRrPMhI27lcNiqbe.e7DPdb.9 byAk38X1V7iathz4_qdtJrgdlRwC4wTHUAPvYgu1JX6Y- Received: by 76.13.26.110; Wed, 13 May 2015 02:15:45 +0000 Date: Wed, 13 May 2015 02:15:44 +0000 (UTC) From: Mark ZZZ Smith To: "STARK, BARBARA H" , Ted Lemon , "Fred Baker (fred)" Message-ID: <779939750.1220485.1431483344791.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130FF2B42@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130FF2B42@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1220484_82292635.1431483344786" Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 02:15:48 -0000 ------=_Part_1220484_82292635.1431483344786 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've seen it as applicable to managed networks, including ISP networks. Hav= ing worked on both enterprise and ISP networks, I don't see any thing in th= ere that is an exclusive consideration for one or the other types of networ= ks. The draft doesn't really describe much context other than saying that the c= onsiderations apply to single or dual stack IPv6 networks. So I think a bit= of expansion on the type of networks it applies to would be useful. I'd suggest it applies to "managed" networks, where deployment decisions ar= e either unavoidable or there can be operational advantages in considering = various methods of achieving the same goal. I think it would also be worth = mentioning that in an=C2=A0automated network (I wouldn't specifically menti= on a home network, but that is an example of one) it may be useful to overr= ide the defaults, and in that case the issues discussed should then be cons= idered. Regards,Mark. =20 From: "STARK, BARBARA H" To: Ted Lemon ; Fred Baker (fred) = =20 Cc: v6ops list ; Philip Matthews = =20 Sent: Tuesday, 12 May 2015, 22:26 Subject: Re: [v6ops] EIGRP and the Design Choices draft =20 > That said, if we are talking about > homenet ... I don't see that draft-ietf-v6ops-design-choices has any applicability to h= omenet. The design-choices draft states up front that the applicable networ= k is one being designed (i.e., "managed") by someone "who is knowledgeable = about best current practices around IPv4 network design, and wishes to lear= n the corresponding practices for IPv6". That puts homenet way, way out of = scope. IMO, it's really about enterprise networks. Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_1220484_82292635.1431483344786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've seen it as applicable to managed networks, including ISP ne= tworks. Having worked on both enterprise and ISP networks, I don't see any = thing in there that is an exclusive consideration for one or the other type= s of networks.

The draft doesn't really describe much context othe= r than saying that the considerations apply to single or dual stack IPv6 ne= tworks. So I think a bit of expansion on the type of networks it applies to= would be useful.

I'd suggest it applies to "managed" networks, where deployment = decisions are either unavoidable or there can be operational advantages in = considering various methods of achieving the same goal. I think it would al= so be worth mentioning that in an automated network (I wouldn't= specifically mention a home network, but that is an example of one) it may= be useful to override the defaults, and in that case the issues discussed = should then be considered.

Regards,
<= div style=3D"color:#000;background-color:#fff;font-family:Helvetica Neue-Li= ght, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande,= Sans-Serif;font-size:16px;" id=3D"yui_3_16_0_1_1431482299909_10962">Mark.<= /div>
=



<= div class=3D"yiv4585652167yqt2108622201" id=3D"yiv4585652167yqt75750">
From: "STARK,= BARBARA H" <bs7652@att.com>
To: Ted Lemon <Ted.Lemon@nominum.com>; Fre= d Baker (fred) <fred@cisco.com>
Cc: v6ops list <v6ops@ietf.org>; Philip= Matthews <philip_matthews@magma.ca>
Sent: Tuesday, 12 May 2015, 22:26
Subject: Re: = [v6ops] EIGRP and the Design Choices draft

<snip>



> That said, if we are t= alking about

> homenet ... <snip>

I don't see that draft-ietf-v6ops-design-choic= es has any applicability to homenet. The design-choices draft states up fro= nt that the applicable network is one being designed (i.e., "managed") by s= omeone "who is knowledgeable about best current practices around IPv4 netwo= rk design, and wishes to learn the corresponding practices for IPv6". That = puts homenet way, way out of scope. IMO, it's really about enterprise netwo= rks.
Barbara

_______= ________________________________________
v6ops mailing li= st
v6ops@ietf.= org
https://www.ietf.org/mailman/listinfo/v6o= ps



<= /div>
------=_Part_1220484_82292635.1431483344786-- From nobody Wed May 13 07:57:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD95D1B2D29 for ; Wed, 13 May 2015 07:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXt5CVDL3wz3 for ; Wed, 13 May 2015 07:57:34 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5381B2D20 for ; Wed, 13 May 2015 07:57:33 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8447E6097A for ; Wed, 13 May 2015 16:57:29 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 34338608CF for ; Wed, 13 May 2015 16:57:29 +0200 (CEST) Received: (qmail 22790 invoked by uid 1007); 13 May 2015 16:57:29 +0200 Date: Wed, 13 May 2015 16:57:29 +0200 From: Gert Doering To: "Fred Baker \(fred\)" Message-ID: <20150513145729.GC54385@Space.Net> References: <555112D8.3000008@gmail.com> <1592568679.113935.1431386263763.JavaMail.yahoo@mail.yahoo.com> <41D8A9FE-0324-4DDF-8868-5187F122F9A7@nominum.com> <16AE7703-1288-40F6-9CD9-29196986B8C6@nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fLGufcSJaIWCyz8" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 14:57:41 -0000 --2fLGufcSJaIWCyz8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, May 12, 2015 at 09:05:39PM +0000, Fred Baker (fred) wrote: > If we're documenting deployment experience with common routing protocols,= it's one of them. Is this about the purity of the RFC series, or the relev= ance to operational networks? If it is about routing in operational network= s, why would we exclude discussion of protocols in current use in operation= al networks? >=20 > As to Brian's suggestion of putting EIGRP into an appendix, I'm not the a= uthor, but if I were, I would wonder how he wanted me to do that. The reque= st is to add one or more rows (the current draft mentions "RIP [RFC2080] or= non-standardized protocols") to This approach works for me - have it in the table, and maybe add a footnote that explains that EIGRP is not an IETF standard but a vendor protocol. "Operational useful content" in an operational RFC trumps "purity" for me. (I'm actually one of the people that use EIGRP for IPv4 and have also used it for IPv6, and prefer it to OSPF or ISIS any day) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --2fLGufcSJaIWCyz8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVVNmWN9WwGXkzn/FAQLplw//ZOhe8nT3N4cGlbKMgBUgIRWXBPpocsoG itYShjXAQ9m6Sv1JbX+K/kAAr5iGspC4Go3dqmZTPqd3lar69llxluZPJyVHRJAv V6yQi9ztxTUTGapkIRlz4ziBxh4dF8lOmdOeb10iuqRYFbWyVMG9gBBz8TSt34In VsP1sTU1cDRIa9uJJE3bh9qB0AbMEEcOdArahUMOD0RogcFuSCGMmQeknmhfnZQd NGljwDIDn+o8VgvWWyyBCQ0X4xVoqLGb18SYzAKYbEBWk3AZmUa/RmWGqC0W/wQD gHoBhaSzAuefCR8IUrMJ07KYTPiiYX9W770E3qt2VaRfrXXCRIdA/I8x76wqNSlp MwNVAvdYpUsPjiVO56i4o0iFeiL7ChIqt11e+I0TLp3RU6/rn91UZ3eMeSxEoHVo sGIZ+oLTUJI0Sw3Z1+PU3fN9lWVaDPhNj+wstLAoxEsbzZhGBzpgaTgmYJHyf8lG 2srKgjfE8VF8H6mHNy9pOdL8DPdIa5UgNcffnNqSt4Ml1E5mDe5e+ac4Y11nESvi 8h4OxyFPFw+aTtnd6sCKIfXrfRANCeT8dc7zeV2nodzw6yr/ndFlAe3iY8eG1m6K JEIGK5KCL7hic58L8aT+G6vjqexUvMChCq8U1DwArWKnxYWvdcB5IFQMV/ML/B0B 5UwhjdFvMp0= =8l4U -----END PGP SIGNATURE----- --2fLGufcSJaIWCyz8-- From nobody Wed May 13 13:45:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16B61A8A6E for ; Wed, 13 May 2015 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9070UHfx24D for ; Wed, 13 May 2015 13:45:53 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF731A8A3A for ; Wed, 13 May 2015 13:45:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFADu3U1WHCzIm/2dsb2JhbABcgmYpVF4GglJGw1GGBQIcgSJMAQEBAQEBgQuEIAEBAQEDDAYREToLDAQCAQYCDQQEAQEBAgIGHQMCAgIfERQBCAgCBAENBQgTB4d1AxIBDJlmkjiKT407DYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihmCTYIHFhsHBoJiL4EWBYZiiSuCSYQngkmCKgGCej6GFgtlhxeDH4NXI4N3bwEBgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,422,1427774400"; d="scan'208";a="120414677" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 May 2015 16:45:52 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 13 May 2015 16:45:52 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Wed, 13 May 2015 16:45:51 -0400 From: "Mudric, Dusan (Dusan)" To: Brian E Carpenter , Lorenzo Colitti , "STARK, BARBARA H" , "v6ops@ietf.org" Thread-Topic: Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AQHQjO7u5SBG9u46QEK4wNDSgsbkgJ16TxHA Date: Wed, 13 May 2015 20:45:51 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> In-Reply-To: <55525CEE.9020106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Lin, Ping \(Ping\)" , "Steven B." Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 20:45:56 -0000 ZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbTogDQotIERvZXMgbm90IG1lbnRp b24gdXNlIG9mIHN0YXRlbGVzcyBESENQdjYgDQotIERvZXMgbm90IG1lbnRpb24gdGhhdCBpcyBu b3QgY2xlYXIgaWYgc3RhdGVsZXNzIERIQ1B2NiBjbGllbnQgc2hvdWxkIHN0YXJ0IGlmIFNMQUFD IGlzIHVzZWQgYW5kIE09MCBhbmQgTyBjaGFuZ2VzIGZyb20gMCB0byAxLiBPciwgc3RhdGVmdWwg REhDUHY2IGNhbiBzdGFydCBidXQgSVB2NiBhZGRyZXNzIGNhbiBiZSBpZ25vcmVkIG9yIE9STyBv cHRpb24gZG9lcyBub3QgcmVxdWlyZSB0aGUgYWRkcmVzcy4NCi0gRG9lcyBub3QgbWVudGlvbiBp ZiB0aGUgaG9zdCBpcyBTTEFBQyBhbmQgc3RhdGVmdWwgREhDUHY2IGNvbmZpZ3VyZWQgc2ltdWx0 YW5lb3VzbHkgKGJ1bGxldCB0d28gZG9lcyBub3Qgc2F5IHN0YXRlZnVsKSwgREhDUHY2IGFkZHJl c3Mgc2hvdWxkIHN0YXJ0IHdpdGggUEkgcHJlZml4DQotIERvZXMgbm90IG1lbnRpb24gdGhhdCAn TScgYW5kICdPJyBmbGFncywgc2hvdWxkIGJlIHVzZWQgYXMgYSBtZWNoYW5pc20gdG8gZGlzYWJs ZSBvbmx5IHN0YXRlZnVsIElQdjYgYWRkcmVzcyBpZiBTTEFBQyBpcyBlbmFibGVkLiBXaGF0IGlz IHRoZSB2YWx1ZSBvZiBkaXNhYmxpbmcgb3RoZXIgREhDUHY2IGNvbmZpZ3VyYXRpb24/IEVuZCBw b2ludCBpbnN0cnVtZW50cyBuZWVkIERIQ1B2NiBmb3Igb3RoZXIgY29uZmlndXJhdGlvbiBpbmZv cm1hdGlvbiBhbmQgdGhhdCBzaGFsbCBub3QgYmUgZGlzYWJsZWQgdmlhIGEgcm91dGVyIChVbmxl c3MgdGhlcmUgaXMgYSBwbGFuIHRvIHByb3ZpZGUgYWxsIHRoYXQgY29uZmlndXJhdGlvbiB2aWEg YSByb3V0ZXI/KS4gSWYgdGhlcmUgaXMgYWdyZWVtZW50IG9uIHRoaXMgc3RhdGVtZW50LCBvbmx5 IG9uZSBmbGFnIGlzIG5lZWRlZCwgJ00nIGZsYWcuIFRoaXMgZmxhZyB3b3VsZCBjb250cm9sIGlm IGVuZCBwb2ludCBpbnN0cnVtZW50cyB3b3VsZCBoYXZlIG9ubHkgU0xBQUMgb3Igb25seSBESENQ djYgYWRkcmVzcyAoZXhhbXBsZTogTT0xIHdvdWxkIG1lYW4gb25seSBESENQdjYgYWRkcmVzcyBp cyBjb25maWd1cmVkIGFuZCBpZiBBPTEgd291bGQgbWVhbiB0aGF0IERIQ1B2NiBhZGRyZXNzIHdv dWxkIGhhdmUgdG8gc3RhcnQgd2l0aCB0aGUgUEkgcHJlZml4KS4gSSBkb24ndCBzZWUgYSBuZWVk IGZvciBib3RoIFNMQUFDIGFuZCBESENQdjYgYWRkcmVzc2VzLg0KDQpEdXNhbg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgTWF5IDEyLCAyMDE1IDQ6 MDUgUE0NClRvOiBNdWRyaWMsIER1c2FuIChEdXNhbik7IExvcmVuem8gQ29saXR0aTsgU1RBUkss IEJBUkJBUkEgSA0KQ2M6IExpbiwgUGluZyAoUGluZyk7IFN0ZXZlbiBCLjsgaXB2NkBpZXRmLm9y ZzsgQmVybmllIFZvbHogKHZvbHopDQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gcmUuIHN0YXRlbGVz cyBESENQdjYgYW5kICdNJyAmICdPJyBmbGFncw0KDQpIaSBEdXNhbiwNCg0KVGhlIE0vTyBmbGFn cyBhcmUgbm90IG9ic29sZXRlLiBUaGV5IGFyZSBkZWZpbmVkIGluIFJGQyA0ODYxLg0KDQpZb3Ug bWlnaHQgd2FudCB0byByZWFkIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkR2Nm9wcy0y RGRoY3B2Ni0yRHNsYWFjLTJEcHJvYmxlbSZkPUF3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QVBoRDVU cTdROUVaNjRlREtUY29vSlg4dnZRZFRDZHdHZTd3LS1RY0MzMCZzPVZ2QzJuUVRvQjUxcWRoOEo3 Smxwdy1ZM05FM2dfSlN1b29heTJmRVZ1MHMmZT0NCihub3RpbmcgdGhhdCBpdCBpcyBzdGlsbCBh IGRyYWZ0LCBkaXNjdXNzZWQgaW4gdGhlIHY2b3BzIFdHKSBhbmQgeW91IG1pZ2h0IG1vdmUgdGhp cyBkaXNjdXNzaW9uIHRvIHRoZSB2Nm9wcyBsaXN0LCB0b28uDQoNClJlZ2FyZHMNCiAgIEJyaWFu IENhcnBlbnRlcg0KDQoNCk9uIDEzLzA1LzIwMTUgMDY6NTMsIE11ZHJpYywgRHVzYW4gKER1c2Fu KSB3cm90ZToNCj4gSGkgRXZlcnlvbmUsDQo+IA0KPiBJIHdvdWxkIGFwcHJlY2lhdGUgeW91ciBo ZWxwIGFuc3dlcmluZyB0aGUgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgc3RhdGVsZXNzIERIQ1B2 NiBhbmQg4oCYTeKAmSAmIOKAmE/igJkgZmxhZ3M6DQo+IA0KPiBCYWNrZ3JvdW5kOg0KPiA9PT09 PT09PT09PQ0KPiBGb2xsb3dpbmcgUkZDIDI0NjIsIOKAnE/igJ0gZmxhZyBpbiBSb3V0ZXIgQWR2 ZXJ0aXNlbWVudHMgaXMgdXNlZCB0byBzdGFydCBzdGF0ZWxlc3MgREhDUHY2IGNsaWVudC4gV2hl biB1c2luZyDigJhP4oCZIGZsYWcsIHRoZSBlbmQgcG9pbnQgc2hhbGwgc3VwcG9ydDoNCj4gDQo+ IMK3ICAgICAgICAgUkZDIDM3MzY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWZ0cC0zQV9fZnRwLnJmYy0yRGVkaXRvci5vcmdfaW4tMkRub3Rlc19yZmMzNzM2LnR4 dCZkPUF3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNy aElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QVBoRDVUcTdROUVaNjRlREtUY29vSlg4dnZRZFRD ZHdHZTd3LS1RY0MzMCZzPW1aa2hCZGhYb0lSR0VzSzZaM21mV1M0Unl2S0ItSWlLaG9ycFhCZm53 RVkmZT0gPiAsIHRoYXQgZGVmaW5lcyBzdGF0ZWxlc3MgREhDUHY2IGNsaWVudA0KPiANCj4gwrcg ICAgICAgICBSRkMgNDI0MiwgdGhhdCBkZWZpbmVzIHdoZW4gdGhlIGVuZCBwb2ludCBzaG91bGQg cmVmcmVzaCB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4NCj4gDQo+IFF1ZXN0aW9uczoN Cj4gPT09PT09PT09DQo+IElmIFJGQyA0ODYyIHJlbW92ZWQg4oCYTeKAmSAmIOKAmE/igJkgZmxh Z3MgYW5kIG9ic29sZXRlZCBSRkMgMjQ2MiAodGhhdCBkZWZpbmVzIOKAmE3igJkgJiDigJhP4oCZ IGZsYWdzKSwgd2h5IGFyZSB0aGUgZmxhZ3Mgbm90IGRlcHJlY2F0ZWQ/IFdoYXQgaXMgdGhlIHZh bHVlIG9mIHJlZmVycmluZyB0byB0aGUgb2Jzb2xldGVkIHN0YW5kYXJkLCBpbiBvcmRlciB0byBz dXBwb3J0IGZsYWdzIGluIHRoZSBzb2x1dGlvbiB0aGF0IGlzIG5vdCBtYXR1cmU/DQo+IA0KPiBy ZmM0ODYyI2FwcGVuZGl4LUMNCj4gICAgbyAgUmVtb3ZlZCB0aGUgdGV4dCByZWdhcmRpbmcgdGhl IE0gYW5kIE8gZmxhZ3MsIGNvbnNpZGVyaW5nIHRoZQ0KPiAgICAgICBtYXR1cml0eSBvZiBpbXBs ZW1lbnRhdGlvbnMgYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2VzLg0KPiAgICAgICBNYW5hZ2Vk RmxhZyBhbmQgT3RoZXJDb25maWdGbGFnIHdlcmUgcmVtb3ZlZCBhY2NvcmRpbmdseS4gIChOb3Rl DQo+ICAgICAgIHRoYXQgdGhpcyBjaGFuZ2UgZG9lcyBub3QgbWVhbiB0aGUgdXNlIG9mIHRoZXNl IGZsYWdzIGlzDQo+ICAgICAgIGRlcHJlY2F0ZWQuKQ0KPiANCj4gSW4gdGhlIHRocmVhZCDigJxS ZTogUXVlc3Rpb24gcmUuIFJFQ09ORklHIGluIERIQ1B2NuKAnSwgQmVybmllIHN0YXRlZDoNCj4g 4oCcVGhlIFJGQyAzNzM2IGRvY3VtZW50IGlzIHJlYWxseSBub3Qgc29tZXRoaW5nIEkgd291bGQg cmVjb21tZW5kIGZvbGxvd2luZyAtIHNlZSBmdWxsIFJGQyAzMzE1IGFuZCBpbXBsZW1lbnQgdGhv c2UgZmVhdHVyZXMgeW91IG5lZWQgKHN1Y2ggYXMgb25seSBJbmZvcm1hdGlvbi1SZXF1ZXN0IGFu ZCBSZXBseSkuIDM3MzYgd2FzIHdyaXR0ZW4gdG8gZGVtb25zdHJhdGUgdGhhdCBzdGF0ZWxlc3Mg ZGhjcHY2IHdhcyByYXRoZXIgc2ltcGxlIHRvIGltcGxlbWVudC7igJ0NCj4gDQo+IEJhc2VkIG9u IHRoZSBmYWN0IHRoYXQg4oCYTeKAmSAmIOKAmE/igJkgZmxhZ3MgYXJlIHJlbW92ZWQgZnJvbSB0 aGUgUkZDIDQ4NjIgYW5kIHRoZSBzdGF0ZW1lbnQgYWJvdmUsIGNhbiB3ZSBzYXkgdGhlIHN0YXRl bGVzcyBESENQdjYgaXMgbm90IG1hbmRhdG9yeSBhbmQsIGNvbnNlcXVlbnRseSwg4oCYT+KAmSBm bGFnIGlzIG5vdCByZXF1aXJlZD8NCj4gDQo+IElmIHN0YXRlbGVzcyBESENQdjYgaXMgbm90IHVz ZWQsIHN0YXRlZnVsIERIQ1B2NiBpcyByZXF1aXJlZC4gVGhlbiwg4oCYTeKAmSBmbGFnIGlzIG5v dCBuZWVkZWQuDQo+IA0KPiBSZWdhcmRzLA0KPiBEdXNhbiBNdWRyaWMuDQo+IA0KPiANCj4gDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBp cHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiANCj4gaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bA0KPiBtYW5fbGlzdGluZm9faXB2NiZkPUF3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEm cj1VVDNCazljYkxlYUp4aGYzDQo+IGlDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUFQaEQ1 VHE3UTlFWjY0ZURLVGNvb0pYOHZ2UWRUQ2R3R2U3dy0tUWMNCj4gQzMwJnM9NGhRd0JrNE12UFNX Rmg3TGJ5ajlwTFlhNG9iYmJET18xN0VZTGNGS2gzVSZlPQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCg0K From nobody Wed May 13 20:09:49 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC3B1B32B2 for ; Wed, 13 May 2015 20:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LSVf-oH_L64 for ; Wed, 13 May 2015 20:09:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332581B32AE for ; Wed, 13 May 2015 20:09:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSN08256; Thu, 14 May 2015 03:09:38 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 May 2015 04:09:37 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 14 May 2015 11:09:33 +0800 From: "Liubing (Leo)" To: "Mudric, Dusan (Dusan)" , Brian E Carpenter , Lorenzo Colitti , "STARK, BARBARA H" , "v6ops@ietf.org" Thread-Topic: Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AdCM5PoG5SBG9u46QEK4wNDSgsbkgP//jcwAgAGdvID//yEnYA== Date: Thu, 14 May 2015 03:09:32 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Lin, Ping \(Ping\)" , "Steven B." Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 03:09:45 -0000 SGkgRHVzYW4gYW5kIGFsbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdWRy aWMsIER1c2FuDQo+IChEdXNhbikNCj4gU2VudDogVGh1cnNkYXksIE1heSAxNCwgMjAxNSA0OjQ2 IEFNDQo+IFRvOiBCcmlhbiBFIENhcnBlbnRlcjsgTG9yZW56byBDb2xpdHRpOyBTVEFSSywgQkFS QkFSQSBIOyB2Nm9wc0BpZXRmLm9yZw0KPiBDYzogTGluLCBQaW5nIChQaW5nKTsgU3RldmVuIEIu DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFF1ZXN0aW9uIHJlLiBzdGF0ZWxlc3MgREhDUHY2IGFu ZCAnTScgJiAnTycgZmxhZ3MNCj4gDQo+IGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXBy b2JsZW06DQo+IC0gRG9lcyBub3QgbWVudGlvbiB1c2Ugb2Ygc3RhdGVsZXNzIERIQ1B2Ng0KPiAt IERvZXMgbm90IG1lbnRpb24gdGhhdCBpcyBub3QgY2xlYXIgaWYgc3RhdGVsZXNzIERIQ1B2NiBj bGllbnQgc2hvdWxkIHN0YXJ0IGlmDQo+IFNMQUFDIGlzIHVzZWQgYW5kIE09MCBhbmQgTyBjaGFu Z2VzIGZyb20gMCB0byAxLiBPciwgc3RhdGVmdWwgREhDUHY2IGNhbg0KPiBzdGFydCBidXQgSVB2 NiBhZGRyZXNzIGNhbiBiZSBpZ25vcmVkIG9yIE9STyBvcHRpb24gZG9lcyBub3QgcmVxdWlyZSB0 aGUNCj4gYWRkcmVzcy4NCltCaW5nXSAoU3BlYWsgYXMgYSBjby1hdXRob3IpIFdlIGluZGVlZCBk aWRuJ3QgdGVzdCB0aGUgY2FzZSBhcyB5b3Ugc2FpZCBhYm92ZSwgYnV0IHdlIHRlc3RlZCBhIHNp bWlsYXIgY2FzZTogYXQgaW5pdGlhbCBzdGFnZSwgd2hlbiBBPTAsTT0wLCBhbmQgTz0xLCBzb21l IHBsYXRmb3JtIHdvdWxkIHN0YXJ0IHN0YXRlbGVzcyBESENQdjYgd2hpbGUgc29tZSBub3QuDQpE ZXRhaWxzIHBsZWFzZSByZWZlciB0byB0aGUgQXBwZW5kaXggQS4yIChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbS0wNCNhcHBl bmRpeC1BLjIpLg0KDQo+IC0gRG9lcyBub3QgbWVudGlvbiBpZiB0aGUgaG9zdCBpcyBTTEFBQyBh bmQgc3RhdGVmdWwgREhDUHY2IGNvbmZpZ3VyZWQNCj4gc2ltdWx0YW5lb3VzbHkgKGJ1bGxldCB0 d28gZG9lcyBub3Qgc2F5IHN0YXRlZnVsKSwgREhDUHY2IGFkZHJlc3Mgc2hvdWxkDQo+IHN0YXJ0 IHdpdGggUEkgcHJlZml4DQpbQmluZ10gU29ycnkgSSBkaWRuJ3QgY2F0Y2ggeW91ciBwb2ludC4g V2h5IGlzIHRoZSAiUEkgcHJlZml4IiByZWxhdGVkIHRvIFNMQUFDL0RIQ1B2NiBjb25maWd1cmVk IHNpbXVsdGFuZW91c2x5Pw0KQnR3LCB3aGljaCAiYnVsbGV0IHR3byIgZGlkIHlvdSByZWZlciB0 bz8NCg0KDQo+IC0gRG9lcyBub3QgbWVudGlvbiB0aGF0ICdNJyBhbmQgJ08nIGZsYWdzLCBzaG91 bGQgYmUgdXNlZCBhcyBhIG1lY2hhbmlzbSB0bw0KPiBkaXNhYmxlIG9ubHkgc3RhdGVmdWwgSVB2 NiBhZGRyZXNzIGlmIFNMQUFDIGlzIGVuYWJsZWQuIA0KW0JpbmddIERpZCB5b3UgbWVhbiwgd2hl biBhIGhvc3QgaXMgY29uZmlndXJlZCB3aXRoIFNMQUFDLCB0aGUgREhDUHY2IGFkZHJlc3MgY29u ZmlndXJhdGlvbiBzaG91bGQgYmUgZGlzYWJsZWQ/DQpXZSBkaWQgb2JzZXJ2ZWQgc29tZSBiZWhh dmlvcnMgbGlrZSB0aGlzIGluIHNvbWUgcGxhdGZvcm06IHdoZW4gYSBob3N0IGhhcyBjb25maWd1 cmVkIFNMQUFDLCBhbmQgdGhlbiBNIGNoYW5nZXMgZnJvbSAwIHRvIDEsIHNvbWUgaG9zdHMganVz dCBpZ25vcmUgdGhlIE0gZmxhZyAoc2VlIHRoZSBzZWNvbmQgYnVsbGV0IG9mIEFwcGVuZGl4IEEu MykuDQoNCkhvd2V2ZXIsIHBlcnNvbmFsbHkgSSdtIG5vdCBzdXJlIHRoaXMgc2hvdWxkIGJlIGEg cmlnaHQgYmVoYXZpb3IuIFNMQUFDL0RIQ1B2NiBhZGRyZXNzZXMgY28tZXhpc3RpbmcgbWlnaHQg bWFrZSBzZW5zZSBpbiBzb21lIHNjZW5hcmlvcy4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWxpdS12Nm9wcy1ydW5uaW5nLW11bHRpcGxlLXByZWZpeGVzLTAzI3NlY3Rpb24tMy4x IGhhcyBhIGJyaWVmIGRpc2N1c3Npb24gb24gdGhpcy4gQnV0IHRoaXMgZHJhZnQtaWV0Zi12Nm9w cy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBkb2VzIG5vdCBpbnRlbmQgdG8gZGlzY3VzcyB3aGF0IHRo ZSByaWdodCBiZWhhdmlvciBzaG91bGQgYmUuDQoNCj4gV2hhdCBpcyB0aGUgdmFsdWUgb2YNCj4g ZGlzYWJsaW5nIG90aGVyIERIQ1B2NiBjb25maWd1cmF0aW9uPyBFbmQgcG9pbnQgaW5zdHJ1bWVu dHMgbmVlZCBESENQdjYNCj4gZm9yIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYW5k IHRoYXQgc2hhbGwgbm90IGJlIGRpc2FibGVkIHZpYSBhDQo+IHJvdXRlciAoVW5sZXNzIHRoZXJl IGlzIGEgcGxhbiB0byBwcm92aWRlIGFsbCB0aGF0IGNvbmZpZ3VyYXRpb24gdmlhIGEgcm91dGVy PykuDQo+IElmIHRoZXJlIGlzIGFncmVlbWVudCBvbiB0aGlzIHN0YXRlbWVudCwgb25seSBvbmUg ZmxhZyBpcyBuZWVkZWQsICdNJyBmbGFnLg0KW0JpbmddIEkgY2FuJ3QgcmVhbGx5IGFuc3dlciB0 aGlzIHF1ZXN0aW9uLiBNeSBndWVzcyBpcyB0aGF0ICwgd2hlbiB0aGUgaG9zdHMgY2FuIGdldCBi b3RoIGFkZHJlc3MgYW5kIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhyb3VnaCBz dGF0ZWZ1bCBESENQdjYgY29uZmlndXJhdGlvbiwgdGhlbiB0aGUgc3RhdGVsZXNzIERIQ1B2NiBj b25maWd1cmF0aW9uIGlzIHJlZHVuZGFudCBpZiBpdCBpcyBhbHdheXMgb24uDQoNCj4gVGhpcyBm bGFnIHdvdWxkIGNvbnRyb2wgaWYgZW5kIHBvaW50IGluc3RydW1lbnRzIHdvdWxkIGhhdmUgb25s eSBTTEFBQyBvcg0KPiBvbmx5IERIQ1B2NiBhZGRyZXNzIChleGFtcGxlOiBNPTEgd291bGQgbWVh biBvbmx5IERIQ1B2NiBhZGRyZXNzIGlzDQo+IGNvbmZpZ3VyZWQgYW5kIGlmIEE9MSB3b3VsZCBt ZWFuIHRoYXQgREhDUHY2IGFkZHJlc3Mgd291bGQgaGF2ZSB0byBzdGFydA0KPiB3aXRoIHRoZSBQ SSBwcmVmaXgpLiBJIGRvbid0IHNlZSBhIG5lZWQgZm9yIGJvdGggU0xBQUMgYW5kIERIQ1B2NiBh ZGRyZXNzZXMuDQpbQmluZ10gQXMgc2FpZCBhYm92ZSwgSSB0aGluayBjby1leGlzdGluZyBtaWdo dCBtYWtlIHNlbnNlIGluIHNvbWUgc2NlbmFyaW9zLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoN Cg0KPiBEdXNhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJp YW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNl bnQ6IFR1ZXNkYXksIE1heSAxMiwgMjAxNSA0OjA1IFBNDQo+IFRvOiBNdWRyaWMsIER1c2FuIChE dXNhbik7IExvcmVuem8gQ29saXR0aTsgU1RBUkssIEJBUkJBUkEgSA0KPiBDYzogTGluLCBQaW5n IChQaW5nKTsgU3RldmVuIEIuOyBpcHY2QGlldGYub3JnOyBCZXJuaWUgVm9seiAodm9seikNCj4g U3ViamVjdDogUmU6IFF1ZXN0aW9uIHJlLiBzdGF0ZWxlc3MgREhDUHY2IGFuZCAnTScgJiAnTycg ZmxhZ3MNCj4gDQo+IEhpIER1c2FuLA0KPiANCj4gVGhlIE0vTyBmbGFncyBhcmUgbm90IG9ic29s ZXRlLiBUaGV5IGFyZSBkZWZpbmVkIGluIFJGQyA0ODYxLg0KPiANCj4gWW91IG1pZ2h0IHdhbnQg dG8gcmVhZA0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfDQo+IGRyYWZ0LTJEaWV0Zi0yRHY2b3BzLTJEZGhj cHY2LTJEc2xhYWMtMkRwcm9ibGVtJmQ9QXdJRmFRJmM9QkZwV1ENCj4gdzhic3VLcGwxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmsNCj4gWSZtPUFQ aEQ1VHE3UTlFWjY0ZURLVGNvb0pYOHZ2UWRUQ2R3R2U3dy0tUWNDMzAmcz1WdkMyblFUb0INCj4g NTFxZGg4SjdKbHB3LVkzTkUzZ19KU3Vvb2F5MmZFVnUwcyZlPQ0KPiAobm90aW5nIHRoYXQgaXQg aXMgc3RpbGwgYSBkcmFmdCwgZGlzY3Vzc2VkIGluIHRoZSB2Nm9wcyBXRykgYW5kIHlvdSBtaWdo dCBtb3ZlDQo+IHRoaXMgZGlzY3Vzc2lvbiB0byB0aGUgdjZvcHMgbGlzdCwgdG9vLg0KPiANCj4g UmVnYXJkcw0KPiAgICBCcmlhbiBDYXJwZW50ZXINCj4gDQo+IA0KPiBPbiAxMy8wNS8yMDE1IDA2 OjUzLCBNdWRyaWMsIER1c2FuIChEdXNhbikgd3JvdGU6DQo+ID4gSGkgRXZlcnlvbmUsDQo+ID4N Cj4gPiBJIHdvdWxkIGFwcHJlY2lhdGUgeW91ciBoZWxwIGFuc3dlcmluZyB0aGUgcXVlc3Rpb25z IHJlZ2FyZGluZyB0aGUNCj4gc3RhdGVsZXNzIERIQ1B2NiBhbmQg4oCYTeKAmSAmIOKAmE/igJkg ZmxhZ3M6DQo+ID4NCj4gPiBCYWNrZ3JvdW5kOg0KPiA+ID09PT09PT09PT09DQo+ID4gRm9sbG93 aW5nIFJGQyAyNDYyLCDigJxP4oCdIGZsYWcgaW4gUm91dGVyIEFkdmVydGlzZW1lbnRzIGlzIHVz ZWQgdG8gc3RhcnQNCj4gc3RhdGVsZXNzIERIQ1B2NiBjbGllbnQuIFdoZW4gdXNpbmcg4oCYT+KA mSBmbGFnLCB0aGUgZW5kIHBvaW50IHNoYWxsIHN1cHBvcnQ6DQo+ID4NCj4gPiDCtyAgICAgICAg IFJGQw0KPiAzNzM2PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1m dHAtM0FfX2Z0cC5yZmMtMkRlZGl0b3IuDQo+IG9yZ19pbi0yRG5vdGVzX3JmYzM3MzYudHh0JmQ9 QXdJRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPQ0KPiBVVDNCazljYkxlYUp4aGYzaUNy aElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QVBoRDVUcTdROUVaNjQNCj4gZURLVGNvb0pYOHZ2 UWRUQ2R3R2U3dy0tUWNDMzAmcz1tWmtoQmRoWG9JUkdFc0s2WjNtZldTNFJ5dktCDQo+IC1JaUto b3JwWEJmbndFWSZlPSA+ICwgdGhhdCBkZWZpbmVzIHN0YXRlbGVzcyBESENQdjYgY2xpZW50DQo+ ID4NCj4gPiDCtyAgICAgICAgIFJGQyA0MjQyLCB0aGF0IGRlZmluZXMgd2hlbiB0aGUgZW5kIHBv aW50IHNob3VsZCByZWZyZXNoIHRoZQ0KPiBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLg0KPiA+ DQo+ID4gUXVlc3Rpb25zOg0KPiA+ID09PT09PT09PQ0KPiA+IElmIFJGQyA0ODYyIHJlbW92ZWQg 4oCYTeKAmSAmIOKAmE/igJkgZmxhZ3MgYW5kIG9ic29sZXRlZCBSRkMgMjQ2MiAodGhhdA0KPiBk ZWZpbmVzIOKAmE3igJkgJiDigJhP4oCZIGZsYWdzKSwgd2h5IGFyZSB0aGUgZmxhZ3Mgbm90IGRl cHJlY2F0ZWQ/IFdoYXQgaXMgdGhlDQo+IHZhbHVlIG9mIHJlZmVycmluZyB0byB0aGUgb2Jzb2xl dGVkIHN0YW5kYXJkLCBpbiBvcmRlciB0byBzdXBwb3J0IGZsYWdzIGluIHRoZQ0KPiBzb2x1dGlv biB0aGF0IGlzIG5vdCBtYXR1cmU/DQo+ID4NCj4gPiByZmM0ODYyI2FwcGVuZGl4LUMNCj4gPiAg ICBvICBSZW1vdmVkIHRoZSB0ZXh0IHJlZ2FyZGluZyB0aGUgTSBhbmQgTyBmbGFncywgY29uc2lk ZXJpbmcgdGhlDQo+ID4gICAgICAgbWF0dXJpdHkgb2YgaW1wbGVtZW50YXRpb25zIGFuZCBvcGVy YXRpb25hbCBleHBlcmllbmNlcy4NCj4gPiAgICAgICBNYW5hZ2VkRmxhZyBhbmQgT3RoZXJDb25m aWdGbGFnIHdlcmUgcmVtb3ZlZCBhY2NvcmRpbmdseS4NCj4gKE5vdGUNCj4gPiAgICAgICB0aGF0 IHRoaXMgY2hhbmdlIGRvZXMgbm90IG1lYW4gdGhlIHVzZSBvZiB0aGVzZSBmbGFncyBpcw0KPiA+ ICAgICAgIGRlcHJlY2F0ZWQuKQ0KPiA+DQo+ID4gSW4gdGhlIHRocmVhZCDigJxSZTogUXVlc3Rp b24gcmUuIFJFQ09ORklHIGluIERIQ1B2NuKAnSwgQmVybmllIHN0YXRlZDoNCj4gPiDigJxUaGUg UkZDIDM3MzYgZG9jdW1lbnQgaXMgcmVhbGx5IG5vdCBzb21ldGhpbmcgSSB3b3VsZCByZWNvbW1l bmQNCj4gZm9sbG93aW5nIC0gc2VlIGZ1bGwgUkZDIDMzMTUgYW5kIGltcGxlbWVudCB0aG9zZSBm ZWF0dXJlcyB5b3UgbmVlZCAoc3VjaA0KPiBhcyBvbmx5IEluZm9ybWF0aW9uLVJlcXVlc3QgYW5k IFJlcGx5KS4gMzczNiB3YXMgd3JpdHRlbiB0byBkZW1vbnN0cmF0ZQ0KPiB0aGF0IHN0YXRlbGVz cyBkaGNwdjYgd2FzIHJhdGhlciBzaW1wbGUgdG8gaW1wbGVtZW50LuKAnQ0KPiA+DQo+ID4gQmFz ZWQgb24gdGhlIGZhY3QgdGhhdCDigJhN4oCZICYg4oCYT+KAmSBmbGFncyBhcmUgcmVtb3ZlZCBm cm9tIHRoZSBSRkMgNDg2Mg0KPiBhbmQgdGhlIHN0YXRlbWVudCBhYm92ZSwgY2FuIHdlIHNheSB0 aGUgc3RhdGVsZXNzIERIQ1B2NiBpcyBub3QgbWFuZGF0b3J5DQo+IGFuZCwgY29uc2VxdWVudGx5 LCDigJhP4oCZIGZsYWcgaXMgbm90IHJlcXVpcmVkPw0KPiA+DQo+ID4gSWYgc3RhdGVsZXNzIERI Q1B2NiBpcyBub3QgdXNlZCwgc3RhdGVmdWwgREhDUHY2IGlzIHJlcXVpcmVkLiBUaGVuLCDigJhN 4oCZDQo+IGZsYWcgaXMgbm90IG5lZWRlZC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gRHVzYW4g TXVkcmljLg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwNCj4gPg0KPiBtYW5fbGlzdGluZm9f aXB2NiZkPUF3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkwNCj4gZWFK eGhmMw0KPiA+DQo+IGlDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUFQaEQ1VHE3UTlFWjY0 ZURLVGNvb0pYOHZ2UWRUDQo+IENkd0dlN3ctLVFjDQo+ID4gQzMwJnM9NGhRd0JrNE12UFNXRmg3 TGJ5ajlwTFlhNG9iYmJET18xN0VZTGNGS2gzVSZlPQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu May 14 01:02:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FEA1B34FC for ; Thu, 14 May 2015 01:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCfitv2HCGZk for ; Thu, 14 May 2015 01:02:17 -0700 (PDT) Received: from mail.opteamax.de (mail.opteamax.de [194.62.23.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7819D1B34F5 for ; Thu, 14 May 2015 01:02:17 -0700 (PDT) Received: (qmail 28281 invoked from network); 14 May 2015 08:26:45 -0000 Received: from unknown (HELO berck.opteamax.de) (jo@opteamax.de@2001:67c:64:49:6257:18ff:fe64:b1b2) by mail.opteamax.de with ESMTPA; 14 May 2015 08:26:45 -0000 Message-ID: <55545683.6070202@opteamax.de> Date: Thu, 14 May 2015 10:02:11 +0200 From: "Jens Ott - Opteamax GmbH" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:02:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Mailinglist-Members, I am pretty new on this list, so I first wave a "Hello" into the round... and immediately continue to ask the question, which led me to subscribing to this list. Apologies if I chose the wrong list, please advise me, where to put my question in this case. I work as consultant and already accompanied several IPv6 roll-outs from the first idea "we want V6" until production. While enterprise-setups are mostly /32 or less IPs, I see more and more rollouts which need much bigger space. At least in RIPE-Region, each LIR can receive a /29 without any justification. And here is where my problem starts. While writing documentation and addressing-plans before requesting the actual prefix at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in RFC3849. But what to do for bigger nets (lower bitmasks)? Before starting to push the ball on the field by writing a proposal, I'd be happy to hear if there is support in the community for updating this rfc and officially define a bigger prefix for documentation. As said, if I chose the wrong mailinglist or simply started bringing my idea into the community in a wrong way, any advise and comment is appreciated. I have no experience with the processes at ietf yet. Best regards and thanks - -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVVFZ+AAoJECrmRJLVnvx6VNMH/1Fls1/HkPwYM4OHxxZCqEmY ssIqUD5YOvef/vJqE2dxklwS3Is4la0nEouHfyL46AQwoy9tkKm7IkYhgNy0aX84 ok+oxxvITihW/4h07UttB/4u9Y8MCSx4rTOTXV0CoccWbnA8jSMBlwRN5fQr+VHS NeWo7iKQ4U95kUY9pJXMHIc+UDpTHl3uIrZlEC0dq/OQ86Xyj5hQX75KAEUhjHfT 7QjD9WEIz8vmc858r53vrzMUsOGIHwhSAGJf9qXZRVx7ygDj9vuVGXUMInVPY0QR XQ/f9GB8RJE3CYIpYX8BGrsutfqK1Qp1jNyJTWQa1xA5zBiXuD1VV9JHg793/TA= =Umao -----END PGP SIGNATURE----- From nobody Thu May 14 07:41:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDDD1B2B59 for ; Thu, 14 May 2015 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFLHn89iXTIQ for ; Thu, 14 May 2015 07:41:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D1F1B2B5B for ; Thu, 14 May 2015 07:41:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAByzVFWHCzIm/2dsb2JhbABcgmYpVF4GglJGwzKFdAIcgSJMAQEBAQEBgQuEIgEBAQECAQwGERE6BgUFBwQCAQYCDQQEAQEDAgYdAwICAh8RFAEICAIEAQ0FCBMHh3UDCggBDJMOkjiKT58tDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihmCTYIHFhsHBoJiL4EWBYZjiTCCTYQoggpAgioBgnw+gyaCcQtlhxeDH4NXI4FmIxyBUm8BAYFDgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,429,1427774400"; d="scan'208";a="120531680" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 May 2015 10:41:34 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 May 2015 10:41:34 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Thu, 14 May 2015 10:41:33 -0400 From: "Mudric, Dusan (Dusan)" To: "Liubing (Leo)" , Brian E Carpenter , Lorenzo Colitti , "STARK, BARBARA H" , "v6ops@ietf.org" Thread-Topic: Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AQHQjO7u5SBG9u46QEK4wNDSgsbkgJ16TxHAgADA6wCAAGZEYA== Date: Thu, 14 May 2015 14:41:32 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Lin, Ping \(Ping\)" , "Steven B." Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:41:39 -0000 SGkgQmluZywNCg0KVGhlIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0gbmlj ZWx5IGNhcHR1cmVzIGFtYmlndWl0aWVzIGFuZCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIGFy b3VuZCAnTScsICdPJyBhbmQgJ0EnIGZsYWdzLiBJdCBhbHNvIG9wZW5zIGEgZmxvb3IgZm9yIGZ1 cnRoZXIgZGlzY3Vzc2lvbiBhcm91bmQ6DQotIHRoZSBuZWVkIGZvciBzdGF0ZWxlc3MgREhDUHY2 LA0KLSBzaW11bHRhbmVvdXMgU0xBQUMgYW5kIERIQ1B2NiBhZGRyZXNzIGFzc2lnbm1lbnRzLCBh bmQNCi0gTkQgYW5kIERIQ1B2NiBpbnRlcndvcmtpbmc6IGUuZy4gdGhlIHJvbGUgb2YgTkQgb24t bGluayBhZGRyZXNzIHByZWZpeCBmb3IgREhDUHY2IGFkZHJlc3Nlcy4NCg0KT25seSB3aGVuIHRo ZSBuZWVkcyBhcmUgc3lzdGVtYXRpY2FsbHkgY2FwdHVyZWQsIGl0IHdpbGwgYmUgcG9zc2libGUg dG8gZGVmaW5lIHRoZSBmbGFncy4NCg0KW0JpbmddIChTcGVhayBhcyBhIGNvLWF1dGhvcikgV2Ug aW5kZWVkIGRpZG4ndCB0ZXN0IHRoZSBjYXNlIGFzIHlvdSBzYWlkIGFib3ZlLCBidXQgd2UgdGVz dGVkIGEgc2ltaWxhciBjYXNlOiBhdCBpbml0aWFsIHN0YWdlLCB3aGVuIEE9MCxNPTAsIGFuZCBP PTEsIHNvbWUgcGxhdGZvcm0gd291bGQgc3RhcnQgc3RhdGVsZXNzIERIQ1B2NiB3aGlsZSBzb21l IG5vdC4NCltEdXNhbl0gRGlkIHRoZSBob3N0cyBydW4gc3RhdGVsZXNzIERIQ1B2Niwgb3Igc3Rh dGVmdWwgREhDUHY2IHdpdGhvdXQgdGhlIGFkZHJlc3Mgb3B0aW9uIGluIE9STywgb3Igc3RhdGVm dWwgREhDUHY2IGFuZCBpZ25vcmVkIHRoZSBhZGRyZXNzIGluIFJFUExZPw0KDQo+IC0gRG9lcyBu b3QgbWVudGlvbiBpZiB0aGUgaG9zdCBpcyBTTEFBQyBhbmQgc3RhdGVmdWwgREhDUHY2IGNvbmZp Z3VyZWQgDQo+IHNpbXVsdGFuZW91c2x5IChidWxsZXQgdHdvIGRvZXMgbm90IHNheSBzdGF0ZWZ1 bCksIERIQ1B2NiBhZGRyZXNzIHNob3VsZCANCj4gc3RhcnQgd2l0aCBQSSBwcmVmaXggDQpbQmlu Z10gU29ycnkgSSBkaWRuJ3QgY2F0Y2ggeW91ciBwb2ludC4gV2h5IGlzIHRoZSAiUEkgcHJlZml4 IiByZWxhdGVkIHRvIFNMQUFDL0RIQ1B2NiBjb25maWd1cmVkIHNpbXVsdGFuZW91c2x5PyANCkJ0 dywgd2hpY2ggImJ1bGxldCB0d28iIGRpZCB5b3UgcmVmZXIgdG8/DQpbRHVzYW5dIEl0IGlzIGlt cG9ydGFudCB0aGF0IERIQ1B2NiBhZGRyZXNzIHN0YXJ0cyB3aXRoIG9uLWxpbmsgcHJlZml4LiBP dGhlcndpc2UgdGhlIGVuZCBwb2ludCB3aWxsIGJlIHVucmVhY2hhYmxlLiBXaGVuIFNMQUFDL0RI Q1B2NiBhcmUgY29uZmlndXJlZCB0byBydW4gc2ltdWx0YW5lb3VzbHksIGlmIE09MSBpcyBpbnRl cnByZXRlZCB0byBtZWFuIHJ1biBzdGF0ZWZ1bCBESENQdjYgYW5kIG9idGFpbiBJUHY2IGFkZHJl c3MgdmlhIERIQ1B2NiBjbGllbnQsIFBJIG9wdGlvbiBzaG91bGQgaGF2ZSBMIGJpdCBzZXQgdG8g YWxsb3cgdGhlIGVuZCBwb2ludCB0byB2ZXJpZnkgdGhlIGFjcXVpcmVkIERIQ1B2NiBhZGRyZXNz IGluIG9uLWxpbmsuIFRoaXMgYmVoYXZpb3Igc2hvdWxkIGJlIHN0YW5kYXJkaXplZC4NCg0KW0Jp bmddIEJ0dywgd2hpY2ggImJ1bGxldCB0d28iIGRpZCB5b3UgcmVmZXIgdG8/DQpbRHVzYW5dIFNl Y3Rpb24gMyAtIDIpLg0KDQo+IC0gRG9lcyBub3QgbWVudGlvbiB0aGF0ICdNJyBhbmQgJ08nIGZs YWdzLCBzaG91bGQgYmUgdXNlZCBhcyBhIG1lY2hhbmlzbSB0byANCj4gZGlzYWJsZSBvbmx5IHN0 YXRlZnVsIElQdjYgYWRkcmVzcyBpZiBTTEFBQyBpcyBlbmFibGVkLiAgDQpbQmluZ10gRGlkIHlv dSBtZWFuLCB3aGVuIGEgaG9zdCBpcyBjb25maWd1cmVkIHdpdGggU0xBQUMsIHRoZSBESENQdjYg YWRkcmVzcyBjb25maWd1cmF0aW9uIHNob3VsZCBiZSBkaXNhYmxlZD8NCltEdXNhbl0gWWVzLCBv bmx5IHRoZSBhZGRyZXNzIHBhcnQgc2hvdWxkIGJlIGRpc2FibGVkLiBCdXQgb3RoZXIgY29uZmln dXJhdGlvbiBpbmZvcm1hdGlvbiBzaG91bGQgYmUgc3RpbGwgYXZhaWxhYmxlIHZpYSBESENQdjYu DQoNCltCaW5nXSBIb3dldmVyLCBwZXJzb25hbGx5IEknbSBub3Qgc3VyZSB0aGlzIHNob3VsZCBi ZSBhIHJpZ2h0IGJlaGF2aW9yLiBTTEFBQy9ESENQdjYgYWRkcmVzc2VzIGNvLWV4aXN0aW5nIG1p Z2h0IG1ha2Ugc2Vuc2UgaW4gc29tZSBzY2VuYXJpb3MuDQpbRHVzYW5dIGRyYWZ0LWxpdS12Nm9w cy1ydW5uaW5nLW11bHRpcGxlLXByZWZpeGVzLTAzI3NlY3Rpb24tMy4xIG9ubHkgdGFsa3MgYWJv dXQgdGhlIHByZWZpeCBkZWxpdmVyaW5nIG1lY2hhbmlzbSB0byByb3V0ZXJzIHVzaW5nIERIQ1B2 Ni4gSXQgZG9lcyBub3QgcmVjb21tZW5kIHRoZSBjby1leGlzdGluZyBTTEFBQy9ESENQdjYgYmVo YXZpb3IgZm9yIGhvc3RzLiBJZiB0aGVyZSBpcyBhIG5lZWQgZm9yIG11bHRpcGxlIElQdjYgYWRk cmVzc2VzIHBlciBpbnRlcmZhY2UsIGFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQsIFNMQUFDIGFs cmVhZHkgYWxsb3dzIHRoZSB1c2Ugb2YgbXVsdGlwbGUgcHJlZml4ZXMgYW5kIERIQ1B2NiBhbHJl YWR5IGFsbG93cyB0aGUgYXNzaWdubWVudCBvZiBtdWx0aXBsZSBJUHY2IGFkZHJlc3Nlcy4gVGhl cmUgaXMgcmVhbGx5IG5vIG5lZWQgZm9yIGFkZGluZyBmdXJ0aGVyIGNvbXBsZXhpdHkgYnkgbWl4 aW5nIHRoZSB0d286IFNMQUFDIElQdjYgYWRkcmVzc2VzIGFuZCBESENQdjYgSVB2NiBhZGRyZXNz ZXMuDQoNCj4gV2hhdCBpcyB0aGUgdmFsdWUgb2YgDQo+IGRpc2FibGluZyBvdGhlciBESENQdjYg Y29uZmlndXJhdGlvbj8gRW5kIHBvaW50IGluc3RydW1lbnRzIG5lZWQgREhDUHY2IA0KPiBmb3Ig b3RoZXIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBhbmQgdGhhdCBzaGFsbCBub3QgYmUgZGlz YWJsZWQgdmlhIGEgDQo+IHJvdXRlciAoVW5sZXNzIHRoZXJlIGlzIGEgcGxhbiB0byBwcm92aWRl IGFsbCB0aGF0IGNvbmZpZ3VyYXRpb24gdmlhIGEgcm91dGVyPykuIA0KPiBJZiB0aGVyZSBpcyBh Z3JlZW1lbnQgb24gdGhpcyBzdGF0ZW1lbnQsIG9ubHkgb25lIGZsYWcgaXMgbmVlZGVkLCAnTScg ZmxhZy4NCltCaW5nXSBJIGNhbid0IHJlYWxseSBhbnN3ZXIgdGhpcyBxdWVzdGlvbi4gTXkgZ3Vl c3MgaXMgdGhhdCAsIHdoZW4gdGhlIGhvc3RzIGNhbiBnZXQgYm90aCBhZGRyZXNzIGFuZCBvdGhl ciBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRocm91Z2ggc3RhdGVmdWwgREhDUHY2IGNvbmZp Z3VyYXRpb24sIHRoZW4gdGhlIHN0YXRlbGVzcyBESENQdjYgY29uZmlndXJhdGlvbiBpcyByZWR1 bmRhbnQgaWYgaXQgaXMgYWx3YXlzIG9uLg0KW0R1c2FuXSBTdGF0ZWxlc3MgREhDUHY2IGlzIHJl ZHVuZGFudCBieSBpdHMgbmF0dXJlLiBTdGF0ZWZ1bCBESENQdjYgY2FuIHNlbmQgU09MSUNJVCBh bmQgUkVRVUVTVCBtZXNzYWdlcyB3aXRoIE9STyBvcHRpb24gdGhhdCBkb2VzIG5vdCByZXF1aXJl IHRoZSBhZGRyZXNzIChlLmcuIHdpdGhvdXQgT1BUSU9OX0lBX05BIG9wdGlvbiBjb2RlKS4gSWYg dGhlcmUgaXMgbm8gc3RhdGVsZXNzIERIQ1B2NiBjbGllbnQgdG8gY29udHJvbCwgdGhlcmUgaXMg bm8gbmVlZCBmb3IgJ08nIGZsYWcuIFRoZSByZW1haW5pbmcgJ00nIGZsYWcgY2FuIGJlIHVzZWQg dG8gY29udHJvbCBpZiBPUk8gb3B0aW9uIGhhcyBPUFRJT05fSUFfTkEgb3B0aW9uIGNvZGUuDQoN ClJlZ2FyZHMsDQpEdXNhbiBNdWRyaWMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMaXViaW5nIChMZW8pIFttYWlsdG86bGVvLmxpdWJpbmdAaHVhd2VpLmNvbV0gDQpTZW50 OiBXZWRuZXNkYXksIE1heSAxMywgMjAxNSAxMToxMCBQTQ0KVG86IE11ZHJpYywgRHVzYW4gKER1 c2FuKTsgQnJpYW4gRSBDYXJwZW50ZXI7IExvcmVuem8gQ29saXR0aTsgU1RBUkssIEJBUkJBUkEg SDsgdjZvcHNAaWV0Zi5vcmcNCkNjOiBMaW4sIFBpbmcgKFBpbmcpOyBTdGV2ZW4gQi4NClN1Ympl Y3Q6IFJFOiBRdWVzdGlvbiByZS4gc3RhdGVsZXNzIERIQ1B2NiBhbmQgJ00nICYgJ08nIGZsYWdz DQoNCkhpIER1c2FuIGFuZCBhbGwsDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQoNCj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTXVkcmljLCBEdXNhbg0KDQo+IChEdXNhbikNCg0KPiBTZW50OiBUaHVyc2RheSwgTWF5 IDE0LCAyMDE1IDQ6NDYgQU0NCg0KPiBUbzogQnJpYW4gRSBDYXJwZW50ZXI7IExvcmVuem8gQ29s aXR0aTsgU1RBUkssIEJBUkJBUkEgSDsgdjZvcHNAaWV0Zi5vcmcNCg0KPiBDYzogTGluLCBQaW5n IChQaW5nKTsgU3RldmVuIEIuDQoNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gUXVlc3Rpb24gcmUu IHN0YXRlbGVzcyBESENQdjYgYW5kICdNJyAmICdPJyBmbGFncw0KDQo+IA0KDQo+IGRyYWZ0LWll dGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW06DQoNCj4gLSBEb2VzIG5vdCBtZW50aW9uIHVz ZSBvZiBzdGF0ZWxlc3MgREhDUHY2DQoNCj4gLSBEb2VzIG5vdCBtZW50aW9uIHRoYXQgaXMgbm90 IGNsZWFyIGlmIHN0YXRlbGVzcyBESENQdjYgY2xpZW50IHNob3VsZCBzdGFydCBpZg0KDQo+IFNM QUFDIGlzIHVzZWQgYW5kIE09MCBhbmQgTyBjaGFuZ2VzIGZyb20gMCB0byAxLiBPciwgc3RhdGVm dWwgREhDUHY2IGNhbg0KDQo+IHN0YXJ0IGJ1dCBJUHY2IGFkZHJlc3MgY2FuIGJlIGlnbm9yZWQg b3IgT1JPIG9wdGlvbiBkb2VzIG5vdCByZXF1aXJlIHRoZQ0KDQo+IGFkZHJlc3MuDQoNCltCaW5n XSAoU3BlYWsgYXMgYSBjby1hdXRob3IpIFdlIGluZGVlZCBkaWRuJ3QgdGVzdCB0aGUgY2FzZSBh cyB5b3Ugc2FpZCBhYm92ZSwgYnV0IHdlIHRlc3RlZCBhIHNpbWlsYXIgY2FzZTogYXQgaW5pdGlh bCBzdGFnZSwgd2hlbiBBPTAsTT0wLCBhbmQgTz0xLCBzb21lIHBsYXRmb3JtIHdvdWxkIHN0YXJ0 IHN0YXRlbGVzcyBESENQdjYgd2hpbGUgc29tZSBub3QuDQoNCkRldGFpbHMgcGxlYXNlIHJlZmVy IHRvIHRoZSBBcHBlbmRpeCBBLjIgKGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkR2Nm9w cy0yRGRoY3B2Ni0yRHNsYWFjLTJEcHJvYmxlbS0yRDA0LTIzYXBwZW5kaXgtMkRBLjImZD1Bd0lH YVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZ TFpVMjMwMjlzTVFHUTJrWSZtPW04QWpBeEwxNmhQd1g0c3ROTGk0bXhkZkJnN1VoLUtaUWZsNE9t QVBCejAmcz1SWUJYNG9YbjlKYjZEMWYyUzIwdW5WZkluWUIzWFFDeXFCdWNoRklJMS13JmU9ICku DQoNCg0KDQo+IC0gRG9lcyBub3QgbWVudGlvbiBpZiB0aGUgaG9zdCBpcyBTTEFBQyBhbmQgc3Rh dGVmdWwgREhDUHY2IGNvbmZpZ3VyZWQNCg0KPiBzaW11bHRhbmVvdXNseSAoYnVsbGV0IHR3byBk b2VzIG5vdCBzYXkgc3RhdGVmdWwpLCBESENQdjYgYWRkcmVzcyBzaG91bGQNCg0KPiBzdGFydCB3 aXRoIFBJIHByZWZpeA0KDQpbQmluZ10gU29ycnkgSSBkaWRuJ3QgY2F0Y2ggeW91ciBwb2ludC4g V2h5IGlzIHRoZSAiUEkgcHJlZml4IiByZWxhdGVkIHRvIFNMQUFDL0RIQ1B2NiBjb25maWd1cmVk IHNpbXVsdGFuZW91c2x5Pw0KDQpCdHcsIHdoaWNoICJidWxsZXQgdHdvIiBkaWQgeW91IHJlZmVy IHRvPw0KDQoNCg0KDQoNCj4gLSBEb2VzIG5vdCBtZW50aW9uIHRoYXQgJ00nIGFuZCAnTycgZmxh Z3MsIHNob3VsZCBiZSB1c2VkIGFzIGEgbWVjaGFuaXNtIHRvDQoNCj4gZGlzYWJsZSBvbmx5IHN0 YXRlZnVsIElQdjYgYWRkcmVzcyBpZiBTTEFBQyBpcyBlbmFibGVkLiANCg0KW0JpbmddIERpZCB5 b3UgbWVhbiwgd2hlbiBhIGhvc3QgaXMgY29uZmlndXJlZCB3aXRoIFNMQUFDLCB0aGUgREhDUHY2 IGFkZHJlc3MgY29uZmlndXJhdGlvbiBzaG91bGQgYmUgZGlzYWJsZWQ/DQoNCldlIGRpZCBvYnNl cnZlZCBzb21lIGJlaGF2aW9ycyBsaWtlIHRoaXMgaW4gc29tZSBwbGF0Zm9ybTogd2hlbiBhIGhv c3QgaGFzIGNvbmZpZ3VyZWQgU0xBQUMsIGFuZCB0aGVuIE0gY2hhbmdlcyBmcm9tIDAgdG8gMSwg c29tZSBob3N0cyBqdXN0IGlnbm9yZSB0aGUgTSBmbGFnIChzZWUgdGhlIHNlY29uZCBidWxsZXQg b2YgQXBwZW5kaXggQS4zKS4NCg0KDQoNCkhvd2V2ZXIsIHBlcnNvbmFsbHkgSSdtIG5vdCBzdXJl IHRoaXMgc2hvdWxkIGJlIGEgcmlnaHQgYmVoYXZpb3IuIFNMQUFDL0RIQ1B2NiBhZGRyZXNzZXMg Y28tZXhpc3RpbmcgbWlnaHQgbWFrZSBzZW5zZSBpbiBzb21lIHNjZW5hcmlvcy4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9y Z19odG1sX2RyYWZ0LTJEbGl1LTJEdjZvcHMtMkRydW5uaW5nLTJEbXVsdGlwbGUtMkRwcmVmaXhl cy0yRDAzLTIzc2VjdGlvbi0yRDMuMSZkPUF3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEm cj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bThBakF4TDE2 aFB3WDRzdE5MaTRteGRmQmc3VWgtS1pRZmw0T21BUEJ6MCZzPXM1STdJcmtVclN2aTZFdjVtVWh2 cmk5R29MMnBMSTFaMmNXWURURVFPbU0mZT0gIGhhcyBhIGJyaWVmIGRpc2N1c3Npb24gb24gdGhp cy4gQnV0IHRoaXMgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBkb2VzIG5v dCBpbnRlbmQgdG8gZGlzY3VzcyB3aGF0IHRoZSByaWdodCBiZWhhdmlvciBzaG91bGQgYmUuDQoN Cg0KDQo+IFdoYXQgaXMgdGhlIHZhbHVlIG9mDQoNCj4gZGlzYWJsaW5nIG90aGVyIERIQ1B2NiBj b25maWd1cmF0aW9uPyBFbmQgcG9pbnQgaW5zdHJ1bWVudHMgbmVlZCBESENQdjYNCg0KPiBmb3Ig b3RoZXIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBhbmQgdGhhdCBzaGFsbCBub3QgYmUgZGlz YWJsZWQgdmlhIGENCg0KPiByb3V0ZXIgKFVubGVzcyB0aGVyZSBpcyBhIHBsYW4gdG8gcHJvdmlk ZSBhbGwgdGhhdCBjb25maWd1cmF0aW9uIHZpYSBhIHJvdXRlcj8pLg0KDQo+IElmIHRoZXJlIGlz IGFncmVlbWVudCBvbiB0aGlzIHN0YXRlbWVudCwgb25seSBvbmUgZmxhZyBpcyBuZWVkZWQsICdN JyBmbGFnLg0KDQpbQmluZ10gSSBjYW4ndCByZWFsbHkgYW5zd2VyIHRoaXMgcXVlc3Rpb24uIE15 IGd1ZXNzIGlzIHRoYXQgLCB3aGVuIHRoZSBob3N0cyBjYW4gZ2V0IGJvdGggYWRkcmVzcyBhbmQg b3RoZXIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiB0aHJvdWdoIHN0YXRlZnVsIERIQ1B2NiBj b25maWd1cmF0aW9uLCB0aGVuIHRoZSBzdGF0ZWxlc3MgREhDUHY2IGNvbmZpZ3VyYXRpb24gaXMg cmVkdW5kYW50IGlmIGl0IGlzIGFsd2F5cyBvbi4NCg0KDQoNCj4gVGhpcyBmbGFnIHdvdWxkIGNv bnRyb2wgaWYgZW5kIHBvaW50IGluc3RydW1lbnRzIHdvdWxkIGhhdmUgb25seSBTTEFBQyBvcg0K DQo+IG9ubHkgREhDUHY2IGFkZHJlc3MgKGV4YW1wbGU6IE09MSB3b3VsZCBtZWFuIG9ubHkgREhD UHY2IGFkZHJlc3MgaXMNCg0KPiBjb25maWd1cmVkIGFuZCBpZiBBPTEgd291bGQgbWVhbiB0aGF0 IERIQ1B2NiBhZGRyZXNzIHdvdWxkIGhhdmUgdG8gc3RhcnQNCg0KPiB3aXRoIHRoZSBQSSBwcmVm aXgpLiBJIGRvbid0IHNlZSBhIG5lZWQgZm9yIGJvdGggU0xBQUMgYW5kIERIQ1B2NiBhZGRyZXNz ZXMuDQoNCltCaW5nXSBBcyBzYWlkIGFib3ZlLCBJIHRoaW5rIGNvLWV4aXN0aW5nIG1pZ2h0IG1h a2Ugc2Vuc2UgaW4gc29tZSBzY2VuYXJpb3MuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkJpbmcN Cg0KDQoNCg0KDQo+IER1c2FuDQoNCj4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cg0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCg0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTIsIDIwMTUgNDowNSBQTQ0KDQo+IFRv OiBNdWRyaWMsIER1c2FuIChEdXNhbik7IExvcmVuem8gQ29saXR0aTsgU1RBUkssIEJBUkJBUkEg SA0KDQo+IENjOiBMaW4sIFBpbmcgKFBpbmcpOyBTdGV2ZW4gQi47IGlwdjZAaWV0Zi5vcmc7IEJl cm5pZSBWb2x6ICh2b2x6KQ0KDQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiByZS4gc3RhdGVsZXNz IERIQ1B2NiBhbmQgJ00nICYgJ08nIGZsYWdzDQoNCj4gDQoNCj4gSGkgRHVzYW4sDQoNCj4gDQoN Cj4gVGhlIE0vTyBmbGFncyBhcmUgbm90IG9ic29sZXRlLiBUaGV5IGFyZSBkZWZpbmVkIGluIFJG QyA0ODYxLg0KDQo+IA0KDQo+IFlvdSBtaWdodCB3YW50IHRvIHJlYWQNCg0KPiBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3Jn X2h0bWxfDQoNCj4gZHJhZnQtMkRpZXRmLTJEdjZvcHMtMkRkaGNwdjYtMkRzbGFhYy0yRHByb2Js ZW0mZD1Bd0lGYVEmYz1CRnBXUQ0KDQo+IHc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFK eGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrDQoNCj4gWSZtPUFQaEQ1VHE3UTlFWjY0ZURL VGNvb0pYOHZ2UWRUQ2R3R2U3dy0tUWNDMzAmcz1WdkMyblFUb0INCg0KPiA1MXFkaDhKN0pscHct WTNORTNnX0pTdW9vYXkyZkVWdTBzJmU9DQoNCj4gKG5vdGluZyB0aGF0IGl0IGlzIHN0aWxsIGEg ZHJhZnQsIGRpc2N1c3NlZCBpbiB0aGUgdjZvcHMgV0cpIGFuZCB5b3UgbWlnaHQgbW92ZQ0KDQo+ IHRoaXMgZGlzY3Vzc2lvbiB0byB0aGUgdjZvcHMgbGlzdCwgdG9vLg0KDQo+IA0KDQo+IFJlZ2Fy ZHMNCg0KPiAgICBCcmlhbiBDYXJwZW50ZXINCg0KPiANCg0KPiANCg0KPiBPbiAxMy8wNS8yMDE1 IDA2OjUzLCBNdWRyaWMsIER1c2FuIChEdXNhbikgd3JvdGU6DQoNCj4gPiBIaSBFdmVyeW9uZSwN Cg0KPiA+DQoNCj4gPiBJIHdvdWxkIGFwcHJlY2lhdGUgeW91ciBoZWxwIGFuc3dlcmluZyB0aGUg cXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUNCg0KPiBzdGF0ZWxlc3MgREhDUHY2IGFuZCDigJhN4oCZ ICYg4oCYT+KAmSBmbGFnczoNCg0KPiA+DQoNCj4gPiBCYWNrZ3JvdW5kOg0KDQo+ID4gPT09PT09 PT09PT0NCg0KPiA+IEZvbGxvd2luZyBSRkMgMjQ2Miwg4oCcT+KAnSBmbGFnIGluIFJvdXRlciBB ZHZlcnRpc2VtZW50cyBpcyB1c2VkIHRvIHN0YXJ0DQoNCj4gc3RhdGVsZXNzIERIQ1B2NiBjbGll bnQuIFdoZW4gdXNpbmcg4oCYT+KAmSBmbGFnLCB0aGUgZW5kIHBvaW50IHNoYWxsIHN1cHBvcnQ6 DQoNCj4gPg0KDQo+ID4gwrcgICAgICAgICBSRkMNCg0KPiAzNzM2PGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5yZmMtMkRlZGl0b3IuDQoNCj4g b3JnX2luLTJEbm90ZXNfcmZjMzczNi50eHQmZD1Bd0lGYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpI NjRRJnI9DQoNCj4gVVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZt PUFQaEQ1VHE3UTlFWjY0DQoNCj4gZURLVGNvb0pYOHZ2UWRUQ2R3R2U3dy0tUWNDMzAmcz1tWmto QmRoWG9JUkdFc0s2WjNtZldTNFJ5dktCDQoNCj4gLUlpS2hvcnBYQmZud0VZJmU9ID4gLCB0aGF0 IGRlZmluZXMgc3RhdGVsZXNzIERIQ1B2NiBjbGllbnQNCg0KPiA+DQoNCj4gPiDCtyAgICAgICAg IFJGQyA0MjQyLCB0aGF0IGRlZmluZXMgd2hlbiB0aGUgZW5kIHBvaW50IHNob3VsZCByZWZyZXNo IHRoZQ0KDQo+IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uDQoNCj4gPg0KDQo+ID4gUXVlc3Rp b25zOg0KDQo+ID4gPT09PT09PT09DQoNCj4gPiBJZiBSRkMgNDg2MiByZW1vdmVkIOKAmE3igJkg JiDigJhP4oCZIGZsYWdzIGFuZCBvYnNvbGV0ZWQgUkZDIDI0NjIgKHRoYXQNCg0KPiBkZWZpbmVz IOKAmE3igJkgJiDigJhP4oCZIGZsYWdzKSwgd2h5IGFyZSB0aGUgZmxhZ3Mgbm90IGRlcHJlY2F0 ZWQ/IFdoYXQgaXMgdGhlDQoNCj4gdmFsdWUgb2YgcmVmZXJyaW5nIHRvIHRoZSBvYnNvbGV0ZWQg c3RhbmRhcmQsIGluIG9yZGVyIHRvIHN1cHBvcnQgZmxhZ3MgaW4gdGhlDQoNCj4gc29sdXRpb24g dGhhdCBpcyBub3QgbWF0dXJlPw0KDQo+ID4NCg0KPiA+IHJmYzQ4NjIjYXBwZW5kaXgtQw0KDQo+ ID4gICAgbyAgUmVtb3ZlZCB0aGUgdGV4dCByZWdhcmRpbmcgdGhlIE0gYW5kIE8gZmxhZ3MsIGNv bnNpZGVyaW5nIHRoZQ0KDQo+ID4gICAgICAgbWF0dXJpdHkgb2YgaW1wbGVtZW50YXRpb25zIGFu ZCBvcGVyYXRpb25hbCBleHBlcmllbmNlcy4NCg0KPiA+ICAgICAgIE1hbmFnZWRGbGFnIGFuZCBP dGhlckNvbmZpZ0ZsYWcgd2VyZSByZW1vdmVkIGFjY29yZGluZ2x5Lg0KDQo+IChOb3RlDQoNCj4g PiAgICAgICB0aGF0IHRoaXMgY2hhbmdlIGRvZXMgbm90IG1lYW4gdGhlIHVzZSBvZiB0aGVzZSBm bGFncyBpcw0KDQo+ID4gICAgICAgZGVwcmVjYXRlZC4pDQoNCj4gPg0KDQo+ID4gSW4gdGhlIHRo cmVhZCDigJxSZTogUXVlc3Rpb24gcmUuIFJFQ09ORklHIGluIERIQ1B2NuKAnSwgQmVybmllIHN0 YXRlZDoNCg0KPiA+IOKAnFRoZSBSRkMgMzczNiBkb2N1bWVudCBpcyByZWFsbHkgbm90IHNvbWV0 aGluZyBJIHdvdWxkIHJlY29tbWVuZA0KDQo+IGZvbGxvd2luZyAtIHNlZSBmdWxsIFJGQyAzMzE1 IGFuZCBpbXBsZW1lbnQgdGhvc2UgZmVhdHVyZXMgeW91IG5lZWQgKHN1Y2gNCg0KPiBhcyBvbmx5 IEluZm9ybWF0aW9uLVJlcXVlc3QgYW5kIFJlcGx5KS4gMzczNiB3YXMgd3JpdHRlbiB0byBkZW1v bnN0cmF0ZQ0KDQo+IHRoYXQgc3RhdGVsZXNzIGRoY3B2NiB3YXMgcmF0aGVyIHNpbXBsZSB0byBp bXBsZW1lbnQu4oCdDQoNCj4gPg0KDQo+ID4gQmFzZWQgb24gdGhlIGZhY3QgdGhhdCDigJhN4oCZ ICYg4oCYT+KAmSBmbGFncyBhcmUgcmVtb3ZlZCBmcm9tIHRoZSBSRkMgNDg2Mg0KDQo+IGFuZCB0 aGUgc3RhdGVtZW50IGFib3ZlLCBjYW4gd2Ugc2F5IHRoZSBzdGF0ZWxlc3MgREhDUHY2IGlzIG5v dCBtYW5kYXRvcnkNCg0KPiBhbmQsIGNvbnNlcXVlbnRseSwg4oCYT+KAmSBmbGFnIGlzIG5vdCBy ZXF1aXJlZD8NCg0KPiA+DQoNCj4gPiBJZiBzdGF0ZWxlc3MgREhDUHY2IGlzIG5vdCB1c2VkLCBz dGF0ZWZ1bCBESENQdjYgaXMgcmVxdWlyZWQuIFRoZW4sIOKAmE3igJkNCg0KPiBmbGFnIGlzIG5v dCBuZWVkZWQuDQoNCj4gPg0KDQo+ID4gUmVnYXJkcywNCg0KPiA+IER1c2FuIE11ZHJpYy4NCg0K PiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCg0KPiA+IGlwdjZAaWV0Zi5vcmcNCg0KPiA+IEFkbWlu aXN0cmF0aXZlIFJlcXVlc3RzOg0KDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KDQo+ID4NCg0KPiBtYW5f bGlzdGluZm9faXB2NiZkPUF3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazlj YkwNCg0KPiBlYUp4aGYzDQoNCj4gPg0KDQo+IGlDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZt PUFQaEQ1VHE3UTlFWjY0ZURLVGNvb0pYOHZ2UWRUDQoNCj4gQ2R3R2U3dy0tUWMNCg0KPiA+IEMz MCZzPTRoUXdCazRNdlBTV0ZoN0xieWo5cExZYTRvYmJiRE9fMTdFWUxjRktoM1UmZT0NCg0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCj4gPg0KDQo+IA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCj4gdjZvcHMgbWFpbGluZyBsaXN0DQoNCj4gdjZvcHNA aWV0Zi5vcmcNCg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9QXdJR2FRJmM9 QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIz MDI5c01RR1Eya1kmbT1tOEFqQXhMMTZoUHdYNHN0TkxpNG14ZGZCZzdVaC1LWlFmbDRPbUFQQnow JnM9UWFmRjR6UWk2V0NSVjFUMV9LS0w4X05ieWlvS2g3TUU5TFRyRUVxcWlYcyZlPSANCg0K From nobody Thu May 14 07:51:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083461A001A for ; Thu, 14 May 2015 07:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arhpxXCmQYLP for ; Thu, 14 May 2015 07:51:38 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF0D1A0091 for ; Thu, 14 May 2015 07:51:04 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 4015C74FA2 for ; Thu, 14 May 2015 16:51:02 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 02237AEA for ; Thu, 14 May 2015 16:51:02 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id CDE47C45F4; Thu, 14 May 2015 16:51:01 +0200 (CEST) Date: Thu, 14 May 2015 16:51:01 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150514145101.GB45151@ernw.de> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:51:42 -0000 All, pls allow to make you aware that we did some similar tests as those laid out in draft-ietf-v6ops-dhcpv6-slaac-problem (btw: very nice work!). Details & results can be found in: https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf. We gave a presentation on this today in the IPv6 WG at RIPE70, with some additionals comments: https://ripe70.ripe.net/presentations/132-ERNW_RIPE70_IPv6_Behavior_Conflicting_Environments_v0_92_short.pdf Overall we observed the same unfortunate ambiguities and differing vendor interpretations/strategies. thanks Enno On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote: > Hi Bing, > > The draft-ietf-v6ops-dhcpv6-slaac-problem nicely captures ambiguities and different interpretations around 'M', 'O' and 'A' flags. It also opens a floor for further discussion around: > - the need for stateless DHCPv6, > - simultaneous SLAAC and DHCPv6 address assignments, and > - ND and DHCPv6 interworking: e.g. the role of ND on-link address prefix for DHCPv6 addresses. > > Only when the needs are systematically captured, it will be possible to define the flags. > > [Bing] (Speak as a co-author) We indeed didn't test the case as you said above, but we tested a similar case: at initial stage, when A=0,M=0, and O=1, some platform would start stateless DHCPv6 while some not. > [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 without the address option in ORO, or stateful DHCPv6 and ignored the address in REPLY? > > > - Does not mention if the host is SLAAC and stateful DHCPv6 configured > > simultaneously (bullet two does not say stateful), DHCPv6 address should > > start with PI prefix > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to SLAAC/DHCPv6 configured simultaneously? > Btw, which "bullet two" did you refer to? > [Dusan] It is important that DHCPv6 address starts with on-link prefix. Otherwise the end point will be unreachable. When SLAAC/DHCPv6 are configured to run simultaneously, if M=1 is interpreted to mean run stateful DHCPv6 and obtain IPv6 address via DHCPv6 client, PI option should have L bit set to allow the end point to verify the acquired DHCPv6 address in on-link. This behavior should be standardized. > > [Bing] Btw, which "bullet two" did you refer to? > [Dusan] Section 3 - 2). > > > - Does not mention that 'M' and 'O' flags, should be used as a mechanism to > > disable only stateful IPv6 address if SLAAC is enabled. > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 address configuration should be disabled? > [Dusan] Yes, only the address part should be disabled. But other configuration information should be still available via DHCPv6. > > [Bing] However, personally I'm not sure this should be a right behavior. SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. > [Dusan] draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 only talks about the prefix delivering mechanism to routers using DHCPv6. It does not recommend the co-existing SLAAC/DHCPv6 behavior for hosts. If there is a need for multiple IPv6 addresses per interface, as mentioned in the draft, SLAAC already allows the use of multiple prefixes and DHCPv6 already allows the assignment of multiple IPv6 addresses. There is really no need for adding further complexity by mixing the two: SLAAC IPv6 addresses and DHCPv6 IPv6 addresses. > > > What is the value of > > disabling other DHCPv6 configuration? End point instruments need DHCPv6 > > for other configuration information and that shall not be disabled via a > > router (Unless there is a plan to provide all that configuration via a router?). > > If there is agreement on this statement, only one flag is needed, 'M' flag. > [Bing] I can't really answer this question. My guess is that , when the hosts can get both address and other configuration information through stateful DHCPv6 configuration, then the stateless DHCPv6 configuration is redundant if it is always on. > [Dusan] Stateless DHCPv6 is redundant by its nature. Stateful DHCPv6 can send SOLICIT and REQUEST messages with ORO option that does not require the address (e.g. without OPTION_IA_NA option code). If there is no stateless DHCPv6 client to control, there is no need for 'O' flag. The remaining 'M' flag can be used to control if ORO option has OPTION_IA_NA option code. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: Wednesday, May 13, 2015 11:10 PM > To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; v6ops@ietf.org > Cc: Lin, Ping (Ping); Steven B. > Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags > > Hi Dusan and all, > > > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mudric, Dusan > > > (Dusan) > > > Sent: Thursday, May 14, 2015 4:46 AM > > > To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; v6ops@ietf.org > > > Cc: Lin, Ping (Ping); Steven B. > > > Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags > > > > > > draft-ietf-v6ops-dhcpv6-slaac-problem: > > > - Does not mention use of stateless DHCPv6 > > > - Does not mention that is not clear if stateless DHCPv6 client should start if > > > SLAAC is used and M=0 and O changes from 0 to 1. Or, stateful DHCPv6 can > > > start but IPv6 address can be ignored or ORO option does not require the > > > address. > > [Bing] (Speak as a co-author) We indeed didn't test the case as you said above, but we tested a similar case: at initial stage, when A=0,M=0, and O=1, some platform would start stateless DHCPv6 while some not. > > Details please refer to the Appendix A.2 (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem-2D04-23appendix-2DA.2&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&s=RYBX4oXn9Jb6D1f2S20unVfInYB3XQCyqBuchFII1-w&e= ). > > > > > - Does not mention if the host is SLAAC and stateful DHCPv6 configured > > > simultaneously (bullet two does not say stateful), DHCPv6 address should > > > start with PI prefix > > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to SLAAC/DHCPv6 configured simultaneously? > > Btw, which "bullet two" did you refer to? > > > > > > > - Does not mention that 'M' and 'O' flags, should be used as a mechanism to > > > disable only stateful IPv6 address if SLAAC is enabled. > > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 address configuration should be disabled? > > We did observed some behaviors like this in some platform: when a host has configured SLAAC, and then M changes from 0 to 1, some hosts just ignore the M flag (see the second bullet of Appendix A.3). > > > > However, personally I'm not sure this should be a right behavior. SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dliu-2Dv6ops-2Drunning-2Dmultiple-2Dprefixes-2D03-23section-2D3.1&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&s=s5I7IrkUrSvi6Ev5mUhvri9GoL2pLI1Z2cWYDTEQOmM&e= has a brief discussion on this. But this draft-ietf-v6ops-dhcpv6-slaac-problem does not intend to discuss what the right behavior should be. > > > > > What is the value of > > > disabling other DHCPv6 configuration? End point instruments need DHCPv6 > > > for other configuration information and that shall not be disabled via a > > > router (Unless there is a plan to provide all that configuration via a router?). > > > If there is agreement on this statement, only one flag is needed, 'M' flag. > > [Bing] I can't really answer this question. My guess is that , when the hosts can get both address and other configuration information through stateful DHCPv6 configuration, then the stateless DHCPv6 configuration is redundant if it is always on. > > > > > This flag would control if end point instruments would have only SLAAC or > > > only DHCPv6 address (example: M=1 would mean only DHCPv6 address is > > > configured and if A=1 would mean that DHCPv6 address would have to start > > > with the PI prefix). I don't see a need for both SLAAC and DHCPv6 addresses. > > [Bing] As said above, I think co-existing might make sense in some scenarios. > > > > Best regards, > > Bing > > > > > > > Dusan > > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > Sent: Tuesday, May 12, 2015 4:05 PM > > > To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H > > > Cc: Lin, Ping (Ping); Steven B.; ipv6@ietf.org; Bernie Volz (volz) > > > Subject: Re: Question re. stateless DHCPv6 and 'M' & 'O' flags > > > > > > Hi Dusan, > > > > > > The M/O flags are not obsolete. They are defined in RFC 4861. > > > > > > You might want to read > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_ > > > draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem&d=AwIFaQ&c=BFpWQ > > > w8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k > > > Y&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=VvC2nQToB > > > 51qdh8J7Jlpw-Y3NE3g_JSuooay2fEVu0s&e= > > > (noting that it is still a draft, discussed in the v6ops WG) and you might move > > > this discussion to the v6ops list, too. > > > > > > Regards > > > Brian Carpenter > > > > > > > > > On 13/05/2015 06:53, Mudric, Dusan (Dusan) wrote: > > > > Hi Everyone, > > > > > > > > I would appreciate your help answering the questions regarding the > > > stateless DHCPv6 and ???M??? & ???O??? flags: > > > > > > > > Background: > > > > =========== > > > > Following RFC 2462, ???O??? flag in Router Advertisements is used to start > > > stateless DHCPv6 client. When using ???O??? flag, the end point shall support: > > > > > > > > ?? RFC > > > 3736 > > org_in-2Dnotes_rfc3736.txt&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r= > > > UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64 > > > eDKTcooJX8vvQdTCdwGe7w--QcC30&s=mZkhBdhXoIRGEsK6Z3mfWS4RyvKB > > > -IiKhorpXBfnwEY&e= > , that defines stateless DHCPv6 client > > > > > > > > ?? RFC 4242, that defines when the end point should refresh the > > > configuration information. > > > > > > > > Questions: > > > > ========= > > > > If RFC 4862 removed ???M??? & ???O??? flags and obsoleted RFC 2462 (that > > > defines ???M??? & ???O??? flags), why are the flags not deprecated? What is the > > > value of referring to the obsoleted standard, in order to support flags in the > > > solution that is not mature? > > > > > > > > rfc4862#appendix-C > > > > o Removed the text regarding the M and O flags, considering the > > > > maturity of implementations and operational experiences. > > > > ManagedFlag and OtherConfigFlag were removed accordingly. > > > (Note > > > > that this change does not mean the use of these flags is > > > > deprecated.) > > > > > > > > In the thread ???Re: Question re. RECONFIG in DHCPv6???, Bernie stated: > > > > ???The RFC 3736 document is really not something I would recommend > > > following - see full RFC 3315 and implement those features you need (such > > > as only Information-Request and Reply). 3736 was written to demonstrate > > > that stateless dhcpv6 was rather simple to implement.??? > > > > > > > > Based on the fact that ???M??? & ???O??? flags are removed from the RFC 4862 > > > and the statement above, can we say the stateless DHCPv6 is not mandatory > > > and, consequently, ???O??? flag is not required? > > > > > > > > If stateless DHCPv6 is not used, stateful DHCPv6 is required. Then, ???M??? > > > flag is not needed. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > > > > > > man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL > > > eaJxhf3 > > > > > > > iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdT > > > CdwGe7w--Qc > > > > C30&s=4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e= > > > > -------------------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e= > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu May 14 09:29:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B6B1A885A for ; Thu, 14 May 2015 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPynmIL3vXgw for ; Thu, 14 May 2015 09:29:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341161A87C4 for ; Thu, 14 May 2015 09:29:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAO7LVFXGmAcV/2dsb2JhbABcgmYpVF4GxkmFdgKBQUwBAQEBAQGBC4QiAQEBAQMSKA8fBgYRBAIBCA0BAwQBAQEKFAkHIREUCQgCBAESCBMHh3UDEgEMpVuqAA2EcQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoJNgWYBAR84BoMRgRYFhmOJMBOCOoQoggpAgioBgnw+gyaCcQtlhxeDH4NXI4FmIxyBUm8BAYEKOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,429,1427774400"; d="scan'208";a="102676741" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2015 12:29:28 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 14 May 2015 12:29:28 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Thu, 14 May 2015 12:29:27 -0400 From: "Mudric, Dusan (Dusan)" To: Enno Rey , "v6ops@ietf.org" Thread-Topic: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AQHQjO7u5SBG9u46QEK4wNDSgsbkgJ17kSnjgAAaFCA= Date: Thu, 14 May 2015 16:29:26 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8011E3@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> <20150514145101.GB45151@ernw.de> In-Reply-To: <20150514145101.GB45151@ernw.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:29:36 -0000 Regarding 'M' and 'O' flags (and possibly other flags: A, L, ...), we need = first to answer: - if there is a need to administratively enable/disable DHCPv6 and SLAAC, - if there is a need for stateless DHCPv6, - if there is a need for simultaneous SLAAC and DHCPv6 address assignments,= and - if there is a need for ND and DHCPv6 interworking: e.g. the role of ND on= -link address prefix for DHCPv6 addresses, MTU and DNS configuration, ... Dusan Mudric. -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Enno Rey Sent: Thursday, May 14, 2015 10:51 AM To: v6ops@ietf.org Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags All, pls allow to make you aware that we did some similar tests as those laid ou= t in draft-ietf-v6ops-dhcpv6-slaac-problem (btw: very nice work!). Details = & results can be found in: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ernw.de_download= _ERNW-5FWhitepaper-5FIPv6-5FRAs-5FRDNSS-5FDHCPv6-5FConflicting-5FParameters= .pdf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YL= ZU23029sMQGQ2kY&m=3DSFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGazMF2c&s=3DS0TH39V= -uf4_dlD9pSQUQ5DVzIQMNk3Om1XWJmf_DZQ&e=3D . We gave a presentation on this today in the IPv6 WG at RIPE70, with some ad= ditionals comments: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ripe70.ripe.net_pres= entations_132-2DERNW-5FRIPE70-5FIPv6-5FBehavior-5FConflicting-5FEnvironment= s-5Fv0-5F92-5Fshort.pdf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL= eaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DSFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0Z= GazMF2c&s=3DAzY7qkWVsXBI5gcqrq5yLCxte8EVuqZnMFRjIvm_keY&e=3D=20 Overall we observed the same unfortunate ambiguities and differing vendor i= nterpretations/strategies. thanks Enno On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote: > Hi Bing, >=20 > The draft-ietf-v6ops-dhcpv6-slaac-problem nicely captures ambiguities and= different interpretations around 'M', 'O' and 'A' flags. It also opens a f= loor for further discussion around: > - the need for stateless DHCPv6, > - simultaneous SLAAC and DHCPv6 address assignments, and > - ND and DHCPv6 interworking: e.g. the role of ND on-link address prefix = for DHCPv6 addresses. >=20 > Only when the needs are systematically captured, it will be possible to d= efine the flags. >=20 > [Bing] (Speak as a co-author) We indeed didn't test the case as you said = above, but we tested a similar case: at initial stage, when A=3D0,M=3D0, an= d O=3D1, some platform would start stateless DHCPv6 while some not. > [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 without th= e address option in ORO, or stateful DHCPv6 and ignored the address in REPL= Y? >=20 > > - Does not mention if the host is SLAAC and stateful DHCPv6=20 > > configured simultaneously (bullet two does not say stateful), DHCPv6=20 > > address should start with PI prefix > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to= SLAAC/DHCPv6 configured simultaneously?=20 > Btw, which "bullet two" did you refer to? > [Dusan] It is important that DHCPv6 address starts with on-link prefix. O= therwise the end point will be unreachable. When SLAAC/DHCPv6 are configure= d to run simultaneously, if M=3D1 is interpreted to mean run stateful DHCPv= 6 and obtain IPv6 address via DHCPv6 client, PI option should have L bit se= t to allow the end point to verify the acquired DHCPv6 address in on-link. = This behavior should be standardized. >=20 > [Bing] Btw, which "bullet two" did you refer to? > [Dusan] Section 3 - 2). >=20 > > - Does not mention that 'M' and 'O' flags, should be used as a=20 > > mechanism to disable only stateful IPv6 address if SLAAC is enabled. > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 add= ress configuration should be disabled? > [Dusan] Yes, only the address part should be disabled. But other configur= ation information should be still available via DHCPv6. >=20 > [Bing] However, personally I'm not sure this should be a right behavior. = SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. > [Dusan] draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 only tal= ks about the prefix delivering mechanism to routers using DHCPv6. It does n= ot recommend the co-existing SLAAC/DHCPv6 behavior for hosts. If there is a= need for multiple IPv6 addresses per interface, as mentioned in the draft,= SLAAC already allows the use of multiple prefixes and DHCPv6 already allow= s the assignment of multiple IPv6 addresses. There is really no need for ad= ding further complexity by mixing the two: SLAAC IPv6 addresses and DHCPv6 = IPv6 addresses. >=20 > > What is the value of > > disabling other DHCPv6 configuration? End point instruments need=20 > > DHCPv6 for other configuration information and that shall not be=20 > > disabled via a router (Unless there is a plan to provide all that confi= guration via a router?). > > If there is agreement on this statement, only one flag is needed, 'M' f= lag. > [Bing] I can't really answer this question. My guess is that , when the h= osts can get both address and other configuration information through state= ful DHCPv6 configuration, then the stateless DHCPv6 configuration is redund= ant if it is always on. > [Dusan] Stateless DHCPv6 is redundant by its nature. Stateful DHCPv6 can = send SOLICIT and REQUEST messages with ORO option that does not require the= address (e.g. without OPTION_IA_NA option code). If there is no stateless = DHCPv6 client to control, there is no need for 'O' flag. The remaining 'M' = flag can be used to control if ORO option has OPTION_IA_NA option code. >=20 > Regards, > Dusan Mudric. >=20 > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: Wednesday, May 13, 2015 11:10 PM > To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK,=20 > BARBARA H; v6ops@ietf.org > Cc: Lin, Ping (Ping); Steven B. > Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags >=20 > Hi Dusan and all, >=20 >=20 >=20 > > -----Original Message----- >=20 > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mudric,=20 > > Dusan >=20 > > (Dusan) >=20 > > Sent: Thursday, May 14, 2015 4:46 AM >=20 > > To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H;=20 > > v6ops@ietf.org >=20 > > Cc: Lin, Ping (Ping); Steven B. >=20 > > Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O'=20 > > flags >=20 > >=20 >=20 > > draft-ietf-v6ops-dhcpv6-slaac-problem: >=20 > > - Does not mention use of stateless DHCPv6 >=20 > > - Does not mention that is not clear if stateless DHCPv6 client=20 > > should start if >=20 > > SLAAC is used and M=3D0 and O changes from 0 to 1. Or, stateful DHCPv6= =20 > > can >=20 > > start but IPv6 address can be ignored or ORO option does not require=20 > > the >=20 > > address. >=20 > [Bing] (Speak as a co-author) We indeed didn't test the case as you said = above, but we tested a similar case: at initial stage, when A=3D0,M=3D0, an= d O=3D1, some platform would start stateless DHCPv6 while some not. >=20 > Details please refer to the Appendix A.2 (https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Ddhcpv6-2= Dslaac-2Dproblem-2D04-23appendix-2DA.2&d=3DAwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64= Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dm8AjAxL16hPwX4stNLi4m= xdfBg7Uh-KZQfl4OmAPBz0&s=3DRYBX4oXn9Jb6D1f2S20unVfInYB3XQCyqBuchFII1-w&e=3D= ). >=20 >=20 >=20 > > - Does not mention if the host is SLAAC and stateful DHCPv6=20 > > configured >=20 > > simultaneously (bullet two does not say stateful), DHCPv6 address=20 > > should >=20 > > start with PI prefix >=20 > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to= SLAAC/DHCPv6 configured simultaneously? >=20 > Btw, which "bullet two" did you refer to? >=20 >=20 >=20 >=20 >=20 > > - Does not mention that 'M' and 'O' flags, should be used as a=20 > > mechanism to >=20 > > disable only stateful IPv6 address if SLAAC is enabled.=20 >=20 > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 add= ress configuration should be disabled? >=20 > We did observed some behaviors like this in some platform: when a host ha= s configured SLAAC, and then M changes from 0 to 1, some hosts just ignore = the M flag (see the second bullet of Appendix A.3). >=20 >=20 >=20 > However, personally I'm not sure this should be a right behavior. SLAAC/D= HCPv6 addresses co-existing might make sense in some scenarios. https://url= defense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dliu= -2Dv6ops-2Drunning-2Dmultiple-2Dprefixes-2D03-23section-2D3.1&d=3DAwIGaQ&c= =3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m= =3Dm8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4OmAPBz0&s=3Ds5I7IrkUrSvi6Ev5mUhvri9G= oL2pLI1Z2cWYDTEQOmM&e=3D has a brief discussion on this. But this draft-ie= tf-v6ops-dhcpv6-slaac-problem does not intend to discuss what the right beh= avior should be. >=20 >=20 >=20 > > What is the value of >=20 > > disabling other DHCPv6 configuration? End point instruments need=20 > > DHCPv6 >=20 > > for other configuration information and that shall not be disabled=20 > > via a >=20 > > router (Unless there is a plan to provide all that configuration via a = router?). >=20 > > If there is agreement on this statement, only one flag is needed, 'M' f= lag. >=20 > [Bing] I can't really answer this question. My guess is that , when the h= osts can get both address and other configuration information through state= ful DHCPv6 configuration, then the stateless DHCPv6 configuration is redund= ant if it is always on. >=20 >=20 >=20 > > This flag would control if end point instruments would have only=20 > > SLAAC or >=20 > > only DHCPv6 address (example: M=3D1 would mean only DHCPv6 address is >=20 > > configured and if A=3D1 would mean that DHCPv6 address would have to=20 > > start >=20 > > with the PI prefix). I don't see a need for both SLAAC and DHCPv6 addre= sses. >=20 > [Bing] As said above, I think co-existing might make sense in some scenar= ios. >=20 >=20 >=20 > Best regards, >=20 > Bing >=20 >=20 >=20 >=20 >=20 > > Dusan >=20 > >=20 >=20 > > -----Original Message----- >=20 > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >=20 > > Sent: Tuesday, May 12, 2015 4:05 PM >=20 > > To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H >=20 > > Cc: Lin, Ping (Ping); Steven B.; ipv6@ietf.org; Bernie Volz (volz) >=20 > > Subject: Re: Question re. stateless DHCPv6 and 'M' & 'O' flags >=20 > >=20 >=20 > > Hi Dusan, >=20 > >=20 >=20 > > The M/O flags are not obsolete. They are defined in RFC 4861. >=20 > >=20 >=20 > > You might want to read >=20 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ > > html_ >=20 > > draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem&d=3DAwIFaQ&c=3DBFpWQ >=20 > > w8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k >=20 > > Y&m=3DAPhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=3DVvC2nQToB >=20 > > 51qdh8J7Jlpw-Y3NE3g_JSuooay2fEVu0s&e=3D >=20 > > (noting that it is still a draft, discussed in the v6ops WG) and you=20 > > might move >=20 > > this discussion to the v6ops list, too. >=20 > >=20 >=20 > > Regards >=20 > > Brian Carpenter >=20 > >=20 >=20 > >=20 >=20 > > On 13/05/2015 06:53, Mudric, Dusan (Dusan) wrote: >=20 > > > Hi Everyone, >=20 > > > >=20 > > > I would appreciate your help answering the questions regarding the >=20 > > stateless DHCPv6 and ???M??? & ???O??? flags: >=20 > > > >=20 > > > Background: >=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > > > Following RFC 2462, ???O??? flag in Router Advertisements is used=20 > > > to start >=20 > > stateless DHCPv6 client. When using ???O??? flag, the end point shall s= upport: >=20 > > > >=20 > > > ?? RFC >=20 > > 3736 > itor .>=20 > > org_in-2Dnotes_rfc3736.txt&d=3DAwIFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3D >=20 > > UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DAPhD5Tq7Q9EZ64 >=20 > > eDKTcooJX8vvQdTCdwGe7w--QcC30&s=3DmZkhBdhXoIRGEsK6Z3mfWS4RyvKB >=20 > > -IiKhorpXBfnwEY&e=3D > , that defines stateless DHCPv6 client >=20 > > > >=20 > > > ?? RFC 4242, that defines when the end point should refresh t= he >=20 > > configuration information. >=20 > > > >=20 > > > Questions: >=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > > > If RFC 4862 removed ???M??? & ???O??? flags and obsoleted RFC 2462=20 > > > (that >=20 > > defines ???M??? & ???O??? flags), why are the flags not deprecated?=20 > > What is the >=20 > > value of referring to the obsoleted standard, in order to support=20 > > flags in the >=20 > > solution that is not mature? >=20 > > > >=20 > > > rfc4862#appendix-C >=20 > > > o Removed the text regarding the M and O flags, considering=20 > > > the >=20 > > > maturity of implementations and operational experiences. >=20 > > > ManagedFlag and OtherConfigFlag were removed accordingly. >=20 > > (Note >=20 > > > that this change does not mean the use of these flags is >=20 > > > deprecated.) >=20 > > > >=20 > > > In the thread ???Re: Question re. RECONFIG in DHCPv6???, Bernie state= d: >=20 > > > ???The RFC 3736 document is really not something I would recommend >=20 > > following - see full RFC 3315 and implement those features you need=20 > > (such >=20 > > as only Information-Request and Reply). 3736 was written to=20 > > demonstrate >=20 > > that stateless dhcpv6 was rather simple to implement.??? >=20 > > > >=20 > > > Based on the fact that ???M??? & ???O??? flags are removed from=20 > > > the RFC 4862 >=20 > > and the statement above, can we say the stateless DHCPv6 is not=20 > > mandatory >=20 > > and, consequently, ???O??? flag is not required? >=20 > > > >=20 > > > If stateless DHCPv6 is not used, stateful DHCPv6 is required. Then, ?= ??M??? >=20 > > flag is not needed. >=20 > > > >=20 > > > Regards, >=20 > > > Dusan Mudric. >=20 > > > >=20 > > > >=20 > > > >=20 > > > ------------------------------------------------------------------ > > > -- >=20 > > > IETF IPv6 working group mailing list >=20 > > > ipv6@ietf.org >=20 > > > Administrative Requests: >=20 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ > > > mail >=20 > > > >=20 > > man_listinfo_ipv6&d=3DAwIFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL >=20 > > eaJxhf3 >=20 > > > >=20 > > iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DAPhD5Tq7Q9EZ64eDKTcooJX8vvQdT >=20 > > CdwGe7w--Qc >=20 > > > C30&s=3D4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=3D >=20 > > > ------------------------------------------------------------------ > > > -- >=20 > > > >=20 > >=20 >=20 > > _______________________________________________ >=20 > > v6ops mailing list >=20 > > v6ops@ietf.org >=20 > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma > > ilman_listinfo_v6ops&d=3DAwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cb= Lea > > Jxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dm8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQ > > fl4OmAPBz0&s=3DQafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_v6ops&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJ= xhf > 3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DSFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGaz > MF2c&s=3DZPjsWnHR8KdgkzP0GOQBecbMqehiw424gpmxD0ya1p8&e=3D -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 622= 1 480390 - Fax 6221 419008 - Cell +49 173 6745902=20 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D _______________________________________________ v6ops mailing list v6ops@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_v6ops&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DSFnCFRD68rGH3IZpXBNaku5TK9XnWGEJrz0ZGazMF2c&= s=3DZPjsWnHR8KdgkzP0GOQBecbMqehiw424gpmxD0ya1p8&e=3D=20 From nobody Thu May 14 09:54:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584821A8A25 for ; Thu, 14 May 2015 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8YrueTtQuf1 for ; Thu, 14 May 2015 09:54:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754921AC42A for ; Thu, 14 May 2015 09:53:15 -0700 (PDT) Authentication-Results: opteamax.de; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 14 May 2015 16:29:56 +0000 Message-ID: <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> From: t.petch To: Jens Ott - Opteamax GmbH , References: <55545683.6070202@opteamax.de> Date: Thu, 14 May 2015 17:27:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: [81.151.162.168] X-ClientProxiedBy: DB5PR08CA0042.eurprd08.prod.outlook.com (25.163.102.180) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMXPR07MB055; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB055; X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(252514010)(13464003)(51704005)(377454003)(51444003)(77096005)(84392001)(107886002)(5001960100002)(14496001)(561944003)(46102003)(66066001)(81816999)(50986999)(81686999)(76176999)(42186005)(61296003)(189998001)(47776003)(5001770100001)(122386002)(92566002)(50226001)(50466002)(62966003)(33646002)(77156002)(40100003)(19580395003)(23676002)(87976001)(86362001)(44716002)(62236002)(5820100001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2015 16:29:56.9917 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:54:38 -0000 Jens I think that there might be a slight procedural issue. The original RFC was produced by the IPv6 Working Group which is responsible for protocol changes. This is the v6ops Working Group which is not allowed to make protocol changes (but is concerned with making the protocol usable). It may not be clearcut, but I would see this as a protocol change and so one that should be discussed and progressed in the IPv6 WG rather than here. The WG Chairs will doubtless arbitrate on this. Otherwise, yes but don't stop at /29; I would go for a /8 and allow myself to be negotiated back to something in between. . Tom Petch ----- Original Message ----- From: "Jens Ott - Opteamax GmbH" To: Sent: Thursday, May 14, 2015 9:02 AM Subject: [v6ops] Idea about updating RFC3849 > > Hi Mailinglist-Members, > > I am pretty new on this list, so I first wave a "Hello" into the > round... and immediately continue to ask the question, which led me to > subscribing to this list. Apologies if I chose the wrong list, please > advise me, where to put my question in this case. > > I work as consultant and already accompanied several IPv6 roll-outs > from the first idea "we want V6" until production. While > enterprise-setups are mostly /32 or less IPs, I see more and more > rollouts which need much bigger space. > > At least in RIPE-Region, each LIR can receive a /29 without any > justification. And here is where my problem starts. While writing > documentation and addressing-plans before requesting the actual prefix > at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in > RFC3849. But what to do for bigger nets (lower bitmasks)? > > Before starting to push the ball on the field by writing a proposal, > I'd be happy to hear if there is support in the community for updating > this rfc and officially define a bigger prefix for documentation. > > As said, if I chose the wrong mailinglist or simply started bringing > my idea into the community in a wrong way, any advise and comment is > appreciated. I have no experience with the processes at ietf yet. > > Best regards and thanks > - -- > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: +49 2224 969500 > Fax: +49 2224 97691059 > Email: jo@opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Geschäftsführer: Jens Ott > Umsatzsteuer-ID.: DE264133989 From nobody Thu May 14 10:36:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ACB1B2B80 for ; Thu, 14 May 2015 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_37=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPQUNQK3nYJD for ; Thu, 14 May 2015 10:36:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA201B2B9F for ; Thu, 14 May 2015 10:36:07 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:484:396b:f794:75d0]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t4EHa2Sl007332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2015 17:36:02 GMT (envelope-from joelja@bogus.com) To: "t.petch" , Jens Ott - Opteamax GmbH , v6ops@ietf.org references: <55545683.6070202@opteamax.de> <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> From: joel jaeggli x-enigmail-draft-status: N1110 message-id: <5554DD01.5040708@bogus.com> Date: Thu, 14 May 2015 10:36:01 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mu15a6LjgXi68lKEDc2ulgtJgdOApW3o3" Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 17:36:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mu15a6LjgXi68lKEDc2ulgtJgdOApW3o3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm pretty sure that growing the example prefix isn't necessary in order to that you might use a prefix with a longer or shorter netmask in a filter. I wouldn't want to expand it to a /3 just so that I could express the size of the ipv6unicast address range. We don't get into existential peril when we refer to ::/0 so if you have to say, "design the filter this way example my address space 2001:db8::/32 substituting your prefix and and appropriate length netmask (shorter or longer as necessary) that doesn't seem excessively circuitous. and if they slavishly copy that prefix or netmask well no harm no foul. On 5/14/15 9:27 AM, t.petch wrote: > Jens >=20 > I think that there might be a slight procedural issue. The original RF= C > was produced by the IPv6 Working Group which is responsible for protoco= l > changes. This is the v6ops Working Group which is not allowed to make > protocol changes (but is concerned with making the protocol usable). >=20 > It may not be clearcut, but I would see this as a protocol change and s= o > one that should be discussed and progressed in the IPv6 WG rather than > here. The WG Chairs will doubtless arbitrate on this. >=20 > Otherwise, yes but don't stop at /29; I would go for a /8 and allow > myself to be negotiated back to something in between. > . > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Jens Ott - Opteamax GmbH" > To: > Sent: Thursday, May 14, 2015 9:02 AM > Subject: [v6ops] Idea about updating RFC3849 >> >> Hi Mailinglist-Members, >> >> I am pretty new on this list, so I first wave a "Hello" into the >> round... and immediately continue to ask the question, which led me to= >> subscribing to this list. Apologies if I chose the wrong list, please >> advise me, where to put my question in this case. >> >> I work as consultant and already accompanied several IPv6 roll-outs >> from the first idea "we want V6" until production. While >> enterprise-setups are mostly /32 or less IPs, I see more and more >> rollouts which need much bigger space. >> >> At least in RIPE-Region, each LIR can receive a /29 without any >> justification. And here is where my problem starts. While writing >> documentation and addressing-plans before requesting the actual prefix= >> at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in >> RFC3849. But what to do for bigger nets (lower bitmasks)? >> >> Before starting to push the ball on the field by writing a proposal, >> I'd be happy to hear if there is support in the community for updating= >> this rfc and officially define a bigger prefix for documentation. >> >> As said, if I chose the wrong mailinglist or simply started bringing >> my idea into the community in a wrong way, any advise and comment is >> appreciated. I have no experience with the processes at ietf yet. >> >> Best regards and thanks >> - -- >> Jens Ott >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo@opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Gesch=C3=A4ftsf=C3=BChrer: Jens Ott >> Umsatzsteuer-ID.: DE264133989 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --mu15a6LjgXi68lKEDc2ulgtJgdOApW3o3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVU3QEACgkQ8AA1q7Z/VrLgRACfXwXFDS/cMquNm8xeAUFkMb9u n0YAn3S4Bd8hpwgjmjZX+S79o3VsfJjB =i8VY -----END PGP SIGNATURE----- --mu15a6LjgXi68lKEDc2ulgtJgdOApW3o3-- From nobody Thu May 14 23:21:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDB31ACD58 for ; Thu, 14 May 2015 23:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P7aLCaBKKSx for ; Thu, 14 May 2015 23:21:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6862A1AC3DC for ; Thu, 14 May 2015 23:21:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSO19633; Fri, 15 May 2015 06:21:11 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 07:21:09 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 15 May 2015 14:21:04 +0800 From: "Liubing (Leo)" To: "Mudric, Dusan (Dusan)" Thread-Topic: Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AdCM5PoG5SBG9u46QEK4wNDSgsbkgP//jcwAgAGdvID//yEnYIACC2QA//6nYnA= Date: Fri, 15 May 2015 06:21:03 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEF1D7E@nkgeml506-mbx.china.huawei.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Lin, Ping \(Ping\)" , "v6ops@ietf.org" Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:21:17 -0000 SGkgRHVzYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTXVkcmlj LCBEdXNhbiAoRHVzYW4pIFttYWlsdG86ZG11ZHJpY0BhdmF5YS5jb21dDQo+IFNlbnQ6IFRodXJz ZGF5LCBNYXkgMTQsIDIwMTUgMTA6NDIgUE0NCj4gVG86IExpdWJpbmcgKExlbyk7IEJyaWFuIEUg Q2FycGVudGVyOyBMb3JlbnpvIENvbGl0dGk7IFNUQVJLLCBCQVJCQVJBIEg7DQo+IHY2b3BzQGll dGYub3JnDQo+IENjOiBMaW4sIFBpbmcgKFBpbmcpOyBTdGV2ZW4gQi4NCj4gU3ViamVjdDogUkU6 IFF1ZXN0aW9uIHJlLiBzdGF0ZWxlc3MgREhDUHY2IGFuZCAnTScgJiAnTycgZmxhZ3MNCj4gDQo+ IEhpIEJpbmcsDQo+IA0KPiBUaGUgZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxl bSBuaWNlbHkgY2FwdHVyZXMgYW1iaWd1aXRpZXMgYW5kDQo+IGRpZmZlcmVudCBpbnRlcnByZXRh dGlvbnMgYXJvdW5kICdNJywgJ08nIGFuZCAnQScgZmxhZ3MuIEl0IGFsc28gb3BlbnMgYSBmbG9v cg0KPiBmb3IgZnVydGhlciBkaXNjdXNzaW9uIGFyb3VuZDoNCj4gLSB0aGUgbmVlZCBmb3Igc3Rh dGVsZXNzIERIQ1B2NiwNCj4gLSBzaW11bHRhbmVvdXMgU0xBQUMgYW5kIERIQ1B2NiBhZGRyZXNz IGFzc2lnbm1lbnRzLCBhbmQNCj4gLSBORCBhbmQgREhDUHY2IGludGVyd29ya2luZzogZS5nLiB0 aGUgcm9sZSBvZiBORCBvbi1saW5rIGFkZHJlc3MgcHJlZml4IGZvcg0KPiBESENQdjYgYWRkcmVz c2VzLg0KPiANCj4gT25seSB3aGVuIHRoZSBuZWVkcyBhcmUgc3lzdGVtYXRpY2FsbHkgY2FwdHVy ZWQsIGl0IHdpbGwgYmUgcG9zc2libGUgdG8gZGVmaW5lDQo+IHRoZSBmbGFncy4NCltCaW5nXSBJ IGFsc28gdGhpbmsgdGhlc2UgZnVydGhlciB0b3BpY3MgbWFrZSBzZW5zZS4gV2UgbWlnaHQgbmVl ZCBhIGJyb2FkZXIgZGlzY3Vzc2lvbiBhY3Jvc3MgdjZvcHMvNmFtL2RoYyBhbmQgbWF5YmUgYW5v dGhlciBjb3VwbGUgb2YgZHJhZnRzIHRvIGRpc2N1c3MgdGhlc2UgdG9waWNzLg0KDQoNCj4gW0Jp bmddIChTcGVhayBhcyBhIGNvLWF1dGhvcikgV2UgaW5kZWVkIGRpZG4ndCB0ZXN0IHRoZSBjYXNl IGFzIHlvdSBzYWlkDQo+IGFib3ZlLCBidXQgd2UgdGVzdGVkIGEgc2ltaWxhciBjYXNlOiBhdCBp bml0aWFsIHN0YWdlLCB3aGVuIEE9MCxNPTAsIGFuZCBPPTEsDQo+IHNvbWUgcGxhdGZvcm0gd291 bGQgc3RhcnQgc3RhdGVsZXNzIERIQ1B2NiB3aGlsZSBzb21lIG5vdC4NCj4gW0R1c2FuXSBEaWQg dGhlIGhvc3RzIHJ1biBzdGF0ZWxlc3MgREhDUHY2LCBvciBzdGF0ZWZ1bCBESENQdjYgd2l0aG91 dCB0aGUNCj4gYWRkcmVzcyBvcHRpb24gaW4gT1JPLCBvciBzdGF0ZWZ1bCBESENQdjYgYW5kIGln bm9yZWQgdGhlIGFkZHJlc3MgaW4NCj4gUkVQTFk/DQpbQmluZ10gTGV0IG1lIHF1b3RlIHRoZSBy ZXN1bHQgaW4gdGhlIGRyYWZ0Og0KbyAgQT0wLCBNPTAsIE89MQ0KDQogICAgICAqICBXaW5kb3dz IDguMSBhY3F1aXJlZCBhZGRyZXNzZXMgYW5kIG90aGVyIGluZm9ybWF0aW9uIGZyb20NCiAgICAg ICAgIERIQ1B2Ni4gKFAuUy4gV2luZG93IDguMSBhbHdheXMgdHJpZXMgdG8gYWNxdWlyZSBhZGRy ZXNzIGFuZCBvdGhlciBpbmZvcm1hdGlvbiB0aHJvdWdoIHN0YXRlZnVsIERIQ1B2NiwgcmVnYXJk bGVzcyBvZiB3aGF0ZXZlciB0aGUgZmxhZ3MgYXJlKQ0KDQogICAgICAqICBXaW5kb3dzIDcsIE9T WCAxMC45IGFuZCBJT1MgOC4wIGFjcXVpcmVkIG90aGVyIGluZm9ybWF0aW9uIGZyb20NCiAgICAg ICAgIERIQ1B2Ni4gKFAuUy4gc3RhdGVsZXNzIERIQ1B2NikNCg0KICAgICAgKiAgVWJ1bnR1IDE0 LjA0IGFjcXVpcmVkIG5vIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uDQoNCj4gPiAtIERvZXMg bm90IG1lbnRpb24gaWYgdGhlIGhvc3QgaXMgU0xBQUMgYW5kIHN0YXRlZnVsIERIQ1B2NiBjb25m aWd1cmVkDQo+ID4gc2ltdWx0YW5lb3VzbHkgKGJ1bGxldCB0d28gZG9lcyBub3Qgc2F5IHN0YXRl ZnVsKSwgREhDUHY2IGFkZHJlc3MNCj4gPiBzaG91bGQgc3RhcnQgd2l0aCBQSSBwcmVmaXgNCj4g W0JpbmddIFNvcnJ5IEkgZGlkbid0IGNhdGNoIHlvdXIgcG9pbnQuIFdoeSBpcyB0aGUgIlBJIHBy ZWZpeCIgcmVsYXRlZCB0bw0KPiBTTEFBQy9ESENQdjYgY29uZmlndXJlZCBzaW11bHRhbmVvdXNs eT8NCj4gQnR3LCB3aGljaCAiYnVsbGV0IHR3byIgZGlkIHlvdSByZWZlciB0bz8NCj4gW0R1c2Fu XSBJdCBpcyBpbXBvcnRhbnQgdGhhdCBESENQdjYgYWRkcmVzcyBzdGFydHMgd2l0aCBvbi1saW5r IHByZWZpeC4NCj4gT3RoZXJ3aXNlIHRoZSBlbmQgcG9pbnQgd2lsbCBiZSB1bnJlYWNoYWJsZS4g V2hlbiBTTEFBQy9ESENQdjYgYXJlDQo+IGNvbmZpZ3VyZWQgdG8gcnVuIHNpbXVsdGFuZW91c2x5 LCBpZiBNPTEgaXMgaW50ZXJwcmV0ZWQgdG8gbWVhbiBydW4gc3RhdGVmdWwNCj4gREhDUHY2IGFu ZCBvYnRhaW4gSVB2NiBhZGRyZXNzIHZpYSBESENQdjYgY2xpZW50LCBQSSBvcHRpb24gc2hvdWxk IGhhdmUgTA0KPiBiaXQgc2V0IHRvIGFsbG93IHRoZSBlbmQgcG9pbnQgdG8gdmVyaWZ5IHRoZSBh Y3F1aXJlZCBESENQdjYgYWRkcmVzcyBpbg0KPiBvbi1saW5rLiBUaGlzIGJlaGF2aW9yIHNob3Vs ZCBiZSBzdGFuZGFyZGl6ZWQuDQpbQmluZ10gQWgsIHlvdSBtZWFudCBQSU8gKFByZWZpeCBJbmZv cm1hdGlvbiBPcHRpb24pLiBJIG1pc3Rha2VubHkgc2F3IGl0IGFzICJQcm92aWRlciBJbmRlcGVu ZGVudCIgcHJlZml4Lg0KDQoNCj4gW0JpbmddIEJ0dywgd2hpY2ggImJ1bGxldCB0d28iIGRpZCB5 b3UgcmVmZXIgdG8/DQo+IFtEdXNhbl0gU2VjdGlvbiAzIC0gMikuDQo+IA0KPiA+IC0gRG9lcyBu b3QgbWVudGlvbiB0aGF0ICdNJyBhbmQgJ08nIGZsYWdzLCBzaG91bGQgYmUgdXNlZCBhcyBhDQo+ ID4gbWVjaGFuaXNtIHRvIGRpc2FibGUgb25seSBzdGF0ZWZ1bCBJUHY2IGFkZHJlc3MgaWYgU0xB QUMgaXMgZW5hYmxlZC4NCj4gW0JpbmddIERpZCB5b3UgbWVhbiwgd2hlbiBhIGhvc3QgaXMgY29u ZmlndXJlZCB3aXRoIFNMQUFDLCB0aGUgREhDUHY2DQo+IGFkZHJlc3MgY29uZmlndXJhdGlvbiBz aG91bGQgYmUgZGlzYWJsZWQ/DQo+IFtEdXNhbl0gWWVzLCBvbmx5IHRoZSBhZGRyZXNzIHBhcnQg c2hvdWxkIGJlIGRpc2FibGVkLiBCdXQgb3RoZXINCj4gY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv biBzaG91bGQgYmUgc3RpbGwgYXZhaWxhYmxlIHZpYSBESENQdjYuDQo+IA0KPiBbQmluZ10gSG93 ZXZlciwgcGVyc29uYWxseSBJJ20gbm90IHN1cmUgdGhpcyBzaG91bGQgYmUgYSByaWdodCBiZWhh dmlvci4NCj4gU0xBQUMvREhDUHY2IGFkZHJlc3NlcyBjby1leGlzdGluZyBtaWdodCBtYWtlIHNl bnNlIGluIHNvbWUgc2NlbmFyaW9zLg0KPiBbRHVzYW5dIGRyYWZ0LWxpdS12Nm9wcy1ydW5uaW5n LW11bHRpcGxlLXByZWZpeGVzLTAzI3NlY3Rpb24tMy4xIG9ubHkgdGFsa3MNCj4gYWJvdXQgdGhl IHByZWZpeCBkZWxpdmVyaW5nIG1lY2hhbmlzbSB0byByb3V0ZXJzIHVzaW5nIERIQ1B2Ni4gSXQg ZG9lcyBub3QNCj4gcmVjb21tZW5kIHRoZSBjby1leGlzdGluZyBTTEFBQy9ESENQdjYgYmVoYXZp b3IgZm9yIGhvc3RzLiBJZiB0aGVyZSBpcyBhDQo+IG5lZWQgZm9yIG11bHRpcGxlIElQdjYgYWRk cmVzc2VzIHBlciBpbnRlcmZhY2UsIGFzIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQsDQo+IFNMQUFD IGFscmVhZHkgYWxsb3dzIHRoZSB1c2Ugb2YgbXVsdGlwbGUgcHJlZml4ZXMgYW5kIERIQ1B2NiBh bHJlYWR5IGFsbG93cw0KPiB0aGUgYXNzaWdubWVudCBvZiBtdWx0aXBsZSBJUHY2IGFkZHJlc3Nl cy4gVGhlcmUgaXMgcmVhbGx5IG5vIG5lZWQgZm9yIGFkZGluZw0KPiBmdXJ0aGVyIGNvbXBsZXhp dHkgYnkgbWl4aW5nIHRoZSB0d286IFNMQUFDIElQdjYgYWRkcmVzc2VzIGFuZCBESENQdjYNCj4g SVB2NiBhZGRyZXNzZXMuDQpbQmluZ10gSSBhZ3JlZSB0aGF0IFNMQUFDIGNvdWxkIGFjaGlldmUg dGhlIGdvYWwgdG8gY29uZmlndXJlIG11bHRpcGxlIGFkZHJlc3Nlcy4gQnV0IGl0IG1pZ2h0IG5v dCBuZWNlc3NhcmlseSBtZWFuIHRoZSBESENQdjYgYWRkcmVzcyBjb25maWcgc2hvdWxkIGJlIGRp c2FibGVkIGluIHRoaXMgY2FzZS4NCk9uZSB0aGluZyBJIGNhbiBpbWFnaW5lIGlzIHRoYXQgaXQg bWlnaHQgbm90IG9ubHkgcmVnYXJkaW5nIHRvIG11bHRpcGxlIGFkZHJlc3NlcywgYnV0IGFsc28g bXVsdGlwbGUgcHJvdmlzaW9uaW5nIGRvbWFpbnMuIFNheSwgaWYgb25lIHByb3Zpc2lvbmluZyBk b21haW4gaXMgdXNpbmcgU0xBQUMgYW5kIHRoZSBvdGhlciB1c2VzIERIQ1B2NiwgdGhlIGNvLWV4 aXN0aW5nIHdvdWxkIGFsbG93IHRoZSBmbGV4aWJpbGl0eSBmb3IgdGhhdCBjYXNlLg0KDQpCZXN0 IHJlZ2FyZHMsDQpCaW5nDQoNCj4gPiBXaGF0IGlzIHRoZSB2YWx1ZSBvZg0KPiA+IGRpc2FibGlu ZyBvdGhlciBESENQdjYgY29uZmlndXJhdGlvbj8gRW5kIHBvaW50IGluc3RydW1lbnRzIG5lZWQN Cj4gPiBESENQdjYgZm9yIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYW5kIHRoYXQg c2hhbGwgbm90IGJlDQo+ID4gZGlzYWJsZWQgdmlhIGEgcm91dGVyIChVbmxlc3MgdGhlcmUgaXMg YSBwbGFuIHRvIHByb3ZpZGUgYWxsIHRoYXQgY29uZmlndXJhdGlvbg0KPiB2aWEgYSByb3V0ZXI/ KS4NCj4gPiBJZiB0aGVyZSBpcyBhZ3JlZW1lbnQgb24gdGhpcyBzdGF0ZW1lbnQsIG9ubHkgb25l IGZsYWcgaXMgbmVlZGVkLCAnTScgZmxhZy4NCj4gW0JpbmddIEkgY2FuJ3QgcmVhbGx5IGFuc3dl ciB0aGlzIHF1ZXN0aW9uLiBNeSBndWVzcyBpcyB0aGF0ICwgd2hlbiB0aGUgaG9zdHMNCj4gY2Fu IGdldCBib3RoIGFkZHJlc3MgYW5kIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhy b3VnaCBzdGF0ZWZ1bA0KPiBESENQdjYgY29uZmlndXJhdGlvbiwgdGhlbiB0aGUgc3RhdGVsZXNz IERIQ1B2NiBjb25maWd1cmF0aW9uIGlzIHJlZHVuZGFudA0KPiBpZiBpdCBpcyBhbHdheXMgb24u DQo+IFtEdXNhbl0gU3RhdGVsZXNzIERIQ1B2NiBpcyByZWR1bmRhbnQgYnkgaXRzIG5hdHVyZS4g U3RhdGVmdWwgREhDUHY2IGNhbg0KPiBzZW5kIFNPTElDSVQgYW5kIFJFUVVFU1QgbWVzc2FnZXMg d2l0aCBPUk8gb3B0aW9uIHRoYXQgZG9lcyBub3QgcmVxdWlyZQ0KPiB0aGUgYWRkcmVzcyAoZS5n LiB3aXRob3V0IE9QVElPTl9JQV9OQSBvcHRpb24gY29kZSkuIElmIHRoZXJlIGlzIG5vDQo+IHN0 YXRlbGVzcyBESENQdjYgY2xpZW50IHRvIGNvbnRyb2wsIHRoZXJlIGlzIG5vIG5lZWQgZm9yICdP JyBmbGFnLiBUaGUNCj4gcmVtYWluaW5nICdNJyBmbGFnIGNhbiBiZSB1c2VkIHRvIGNvbnRyb2wg aWYgT1JPIG9wdGlvbiBoYXMgT1BUSU9OX0lBX05BDQo+IG9wdGlvbiBjb2RlLg0KPiANCj4gUmVn YXJkcywNCj4gRHVzYW4gTXVkcmljLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogTGl1YmluZyAoTGVvKSBbbWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5jb21dDQo+ IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDEzLCAyMDE1IDExOjEwIFBNDQo+IFRvOiBNdWRyaWMsIER1 c2FuIChEdXNhbik7IEJyaWFuIEUgQ2FycGVudGVyOyBMb3JlbnpvIENvbGl0dGk7IFNUQVJLLA0K PiBCQVJCQVJBIEg7IHY2b3BzQGlldGYub3JnDQo+IENjOiBMaW4sIFBpbmcgKFBpbmcpOyBTdGV2 ZW4gQi4NCj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIHJlLiBzdGF0ZWxlc3MgREhDUHY2IGFuZCAn TScgJiAnTycgZmxhZ3MNCj4gDQo+IEhpIER1c2FuIGFuZCBhbGwsDQo+IA0KPiANCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gDQo+ID4gRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVkcmljLCBEdXNhbg0KPiANCj4g PiAoRHVzYW4pDQo+IA0KPiA+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTQsIDIwMTUgNDo0NiBBTQ0K PiANCj4gPiBUbzogQnJpYW4gRSBDYXJwZW50ZXI7IExvcmVuem8gQ29saXR0aTsgU1RBUkssIEJB UkJBUkEgSDsNCj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiANCj4gPiBDYzogTGluLCBQaW5nIChQaW5n KTsgU3RldmVuIEIuDQo+IA0KPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFF1ZXN0aW9uIHJlLiBz dGF0ZWxlc3MgREhDUHY2IGFuZCAnTScgJiAnTycgZmxhZ3MNCj4gDQo+ID4NCj4gDQo+ID4gZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbToNCj4gDQo+ID4gLSBEb2VzIG5vdCBt ZW50aW9uIHVzZSBvZiBzdGF0ZWxlc3MgREhDUHY2DQo+IA0KPiA+IC0gRG9lcyBub3QgbWVudGlv biB0aGF0IGlzIG5vdCBjbGVhciBpZiBzdGF0ZWxlc3MgREhDUHY2IGNsaWVudCBzaG91bGQNCj4g PiBzdGFydCBpZg0KPiANCj4gPiBTTEFBQyBpcyB1c2VkIGFuZCBNPTAgYW5kIE8gY2hhbmdlcyBm cm9tIDAgdG8gMS4gT3IsIHN0YXRlZnVsIERIQ1B2Ng0KPiA+IGNhbg0KPiANCj4gPiBzdGFydCBi dXQgSVB2NiBhZGRyZXNzIGNhbiBiZSBpZ25vcmVkIG9yIE9STyBvcHRpb24gZG9lcyBub3QgcmVx dWlyZQ0KPiA+IHRoZQ0KPiANCj4gPiBhZGRyZXNzLg0KPiANCj4gW0JpbmddIChTcGVhayBhcyBh IGNvLWF1dGhvcikgV2UgaW5kZWVkIGRpZG4ndCB0ZXN0IHRoZSBjYXNlIGFzIHlvdSBzYWlkDQo+ IGFib3ZlLCBidXQgd2UgdGVzdGVkIGEgc2ltaWxhciBjYXNlOiBhdCBpbml0aWFsIHN0YWdlLCB3 aGVuIEE9MCxNPTAsIGFuZCBPPTEsDQo+IHNvbWUgcGxhdGZvcm0gd291bGQgc3RhcnQgc3RhdGVs ZXNzIERIQ1B2NiB3aGlsZSBzb21lIG5vdC4NCj4gDQo+IERldGFpbHMgcGxlYXNlIHJlZmVyIHRv IHRoZSBBcHBlbmRpeCBBLjINCj4gKGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbA0KPiBfZHJhZnQtMkRpZXRmLTJE djZvcHMtMkRkaGNwdjYtMkRzbGFhYy0yRHByb2JsZW0tMkQwNC0yM2FwcGVuZGl4LTJEDQo+IEEu MiZkPUF3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNy aElvDQo+IFVXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPW04QWpBeEwxNmhQd1g0c3ROTGk0bXhkZkJn N1VoLUtaUWZsDQo+IDRPbUFQQnowJnM9UllCWDRvWG45SmI2RDFmMlMyMHVuVmZJbllCM1hRQ3lx QnVjaEZJSTEtdyZlPSApLg0KPiANCj4gDQo+IA0KPiA+IC0gRG9lcyBub3QgbWVudGlvbiBpZiB0 aGUgaG9zdCBpcyBTTEFBQyBhbmQgc3RhdGVmdWwgREhDUHY2IGNvbmZpZ3VyZWQNCj4gDQo+ID4g c2ltdWx0YW5lb3VzbHkgKGJ1bGxldCB0d28gZG9lcyBub3Qgc2F5IHN0YXRlZnVsKSwgREhDUHY2 IGFkZHJlc3MNCj4gPiBzaG91bGQNCj4gDQo+ID4gc3RhcnQgd2l0aCBQSSBwcmVmaXgNCj4gDQo+ IFtCaW5nXSBTb3JyeSBJIGRpZG4ndCBjYXRjaCB5b3VyIHBvaW50LiBXaHkgaXMgdGhlICJQSSBw cmVmaXgiIHJlbGF0ZWQgdG8NCj4gU0xBQUMvREhDUHY2IGNvbmZpZ3VyZWQgc2ltdWx0YW5lb3Vz bHk/DQo+IA0KPiBCdHcsIHdoaWNoICJidWxsZXQgdHdvIiBkaWQgeW91IHJlZmVyIHRvPw0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+ID4gLSBEb2VzIG5vdCBtZW50aW9uIHRoYXQgJ00nIGFuZCAnTycg ZmxhZ3MsIHNob3VsZCBiZSB1c2VkIGFzIGENCj4gPiBtZWNoYW5pc20gdG8NCj4gDQo+ID4gZGlz YWJsZSBvbmx5IHN0YXRlZnVsIElQdjYgYWRkcmVzcyBpZiBTTEFBQyBpcyBlbmFibGVkLg0KPiAN Cj4gW0JpbmddIERpZCB5b3UgbWVhbiwgd2hlbiBhIGhvc3QgaXMgY29uZmlndXJlZCB3aXRoIFNM QUFDLCB0aGUgREhDUHY2DQo+IGFkZHJlc3MgY29uZmlndXJhdGlvbiBzaG91bGQgYmUgZGlzYWJs ZWQ/DQo+IA0KPiBXZSBkaWQgb2JzZXJ2ZWQgc29tZSBiZWhhdmlvcnMgbGlrZSB0aGlzIGluIHNv bWUgcGxhdGZvcm06IHdoZW4gYSBob3N0IGhhcw0KPiBjb25maWd1cmVkIFNMQUFDLCBhbmQgdGhl biBNIGNoYW5nZXMgZnJvbSAwIHRvIDEsIHNvbWUgaG9zdHMganVzdCBpZ25vcmUNCj4gdGhlIE0g ZmxhZyAoc2VlIHRoZSBzZWNvbmQgYnVsbGV0IG9mIEFwcGVuZGl4IEEuMykuDQo+IA0KPiANCj4g DQo+IEhvd2V2ZXIsIHBlcnNvbmFsbHkgSSdtIG5vdCBzdXJlIHRoaXMgc2hvdWxkIGJlIGEgcmln aHQgYmVoYXZpb3IuDQo+IFNMQUFDL0RIQ1B2NiBhZGRyZXNzZXMgY28tZXhpc3RpbmcgbWlnaHQg bWFrZSBzZW5zZSBpbiBzb21lIHNjZW5hcmlvcy4NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sXw0KPiBkcmFm dC0yRGxpdS0yRHY2b3BzLTJEcnVubmluZy0yRG11bHRpcGxlLTJEcHJlZml4ZXMtMkQwMy0yM3Nl Y3Rpb24tMkQzLg0KPiAxJmQ9QXdJR2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0Jr OWNiTGVhSnhoZjNpQ3JoSW9VDQo+IFdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bThBakF4TDE2aFB3 WDRzdE5MaTRteGRmQmc3VWgtS1pRZmw0DQo+IE9tQVBCejAmcz1zNUk3SXJrVXJTdmk2RXY1bVVo dnJpOUdvTDJwTEkxWjJjV1lEVEVRT21NJmU9ICBoYXMNCj4gYSBicmllZiBkaXNjdXNzaW9uIG9u IHRoaXMuIEJ1dCB0aGlzIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCj4g ZG9lcyBub3QgaW50ZW5kIHRvIGRpc2N1c3Mgd2hhdCB0aGUgcmlnaHQgYmVoYXZpb3Igc2hvdWxk IGJlLg0KPiANCj4gDQo+IA0KPiA+IFdoYXQgaXMgdGhlIHZhbHVlIG9mDQo+IA0KPiA+IGRpc2Fi bGluZyBvdGhlciBESENQdjYgY29uZmlndXJhdGlvbj8gRW5kIHBvaW50IGluc3RydW1lbnRzIG5l ZWQNCj4gPiBESENQdjYNCj4gDQo+ID4gZm9yIG90aGVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24gYW5kIHRoYXQgc2hhbGwgbm90IGJlIGRpc2FibGVkIHZpYQ0KPiA+IGENCj4gDQo+ID4gcm91 dGVyIChVbmxlc3MgdGhlcmUgaXMgYSBwbGFuIHRvIHByb3ZpZGUgYWxsIHRoYXQgY29uZmlndXJh dGlvbiB2aWEgYQ0KPiByb3V0ZXI/KS4NCj4gDQo+ID4gSWYgdGhlcmUgaXMgYWdyZWVtZW50IG9u IHRoaXMgc3RhdGVtZW50LCBvbmx5IG9uZSBmbGFnIGlzIG5lZWRlZCwgJ00nIGZsYWcuDQo+IA0K PiBbQmluZ10gSSBjYW4ndCByZWFsbHkgYW5zd2VyIHRoaXMgcXVlc3Rpb24uIE15IGd1ZXNzIGlz IHRoYXQgLCB3aGVuIHRoZSBob3N0cw0KPiBjYW4gZ2V0IGJvdGggYWRkcmVzcyBhbmQgb3RoZXIg Y29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiB0aHJvdWdoIHN0YXRlZnVsDQo+IERIQ1B2NiBjb25m aWd1cmF0aW9uLCB0aGVuIHRoZSBzdGF0ZWxlc3MgREhDUHY2IGNvbmZpZ3VyYXRpb24gaXMgcmVk dW5kYW50DQo+IGlmIGl0IGlzIGFsd2F5cyBvbi4NCj4gDQo+IA0KPiANCj4gPiBUaGlzIGZsYWcg d291bGQgY29udHJvbCBpZiBlbmQgcG9pbnQgaW5zdHJ1bWVudHMgd291bGQgaGF2ZSBvbmx5IFNM QUFDDQo+ID4gb3INCj4gDQo+ID4gb25seSBESENQdjYgYWRkcmVzcyAoZXhhbXBsZTogTT0xIHdv dWxkIG1lYW4gb25seSBESENQdjYgYWRkcmVzcyBpcw0KPiANCj4gPiBjb25maWd1cmVkIGFuZCBp ZiBBPTEgd291bGQgbWVhbiB0aGF0IERIQ1B2NiBhZGRyZXNzIHdvdWxkIGhhdmUgdG8NCj4gPiBz dGFydA0KPiANCj4gPiB3aXRoIHRoZSBQSSBwcmVmaXgpLiBJIGRvbid0IHNlZSBhIG5lZWQgZm9y IGJvdGggU0xBQUMgYW5kIERIQ1B2Ng0KPiBhZGRyZXNzZXMuDQo+IA0KPiBbQmluZ10gQXMgc2Fp ZCBhYm92ZSwgSSB0aGluayBjby1leGlzdGluZyBtaWdodCBtYWtlIHNlbnNlIGluIHNvbWUgc2Nl bmFyaW9zLg0KPiANCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiBCaW5nDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gPiBEdXNhbg0KPiANCj4gPg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiANCj4gPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gDQo+ID4gU2VudDogVHVlc2RheSwgTWF5IDEyLCAy MDE1IDQ6MDUgUE0NCj4gDQo+ID4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKTsgTG9yZW56byBD b2xpdHRpOyBTVEFSSywgQkFSQkFSQSBIDQo+IA0KPiA+IENjOiBMaW4sIFBpbmcgKFBpbmcpOyBT dGV2ZW4gQi47IGlwdjZAaWV0Zi5vcmc7IEJlcm5pZSBWb2x6ICh2b2x6KQ0KPiANCj4gPiBTdWJq ZWN0OiBSZTogUXVlc3Rpb24gcmUuIHN0YXRlbGVzcyBESENQdjYgYW5kICdNJyAmICdPJyBmbGFn cw0KPiANCj4gPg0KPiANCj4gPiBIaSBEdXNhbiwNCj4gDQo+ID4NCj4gDQo+ID4gVGhlIE0vTyBm bGFncyBhcmUgbm90IG9ic29sZXRlLiBUaGV5IGFyZSBkZWZpbmVkIGluIFJGQyA0ODYxLg0KPiAN Cj4gPg0KPiANCj4gPiBZb3UgbWlnaHQgd2FudCB0byByZWFkDQo+IA0KPiA+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf aHQNCj4gPiBtbF8NCj4gDQo+ID4NCj4gZHJhZnQtMkRpZXRmLTJEdjZvcHMtMkRkaGNwdjYtMkRz bGFhYy0yRHByb2JsZW0mZD1Bd0lGYVEmYz1CRnBXUQ0KPiANCj4gPg0KPiB3OGJzdUtwbDFTZ2la SDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eyaw0KPiANCj4g Pg0KPiBZJm09QVBoRDVUcTdROUVaNjRlREtUY29vSlg4dnZRZFRDZHdHZTd3LS1RY0MzMCZzPVZ2 QzJuUVRvQg0KPiANCj4gPiA1MXFkaDhKN0pscHctWTNORTNnX0pTdW9vYXkyZkVWdTBzJmU9DQo+ IA0KPiA+IChub3RpbmcgdGhhdCBpdCBpcyBzdGlsbCBhIGRyYWZ0LCBkaXNjdXNzZWQgaW4gdGhl IHY2b3BzIFdHKSBhbmQgeW91DQo+ID4gbWlnaHQgbW92ZQ0KPiANCj4gPiB0aGlzIGRpc2N1c3Np b24gdG8gdGhlIHY2b3BzIGxpc3QsIHRvby4NCj4gDQo+ID4NCj4gDQo+ID4gUmVnYXJkcw0KPiAN Cj4gPiAgICBCcmlhbiBDYXJwZW50ZXINCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4gT24gMTMv MDUvMjAxNSAwNjo1MywgTXVkcmljLCBEdXNhbiAoRHVzYW4pIHdyb3RlOg0KPiANCj4gPiA+IEhp IEV2ZXJ5b25lLA0KPiANCj4gPiA+DQo+IA0KPiA+ID4gSSB3b3VsZCBhcHByZWNpYXRlIHlvdXIg aGVscCBhbnN3ZXJpbmcgdGhlIHF1ZXN0aW9ucyByZWdhcmRpbmcgdGhlDQo+IA0KPiA+IHN0YXRl bGVzcyBESENQdjYgYW5kIOKAmE3igJkgJiDigJhP4oCZIGZsYWdzOg0KPiANCj4gPiA+DQo+IA0K PiA+ID4gQmFja2dyb3VuZDoNCj4gDQo+ID4gPiA9PT09PT09PT09PQ0KPiANCj4gPiA+IEZvbGxv d2luZyBSRkMgMjQ2Miwg4oCcT+KAnSBmbGFnIGluIFJvdXRlciBBZHZlcnRpc2VtZW50cyBpcyB1 c2VkIHRvDQo+ID4gPiBzdGFydA0KPiANCj4gPiBzdGF0ZWxlc3MgREhDUHY2IGNsaWVudC4gV2hl biB1c2luZyDigJhP4oCZIGZsYWcsIHRoZSBlbmQgcG9pbnQgc2hhbGwgc3VwcG9ydDoNCj4gDQo+ ID4gPg0KPiANCj4gPiA+IMK3ICAgICAgICAgUkZDDQo+IA0KPiA+DQo+IDM3MzY8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWZ0cC0zQV9fZnRwLnJmYy0yRGVkaXRv ci4NCj4gDQo+ID4NCj4gb3JnX2luLTJEbm90ZXNfcmZjMzczNi50eHQmZD1Bd0lGYVEmYz1CRnBX UXc4YnN1S3BsMVNnaVpINjRRJnI9DQo+IA0KPiA+DQo+IFVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9V V0I4WUxaVTIzMDI5c01RR1Eya1kmbT1BUGhENVRxN1E5RVo2NA0KPiANCj4gPg0KPiBlREtUY29v Slg4dnZRZFRDZHdHZTd3LS1RY0MzMCZzPW1aa2hCZGhYb0lSR0VzSzZaM21mV1M0Unl2S0INCj4g DQo+ID4gLUlpS2hvcnBYQmZud0VZJmU9ID4gLCB0aGF0IGRlZmluZXMgc3RhdGVsZXNzIERIQ1B2 NiBjbGllbnQNCj4gDQo+ID4gPg0KPiANCj4gPiA+IMK3ICAgICAgICAgUkZDIDQyNDIsIHRoYXQg ZGVmaW5lcyB3aGVuIHRoZSBlbmQgcG9pbnQgc2hvdWxkIHJlZnJlc2gNCj4gdGhlDQo+IA0KPiA+ IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24uDQo+IA0KPiA+ID4NCj4gDQo+ID4gPiBRdWVzdGlv bnM6DQo+IA0KPiA+ID4gPT09PT09PT09DQo+IA0KPiA+ID4gSWYgUkZDIDQ4NjIgcmVtb3ZlZCDi gJhN4oCZICYg4oCYT+KAmSBmbGFncyBhbmQgb2Jzb2xldGVkIFJGQyAyNDYyICh0aGF0DQo+IA0K PiA+IGRlZmluZXMg4oCYTeKAmSAmIOKAmE/igJkgZmxhZ3MpLCB3aHkgYXJlIHRoZSBmbGFncyBu b3QgZGVwcmVjYXRlZD8gV2hhdCBpcw0KPiA+IHRoZQ0KPiANCj4gPiB2YWx1ZSBvZiByZWZlcnJp bmcgdG8gdGhlIG9ic29sZXRlZCBzdGFuZGFyZCwgaW4gb3JkZXIgdG8gc3VwcG9ydA0KPiA+IGZs YWdzIGluIHRoZQ0KPiANCj4gPiBzb2x1dGlvbiB0aGF0IGlzIG5vdCBtYXR1cmU/DQo+IA0KPiA+ ID4NCj4gDQo+ID4gPiByZmM0ODYyI2FwcGVuZGl4LUMNCj4gDQo+ID4gPiAgICBvICBSZW1vdmVk IHRoZSB0ZXh0IHJlZ2FyZGluZyB0aGUgTSBhbmQgTyBmbGFncywgY29uc2lkZXJpbmcgdGhlDQo+ IA0KPiA+ID4gICAgICAgbWF0dXJpdHkgb2YgaW1wbGVtZW50YXRpb25zIGFuZCBvcGVyYXRpb25h bCBleHBlcmllbmNlcy4NCj4gDQo+ID4gPiAgICAgICBNYW5hZ2VkRmxhZyBhbmQgT3RoZXJDb25m aWdGbGFnIHdlcmUgcmVtb3ZlZCBhY2NvcmRpbmdseS4NCj4gDQo+ID4gKE5vdGUNCj4gDQo+ID4g PiAgICAgICB0aGF0IHRoaXMgY2hhbmdlIGRvZXMgbm90IG1lYW4gdGhlIHVzZSBvZiB0aGVzZSBm bGFncyBpcw0KPiANCj4gPiA+ICAgICAgIGRlcHJlY2F0ZWQuKQ0KPiANCj4gPiA+DQo+IA0KPiA+ ID4gSW4gdGhlIHRocmVhZCDigJxSZTogUXVlc3Rpb24gcmUuIFJFQ09ORklHIGluIERIQ1B2NuKA nSwgQmVybmllIHN0YXRlZDoNCj4gDQo+ID4gPiDigJxUaGUgUkZDIDM3MzYgZG9jdW1lbnQgaXMg cmVhbGx5IG5vdCBzb21ldGhpbmcgSSB3b3VsZCByZWNvbW1lbmQNCj4gDQo+ID4gZm9sbG93aW5n IC0gc2VlIGZ1bGwgUkZDIDMzMTUgYW5kIGltcGxlbWVudCB0aG9zZSBmZWF0dXJlcyB5b3UgbmVl ZA0KPiA+IChzdWNoDQo+IA0KPiA+IGFzIG9ubHkgSW5mb3JtYXRpb24tUmVxdWVzdCBhbmQgUmVw bHkpLiAzNzM2IHdhcyB3cml0dGVuIHRvDQo+ID4gZGVtb25zdHJhdGUNCj4gDQo+ID4gdGhhdCBz dGF0ZWxlc3MgZGhjcHY2IHdhcyByYXRoZXIgc2ltcGxlIHRvIGltcGxlbWVudC7igJ0NCj4gDQo+ ID4gPg0KPiANCj4gPiA+IEJhc2VkIG9uIHRoZSBmYWN0IHRoYXQg4oCYTeKAmSAmIOKAmE/igJkg ZmxhZ3MgYXJlIHJlbW92ZWQgZnJvbSB0aGUgUkZDIDQ4NjINCj4gDQo+ID4gYW5kIHRoZSBzdGF0 ZW1lbnQgYWJvdmUsIGNhbiB3ZSBzYXkgdGhlIHN0YXRlbGVzcyBESENQdjYgaXMgbm90DQo+ID4g bWFuZGF0b3J5DQo+IA0KPiA+IGFuZCwgY29uc2VxdWVudGx5LCDigJhP4oCZIGZsYWcgaXMgbm90 IHJlcXVpcmVkPw0KPiANCj4gPiA+DQo+IA0KPiA+ID4gSWYgc3RhdGVsZXNzIERIQ1B2NiBpcyBu b3QgdXNlZCwgc3RhdGVmdWwgREhDUHY2IGlzIHJlcXVpcmVkLiBUaGVuLCDigJhN4oCZDQo+IA0K PiA+IGZsYWcgaXMgbm90IG5lZWRlZC4NCj4gDQo+ID4gPg0KPiANCj4gPiA+IFJlZ2FyZHMsDQo+ IA0KPiA+ID4gRHVzYW4gTXVkcmljLg0KPiANCj4gPiA+DQo+IA0KPiA+ID4NCj4gDQo+ID4gPg0K PiANCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiA+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+IA0KPiA+ID4gaXB2NkBpZXRmLm9yZw0KPiANCj4gPiA+IEFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOg0KPiANCj4gPiA+DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbA0KPiAN Cj4gPiA+DQo+IA0KPiA+DQo+IG1hbl9saXN0aW5mb19pcHY2JmQ9QXdJRmFRJmM9QkZwV1F3OGJz dUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTA0KPiANCj4gPiBlYUp4aGYzDQo+IA0KPiA+ID4NCj4g DQo+ID4NCj4gaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QVBoRDVUcTdROUVaNjRlREtU Y29vSlg4dnZRZFQNCj4gDQo+ID4gQ2R3R2U3dy0tUWMNCj4gDQo+ID4gPiBDMzAmcz00aFF3Qms0 TXZQU1dGaDdMYnlqOXBMWWE0b2JiYkRPXzE3RVlMY0ZLaDNVJmU9DQo+IA0KPiA+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+ID4gPg0KPiANCj4gPg0KPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiA+DQo+IG1hbl9s aXN0aW5mb192Nm9wcyZkPUF3SUdhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazlj DQo+IGJMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPW04QWpBeEwxNmhQd1g0 c3ROTGk0bQ0KPiB4ZGZCZzdVaC1LWlFmbDRPbUFQQnowJnM9UWFmRjR6UWk2V0NSVjFUMV9LS0w4 X05ieWlvS2g3TUU5TFRyRQ0KPiBFcXFpWHMmZT0NCg0K From nobody Fri May 15 00:49:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED04B1AD366 for ; Fri, 15 May 2015 00:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.198 X-Spam-Level: *** X-Spam-Status: No, score=3.198 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHLqceZl9fAW for ; Fri, 15 May 2015 00:49:40 -0700 (PDT) Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F010F1AD351 for ; Fri, 15 May 2015 00:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=tsahara@iij.ad.jp;s=omgo2;t=1431676173;x= 1432885773; bh=QzaDcjXBb/+OkOR/DQewlFgB1l1TswNr61WA6zvT5Tc=; b=BRxXLCRBAtaBL//Q enpyU7wMmrHHwu2NdI/UFD1oXYbcNb3yZwidpQFAo6Eh7kt6g3zVoSr/oufASDkuQy5eAz+Y7qsLw 99RH2qIfoXnaKsKoFGfq/1TCfKkzQlCHq1APRaJ7Un67UMWdb6hBZp4xrMqAhJidw3m5JX7YR7WC4 7Tv24MbP813ZwCBgHdp5zmhjoeXJ7aPDJMEng2zXryyIe7HRSYhiRfNp5p46kW6mpSwvvgszyxjqC 0U++uY9ZEcTv/TrfyDpUHTLlcNWs7HsTZzdqPqedH+ivtz/ZwowV2Uel/RKIe3rMdtLs81paQ6o+g 4BfZHuRIX5PK7qLBvw==; Received: by omgo.iij.ad.jp (mo900) id t4F7nX9M021572; Fri, 15 May 2015 16:49:33 +0900 X-MXL-Hash: 5555a50d7a31e379-befeee753deaa8c5cfa3d23906df90037223ae23 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Tomoyuki Sahara In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEF1D7E@nkgeml506-mbx.china.huawei.com> Date: Fri, 15 May 2015 16:49:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <04291463-7A8F-4AED-8EA8-7EA1450F0942@iij.ad.jp> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF1D7E@nkgeml506-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Lin, Ping \(Ping\)" , "v6ops@ietf.org" Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 07:49:41 -0000 Hi, > On May 15, 2015, at 15:21, Liubing (Leo) = wrote: >=20 >> [Bing] (Speak as a co-author) We indeed didn't test the case as you = said >> above, but we tested a similar case: at initial stage, when A=3D0,M=3D0= , and O=3D1, >> some platform would start stateless DHCPv6 while some not. >> [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 = without the >> address option in ORO, or stateful DHCPv6 and ignored the address in >> REPLY? > [Bing] Let me quote the result in the draft: > o A=3D0, M=3D0, O=3D1 >=20 > * Windows 8.1 acquired addresses and other information from > DHCPv6. (P.S. Window 8.1 always tries to acquire address and = other information through stateful DHCPv6, regardless of whatever the = flags are) I got a different result from my experiment. My Windows 8.1 host (updated today, running on VirtualBox on MacOS) does not try to acquire address from DHCPv6 Solicitation but sends DHCPv6 Information Request to aquire other information where RA flags are A=3D0, M=3D0, O=3D1. It behaves same as other operating systems. I changed router's configuration to send RA with M=3D1 and the host started to send DHCPv6 Solicitation, as I expected. Then, I changed router's configuration back to M=3D0. I expected that Windows 8.1 host would send DHCPv6 Information Request but it continued to send DHCPv6 Soliciation actually. Then, I unplugged the Ethenret cable and plugged it back. The host started to send DHCPv6 Information Request again. Thanks, Tomoyuki From nobody Fri May 15 02:01:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7E1A1A90 for ; Fri, 15 May 2015 02:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zTz0B8cteSZ for ; Fri, 15 May 2015 02:01:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4564F1A1B53 for ; Fri, 15 May 2015 02:01:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSO35783; Fri, 15 May 2015 09:01:19 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 10:01:17 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 15 May 2015 17:01:10 +0800 From: "Liubing (Leo)" To: Enno Rey , "v6ops@ietf.org" Thread-Topic: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags Thread-Index: AdCM5PoG5SBG9u46QEK4wNDSgsbkgP//jcwAgAGdvID//yEnYIACC2QAgAACpoD//mjTMA== Date: Fri, 15 May 2015 09:01:10 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEF1DD2@nkgeml506-mbx.china.huawei.com> References: <9142206A0C5BF24CB22755C8EC422E457A8009F5@AZ-US1EXMB03.global.avaya.com> <55525CEE.9020106@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A800ED4@AZ-US1EXMB03.global.avaya.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEF17D8@nkgeml506-mbx.china.huawei.com> <9142206A0C5BF24CB22755C8EC422E457A8010E2@AZ-US1EXMB03.global.avaya.com> <20150514145101.GB45151@ernw.de> In-Reply-To: <20150514145101.GB45151@ernw.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 09:01:28 -0000 Hi Enno and all, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Enno Rey > Sent: Thursday, May 14, 2015 10:51 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags >=20 > All, >=20 > pls allow to make you aware that we did some similar tests as those laid = out > in draft-ietf-v6ops-dhcpv6-slaac-problem (btw: very nice work!). Details = & > results can be found in: > https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DH > CPv6_Conflicting_Parameters.pdf. [Bing] Thanks much for sharing the information.=20 I'm very happy to see you've done RDNSS&DHCPv6-DNS_Option test and also the= more complex scenarios with two routers on the same link. Those tests are = really a nice step forward beyond the current v6ops draft. Another very useful information from your report is the security considerat= ions. Please allow me to quote some of them: - "An attacker, without having to install a rogue router, can install a rog= ue DHCPv6 server and provide IPv6 addresses to Windows 8.1 systems. This can allow her to interact with these systems in a= different scope, which, for instance, is not monitored by an IDPS system." - " If you want to perform MiTM using a rogue DNS while legitimate RAs with= the O flag set are sent to enforce the use of a DHCPv6 server, you can spoof RAs with the same settings with the legitimate= prefix (in order to remain undetectable) but advertising YOUR (attacker's)= DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 will u= se the rogue RDNSS (advertised by the RAs) as a first option." - " Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack u= sing a rogue DNS information either, since the one obtained by the RAs of the first router has a higher priority." - " The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited for= DoS purposes. A rogue IPv6 router not only provides its own information to the clients, but it also removes the previo= us obtained (legitimate) information." - " The Fedora and Centos behaviour can also be exploited for MiTM purposes= by advertising rogue RDNSS by RAs which include RDNSS information." I think these are essential cautions for the administrators to refer. > We gave a presentation on this today in the IPv6 WG at RIPE70, with some > additionals comments: > https://ripe70.ripe.net/presentations/132-ERNW_RIPE70_IPv6_Behavior_Co > nflicting_Environments_v0_92_short.pdf [Bing] Very interesting and thoughtful presentation. Recommend all to have = a read. Best regards, Bing > Overall we observed the same unfortunate ambiguities and differing vendor > interpretations/strategies. > thanks >=20 > Enno >=20 >=20 > On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote: > > Hi Bing, > > > > The draft-ietf-v6ops-dhcpv6-slaac-problem nicely captures ambiguities a= nd > different interpretations around 'M', 'O' and 'A' flags. It also opens a = floor > for further discussion around: > > - the need for stateless DHCPv6, > > - simultaneous SLAAC and DHCPv6 address assignments, and > > - ND and DHCPv6 interworking: e.g. the role of ND on-link address prefi= x > for DHCPv6 addresses. > > > > Only when the needs are systematically captured, it will be possible to > define the flags. > > > > [Bing] (Speak as a co-author) We indeed didn't test the case as you sai= d > above, but we tested a similar case: at initial stage, when A=3D0,M=3D0, = and O=3D1, > some platform would start stateless DHCPv6 while some not. > > [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 without > the address option in ORO, or stateful DHCPv6 and ignored the address in > REPLY? > > > > > - Does not mention if the host is SLAAC and stateful DHCPv6 > > > configured simultaneously (bullet two does not say stateful), DHCPv6 > > > address should start with PI prefix > > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related = to > SLAAC/DHCPv6 configured simultaneously? > > Btw, which "bullet two" did you refer to? > > [Dusan] It is important that DHCPv6 address starts with on-link prefix. > Otherwise the end point will be unreachable. When SLAAC/DHCPv6 are > configured to run simultaneously, if M=3D1 is interpreted to mean run sta= teful > DHCPv6 and obtain IPv6 address via DHCPv6 client, PI option should have L > bit set to allow the end point to verify the acquired DHCPv6 address in > on-link. This behavior should be standardized. > > > > [Bing] Btw, which "bullet two" did you refer to? > > [Dusan] Section 3 - 2). > > > > > - Does not mention that 'M' and 'O' flags, should be used as a > > > mechanism to disable only stateful IPv6 address if SLAAC is enabled. > > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 > address configuration should be disabled? > > [Dusan] Yes, only the address part should be disabled. But other > configuration information should be still available via DHCPv6. > > > > [Bing] However, personally I'm not sure this should be a right behavior= . > SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. > > [Dusan] draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 only t= alks > about the prefix delivering mechanism to routers using DHCPv6. It does no= t > recommend the co-existing SLAAC/DHCPv6 behavior for hosts. If there is a > need for multiple IPv6 addresses per interface, as mentioned in the draft= , > SLAAC already allows the use of multiple prefixes and DHCPv6 already allo= ws > the assignment of multiple IPv6 addresses. There is really no need for ad= ding > further complexity by mixing the two: SLAAC IPv6 addresses and DHCPv6 > IPv6 addresses. > > > > > What is the value of > > > disabling other DHCPv6 configuration? End point instruments need > > > DHCPv6 for other configuration information and that shall not be > > > disabled via a router (Unless there is a plan to provide all that > configuration via a router?). > > > If there is agreement on this statement, only one flag is needed, 'M'= flag. > > [Bing] I can't really answer this question. My guess is that , when the= hosts > can get both address and other configuration information through stateful > DHCPv6 configuration, then the stateless DHCPv6 configuration is redundan= t > if it is always on. > > [Dusan] Stateless DHCPv6 is redundant by its nature. Stateful DHCPv6 ca= n > send SOLICIT and REQUEST messages with ORO option that does not require > the address (e.g. without OPTION_IA_NA option code). If there is no > stateless DHCPv6 client to control, there is no need for 'O' flag. The > remaining 'M' flag can be used to control if ORO option has OPTION_IA_NA > option code. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > > Sent: Wednesday, May 13, 2015 11:10 PM > > To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK, > > BARBARA H; v6ops@ietf.org > > Cc: Lin, Ping (Ping); Steven B. > > Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags > > > > Hi Dusan and all, > > > > > > > > > -----Original Message----- > > > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mudric, > > > Dusan > > > > > (Dusan) > > > > > Sent: Thursday, May 14, 2015 4:46 AM > > > > > To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H; > > > v6ops@ietf.org > > > > > Cc: Lin, Ping (Ping); Steven B. > > > > > Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' > > > flags > > > > > > > > > > draft-ietf-v6ops-dhcpv6-slaac-problem: > > > > > - Does not mention use of stateless DHCPv6 > > > > > - Does not mention that is not clear if stateless DHCPv6 client > > > should start if > > > > > SLAAC is used and M=3D0 and O changes from 0 to 1. Or, stateful DHCPv= 6 > > > can > > > > > start but IPv6 address can be ignored or ORO option does not require > > > the > > > > > address. > > > > [Bing] (Speak as a co-author) We indeed didn't test the case as you sai= d > above, but we tested a similar case: at initial stage, when A=3D0,M=3D0, = and O=3D1, > some platform would start stateless DHCPv6 while some not. > > > > Details please refer to the Appendix A.2 > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht= ml > _draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem-2D04-23appendix-2D > A.2&d=3DAwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3Dm8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl > 4OmAPBz0&s=3DRYBX4oXn9Jb6D1f2S20unVfInYB3XQCyqBuchFII1-w&e=3D ). > > > > > > > > > - Does not mention if the host is SLAAC and stateful DHCPv6 > > > configured > > > > > simultaneously (bullet two does not say stateful), DHCPv6 address > > > should > > > > > start with PI prefix > > > > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related = to > SLAAC/DHCPv6 configured simultaneously? > > > > Btw, which "bullet two" did you refer to? > > > > > > > > > > > > > - Does not mention that 'M' and 'O' flags, should be used as a > > > mechanism to > > > > > disable only stateful IPv6 address if SLAAC is enabled. > > > > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6 > address configuration should be disabled? > > > > We did observed some behaviors like this in some platform: when a host > has configured SLAAC, and then M changes from 0 to 1, some hosts just > ignore the M flag (see the second bullet of Appendix A.3). > > > > > > > > However, personally I'm not sure this should be a right behavior. > SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios. > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_ > draft-2Dliu-2Dv6ops-2Drunning-2Dmultiple-2Dprefixes-2D03-23section-2D3. > 1&d=3DAwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoU > WB8YLZU23029sMQGQ2kY&m=3Dm8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4 > OmAPBz0&s=3Ds5I7IrkUrSvi6Ev5mUhvri9GoL2pLI1Z2cWYDTEQOmM&e=3D has > a brief discussion on this. But this draft-ietf-v6ops-dhcpv6-slaac-proble= m > does not intend to discuss what the right behavior should be. > > > > > > > > > What is the value of > > > > > disabling other DHCPv6 configuration? End point instruments need > > > DHCPv6 > > > > > for other configuration information and that shall not be disabled > > > via a > > > > > router (Unless there is a plan to provide all that configuration via = a > router?). > > > > > If there is agreement on this statement, only one flag is needed, 'M'= flag. > > > > [Bing] I can't really answer this question. My guess is that , when the= hosts > can get both address and other configuration information through stateful > DHCPv6 configuration, then the stateless DHCPv6 configuration is redundan= t > if it is always on. > > > > > > > > > This flag would control if end point instruments would have only > > > SLAAC or > > > > > only DHCPv6 address (example: M=3D1 would mean only DHCPv6 address is > > > > > configured and if A=3D1 would mean that DHCPv6 address would have to > > > start > > > > > with the PI prefix). I don't see a need for both SLAAC and DHCPv6 > addresses. > > > > [Bing] As said above, I think co-existing might make sense in some > scenarios. > > > > > > > > Best regards, > > > > Bing > > > > > > > > > > > > > Dusan > > > > > > > > > > -----Original Message----- > > > > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > > > > > Sent: Tuesday, May 12, 2015 4:05 PM > > > > > To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H > > > > > Cc: Lin, Ping (Ping); Steven B.; ipv6@ietf.org; Bernie Volz (volz) > > > > > Subject: Re: Question re. stateless DHCPv6 and 'M' & 'O' flags > > > > > > > > > > Hi Dusan, > > > > > > > > > > The M/O flags are not obsolete. They are defined in RFC 4861. > > > > > > > > > > You might want to read > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _ > > > html_ > > > > > > draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem&d=3DAwIFaQ&c=3DBFpWQ > > > > > > w8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k > > > > > > Y&m=3DAPhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=3DVvC2nQToB > > > > > 51qdh8J7Jlpw-Y3NE3g_JSuooay2fEVu0s&e=3D > > > > > (noting that it is still a draft, discussed in the v6ops WG) and you > > > might move > > > > > this discussion to the v6ops list, too. > > > > > > > > > > Regards > > > > > Brian Carpenter > > > > > > > > > > > > > > > On 13/05/2015 06:53, Mudric, Dusan (Dusan) wrote: > > > > > > Hi Everyone, > > > > > > > > > > > > I would appreciate your help answering the questions regarding the > > > > > stateless DHCPv6 and ???M??? & ???O??? flags: > > > > > > > > > > > > Background: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Following RFC 2462, ???O??? flag in Router Advertisements is used > > > > to start > > > > > stateless DHCPv6 client. When using ???O??? flag, the end point shall > support: > > > > > > > > > > > > ?? RFC > > > > > > 3736 > > > > > org_in-2Dnotes_rfc3736.txt&d=3DAwIFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3D > > > > > > UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DAPhD5Tq7Q9EZ64 > > > > > > eDKTcooJX8vvQdTCdwGe7w--QcC30&s=3DmZkhBdhXoIRGEsK6Z3mfWS4RyvKB > > > > > -IiKhorpXBfnwEY&e=3D > , that defines stateless DHCPv6 client > > > > > > > > > > > > ?? RFC 4242, that defines when the end point should refresh > the > > > > > configuration information. > > > > > > > > > > > > Questions: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > If RFC 4862 removed ???M??? & ???O??? flags and obsoleted RFC 2462 > > > > (that > > > > > defines ???M??? & ???O??? flags), why are the flags not deprecated? > > > What is the > > > > > value of referring to the obsoleted standard, in order to support > > > flags in the > > > > > solution that is not mature? > > > > > > > > > > > > rfc4862#appendix-C > > > > > > o Removed the text regarding the M and O flags, considering > > > > the > > > > > > maturity of implementations and operational experiences. > > > > > > ManagedFlag and OtherConfigFlag were removed accordingly. > > > > > (Note > > > > > > that this change does not mean the use of these flags is > > > > > > deprecated.) > > > > > > > > > > > > In the thread ???Re: Question re. RECONFIG in DHCPv6???, Bernie > stated: > > > > > > ???The RFC 3736 document is really not something I would recommend > > > > > following - see full RFC 3315 and implement those features you need > > > (such > > > > > as only Information-Request and Reply). 3736 was written to > > > demonstrate > > > > > that stateless dhcpv6 was rather simple to implement.??? > > > > > > > > > > > > Based on the fact that ???M??? & ???O??? flags are removed from > > > > the RFC 4862 > > > > > and the statement above, can we say the stateless DHCPv6 is not > > > mandatory > > > > > and, consequently, ???O??? flag is not required? > > > > > > > > > > > > If stateless DHCPv6 is not used, stateful DHCPv6 is required. > Then, ???M??? > > > > > flag is not needed. > > > > > > > > > > > > Regards, > > > > > > Dusan Mudric. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests: > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _ > > > > mail > > > > > > > > > > > > man_listinfo_ipv6&d=3DAwIFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL > > > > > eaJxhf3 > > > > > > > > > > > > iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DAPhD5Tq7Q9EZ64eDKTcooJX8vvQdT > > > > > CdwGe7w--Qc > > > > > > C30&s=3D4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=3D > > > > > > ------------------------------------------------------------------ > > > > -- > > > > > > > > > > > > > > > > _______________________________________________ > > > > > v6ops mailing list > > > > > v6ops@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma > > > > ilman_listinfo_v6ops&d=3DAwIGaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9 > cbLea > > > > Jxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dm8AjAxL16hPwX4stNLi4mxdfBg > 7Uh-KZQ > > > fl4OmAPBz0&s=3DQafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > -- > Enno Rey >=20 > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 > 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 >=20 > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri May 15 04:37:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0E1A0161 for ; Fri, 15 May 2015 04:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBWr3Ch7Eyym for ; Fri, 15 May 2015 04:37:32 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982071A00ED for ; Fri, 15 May 2015 04:37:30 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id CF4806226B; Fri, 15 May 2015 13:37:28 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id ACA09DCE; Fri, 15 May 2015 13:37:28 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 8685AC49CD; Fri, 15 May 2015 13:37:28 +0200 (CEST) Date: Fri, 15 May 2015 13:37:28 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150515113728.GH3028@ernw.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 11:37:34 -0000 All, yesterday's IPv6 WG session at the RIPE meeting saw another debate on extension headers. Pls allow to submit our contribution to v6ops as well. Let me know if you think that the 6man mailing list would be the more appropriate place. Here's some material/sources we'd like to bring up: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= ----- End forwarded message ----- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Fri May 15 13:36:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442B01A1BFA for ; Fri, 15 May 2015 13:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk1VE7t0BK2M for ; Fri, 15 May 2015 13:36:38 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3DE1A0270 for ; Fri, 15 May 2015 13:36:38 -0700 (PDT) Received: by pabru16 with SMTP id ru16so27251018pab.1 for ; Fri, 15 May 2015 13:36:38 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CCRegco97fo2gcqQMQBEYNI6A2C9PV89wxRi6vSh4Ro=; b=vdgS4VsMi3GUNqLRBMnNDhx6InvBq3uFGxhbztQL8WOoCiIGf8d7jHy4bQ11BXb9js H9KNZUXQrnd/rvsoBr1hbI8ErdpFvYjneW60ual3onBWpqzyO+wtr8ZqrBwrDFUMN2lP EHGvWY1WZj3IV+M4uTUqiltAmErjpNV81Y3lk4ZqU13xgXDSy2+J0m7MghKE/mDYRq9C Yy1vWqjh0YPAfIy8+xh2EvIDFDzCBNJUx/0qmbLvmu7Cq99i92G1L8xVVB/Fz2EizBkw Wj84Shfso52Z2JtcRn6pnjxUrs0RyBK3R5eqHU8GfP8A3406Irv2Jgcb512m0kT7R1Va 19fg== X-Received: by 10.68.135.36 with SMTP id pp4mr21754355pbb.134.1431722198325; Fri, 15 May 2015 13:36:38 -0700 (PDT) Received: from ?IPv6:2406:e007:6f4c:1:28cc:dc4c:9703:6781? ([2406:e007:6f4c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id zt9sm2735137pac.9.2015.05.15.13.36.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 13:36:37 -0700 (PDT) Message-ID: <555658DE.6080402@gmail.com> Date: Sat, 16 May 2015 08:36:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Enno Rey , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> In-Reply-To: <20150515113728.GH3028@ernw.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:36:40 -0000 Enno, On 15/05/2015 23:37, Enno Rey wrote: ... > As for the topic itself I'd like to summarize our position as follows: > - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. I object to that logic. Firstly, the timescale is misleading: IPv6 deployment has been so painfully slow that you really can't look at the 17 year span for this argument; it's only within the last 5 years or so that the words "compelling" and "Internet-scale" could be relevant. That's why the obvious issues in RFC 2460 were only fixed in 2013, by the way (RFC 7045). We haven't even had time for those fixes to reach deployment. Secondly, "compelling" is entirely a matter of judgement. There's no possibility of a compelling case for something that is undeployable, and it's well known that because of faulty handling of new extension headers by middleboxes, no new extension headers are deployable today. > - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. Of course you won't, until middleboxes stop breaking them. Extensibility is for the future and unpredictable, by definition. > - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. That is automatically a self-fulfilling prophecy. The new rules in RFC 7045 were carefully constructed to offer a way out of this. I hope your advice is to follow those rules and to insist on products that allow this (correct defaults, for example). > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either). I assume you are following documents like draft-ietf-6man-deprecate-atomfrag-generation, RFC 7112, RFC 6946, etc. It isn't as if the IETF is unaware of the issues. > Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. Well, Moore's law is stll with us, so I think that is plain wrong as products evolve, which is exactly why we should update the standards accordingly. Of course that applies to vendors, not operators. > - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). > - now that "this vicious circle" has gained sufficient ground it will be evfixesen less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. It's possible, but that doesn't mean that the IETF should give up on extensibility. We should continue to mitigate the problems, which is what we've been doing for several years, since they became apparent. Nobody, I think, is arguing that the extensibility design in IPv6 is middlebox-friendly. But that's history and we have to deal with it. Brian From nobody Fri May 15 18:16:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00D1ACAD5 for ; Fri, 15 May 2015 18:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.402 X-Spam-Level: **** X-Spam-Status: No, score=4.402 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRkKc1uMmkjZ for ; Fri, 15 May 2015 18:16:14 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B991ACAD4 for ; Fri, 15 May 2015 18:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431738973; bh=JugUUcIIUzKmMyhTLZvn8idrPHbAiYSnxWFXfPhbt5o=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=nscb+Vj6Iv+wn8185uEg+GmsKrIHb21hwBgYipwTXOV3bxK2wqOyMR1UJ789po5WC0GMp2nxxRppAZhFnMg4pKH8zw966LzmViB+kvA79myaIaCEfgyqUIAEJa2MmQIfSfBqSOsp0fC1qhsMr7tzs2r9uENmF06JhFm+4JyyPm8P1iAVihffRyUUUAJAcA1ttPFzfnJU3zGvcL6EExKpkqmnH6JT1xnajGLhUleFDvEf7fWudkpGOEt95xUsJwMKMcvqcWy2rh2W9iTkVADPw4UZM7F5w0weF++AgfuakWoFkdA5qc73CWxlPdjEGhHEdmdf4A7xvvH7FLYoQzg5ng== Received: from [98.139.170.179] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:16:13 -0000 Received: from [98.139.212.197] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:16:13 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:16:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 265671.62464.bm@omp1006.mail.bf1.yahoo.com X-YMail-OSG: HPKewJAVM1kXxBcvL.Sqr2B.KI.lVxDCnrDbqrAEHQBssufwTj6sdaEBJc8TGwj lnyGxA9huZHW8ENnAvovZwdrspytRS41HA2.9j_vLfWHSSRYRvt_VQyVbo6rBMxbYmNwXbUAinWF R4w6hcjByOZvfVoPOWGpIqUlcTzbrIFxtbvhv3Botr4.Izw21CDi725OGqjFa0riQPexB6sOkAHy R3FMy8zMreWxmESTHIFSC4xNnETNWpgZwy_tu2wz5QzxHLTfP0rht_0NCYjbAozkGpFEz_1.DeLg jmK.WO62IdsqlIqvR2L339SoPgalg36R_x27hHeBevx.RCOHP4ZMWPYs.3nhUb1_uzesHe8q7Jnl QbBes_pX35_ekPycIEomBR2iPqmquwY0ZrFRC0l82iX8SoLaSeDNMfwEukFRv10w3VUu3p9WGCNh JyYuEkxJBHZstlqjoA6YHy2cqQAwjevBG653VdSIqJxuGWlJokMKGATEShgaNgNl40DU9Km1l3wB B8hZLxp9qPS7xpXf1r6fkzcgX4U057WgDUT865Wa8leVgDduqcUA- Received: by 66.196.81.119; Sat, 16 May 2015 01:16:12 +0000 Date: Sat, 16 May 2015 01:16:04 +0000 (UTC) From: Mark ZZZ Smith To: joel jaeggli , "t.petch" , Jens Ott - Opteamax GmbH , "v6ops@ietf.org" Message-ID: <2024854323.39544.1431738964510.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5554DD01.5040708@bogus.com> References: <5554DD01.5040708@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39543_692499850.1431738964503" Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:16:16 -0000 ------=_Part_39543_692499850.1431738964503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: joel jaeggli To: t.petch ; Jens Ott - Opteamax GmbH ; v6ops@ietf.org=20 Sent: Friday, 15 May 2015, 3:36 Subject: Re: [v6ops] Idea about updating RFC3849 =20 I'm pretty sure that growing the example prefix isn't necessary in order to that you might use a prefix with a longer or shorter netmask in a filter.=C2=A0 I wouldn't want to expand it to a /3 just so that I could express the size of the ipv6unicast address range. We don't get into existential peril when we refer to ::/0 so if you have to say,=C2=A0 "design the filter this way example my address space=C2=A0 2001:db8::/32 substituting your prefix and and appropriate leng= th netmask (shorter or longer as necessary) that doesn't seem excessively circuitous. and if=C2=A0 they slavishly copy that prefix or netmask well no harm no foul. / As the focus of this sort of documentation is the lower order bits, you c= ould probably explain the technique you want to convey of dividing up the l= ower order bits using 'X'/'x's in place of the upper portion, with the adva= ntage that 'X'/'x's are invalid in IPv6 addresses, and then possibly use th= e=C2=A02001:db8::/32 to demonstrate the technique. On 5/14/15 9:27 AM, t.petch wrote: > Jens >=20 > I think that there might be a slight procedural issue.=C2=A0 The original= RFC > was produced by the IPv6 Working Group which is responsible for protocol > changes.=C2=A0 This is the v6ops Working Group which is not allowed to ma= ke > protocol changes (but is concerned with making the protocol usable). >=20 > It may not be clearcut, but I would see this as a protocol change and so > one that should be discussed and progressed in the IPv6 WG rather than > here.=C2=A0 The WG Chairs will doubtless arbitrate on this. >=20 > Otherwise, yes but don't stop at /29; I would go for a /8 and allow > myself to be negotiated back to something in between. > . > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Jens Ott - Opteamax GmbH" > To: > Sent: Thursday, May 14, 2015 9:02 AM > Subject: [v6ops] Idea about updating RFC3849 >> >> Hi Mailinglist-Members, >> >> I am pretty new on this list, so I first wave a "Hello" into the >> round... and immediately continue to ask the question, which led me to >> subscribing to this list. Apologies if I chose the wrong list, please >> advise me, where to put my question in this case. >> >> I work as consultant and already accompanied several IPv6 roll-outs >> from the first idea "we want V6" until production. While >> enterprise-setups are mostly /32 or less IPs, I see more and more >> rollouts which need much bigger space. >> >> At least in RIPE-Region, each LIR can receive a /29 without any >> justification. And here is where my problem starts. While writing >> documentation and addressing-plans before requesting the actual prefix >> at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in >> RFC3849. But what to do for bigger nets (lower bitmasks)? >> >> Before starting to push the ball on the field by writing a proposal, >> I'd be happy to hear if there is support in the community for updating >> this rfc and officially define a bigger prefix for documentation. >> >> As said, if I chose the wrong mailinglist or simply started bringing >> my idea into the community in a wrong way, any advise and comment is >> appreciated. I have no experience with the processes at ietf yet. >> >> Best regards and thanks >> - -- >> Jens Ott >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.:=C2=A0 +49 2224 969500 >> Fax:=C2=A0 +49 2224 97691059 >> Email: jo@opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Gesch=C3=A4ftsf=C3=BChrer: Jens Ott >> Umsatzsteuer-ID.: DE264133989 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_39543_692499850.1431738964503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

From: joel jaeggli <joelja@bogus.com>
To: t.petch <ietfc@btconnect.com>= ;; Jens Ott - Opteamax GmbH <jo@opteamax.de>; v6ops@ietf.org
= Sent: Friday, 15 May 2015, 3:= 36
Subject: Re: [v6ops= ] Idea about updating RFC3849

I'm pretty sure that growin= g the example prefix isn't necessary in order
to that you= might use a prefix with a longer or shorter netmask in a
filter.  I wouldn't want to expand it to a /3 just so that I couldexpress the size of the ipv6unicast address range.

We don't get into existential peril when we re= fer to ::/0

so if you have to say,&nbs= p; "design the filter this way example my address
space&n= bsp; 2001:db8::/32 substituting your prefix and and appropriate length
netmask (shorter or longer as necessary) that doesn't seem ex= cessively
circuitous. and if  they slavishly copy th= at prefix or netmask well no
harm no foul.

/ As the focus of this sort of documentation is the lower order bits, yo= u could probably explain the technique you want to convey of dividing up th= e lower order bits using 'X'/'x's in place of the upper portion, with the a= dvantage that 'X'/'x's are invalid in IPv6 addresses, and then possibly use= the 2001:db8::/32 to demonstrate the technique.




On 5/14/15 9:27 AM, t.petch wrote:
> Jens
>
> I think = that there might be a slight procedural issue.  The original RFC
> was produced by the IPv6 Working Group which is responsib= le for protocol
> changes.  This is the v6ops Wor= king Group which is not allowed to make
> protocol cha= nges (but is concerned with making the protocol usable).
= >
> It may not be clearcut, but I would see this a= s a protocol change and so
> one that should be discus= sed and progressed in the IPv6 WG rather than
> here.&= nbsp; The WG Chairs will doubtless arbitrate on this.
>= ;
> Otherwise, yes but don't stop at /29; I would go = for a /8 and allow
> myself to be negotiated back to s= omething in between.
> .
> Tom Pe= tch
>
>
> = ----- Original Message -----
> From: "Jens Ott - Optea= max GmbH" <jo@opteamax.de>
> To: <= ;v6ops@ietf.org>
> Sent: Thursday, May = 14, 2015 9:02 AM
> Subject: [v6ops] Idea about updatin= g RFC3849
>>
>> Hi Mailingl= ist-Members,
>>
>> I am pre= tty new on this list, so I first wave a "Hello" into the
= >> round... and immediately continue to ask the question, which led m= e to
>> subscribing to this list. Apologies if I ch= ose the wrong list, please
>> advise me, where to p= ut my question in this case.
>>
&= gt;> I work as consultant and already accompanied several IPv6 roll-outs=
>> from the first idea "we want V6" until producti= on. While
>> enterprise-setups are mostly /32 or le= ss IPs, I see more and more
>> rollouts which need = much bigger space.
>>
>> At= least in RIPE-Region, each LIR can receive a /29 without any
>> justification. And here is where my problem starts. While wri= ting
>> documentation and addressing-plans before r= equesting the actual prefix
>> at the appropriate R= IR, I'm used to use 2001:db8::/32 as defined in
>> = RFC3849. But what to do for bigger nets (lower bitmasks)?
>>
>> Before starting to push the ball on th= e field by writing a proposal,
>> I'd be happy to h= ear if there is support in the community for updating
>= ;> this rfc and officially define a bigger prefix for documentation.
>>
>> As said, if I chose the = wrong mailinglist or simply started bringing
>> my = idea into the community in a wrong way, any advise and comment is
>> appreciated. I have no experience with the processes at = ietf yet.
>>
>> Best regard= s and thanks
>> - --
>> Jen= s Ott
>>
>> Opteamax GmbH>>
>> Simrockstr. 4b
>> 53619 Rheinbreitbach
>>
>> Tel.:  +49 2224 969500
>> = Fax:  +49 2224 97691059
>> Email: jo@= opteamax.de
>>
>> HRB: = 23144, Amtsgericht Montabaur
>> Gesch=C3=A4ftsf=C3= =BChrer: Jens Ott
>> Umsatzsteuer-ID.: DE264133989<= br clear=3D"none">>
> ____________________________= ___________________
> v6ops mailing list
> v6ops@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/v6ops
>


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


------=_Part_39543_692499850.1431738964503-- From nobody Fri May 15 18:22:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C91ACD61 for ; Fri, 15 May 2015 18:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu3mVviAA9CY for ; Fri, 15 May 2015 18:22:29 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64FE1ACCE4 for ; Fri, 15 May 2015 18:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1431739347; bh=inFLHciXv4sK3Ze9lw/h1RRh7ugX1hG6/gzz1ANQHRM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=VUGEWHE4xrA7As2wFz/YA5gjVDQoLmQJZ9qQ55MOAm+CjI8h6LoHxOQEnCSJSYS2peWEy36SNMu6W7Yzqf5Vz9vAxLEalpQfKcThJ/TaNBHDNuI+WDvxwhqCaOP8q1RvA/5KaSTNdaygFujm/yDljsWHDdk6A7P7AgnNvOayf2CwksMTId6LPe6nXTZa6JpnQYbj94GLHAEfmGcsrvfRh3ApeFuglrqFHTYx/Oh3fA7htelSn9E97IhxVVKRa3Zhre7KVlRmh8u/6Q8fg59XdMlE+eFGU+K0jwLEsCWsSgnnrFVFBIu0AcRzbGsicWZkrd/YyzuyPO349Zb/3rwmLA== Received: from [98.139.170.181] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:22:27 -0000 Received: from [98.139.212.249] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:22:27 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 16 May 2015 01:22:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 718393.38234.bm@omp1058.mail.bf1.yahoo.com X-YMail-OSG: JAct0FcVM1n5QcF5Yyps.J22tMYzms5AK592DFEMc8GeHy.pWSQwZeMaEiGhjMd YMk0NmLBD2OJvEkX2A.UPsf3zkoAP47PbONX.OxUdXAvIo8X67UdhIgF2L0CjQEik06ov7PlrW9P ak.MDocXZNfz4ahRIpC9aJLOMwD7vOnT51xwf9hl98i_aiM8F11h_LJmSVVVXoh34ymV5bYjbow. EezVKu6zy6Z5XuD2OX.aduVegh3l7Xx5I3P3pTdxbZTov9fiTTHrIvpMU2XDv3R3jUP9YNHqcheu .sMEtZ6fEKyktFGJO_HYrpu0_BWpuE2xbIwnBwNNqYPJdSMC5hrNi_lrpHD7yjRHH_9bzTXqCIEa bBKVGitxyKWFUbe5s2E_t9qozzEhk_DKKgJ9gpREFvTSXHYYur8138PWMrhi5UmKM7u.r7d09G2d kUWgrIZ2655DxO1Pphkeykp1iy7aK3XyEBDkaurXQOQMdqY1ozCCgKJgpRwbvZ.fINkSx.kU7Yzl 67c1_VBR4xabj0QVdKoa_bj2Ra.MMilC4Uqfli5yVGVFRgH8wuw-- Received: by 76.13.27.69; Sat, 16 May 2015 01:22:27 +0000 Date: Sat, 16 May 2015 01:22:26 +0000 (UTC) From: Mark ZZZ Smith To: Enno Rey , "v6ops@ietf.org" Message-ID: <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150515113728.GH3028@ernw.de> References: <20150515113728.GH3028@ernw.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_793_1722314160.1431739346718" Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:22:31 -0000 ------=_Part_793_1722314160.1431739346718 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit So quickly, how have IPv4 options been handled? They too can vary the location of the TCP/UDP etc. headers in an IPv4 packet. How have the variety and variable number of TCP options been handled? They too can vary the location of the TCP segment payload. IOW, I don't think is a new problem exclusive to IPv6, so I think the IPv4 methods used to overcome packet header location variations should be reviewed/considered for applicability to IPv6. How are you going to handle encryption of payloads and techniques such as multipath TCP when trying to do host and application security in the network rather than on the hosts? From: Enno Rey To: v6ops@ietf.org Sent: Friday, 15 May 2015, 21:37 Subject: [v6ops] Extension Headers / Impact on Security Devices All, yesterday's IPv6 WG session at the RIPE meeting saw another debate on extension headers. Pls allow to submit our contribution to v6ops as well. Let me know if you think that the 6man mailing list would be the more appropriate place. Here's some material/sources we'd like to bring up: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= ----- End forwarded message ----- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_793_1722314160.1431739346718 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So quickly, how ha= ve IPv4 options been handled? They too can vary the location of the TCP/UDP= etc. headers in an IPv4 packet. How have the variety and variable number o= f TCP options been handled? They too can vary the location of the TCP segme= nt payload.
<= br>
IOW, I don't think is a new probl= em exclusive to IPv6, so I think the IPv4 methods used to overcome packet h= eader location variations should be reviewed/considered for applicability t= o IPv6.

How are you going to hand= le encryption of payloads and techniques such as multipath TCP when trying = to do host and application security in the network rather than on the hosts= ?

<= /div>
From: Enno Rey <erey@ernw.de>
To: v6ops@ietf.org
Sent: Friday, 15 May 2015, 21:37<= br> Subject: [v6ops] Exten= sion Headers / Impact on Security Devices

All,

yes= terday's IPv6 WG session at the RIPE meeting saw another debate on extensio= n headers.
Pls allow to submit our contribution to v6ops as well. Let me= know if you think that the 6man mailing list would be the more appropriate= place.

Here's some material/sources we'd like to bring up:

-= this is a paper laying out how we could circumvent some major (both commer= cial and FOSS) IDPS solutions in their at the time of testing latest versio= ns, by various combinations of extension headers and fragmentation:
http= s://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-Hi= ghEnd-IPS-Devices-wp.pdf.

- here's some thoughts and preliminary res= ults of tests performed to circumvent stateless ACLs:
http://www.insinua= tor.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigat= ion-techniques/.
http://www.insinuator.net/2015/01/the-persistent-proble= m-of-state-in-ipv6-security/.

We have a (somewhat) ongoing research = project looking more closely on the interaction of ACLs and extension heade= rs. For the moment I can only state that it's not just Cisco who are "affec= ted". More results will be available in some months.

As for the topi= c itself I'd like to summarize our position as follows:
- it has not hap= pened in the past 17 yrs (since publication of RFC2460) that compelling, In= ternet-scale use cases of extension headers have been brought up.
- we'r= e hence quite sceptical as for the "we might see cool use cases in 15-20 yr= s" position someone expressed at the mic.
- from a security perspective = they turn out to be a nightmare for (a number of) current security architec= tures and controls. it is hence understandable (and we actually advise to d= o so) that they are blocked at the _border_ of networks that have not yet m= anaged to identify a compelling use case.
- looking at the "liberty" RFC= 2460 provides as for ext_hdrs (wrt to their number, order, options, fragmen= table vs. unfragmentable part etc.) we do not expect that type of security = issues to disappear soon (the main reason why we did not continue the IDPS = research was that the involved student eventually delivered his thesis. one= can probably find much more issues provided time & resources. followin= g LANGSEC it might be impossible to "fix" all of them either).
Adding mo= re parsing cycles & intelligence (read: silicon) is not an option, at l= east not for sth that doesn't have a use case.
- the results of this (bl= ocking) approach have been observed and documented by Jen & Fernando an= d others (Tim Chown).
- now that "this vicious circle" has gained suffic= ient ground it will be even less incentivized to develop a compelling use c= ase. which is why we do not expect to see one in the future.

=3D=3D= =3D

Everybody have a great weekend

Best

Enno



--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heid= elberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 1= 73 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehre= r: Enno Rey

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Blog: www.insinuator.net || Confere= nce: www.troopers.de
Twitter: @Enno_Insinuator
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 forwarded message -----

--
Enno Rey

ERNW GmbH= - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 4803= 90 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannhei= m: HRB 337135
Geschaeftsfuehrer: Enno Rey

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bl= og: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Ins= inuator
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

________________________________________= _______
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailma= n/listinfo/v6ops


------=_Part_793_1722314160.1431739346718-- From nobody Sat May 16 04:21:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5C41A6FEE for ; Sat, 16 May 2015 04:21:32 -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=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_7wgoLy21u3 for ; Sat, 16 May 2015 04:21:29 -0700 (PDT) Received: from mail.opteamax.de (mail.opteamax.de [194.62.23.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC141A0545 for ; Sat, 16 May 2015 04:21:29 -0700 (PDT) Received: (qmail 4041 invoked from network); 16 May 2015 11:47:17 -0000 Received: from ip-109-44-2-14.web.vodafone.de (HELO ?10.157.152.154?) (jo@opteamax.de@109.44.2.14) by mail.opteamax.de with ESMTPA; 16 May 2015 11:47:17 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <5554DD01.5040708@bogus.com> References: <55545683.6070202@opteamax.de> <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> <5554DD01.5040708@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WULIAUBJ31I6XUCOJGJF55TL1EKEGQ" Content-Transfer-Encoding: 8bit From: Jens Ott - Opteamax GmbH Date: Sat, 16 May 2015 13:21:24 +0200 To: joel jaeggli , "t.petch" , v6ops@ietf.org Message-ID: <274D59F3-D4C5-48EE-BED0-736FFA35FA3D@opteamax.de> Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 11:21:32 -0000 ------WULIAUBJ31I6XUCOJGJF55TL1EKEGQ Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi, extending to /3 is not the idea, but there are lot's of cases where e.g. /16 reserved space would make sense. You'd be surprised, how often people simply copy+paste examples in workshops, actually I was really surprised when I saw 666::/26 in a bunch of looking glasses during a workshop I attended last year. So obviously filtering seems to be less used as you might think. As long as people use non allocated addressspace, there is no harm and no issue, the project which led me to write this idea, was using actually assigned and active IPs and then harm can occur quickly for the actual owners... you remember the more specific announcements of Google prefixes some month ago? And yes, I also know that the pure existence of an RFC does not mean, everybody adopts it, but I am also sure if this existence is promoted a little, it will reduce the risk of accidentally copy+pasted harm. BR and have a nice weekend Jens PS: Sorry for tofu, writing on my mobile and for unknown reason my mua did refuse to edit inside quotation. Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli : >I'm pretty sure that growing the example prefix isn't necessary in >order >to that you might use a prefix with a longer or shorter netmask in a >filter. I wouldn't want to expand it to a /3 just so that I could >express the size of the ipv6unicast address range. > >We don't get into existential peril when we refer to ::/0 > >so if you have to say, "design the filter this way example my address >space 2001:db8::/32 substituting your prefix and and appropriate >length >netmask (shorter or longer as necessary) that doesn't seem excessively >circuitous. and if they slavishly copy that prefix or netmask well no >harm no foul. > >On 5/14/15 9:27 AM, t.petch wrote: >> Jens >> >> I think that there might be a slight procedural issue. The original >RFC >> was produced by the IPv6 Working Group which is responsible for >protocol >> changes. This is the v6ops Working Group which is not allowed to >make >> protocol changes (but is concerned with making the protocol usable). >> >> It may not be clearcut, but I would see this as a protocol change and >so >> one that should be discussed and progressed in the IPv6 WG rather >than >> here. The WG Chairs will doubtless arbitrate on this. >> >> Otherwise, yes but don't stop at /29; I would go for a /8 and allow >> myself to be negotiated back to something in between. >> . >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Jens Ott - Opteamax GmbH" >> To: >> Sent: Thursday, May 14, 2015 9:02 AM >> Subject: [v6ops] Idea about updating RFC3849 >>> >>> Hi Mailinglist-Members, >>> >>> I am pretty new on this list, so I first wave a "Hello" into the >>> round... and immediately continue to ask the question, which led me >to >>> subscribing to this list. Apologies if I chose the wrong list, >please >>> advise me, where to put my question in this case. >>> >>> I work as consultant and already accompanied several IPv6 roll-outs >>> from the first idea "we want V6" until production. While >>> enterprise-setups are mostly /32 or less IPs, I see more and more >>> rollouts which need much bigger space. >>> >>> At least in RIPE-Region, each LIR can receive a /29 without any >>> justification. And here is where my problem starts. While writing >>> documentation and addressing-plans before requesting the actual >prefix >>> at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in >>> RFC3849. But what to do for bigger nets (lower bitmasks)? >>> >>> Before starting to push the ball on the field by writing a proposal, >>> I'd be happy to hear if there is support in the community for >updating >>> this rfc and officially define a bigger prefix for documentation. >>> >>> As said, if I chose the wrong mailinglist or simply started bringing >>> my idea into the community in a wrong way, any advise and comment is >>> appreciated. I have no experience with the processes at ietf yet. >>> >>> Best regards and thanks >>> - -- >>> Jens Ott >>> >>> Opteamax GmbH >>> >>> Simrockstr. 4b >>> 53619 Rheinbreitbach >>> >>> Tel.: +49 2224 969500 >>> Fax: +49 2224 97691059 >>> Email: jo@opteamax.de >>> >>> HRB: 23144, Amtsgericht Montabaur >>> Geschäftsführer: Jens Ott >>> Umsatzsteuer-ID.: DE264133989 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > >------------------------------------------------------------------------ > >!DSPAM:637,5554e2db213971574413910! -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------WULIAUBJ31I6XUCOJGJF55TL1EKEGQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

extending to /3 is not the idea, but there are lot's of cases where e.g. /16 reserved space would make sense. You'd be surprised, how often people simply copy+paste examples in workshops, actually I was really surprised when I saw 666::/26 in a bunch of looking glasses during a workshop I attended last year.

So obviously filtering seems to be less used as you might think. As long as people use non allocated addressspace, there is no harm and no issue, the project which led me to write this idea, was using actually assigned and active IPs and then harm can occur quickly for the actual owners... you remember the more specific announcements of Google prefixes some month ago?

And yes, I also know that the pure existence of an RFC does not mean, everybody adopts it, but I am also sure if this existence is promoted a little, it will reduce the risk of accidentally copy+pasted harm.

BR and have a nice weekend
Jens

PS: Sorry for tofu, writing on my mobile and for unknown reason my mua did refuse to edit inside quotation.

Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli <joelja@bogus.com>:
I'm pretty sure that growing the example prefix isn't necessary in order
to that you might use a prefix with a longer or shorter netmask in a
filter.  I wouldn't want to expand it to a /3 just so that I could
express the size of the ipv6unicast address range.

We don't get into existential peril when we refer to ::/0

so if you have to say,  "design the filter this way example my address
space  2001:db8::/32 substituting your prefix and and appropriate length
netmask (shorter or longer as necessary) that doesn't seem excessively
circuitous. and if  they slavishly copy that prefix or netmask well no
harm no foul.

On 5/14/15 9:27 AM, t.petch wrote:
 Jens
 
 I think that there might be a slight procedural issue.  The original RFC
 was produced by the IPv6 Working
Group which is responsible for protocol
 changes.  This is the v6ops Working Group which is not allowed to make
 protocol changes (but is concerned with making the protocol usable).
 
 It may not be clearcut, but I would see this as a protocol change and so
 one that should be discussed and progressed in the IPv6 WG rather than
 here.  The WG Chairs will doubtless arbitrate on this.
 
 Otherwise, yes but don't stop at /29; I would go for a /8 and allow
 myself to be negotiated back to something in between.
 .
 Tom Petch
 
 
 ----- Original Message -----
 From: "Jens Ott - Opteamax GmbH" <jo@opteamax.de>
 To: <v6ops@ietf.org>
 Sent: Thursday, May 14, 2015 9:02 AM
 Subject: [v6ops] Idea about updating RFC3849

 Hi Mailinglist-Members,

 I am pretty
new on this list, so I first wave a "Hello" into the
 round... and immediately continue to ask the question, which led me to
 subscribing to this list. Apologies if I chose the wrong list, please
 advise me, where to put my question in this case.

 I work as consultant and already accompanied several IPv6 roll-outs
 from the first idea "we want V6" until production. While
 enterprise-setups are mostly /32 or less IPs, I see more and more
 rollouts which need much bigger space.

 At least in RIPE-Region, each LIR can receive a /29 without any
 justification. And here is where my problem starts. While writing
 documentation and addressing-plans before requesting the actual prefix
 at the appropriate RIR, I'm used to use 2001:db8::/32 as defined in
 RFC3849. But what to do for bigger nets (lower bitmasks)?

 Before starting to push the ball on the field by writing a proposal,
 I'd be happy to hear if
there is support in the community for updating
 this rfc and officially define a bigger prefix for documentation.

 As said, if I chose the wrong mailinglist or simply started bringing
 my idea into the community in a wrong way, any advise and comment is
 appreciated. I have no experience with the processes at ietf yet.

 Best regards and thanks
 - --
 Jens Ott

 Opteamax GmbH

 Simrockstr. 4b
 53619 Rheinbreitbach

 Tel.:  +49 2224 969500
 Fax:   +49 2224 97691059
 Email: jo@opteamax.de

 HRB: 23144, Amtsgericht Montabaur
 Geschäftsführer: Jens Ott
 Umsatzsteuer-ID.: DE264133989
 

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


!DSPAM:637,5554e2db213971574413910!

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------WULIAUBJ31I6XUCOJGJF55TL1EKEGQ-- From nobody Sat May 16 05:56:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3F41A06E9 for ; Sat, 16 May 2015 05:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWJbmX5x2owa for ; Sat, 16 May 2015 05:56:29 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 852DE1A0100 for ; Sat, 16 May 2015 05:56:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D569140175; Sat, 16 May 2015 14:56:28 +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 1RvCySHnLg1J; Sat, 16 May 2015 14:56:26 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E9C0B4009C; Sat, 16 May 2015 14:56:25 +0200 (CEST) Message-ID: <55573E78.4090603@globis.net> Date: Sat, 16 May 2015 14:56:24 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Ackermann, Michael" References: <555112D8.3000008@gmail.com> <4FC37E442D05A748896589E468752CAA0CDD4E69@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CDD4E69@PWN401EA160.ent.corp.bcbsm.com> Content-Type: multipart/alternative; boundary="------------050601050208030206000109" Archived-At: Cc: v6ops list , Philip Matthews Subject: Re: [v6ops] EIGRP and the Design Choices draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 12:56:31 -0000 This is a multi-part message in MIME format. --------------050601050208030206000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ackermann, Michael wrote: > As perhaps one of the individuals responsible for this idea. I realize EIGRP is proprietary protocol and therefore possibly not appropriate for IETF consideration. > But the reason I would even ask, is that EIGRP deployment within Enterprise/Corporate Networks, is nearly ubiquitous. These are the same large networks that need guidance and motivation to get serious about IPv6 deployment. Optimal configuration of the primary routing protocol, in dual stack environments, is likely to be a significant success factor. Providing related information and experiences could give us E/C Networks one less reason to delay IPv6 deployments, which is what most of us are doing currently. > So although I understand the potential inappropriateness, please consider this a call for help from those of us trying to evangelize IPv6 in corporate networks. +1 IMHO Having the IETF recommending proprietary protocols is entirely different from documenting operational experience of whether they will work nicely together with IETF standard protocols or not, and/or how to migrate to/ introduce said "standard track" solutions in place of the proprietary one. My most recent project just turned off the last EIGRP connection to a particular data centre (replaced with eBGP), almost twenty years after I first introduced EIGRP there ..... and I know there's plenty of EIGRP still around elsewhere. > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Monday, May 11, 2015 4:37 PM > To: Philip Matthews; v6ops list > Subject: Re: [v6ops] EIGRP and the Design Choices draft > > On 12/05/2015 03:38, Philip Matthews wrote: >> Folks: >> >> Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP. > > If I'm not mistaken, that's a proprietary protocol that isn't even described in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I think you need to explain *why* it's appropriate to do this in an IETF stream draft. > > If you go ahead, I would suggest putting this topic in an appendix. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > > --------------050601050208030206000109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Ackermann, Michael wrote: 
As perhaps one of the individuals responsible for this idea.   I realize EIGRP is proprietary protocol and therefore possibly not appropriate for IETF consideration.  
But the reason I would even ask, is that EIGRP deployment within Enterprise/Corporate Networks, is nearly ubiquitous.   These are the same large networks that need guidance and motivation to get serious about IPv6 deployment.   Optimal configuration of the primary routing protocol, in dual stack environments,  is likely to be a significant success factor.   Providing related information and experiences could give us E/C Networks one less reason to delay IPv6 deployments, which is what most of us are doing currently.  
So although I understand the potential inappropriateness,  please consider this a call for help from those of us trying to evangelize IPv6 in corporate networks.
+1

IMHO Having the IETF recommending proprietary protocols is entirely different from documenting operational experience of whether they will work nicely together with IETF standard protocols or not, and/or how to migrate to/ introduce said "standard track" solutions in place of the proprietary one.

My most recent project just turned off the last EIGRP connection to a particular data centre (replaced with eBGP), almost twenty years after I first introduced EIGRP there ..... and I know there's plenty of EIGRP still around elsewhere.
 

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Monday, May 11, 2015 4:37 PM
To: Philip Matthews; v6ops list
Subject: Re: [v6ops] EIGRP and the Design Choices draft

On 12/05/2015 03:38, Philip Matthews wrote:

Folks:

Victor and I have been talking with the chairs about the Design Choices draft, and have convinced us act on a request from Michael Ackermann to extend the Design Choices draft to cover EIGRP.


If I'm not mistaken, that's a proprietary protocol that isn't even described in an RFC (although there seems to be a stalled draft under consideration as an Independent Submission RFC). While I don't object to describing reality, I think you need to explain *why* it's appropriate to do this in an IETF stream draft.

If you go ahead, I would suggest putting this topic in an appendix.

    Brian

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


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
--------------050601050208030206000109-- From nobody Sat May 16 10:06:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67EB1A9094 for ; Sat, 16 May 2015 10:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.2 X-Spam-Level: *** X-Spam-Status: No, score=3.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWMkO7s1NVxN for ; Sat, 16 May 2015 10:06:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465F51A8700 for ; Sat, 16 May 2015 10:06:51 -0700 (PDT) Received: from CO2PR04MB586.namprd04.prod.outlook.com (10.141.196.145) by CO2PR04MB665.namprd04.prod.outlook.com (10.141.199.11) with Microsoft SMTP Server (TLS) id 15.1.154.19; Sat, 16 May 2015 17:06:31 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB586.namprd04.prod.outlook.com (10.141.196.145) with Microsoft SMTP Server (TLS) id 15.1.154.19; Sat, 16 May 2015 17:06:30 +0000 Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0154.018; Sat, 16 May 2015 17:06:30 +0000 From: "Metzler, Dan J" To: Jens Ott - Opteamax GmbH , joel jaeggli , t.petch , "v6ops@ietf.org" Thread-Topic: [v6ops] Idea about updating RFC3849 Thread-Index: AQHQjhxRY7454+MUGkC6nvHLyMUMvp17sT9XgAALa4CAArv/AIAAVD0A Date: Sat, 16 May 2015 17:06:29 +0000 Message-ID: References: <55545683.6070202@opteamax.de> <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> <5554DD01.5040708@bogus.com> <274D59F3-D4C5-48EE-BED0-736FFA35FA3D@opteamax.de> In-Reply-To: <274D59F3-D4C5-48EE-BED0-736FFA35FA3D@opteamax.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: opteamax.de; dkim=none (message not signed) header.d=none; x-originating-ip: [67.55.230.66] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB586; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB665; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO2PR04MB586; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB586; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(51164003)(51444003)(24454002)(164054003)(377454003)(252514010)(13464003)(16236675004)(86362001)(99286002)(106116001)(40100003)(75432002)(561944003)(19625215002)(66066001)(54356999)(76176999)(76576001)(50986999)(62966003)(77156002)(19617315012)(90282001)(15975445007)(2900100001)(102836002)(93886004)(2950100001)(77096005)(5001770100001)(2501003)(88552001)(46102003)(122556002)(19580405001)(33656002)(89122001)(74316001)(92566002)(19300405004)(5001960100002)(5001920100001)(19580395003)(87936001)(19609705001)(2656002)(107886002)(189998001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB586; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR04MB585B94F567395BBBD771768FEC60CO2PR04MB585namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2015 17:06:29.3517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB586 X-OriginatorOrg: uiowa.edu Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 17:06:55 -0000 --_000_CO2PR04MB585B94F567395BBBD771768FEC60CO2PR04MB585namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFkbWl0dGVkbHkgbXkgcHJvZmVzc2lvbiBpcyBub3QgZG9jdW1lbnRhdGlvbiwgYnV0 IG15IGluaXRpYWwgb3BpbmlvbiBpcyBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXMsIGlmIHlv deKAmXJlIGFkdm9jYXRpbmcgd2UgdGFrZSBtb3JlIElQdjYgYWRkcmVzcyBzcGFjZSBvdXQgb2Yg dXNlIGZvciBkb2N1bWVudGF0aW9uLg0KDQpJIGRvbuKAmXQgdGhpbmsgZXhhbXBsZSBkb2N1bWVu dGF0aW9uIG5lZWRzIHRvIG1hdGNoIGV4YWN0bHksIGV2ZXJ5IGNvbmNlaXZhYmxlIHByZWZpeCBs ZW5ndGggZm9yIGV2ZXJ5IHBvc3NpYmxlIHNjZW5hcmlvLiAgVGhlIGlkZWEgYmVoaW5kIGV4YW1w bGVzIGlzIHRvIGdpdmUgYSBnZW5lcmFsIGlkZWEsIGFuZCB0aGVuIGlmIG5lY2Vzc2FyeSBleHBs YWluIHRoYXQgb25lIG1pZ2h0IHVzZSBkaWZmZXJlbnQgbGVuZ3RocywgcGVyaGFwcyBhcyBzbWFs bCBhcyB4IG9yIGFzIGxhcmdlIGFzIHkuDQpUaGVyZSBhcmUgb3RoZXIgdHlwZXMgb2YgZG9jdW1l bnRhdGlvbiwgdGhhdCBzaG91bGQgYmUgdGFrZW4gbGl0ZXJhbGx5LCBiZWNhdXNlIHNwZWNpZmlj IGZpbHRlcnMgYXJlIGJlaW5nIGRvY3VtZW50ZWQsIG9yIHNwZWNpZmljIG5ldHdvcmtzIGFyZSBi ZWluZyBkb2N1bWVudGVkLiAgSW4gdGhvc2Ugc2l0dWF0aW9ucywgeW91IGFyZW7igJl0IHVzaW5n IHRoZSBhZGRyZXNzIHNwYWNlIHJlc2VydmVkIGZvciBkb2N1bWVudGF0aW9uLg0KDQpXaXRoIHJl Z2FyZCB0byB5b3VyIHNwZWNpZmljIGV4YW1wbGU6DQrigJxXaGlsZSB3cml0aW5nIGRvY3VtZW50 YXRpb24gYW5kIGFkZHJlc3NpbmctcGxhbnMgYmVmb3JlIHJlcXVlc3RpbmcgdGhlIGFjdHVhbCBw cmVmaXggYXQgdGhlIGFwcHJvcHJpYXRlIFJJUiwgSSdtIHVzZWQgdG8gdXNlIDIwMDE6ZGI4Ojov MzIgYXMgZGVmaW5lZCBpbg0KUkZDMzg0OS4gQnV0IHdoYXQgdG8gZG8gZm9yIGJpZ2dlciBuZXRz IChsb3dlciBiaXRtYXNrcyk/4oCdDQpJIHdvdWxkIGp1c3Qga2VlcCBkb2luZyBhcyB5b3UgaGF2 ZSwgYnV0IG1ha2UgYSBub3RlIHRoYXQgYSAvMjkgd291bGQgYmUgdXNlZCBpbnN0ZWFkLCBpZiB0 aGF0IGlzIHlvdXIgaW50ZW50LCBhbmQgZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGUgZXhhbXBsZSwg bm90ZSB0aGF0IHlvdSBtYWRlIGFsbCBvZiB5b3VyIHByZWZpeGVzIDMgYml0cyBsb25nZXIuICBX aGVuIHRoZSBhY3R1YWwgYXNzaWdubWVudCBpcyBtYWRlLCB0aGF04oCZcyB3aGVuIHlvdSBzdGFy dCBkb2N1bWVudGluZyBhY3R1YWwgcHJlZml4IGxlbmd0aHMsIGFuZCBtb3ZlIG91dCBvZiB0aGUg cmVzZXJ2ZWQgZG9jdW1lbnRhdGlvbiBhZGRyZXNzIHNwYWNlLg0KDQpBdCBhIGNlcnRhaW4gcG9p bnQgaXQgYmVjb21lcyB3YXN0ZWZ1bCB0byB0YWtlIHJlbGF0aXZlbHkgbGFyZ2UgYW1vdW50cyBv ZiBhZGRyZXNzIHNwYWNlIG91dCBvZiBhY3RpdmUgdXNlLCBmb3IgdXNlIGNhc2VzIGxpa2UgZG9j dW1lbnRhdGlvbi4gIFdoZXJlIHRoYXQgbGluZSBpcyBkcmF3biwgaXMgYWx3YXlzIHN1YmplY3Rp dmUsIGFuZCBJIGtub3cgaXTigJlzIElQdjYsIGJ1dCBJ4oCZbSBzdXJlLCBhdCBsZWFzdCBkdXJp bmcgbXkgY29sbGVnZSB5ZWFycywgbm9ib2R5IHRob3VnaHQgd2XigJlkIGV2ZXIgcnVuIG91dCBv ZiBJUHY0IGFkZHJlc3Mgc3BhY2UgZWl0aGVyLg0KDQpUaGFua3MsDQoNCg0KLSAgICAgICAgICBE YW4gTWV0emxlcg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKZW5zIE90dCAtIE9wdGVhbWF4IEdtYkgNClNlbnQ6IFNhdHVyZGF5LCBN YXkgMTYsIDIwMTUgNjoyMSBBTQ0KVG86IGpvZWwgamFlZ2dsaTsgdC5wZXRjaDsgdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIElkZWEgYWJvdXQgdXBkYXRpbmcgUkZDMzg0OQ0K DQpIaSwNCg0KZXh0ZW5kaW5nIHRvIC8zIGlzIG5vdCB0aGUgaWRlYSwgYnV0IHRoZXJlIGFyZSBs b3QncyBvZiBjYXNlcyB3aGVyZSBlLmcuIC8xNiByZXNlcnZlZCBzcGFjZSB3b3VsZCBtYWtlIHNl bnNlLiBZb3UnZCBiZSBzdXJwcmlzZWQsIGhvdyBvZnRlbiBwZW9wbGUgc2ltcGx5IGNvcHkrcGFz dGUgZXhhbXBsZXMgaW4gd29ya3Nob3BzLCBhY3R1YWxseSBJIHdhcyByZWFsbHkgc3VycHJpc2Vk IHdoZW4gSSBzYXcgNjY2OjovMjYgaW4gYSBidW5jaCBvZiBsb29raW5nIGdsYXNzZXMgZHVyaW5n IGEgd29ya3Nob3AgSSBhdHRlbmRlZCBsYXN0IHllYXIuDQoNClNvIG9idmlvdXNseSBmaWx0ZXJp bmcgc2VlbXMgdG8gYmUgbGVzcyB1c2VkIGFzIHlvdSBtaWdodCB0aGluay4gQXMgbG9uZyBhcyBw ZW9wbGUgdXNlIG5vbiBhbGxvY2F0ZWQgYWRkcmVzc3NwYWNlLCB0aGVyZSBpcyBubyBoYXJtIGFu ZCBubyBpc3N1ZSwgdGhlIHByb2plY3Qgd2hpY2ggbGVkIG1lIHRvIHdyaXRlIHRoaXMgaWRlYSwg d2FzIHVzaW5nIGFjdHVhbGx5IGFzc2lnbmVkIGFuZCBhY3RpdmUgSVBzIGFuZCB0aGVuIGhhcm0g Y2FuIG9jY3VyIHF1aWNrbHkgZm9yIHRoZSBhY3R1YWwgb3duZXJzLi4uIHlvdSByZW1lbWJlciB0 aGUgbW9yZSBzcGVjaWZpYyBhbm5vdW5jZW1lbnRzIG9mIEdvb2dsZSBwcmVmaXhlcyBzb21lIG1v bnRoIGFnbz8NCg0KQW5kIHllcywgSSBhbHNvIGtub3cgdGhhdCB0aGUgcHVyZSBleGlzdGVuY2Ug b2YgYW4gUkZDIGRvZXMgbm90IG1lYW4sIGV2ZXJ5Ym9keSBhZG9wdHMgaXQsIGJ1dCBJIGFtIGFs c28gc3VyZSBpZiB0aGlzIGV4aXN0ZW5jZSBpcyBwcm9tb3RlZCBhIGxpdHRsZSwgaXQgd2lsbCBy ZWR1Y2UgdGhlIHJpc2sgb2YgYWNjaWRlbnRhbGx5IGNvcHkrcGFzdGVkIGhhcm0uDQoNCkJSIGFu ZCBoYXZlIGEgbmljZSB3ZWVrZW5kDQpKZW5zDQoNClBTOiBTb3JyeSBmb3IgdG9mdSwgd3JpdGlu ZyBvbiBteSBtb2JpbGUgYW5kIGZvciB1bmtub3duIHJlYXNvbiBteSBtdWEgZGlkIHJlZnVzZSB0 byBlZGl0IGluc2lkZSBxdW90YXRpb24uDQpBbSAxNC4gTWFpIDIwMTUgMTk6MzY6MDEgTUVTWiwg c2NocmllYiBqb2VsIGphZWdnbGkgPGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1 cy5jb20+PjoNCg0KSSdtIHByZXR0eSBzdXJlIHRoYXQgZ3Jvd2luZyB0aGUgZXhhbXBsZSBwcmVm aXggaXNuJ3QgbmVjZXNzYXJ5IGluIG9yZGVyDQp0byB0aGF0IHlvdSBtaWdodCB1c2UgYSBwcmVm aXggd2l0aCBhIGxvbmdlciBvciBzaG9ydGVyIG5ldG1hc2sgaW4gYQ0KZmlsdGVyLiAgSSB3b3Vs ZG4ndCB3YW50IHRvIGV4cGFuZCBpdCB0byBhIC8zIGp1c3Qgc28gdGhhdCBJIGNvdWxkDQpleHBy ZXNzIHRoZSBzaXplIG9mIHRoZSBpcHY2dW5pY2FzdCBhZGRyZXNzIHJhbmdlLg0KDQpXZSBkb24n dCBnZXQgaW50byBleGlzdGVudGlhbCBwZXJpbCB3aGVuIHdlIHJlZmVyIHRvIDo6LzANCg0Kc28g aWYgeW91IGhhdmUgdG8gc2F5LCAgImRlc2lnbiB0aGUgZmlsdGVyIHRoaXMgd2F5IGV4YW1wbGUg bXkgYWRkcmVzcw0Kc3BhY2UgIDIwMDE6ZGI4OjovMzIgc3Vic3RpdHV0aW5nIHlvdXIgcHJlZml4 IGFuZCBhbmQgYXBwcm9wcmlhdGUgbGVuZ3RoDQpuZXRtYXNrIChzaG9ydGVyIG9yIGxvbmdlciBh cyBuZWNlc3NhcnkpIHRoYXQgZG9lc24ndCBzZWVtIGV4Y2Vzc2l2ZWx5DQpjaXJjdWl0b3VzLiBh bmQgaWYgIHRoZXkgc2xhdmlzaGx5IGNvcHkgdGhhdCBwcmVmaXggb3IgbmV0bWFzayB3ZWxsIG5v DQpoYXJtIG5vIGZvdWwuDQoNCk9uIDUvMTQvMTUgOToyNyBBTSwgdC5wZXRjaCB3cm90ZToNCg0K IEplbnMNCg0KIEkgdGhpbmsgdGhhdCB0aGVyZSBtaWdodCBiZSBhIHNsaWdodCBwcm9jZWR1cmFs IGlzc3VlLiAgVGhlIG9yaWdpbmFsIFJGQw0KIHdhcyBwcm9kdWNlZCBieSB0aGUgSVB2NiBXbyEN Cg0KIHJraW5nDQoNCkdyb3VwIHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBwcm90b2NvbA0KIGNo YW5nZXMuICBUaGlzIGlzIHRoZSB2Nm9wcyBXb3JraW5nIEdyb3VwIHdoaWNoIGlzIG5vdCBhbGxv d2VkIHRvIG1ha2UNCiBwcm90b2NvbCBjaGFuZ2VzIChidXQgaXMgY29uY2VybmVkIHdpdGggbWFr aW5nIHRoZSBwcm90b2NvbCB1c2FibGUpLg0KDQogSXQgbWF5IG5vdCBiZSBjbGVhcmN1dCwgYnV0 IEkgd291bGQgc2VlIHRoaXMgYXMgYSBwcm90b2NvbCBjaGFuZ2UgYW5kIHNvDQogb25lIHRoYXQg c2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgcHJvZ3Jlc3NlZCBpbiB0aGUgSVB2NiBXRyByYXRoZXIg dGhhbg0KIGhlcmUuICBUaGUgV0cgQ2hhaXJzIHdpbGwgZG91YnRsZXNzIGFyYml0cmF0ZSBvbiB0 aGlzLg0KDQogT3RoZXJ3aXNlLCB5ZXMgYnV0IGRvbid0IHN0b3AgYXQgLzI5OyBJIHdvdWxkIGdv IGZvciBhIC84IGFuZCBhbGxvdw0KIG15c2VsZiB0byBiZSBuZWdvdGlhdGVkIGJhY2sgdG8gc29t ZXRoaW5nIGluIGJldHdlZW4uDQogLg0KIFRvbSBQZXRjaA0KDQoNCiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQogRnJvbTogIkplbnMgT3R0IC0gT3B0ZWFtYXggR21iSCIgPGpvQG9wdGVh bWF4LmRlPG1haWx0bzpqb0BvcHRlYW1heC5kZT4+DQogVG86IDx2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Pg0KIFNlbnQ6IFRodXJzZGF5LCBNYXkgMTQsIDIwMTUgOTowMiBB TQ0KIFN1YmplY3Q6IFt2Nm9wc10gSWRlYSBhYm91dCB1cGRhdGluZyBSRkMzODQ5DQoNCiBIaSBN YWlsaW5nbGlzdC1NZW1iZXJzLA0KDQogSSBhbSENCg0KICBwcmV0dHkNCg0KbmV3IG9uIHRoaXMg bGlzdCwgc28gSSBmaXJzdCB3YXZlIGEgIkhlbGxvIiBpbnRvIHRoZQ0KIHJvdW5kLi4uIGFuZCBp bW1lZGlhdGVseSBjb250aW51ZSB0byBhc2sgdGhlIHF1ZXN0aW9uLCB3aGljaCBsZWQgbWUgdG8N CiBzdWJzY3JpYmluZyB0byB0aGlzIGxpc3QuIEFwb2xvZ2llcyBpZiBJIGNob3NlIHRoZSB3cm9u ZyBsaXN0LCBwbGVhc2UNCiBhZHZpc2UgbWUsIHdoZXJlIHRvIHB1dCBteSBxdWVzdGlvbiBpbiB0 aGlzIGNhc2UuDQoNCiBJIHdvcmsgYXMgY29uc3VsdGFudCBhbmQgYWxyZWFkeSBhY2NvbXBhbmll ZCBzZXZlcmFsIElQdjYgcm9sbC1vdXRzDQogZnJvbSB0aGUgZmlyc3QgaWRlYSAid2Ugd2FudCBW NiIgdW50aWwgcHJvZHVjdGlvbi4gV2hpbGUNCiBlbnRlcnByaXNlLXNldHVwcyBhcmUgbW9zdGx5 IC8zMiBvciBsZXNzIElQcywgSSBzZWUgbW9yZSBhbmQgbW9yZQ0KIHJvbGxvdXRzIHdoaWNoIG5l ZWQgbXVjaCBiaWdnZXIgc3BhY2UuDQoNCiBBdCBsZWFzdCBpbiBSSVBFLVJlZ2lvbiwgZWFjaCBM SVIgY2FuIHJlY2VpdmUgYSAvMjkgd2l0aG91dCBhbnkNCiBqdXN0aWZpY2F0aW9uLiBBbmQgaGVy ZSBpcyB3aGVyZSBteSBwcm9ibGVtIHN0YXJ0cy4gV2hpbGUgd3JpdGluZw0KIGRvY3VtZW50YXRp b24gYW5kIGFkZHJlc3NpbmctcGxhbnMgYmVmb3JlIHJlcXVlc3RpbmcgdGhlIGFjdHVhbCBwcmVm aXgNCiBhdCB0aGUgYXBwcm9wcmlhdGUgUklSLCBJJ20gdXNlZCB0byB1c2UgMjAwMTpkYjg6Oi8z MiBhcyBkZWZpbmVkIGluDQogUkZDMzg0OS4gQnV0IHdoYXQgdG8gZG8gZm9yIGJpZ2dlciBuZXRz IChsb3dlciBiaXRtYXNrcyk/DQoNCiBCZWZvcmUgc3RhcnRpbmcgdG8gcHVzaCB0aGUgYmFsbCBv biB0aGUgZmllbGQgYnkgd3JpdGluZyBhIHByb3Bvc2FsLA0KIEknZCBiZSBoYXBweSB0byBoIQ0K DQogZWFyIGlmDQoNCnRoZXJlIGlzIHN1cHBvcnQgaW4gdGhlIGNvbW11bml0eSBmb3IgdXBkYXRp bmcNCiB0aGlzIHJmYyBhbmQgb2ZmaWNpYWxseSBkZWZpbmUgYSBiaWdnZXIgcHJlZml4IGZvciBk b2N1bWVudGF0aW9uLg0KDQogQXMgc2FpZCwgaWYgSSBjaG9zZSB0aGUgd3JvbmcgbWFpbGluZ2xp c3Qgb3Igc2ltcGx5IHN0YXJ0ZWQgYnJpbmdpbmcNCiBteSBpZGVhIGludG8gdGhlIGNvbW11bml0 eSBpbiBhIHdyb25nIHdheSwgYW55IGFkdmlzZSBhbmQgY29tbWVudCBpcw0KIGFwcHJlY2lhdGVk LiBJIGhhdmUgbm8gZXhwZXJpZW5jZSB3aXRoIHRoZSBwcm9jZXNzZXMgYXQgaWV0ZiB5ZXQuDQoN CiBCZXN0IHJlZ2FyZHMgYW5kIHRoYW5rcw0KIC0gLS0NCiBKZW5zIE90dA0KDQogT3B0ZWFtYXgg R21iSA0KDQogU2ltcm9ja3N0ci4gNGINCiA1MzYxOSBSaGVpbmJyZWl0YmFjaA0KDQogVGVsLjog ICs0OSAyMjI0IDk2OTUwMA0KIEZheDogICArNDkgMjIyNCA5NzY5MTA1OQ0KIEVtYWlsOiBqb0Bv cHRlYW1heC5kZTxtYWlsdG86am9Ab3B0ZWFtYXguZGU+DQoNCiBIUkI6IDIzMTQ0LCBBbXRzZ2Vy aWNodCBNb250YWJhdXINCiBHZXNjaMOkZnRzZsO8aHJlcjogSmVucyBPdHQNCiBVbXNhdHpzdGV1 ZXItSUQuOiBERTI2NDEzMzk4OQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KIHY2b3BzIG1haWxpbmcgbGlzdA0KIHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0Bp ZXRmLm9yZz4NCiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoN Cg0KDQoNCiFEU1BBTTo2MzcsNTU1NGUyZGIyMTM5NzE1NzQ0MTM5MTAhDQoNCi0tDQpEaWVzZSBO YWNocmljaHQgd3VyZGUgdm9uIG1laW5lbSBBbmRyb2lkLU1vYmlsdGVsZWZvbiBtaXQgSy05IE1h aWwgZ2VzZW5kZXQuDQo= --_000_CO2PR04MB585B94F567395BBBD771768FEC60CO2PR04MB585namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY5NzU4OTU3OTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ2NTk4NjcwIC0z NDMwMDYyMzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDoxNzI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZG1pdHRlZGx5IG15IHByb2Zlc3Npb24g aXMgbm90IGRvY3VtZW50YXRpb24sIGJ1dCBteSBpbml0aWFsIG9waW5pb24gaXMgc29tZXRoaW5n IGFsb25nIHRoZXNlIGxpbmVzLCBpZiB5b3XigJlyZSBhZHZvY2F0aW5nIHdlIHRha2UgbW9yZSBJ UHY2IGFkZHJlc3Mgc3BhY2Ugb3V0DQogb2YgdXNlIGZvciBkb2N1bWVudGF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIGV4YW1w bGUgZG9jdW1lbnRhdGlvbiBuZWVkcyB0byBtYXRjaCBleGFjdGx5LCBldmVyeSBjb25jZWl2YWJs ZSBwcmVmaXggbGVuZ3RoIGZvciBldmVyeSBwb3NzaWJsZSBzY2VuYXJpby4mbmJzcDsgVGhlIGlk ZWEgYmVoaW5kIGV4YW1wbGVzIGlzIHRvIGdpdmUNCiBhIGdlbmVyYWwgaWRlYSwgYW5kIHRoZW4g aWYgbmVjZXNzYXJ5IGV4cGxhaW4gdGhhdCBvbmUgbWlnaHQgdXNlIGRpZmZlcmVudCBsZW5ndGhz LCBwZXJoYXBzIGFzIHNtYWxsIGFzIHggb3IgYXMgbGFyZ2UgYXMgeS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhlcmUgYXJlIG90aGVyIHR5cGVzIG9mIGRvY3VtZW50YXRpb24sIHRoYXQgc2hvdWxkIGJl IHRha2VuIGxpdGVyYWxseSwgYmVjYXVzZSBzcGVjaWZpYyBmaWx0ZXJzIGFyZSBiZWluZyBkb2N1 bWVudGVkLCBvciBzcGVjaWZpYyBuZXR3b3JrcyBhcmUgYmVpbmcgZG9jdW1lbnRlZC4mbmJzcDsN CiBJbiB0aG9zZSBzaXR1YXRpb25zLCB5b3UgYXJlbuKAmXQgdXNpbmcgdGhlIGFkZHJlc3Mgc3Bh Y2UgcmVzZXJ2ZWQgZm9yIGRvY3VtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5XaXRoIHJlZ2FyZCB0byB5b3VyIHNwZWNpZmljIGV4YW1wbGU6ICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+V2hpbGUgd3JpdGluZyBkb2N1bWVudGF0 aW9uIGFuZCBhZGRyZXNzaW5nLXBsYW5zIGJlZm9yZSByZXF1ZXN0aW5nIHRoZSBhY3R1YWwgcHJl Zml4IGF0IHRoZSBhcHByb3ByaWF0ZSBSSVIsIEknbSB1c2VkIHRvIHVzZSAyMDAxOmRiODo6LzMy IGFzIGRlZmluZWQNCiBpbjxicj4NClJGQzM4NDkuIEJ1dCB3aGF0IHRvIGRvIGZvciBiaWdnZXIg bmV0cyAobG93ZXIgYml0bWFza3MpPzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJ08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBqdXN0IGtlZXAgZG9pbmcgYXMgeW91IGhhdmUsIGJ1 dCBtYWtlIGEgbm90ZSB0aGF0IGEgLzI5IHdvdWxkIGJlIHVzZWQgaW5zdGVhZCwgaWYgdGhhdCBp cyB5b3VyIGludGVudCwgYW5kIGZvciB0aGUgcHVycG9zZXMgb2YgdGhlIGV4YW1wbGUsIG5vdGUg dGhhdA0KIHlvdSBtYWRlIGFsbCBvZiB5b3VyIHByZWZpeGVzIDMgYml0cyBsb25nZXIuJm5ic3A7 IFdoZW4gdGhlIGFjdHVhbCBhc3NpZ25tZW50IGlzIG1hZGUsIHRoYXTigJlzIHdoZW4geW91IHN0 YXJ0IGRvY3VtZW50aW5nIGFjdHVhbCBwcmVmaXggbGVuZ3RocywgYW5kIG1vdmUgb3V0IG9mIHRo ZSByZXNlcnZlZCBkb2N1bWVudGF0aW9uIGFkZHJlc3Mgc3BhY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BdCBhIGNlcnRhaW4gcG9pbnQgaXQgYmVjb21lcyB3 YXN0ZWZ1bCB0byB0YWtlIHJlbGF0aXZlbHkgbGFyZ2UgYW1vdW50cyBvZiBhZGRyZXNzIHNwYWNl IG91dCBvZiBhY3RpdmUgdXNlLCBmb3IgdXNlIGNhc2VzIGxpa2UgZG9jdW1lbnRhdGlvbi4mbmJz cDsgV2hlcmUgdGhhdCBsaW5lDQogaXMgZHJhd24sIGlzIGFsd2F5cyBzdWJqZWN0aXZlLCBhbmQg SSBrbm93IGl04oCZcyBJUHY2LCBidXQgSeKAmW0gc3VyZSwgYXQgbGVhc3QgZHVyaW5nIG15IGNv bGxlZ2UgeWVhcnMsIG5vYm9keSB0aG91Z2h0IHdl4oCZZCBldmVyIHJ1biBvdXQgb2YgSVB2NCBh ZGRyZXNzIHNwYWNlIGVpdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGFu IE1ldHpsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkplbnMg T3R0IC0gT3B0ZWFtYXggR21iSDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5IDE2LCAy MDE1IDY6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IGpvZWwgamFlZ2dsaTsgdC5wZXRjaDsgdjZvcHNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSWRlYSBhYm91dCB1cGRh dGluZyBSRkMzODQ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQpleHRlbmRpbmcg dG8gLzMgaXMgbm90IHRoZSBpZGVhLCBidXQgdGhlcmUgYXJlIGxvdCdzIG9mIGNhc2VzIHdoZXJl IGUuZy4gLzE2IHJlc2VydmVkIHNwYWNlIHdvdWxkIG1ha2Ugc2Vuc2UuIFlvdSdkIGJlIHN1cnBy aXNlZCwgaG93IG9mdGVuIHBlb3BsZSBzaW1wbHkgY29weSYjNDM7cGFzdGUgZXhhbXBsZXMgaW4g d29ya3Nob3BzLCBhY3R1YWxseSBJIHdhcyByZWFsbHkgc3VycHJpc2VkIHdoZW4gSSBzYXcgNjY2 OjovMjYgaW4gYSBidW5jaCBvZiBsb29raW5nDQogZ2xhc3NlcyBkdXJpbmcgYSB3b3Jrc2hvcCBJ IGF0dGVuZGVkIGxhc3QgeWVhci48YnI+DQo8YnI+DQpTbyBvYnZpb3VzbHkgZmlsdGVyaW5nIHNl ZW1zIHRvIGJlIGxlc3MgdXNlZCBhcyB5b3UgbWlnaHQgdGhpbmsuIEFzIGxvbmcgYXMgcGVvcGxl IHVzZSBub24gYWxsb2NhdGVkIGFkZHJlc3NzcGFjZSwgdGhlcmUgaXMgbm8gaGFybSBhbmQgbm8g aXNzdWUsIHRoZSBwcm9qZWN0IHdoaWNoIGxlZCBtZSB0byB3cml0ZSB0aGlzIGlkZWEsIHdhcyB1 c2luZyBhY3R1YWxseSBhc3NpZ25lZCBhbmQgYWN0aXZlIElQcyBhbmQgdGhlbiBoYXJtIGNhbiBv Y2N1cg0KIHF1aWNrbHkgZm9yIHRoZSBhY3R1YWwgb3duZXJzLi4uIHlvdSByZW1lbWJlciB0aGUg bW9yZSBzcGVjaWZpYyBhbm5vdW5jZW1lbnRzIG9mIEdvb2dsZSBwcmVmaXhlcyBzb21lIG1vbnRo IGFnbz88YnI+DQo8YnI+DQpBbmQgeWVzLCBJIGFsc28ga25vdyB0aGF0IHRoZSBwdXJlIGV4aXN0 ZW5jZSBvZiBhbiBSRkMgZG9lcyBub3QgbWVhbiwgZXZlcnlib2R5IGFkb3B0cyBpdCwgYnV0IEkg YW0gYWxzbyBzdXJlIGlmIHRoaXMgZXhpc3RlbmNlIGlzIHByb21vdGVkIGEgbGl0dGxlLCBpdCB3 aWxsIHJlZHVjZSB0aGUgcmlzayBvZiBhY2NpZGVudGFsbHkgY29weSYjNDM7cGFzdGVkIGhhcm0u PGJyPg0KPGJyPg0KQlIgYW5kIGhhdmUgYSBuaWNlIHdlZWtlbmQgPGJyPg0KSmVuczxicj4NCjxi cj4NClBTOiBTb3JyeSBmb3IgdG9mdSwgd3JpdGluZyBvbiBteSBtb2JpbGUgYW5kIGZvciB1bmtu b3duIHJlYXNvbiBteSBtdWEgZGlkIHJlZnVzZSB0byBlZGl0IGluc2lkZSBxdW90YXRpb24uPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMTQuIE1haSAyMDE1 IDE5OjM2OjAxIE1FU1osIHNjaHJpZWIgam9lbCBqYWVnZ2xpICZsdDs8YSBocmVmPSJtYWlsdG86 am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwcmU+SSdtIHByZXR0eSBzdXJlIHRoYXQgZ3Jvd2luZyB0aGUgZXhh bXBsZSBwcmVmaXggaXNuJ3QgbmVjZXNzYXJ5IGluIG9yZGVyPGJyPnRvIHRoYXQgeW91IG1pZ2h0 IHVzZSBhIHByZWZpeCB3aXRoIGEgbG9uZ2VyIG9yIHNob3J0ZXIgbmV0bWFzayBpbiBhPGJyPmZp bHRlci4mbmJzcDsgSSB3b3VsZG4ndCB3YW50IHRvIGV4cGFuZCBpdCB0byBhIC8zIGp1c3Qgc28g dGhhdCBJIGNvdWxkPGJyPmV4cHJlc3MgdGhlIHNpemUgb2YgdGhlIGlwdjZ1bmljYXN0IGFkZHJl c3MgcmFuZ2UuPGJyPjxicj5XZSBkb24ndCBnZXQgaW50byBleGlzdGVudGlhbCBwZXJpbCB3aGVu IHdlIHJlZmVyIHRvIDo6LzA8YnI+PGJyPnNvIGlmIHlvdSBoYXZlIHRvIHNheSwmbmJzcDsgJnF1 b3Q7ZGVzaWduIHRoZSBmaWx0ZXIgdGhpcyB3YXkgZXhhbXBsZSBteSBhZGRyZXNzPGJyPnNwYWNl Jm5ic3A7IDIwMDE6ZGI4OjovMzIgc3Vic3RpdHV0aW5nIHlvdXIgcHJlZml4IGFuZCBhbmQgYXBw cm9wcmlhdGUgbGVuZ3RoPGJyPm5ldG1hc2sgKHNob3J0ZXIgb3IgbG9uZ2VyIGFzIG5lY2Vzc2Fy eSkgdGhhdCBkb2Vzbid0IHNlZW0gZXhjZXNzaXZlbHk8YnI+Y2lyY3VpdG91cy4gYW5kIGlmJm5i c3A7IHRoZXkgc2xhdmlzaGx5IGNvcHkgdGhhdCBwcmVmaXggb3IgbmV0bWFzayB3ZWxsIG5vPGJy Pmhhcm0gbm8gZm91bC48YnI+PGJyPk9uIDUvMTQvMTUgOToyNyBBTSwgdC5wZXRjaCB3cm90ZTo8 bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICM3MjlGQ0YgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHByZT4g SmVuczxicj4gPGJyPiZuYnNwO0kgdGhpbmsgdGhhdCB0aGVyZSBtaWdodCBiZSBhIHNsaWdodCBw cm9jZWR1cmFsIGlzc3VlLiZuYnNwOyBUaGUgb3JpZ2luYWwgUkZDPGJyPiB3YXMgcHJvZHVjZWQg YnkgdGhlIElQdjYgV28hPG86cD48L286cD48L3ByZT4NCjxwcmU+IHJraW5nPG86cD48L286cD48 L3ByZT4NCjxwcmU+R3JvdXAgd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIHByb3RvY29sPGJyPiBj aGFuZ2VzLiZuYnNwOyBUaGlzIGlzIHRoZSB2Nm9wcyBXb3JraW5nIEdyb3VwIHdoaWNoIGlzIG5v dCBhbGxvd2VkIHRvIG1ha2U8YnI+IHByb3RvY29sIGNoYW5nZXMgKGJ1dCBpcyBjb25jZXJuZWQg d2l0aCBtYWtpbmcgdGhlIHByb3RvY29sIHVzYWJsZSkuPGJyPiA8YnI+Jm5ic3A7SXQgbWF5IG5v dCBiZSBjbGVhcmN1dCwgYnV0IEkgd291bGQgc2VlIHRoaXMgYXMgYSBwcm90b2NvbCBjaGFuZ2Ug YW5kIHNvPGJyPiBvbmUgdGhhdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGFuZCBwcm9ncmVzc2VkIGlu IHRoZSBJUHY2IFdHIHJhdGhlciB0aGFuPGJyPiBoZXJlLiZuYnNwOyBUaGUgV0cgQ2hhaXJzIHdp bGwgZG91YnRsZXNzIGFyYml0cmF0ZSBvbiB0aGlzLjxicj4gPGJyPiZuYnNwO090aGVyd2lzZSwg eWVzIGJ1dCBkb24ndCBzdG9wIGF0IC8yOTsgSSB3b3VsZCBnbyBmb3IgYSAvOCBhbmQgYWxsb3c8 YnI+IG15c2VsZiB0byBiZSBuZWdvdGlhdGVkIGJhY2sgdG8gc29tZXRoaW5nIGluIGJldHdlZW4u PGJyPiAuPGJyPiBUb20gUGV0Y2g8YnI+IDxicj4mbmJzcDs8YnI+Jm5ic3A7LS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLTxicj4gRnJvbTogJnF1b3Q7SmVucyBPdHQgLSBPcHRlYW1heCBHbWJI JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am9Ab3B0ZWFtYXguZGUiPmpvQG9wdGVhbWF4LmRl PC9hPiZndDs8YnI+IFRvOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9w c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPiBTZW50OiBUaHVyc2RheSwgTWF5IDE0LCAyMDE1IDk6MDIg QU08YnI+IFN1YmplY3Q6IFt2Nm9wc10gSWRlYSBhYm91dCB1cGRhdGluZyBSRkMzODQ5PG86cD48 L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQUQ3RkE4IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwcmU+PGJyPiBI aSBNYWlsaW5nbGlzdC1NZW1iZXJzLDxicj48YnI+IEkgYW0hPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7IHByZXR0eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5ldyBvbiB0aGlzIGxpc3Qs IHNvIEkgZmlyc3Qgd2F2ZSBhICZxdW90O0hlbGxvJnF1b3Q7IGludG8gdGhlPGJyPiByb3VuZC4u LiBhbmQgaW1tZWRpYXRlbHkgY29udGludWUgdG8gYXNrIHRoZSBxdWVzdGlvbiwgd2hpY2ggbGVk IG1lIHRvPGJyPiBzdWJzY3JpYmluZyB0byB0aGlzIGxpc3QuIEFwb2xvZ2llcyBpZiBJIGNob3Nl IHRoZSB3cm9uZyBsaXN0LCBwbGVhc2U8YnI+IGFkdmlzZSBtZSwgd2hlcmUgdG8gcHV0IG15IHF1 ZXN0aW9uIGluIHRoaXMgY2FzZS48YnI+PGJyPiBJIHdvcmsgYXMgY29uc3VsdGFudCBhbmQgYWxy ZWFkeSBhY2NvbXBhbmllZCBzZXZlcmFsIElQdjYgcm9sbC1vdXRzPGJyPiBmcm9tIHRoZSBmaXJz dCBpZGVhICZxdW90O3dlIHdhbnQgVjYmcXVvdDsgdW50aWwgcHJvZHVjdGlvbi4gV2hpbGU8YnI+ IGVudGVycHJpc2Utc2V0dXBzIGFyZSBtb3N0bHkgLzMyIG9yIGxlc3MgSVBzLCBJIHNlZSBtb3Jl IGFuZCBtb3JlPGJyPiByb2xsb3V0cyB3aGljaCBuZWVkIG11Y2ggYmlnZ2VyIHNwYWNlLjxicj48 YnI+IEF0IGxlYXN0IGluIFJJUEUtUmVnaW9uLCBlYWNoIExJUiBjYW4gcmVjZWl2ZSBhIC8yOSB3 aXRob3V0IGFueTxicj4ganVzdGlmaWNhdGlvbi4gQW5kIGhlcmUgaXMgd2hlcmUgbXkgcHJvYmxl bSBzdGFydHMuIFdoaWxlIHdyaXRpbmc8YnI+IGRvY3VtZW50YXRpb24gYW5kIGFkZHJlc3Npbmct cGxhbnMgYmVmb3JlIHJlcXVlc3RpbmcgdGhlIGFjdHVhbCBwcmVmaXg8YnI+IGF0IHRoZSBhcHBy b3ByaWF0ZSBSSVIsIEknbSB1c2VkIHRvIHVzZSAyMDAxOmRiODo6LzMyIGFzIGRlZmluZWQgaW48 YnI+IFJGQzM4NDkuIEJ1dCB3aGF0IHRvIGRvIGZvciBiaWdnZXIgbmV0cyAobG93ZXIgYml0bWFz a3MpPzxicj48YnI+IEJlZm9yZSBzdGFydGluZyB0byBwdXNoIHRoZSBiYWxsIG9uIHRoZSBmaWVs ZCBieSB3cml0aW5nIGEgcHJvcG9zYWwsPGJyPiBJJ2QgYmUgaGFwcHkgdG8gaCE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4gZWFyIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlcmUgaXMgc3Vw cG9ydCBpbiB0aGUgY29tbXVuaXR5IGZvciB1cGRhdGluZzxicj4gdGhpcyByZmMgYW5kIG9mZmlj aWFsbHkgZGVmaW5lIGEgYmlnZ2VyIHByZWZpeCBmb3IgZG9jdW1lbnRhdGlvbi48YnI+PGJyPiBB cyBzYWlkLCBpZiBJIGNob3NlIHRoZSB3cm9uZyBtYWlsaW5nbGlzdCBvciBzaW1wbHkgc3RhcnRl ZCBicmluZ2luZzxicj4gbXkgaWRlYSBpbnRvIHRoZSBjb21tdW5pdHkgaW4gYSB3cm9uZyB3YXks IGFueSBhZHZpc2UgYW5kIGNvbW1lbnQgaXM8YnI+IGFwcHJlY2lhdGVkLiBJIGhhdmUgbm8gZXhw ZXJpZW5jZSB3aXRoIHRoZSBwcm9jZXNzZXMgYXQgaWV0ZiB5ZXQuPGJyPjxicj4gQmVzdCByZWdh cmRzIGFuZCB0aGFua3M8YnI+IC0gLS08YnI+IEplbnMgT3R0PGJyPjxicj4gT3B0ZWFtYXggR21i SDxicj48YnI+IFNpbXJvY2tzdHIuIDRiPGJyPiA1MzYxOSBSaGVpbmJyZWl0YmFjaDxicj48YnI+ IFRlbC46Jm5ic3A7ICYjNDM7NDkgMjIyNCA5Njk1MDA8YnI+IEZheDombmJzcDsmbmJzcDsgJiM0 Mzs0OSAyMjI0IDk3NjkxMDU5PGJyPiBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmpvQG9wdGVhbWF4 LmRlIj5qb0BvcHRlYW1heC5kZTwvYT48YnI+PGJyPiBIUkI6IDIzMTQ0LCBBbXRzZ2VyaWNodCBN b250YWJhdXI8YnI+IEdlc2Now6RmdHNmw7xocmVyOiBKZW5zIE90dDxicj4gVW1zYXR6c3RldWVy LUlELjogREUyNjQxMzM5ODk8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4g PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48aHIgc2l6 ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPjwvcHJlPg0KPHByZT48YnI+Jm5ic3A7 djZvcHMgbWFpbGluZyBsaXN0PGJyPiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2 b3BzQGlldGYub3JnPC9hPjxicj4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wczwvYT48YnI+IDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IURT UEFNOjYzNyw1NTU0ZTJkYjIxMzk3MTU3NDQxMzkxMCE8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSA8YnI+DQpEaWVz ZSBOYWNocmljaHQgd3VyZGUgdm9uIG1laW5lbSBBbmRyb2lkLU1vYmlsdGVsZWZvbiBtaXQgSy05 IE1haWwgZ2VzZW5kZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CO2PR04MB585B94F567395BBBD771768FEC60CO2PR04MB585namprd_-- From nobody Sat May 16 14:18:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DD31A8757 for ; Sat, 16 May 2015 14:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sDb1-sGZg_S for ; Sat, 16 May 2015 14:18:44 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0551A1AAA for ; Sat, 16 May 2015 14:18:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2156B609A7 for ; Sat, 16 May 2015 23:18:41 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D7E2260760 for ; Sat, 16 May 2015 23:18:40 +0200 (CEST) Received: (qmail 23508 invoked by uid 1007); 16 May 2015 23:18:40 +0200 Date: Sat, 16 May 2015 23:18:40 +0200 From: Gert Doering To: Mark ZZZ Smith Message-ID: <20150516211840.GJ54385@Space.Net> References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:18:45 -0000 Hi, On Sat, May 16, 2015 at 01:22:26AM +0000, Mark ZZZ Smith wrote: > So quickly, how have IPv4 options been handled? > They too can vary the location of the TCP/UDP etc. headers in an IPv4 packet. "Drop packets with IP options". > How have the variety and variable number of TCP options been handled? They > too can vary the location of the TCP segment payload. But they do not move the location of the TCP port info. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat May 16 16:16:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320031A8820 for ; Sat, 16 May 2015 16:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_hdWvloPvmh for ; Sat, 16 May 2015 16:16:09 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A661A1B13 for ; Sat, 16 May 2015 16:16:09 -0700 (PDT) Received: by pablj1 with SMTP id lj1so22640879pab.3 for ; Sat, 16 May 2015 16:16:08 -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=9hwdUnWM54EgWiH3TCJHsZtLu6ipqC++Iln9JLUuL9s=; b=bQw/PqUwTfzEkBcXD9mRxNZj2mBcIhpjvX5Cc+SjttwpSAkyAKKgta+l1FbrkURs1n 0Z8armK+Fh/VANRyWp3/BgkFIAZO04MyUFx/dgWZlT0lL5vWZnGaqjeirKxGYANJl0Jb 0jOg6ztwO/xGKmYpsbF4/TPiz+WWloGXICtLUIh9fa87gJ/Oc/G5Ke37+uXati086/oM RyVWBgbyqxgJjJcYPOnhKsQXlHcN/1QkFRN2/j50OKs1IdiFNMmdHj1FHMdnljp9rztZ 07vN1nQFCQ1WjCQ+66Jg3V8TtcZ9oCvOEiJslF1QRz1pccYFcSi2QjtLy4j5EJKmlkeB Dl3g== X-Received: by 10.66.251.165 with SMTP id zl5mr30811620pac.93.1431818168766; Sat, 16 May 2015 16:16:08 -0700 (PDT) Received: from ?IPv6:2406:e007:468a:1:28cc:dc4c:9703:6781? ([2406:e007:468a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id za1sm5701655pbb.55.2015.05.16.16.16.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 16:16:07 -0700 (PDT) Message-ID: <5557CFB2.2070407@gmail.com> Date: Sun, 17 May 2015 11:16:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gert Doering , Mark ZZZ Smith References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <20150516211840.GJ54385@Space.Net> In-Reply-To: <20150516211840.GJ54385@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 23:16:10 -0000 On 17/05/2015 09:18, Gert Doering wrote: > Hi, > > On Sat, May 16, 2015 at 01:22:26AM +0000, Mark ZZZ Smith wrote: >> So quickly, how have IPv4 options been handled? >> They too can vary the location of the TCP/UDP etc. headers in an IPv4 packet. > > "Drop packets with IP options". And, to be clear, that has been a fact of life since before IPv6 was designed. (If it hadn't, back in early 1994 I would have pushed very very hard on my own proposal to add address extension options to IPv4.) Brian > >> How have the variety and variable number of TCP options been handled? They >> too can vary the location of the TCP segment payload. > > But they do not move the location of the TCP port info. > > Gert Doering > -- NetMaster > From nobody Sun May 17 02:01:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614881A8AE2 for ; Sun, 17 May 2015 02:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.2 X-Spam-Level: *** X-Spam-Status: No, score=3.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eySqhrmkg-xT for ; Sun, 17 May 2015 02:01:24 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B3E1A8AE1 for ; Sun, 17 May 2015 02:01:23 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc8xp (81.151.162.168) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.154.19; Sun, 17 May 2015 08:21:38 +0000 Message-ID: <6F1F282D3C014759B76E32C461152652@pc8xp> From: tom petch To: Jens Ott - Opteamax GmbH , joel jaeggli , References: <55545683.6070202@opteamax.de> <0b0c01d08e62$f33dd7c0$4001a8c0@gateway.2wire.net> <5554DD01.5040708@bogus.com> <274D59F3-D4C5-48EE-BED0-736FFA35FA3D@opteamax.de> Date: Sun, 17 May 2015 09:14:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010F_01D09081.F13D4610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB4PR02CA0050.eurprd02.prod.outlook.com (10.242.174.178) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 057906460E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(24454002)(51444003)(51164003)(252514010)(13464003)(199003)(479174004)(377454003)(189002)(122386002)(5001860100001)(4001540100001)(5001770100001)(50226001)(189998001)(86362001)(22776003)(107886002)(5001960100002)(97736004)(81156007)(44706002)(5001830100001)(50986999)(81816999)(76176999)(68736005)(66066001)(81686999)(106356001)(33716001)(9626003)(62966003)(77096005)(77156002)(64706001)(46102003)(19580395003)(19580405001)(61296003)(92566002)(105586002)(15975445007)(84326002)(512874002)(561944003)(101416001)(62236002)(93886004)(33656002)(19617315012)(71636004)(40100003)(44716002)(2920100001)(71666007)(84392001)(86152002)(42186005)(87976001)(62796013)(4526008)(44726022)(80546004); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc8xp; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2015 08:21:38.4385 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Subject: Re: [v6ops] Idea about updating RFC3849 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 09:01:27 -0000 ------=_NextPart_000_010F_01D09081.F13D4610 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Jens Ott - Opteamax GmbH=20 To: joel jaeggli ; t.petch ; v6ops@ietf.org=20 Sent: Saturday, May 16, 2015 12:21 PM Hi, extending to /3 is not the idea, but there are lot's of cases where = e.g. /16 reserved space would make sense. You'd be surprised, how often = people simply copy+paste examples in workshops, actually I was really = surprised when I saw 666::/26 in a bunch of looking glasses during a = workshop I attended last year. Yes, that is what drove my reply. I still recall teaching how to = renumber to a customer whose predecessor had been on a course which had = not used documentation prefixes and so had incorporated someone else's = public IP addresses into their organisation. Which worked fine for a = while and then they connected to the Internet. So yes, the examples in a workshop should match reality as closely as = possible, so that, in effect, when the student is back in the real = world, all they have to do is a global change, not try to remember when = /48 becomes /64 or /36 becomes /29. Tom Petch p.s. different e-mail client, heaven knows what this will look like p.p.s. and I still think that this is one for IPv6 not v6ops So obviously filtering seems to be less used as you might think. As = long as people use non allocated addressspace, there is no harm and no = issue, the project which led me to write this idea, was using actually = assigned and active IPs and then harm can occur quickly for the actual = owners... you remember the more specific announcements of Google = prefixes some month ago? And yes, I also know that the pure existence of an RFC does not mean, = everybody adopts it, but I am also sure if this existence is promoted a = little, it will reduce the risk of accidentally copy+pasted harm. BR and have a nice weekend=20 Jens PS: Sorry for tofu, writing on my mobile and for unknown reason my mua = did refuse to edit inside quotation. Am 14. Mai 2015 19:36:01 MESZ, schrieb joel jaeggli = : I'm pretty sure that growing the example prefix isn't necessary in = orderto that you might use a prefix with a longer or shorter netmask in = afilter. I wouldn't want to expand it to a /3 just so that I = couldexpress the size of the ipv6unicast address range.We don't get into = existential peril when we refer to ::/0so if you have to say, "design = the filter this way example my addressspace 2001:db8::/32 substituting = your prefix and and appropriate lengthnetmask (shorter or longer as = necessary) that doesn't seem excessivelycircuitous. and if they = slavishly copy that prefix or netmask well noharm no foul.On 5/14/15 = 9:27 AM, t.petch wrote: Jens I think that there might be a slight = procedural issue. The original RFC was produced by the IPv6 Working Group which is responsible for protocol changes. This is the v6ops = Working Group which is not allowed to make protocol changes (but is = concerned with making the protocol usable). It may not be clearcut, but = I would see this as a protocol change and so one that should be = discussed and progressed in the IPv6 WG rather than here. The WG Chairs = will doubtless arbitrate on this. Otherwise, yes but don't stop at /29; = I would go for a /8 and allow myself to be negotiated back to something = in between. . Tom Petch ----- Original Message ----- From: "Jens Ott - = Opteamax GmbH" To: Sent: Thursday, May = 14, 2015 9:02 AM Subject: [v6ops] Idea about updating RFC3849 Hi = Mailinglist-Members, I am pretty new on this list, so I first wave a "Hello" into the round... and = immediately continue to ask the question, which led me to subscribing to = this list. Apologies if I chose the wrong list, please advise me, where = to put my question in this case. I work as consultant and already = accompanied several IPv6 roll-outs from the first idea "we want V6" = until production. While enterprise-setups are mostly /32 or less IPs, I = see more and more rollouts which need much bigger space. At least in = RIPE-Region, each LIR can receive a /29 without any justification. And = here is where my problem starts. While writing documentation and = addressing-plans before requesting the actual prefix at the appropriate = RIR, I'm used to use 2001:db8::/32 as defined in RFC3849. But what to do = for bigger nets (lower bitmasks)? Before starting to push the ball on = the field by writing a proposal, I'd be happy to hear if there is support in the community for updating this rfc and officially = define a bigger prefix for documentation. As said, if I chose the wrong = mailinglist or simply started bringing my idea into the community in a = wrong way, any advise and comment is appreciated. I have no experience = with the processes at ietf yet. Best regards and thanks - -- Jens Ott = Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 = Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht = Montabaur Gesch=C3=A4ftsf=C3=BChrer: Jens Ott Umsatzsteuer-ID.: = DE264133989 = -------------------------------------------------------------------------= - v6ops mailing list v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops=20 !DSPAM:637,5554e2db213971574413910! --=20 Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail = gesendet. ------=_NextPart_000_010F_01D09081.F13D4610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
----- Original Message -----
From:=20 Jens Ott - = Opteamax=20 GmbH
Sent: Saturday, May 16, 2015 = 12:21=20 PM

Hi,

extending to /3 is not the idea, but there are lot's = of cases=20 where e.g. /16 reserved space would make sense. You'd be surprised, = how often=20 people simply copy+paste examples in workshops, actually I was really=20 surprised when I saw 666::/26 in a bunch of looking glasses during a = workshop=20 I attended last year.
<tp>
 
Yes, that is what drove my = reply.  I still=20 recall teaching how to renumber to a customer whose predecessor had = been on a=20 course which had not used documentation prefixes and so had = incorporated=20 someone else's public IP addresses into their organisation.  = Which worked=20 fine for a while and then they connected to the Internet.
 
So yes, the examples in a workshop = should match=20 reality as closely as possible, so that, in effect, when the student = is back=20 in the real world, all they have to do is a global change, not try to = remember=20 when /48 becomes /64 or /36 becomes /29.
Tom Petch
 
p.s. different e-mail client, heaven = knows what=20 this will look like
 
p.p.s. and I still think that this is = one for=20 IPv6 not v6ops
 

So=20 obviously filtering seems to be less used as you might think. As long = as=20 people use non allocated addressspace, there is no harm and no issue, = the=20 project which led me to write this idea, was using actually assigned = and=20 active IPs and then harm can occur quickly for the actual owners... = you=20 remember the more specific announcements of Google prefixes some month = ago?

And yes, I also know that the pure existence of an RFC = does not=20 mean, everybody adopts it, but I am also sure if this existence is = promoted a=20 little, it will reduce the risk of accidentally copy+pasted = harm.

BR=20 and have a nice weekend
Jens

PS: Sorry for tofu, writing on = my=20 mobile and for unknown reason my mua did refuse to edit inside=20 quotation.

Am 14. Mai 2015 19:36:01 MESZ, schrieb joel = jaeggli=20 <joelja@bogus.com>: 
I'm pretty sure that growing =
the example prefix isn't necessary in order
to that you might use a =
prefix with a longer or shorter netmask in a
filter.  I wouldn't want =
to expand it to a /3 just so that I could
express the size of the =
ipv6unicast address range.

We don't get into existential peril =
when we refer to ::/0

so if you have to say,  "design the filter =
this way example my address
space  2001:db8::/32 substituting your =
prefix and and appropriate length
netmask (shorter or longer as =
necessary) that doesn't seem excessively
circuitous. and if  they =
slavishly copy that prefix or netmask well no
harm no foul.

On =
5/14/15 9:27 AM, t.petch wrote:
 Jens
 
 I think that there might be a slight =
procedural issue.  The original RFC
 was produced by the IPv6 Working
Group which is responsible for protocol
 changes.  This is the v6ops =
Working Group which is not allowed to make
 protocol changes (but is =
concerned with making the protocol usable).
 
 It may not be =
clearcut, but I would see this as a protocol change and so
 one that =
should be discussed and progressed in the IPv6 WG rather than
 here.  =
The WG Chairs will doubtless arbitrate on this.
 
 Otherwise, yes =
but don't stop at /29; I would go for a /8 and allow
 myself to be =
negotiated back to something in between.
 .
 Tom Petch
 
 =

 ----- Original Message -----
 From: "Jens Ott - Opteamax GmbH" =
<jo@opteamax.de>
 To: <v6ops@ietf.org>
 Sent: =
Thursday, May 14, 2015 9:02 AM
 Subject: [v6ops] Idea about updating =
RFC3849

 Hi =
Mailinglist-Members,

 I am pretty
new on this list, so I first wave a "Hello" into the
 round... and =
immediately continue to ask the question, which led me to
 =
subscribing to this list. Apologies if I chose the wrong list, =
please
 advise me, where to put my question in this case.

 I =
work as consultant and already accompanied several IPv6 roll-outs
 =
from the first idea "we want V6" until production. While
 =
enterprise-setups are mostly /32 or less IPs, I see more and more
 =
rollouts which need much bigger space.

 At least in RIPE-Region, =
each LIR can receive a /29 without any
 justification. And here is =
where my problem starts. While writing
 documentation and =
addressing-plans before requesting the actual prefix
 at the =
appropriate RIR, I'm used to use 2001:db8::/32 as defined in
 =
RFC3849. But what to do for bigger nets (lower bitmasks)?

 Before =
starting to push the ball on the field by writing a proposal,
 I'd be =
happy to hear if
there is support in the community for updating
 this rfc and =
officially define a bigger prefix for documentation.

 As said, if =
I chose the wrong mailinglist or simply started bringing
 my idea =
into the community in a wrong way, any advise and comment is
 =
appreciated. I have no experience with the processes at ietf =
yet.

 Best regards and thanks
 - --
 Jens Ott

 =
Opteamax GmbH

 Simrockstr. 4b
 53619 Rheinbreitbach

 =
Tel.:  +49 2224 969500
 Fax:   +49 2224 97691059
 Email: =
jo@opteamax.de

 HRB: 23144, Amtsgericht Montabaur
 =
Gesch=C3=A4ftsf=C3=BChrer: Jens Ott
 Umsatzsteuer-ID.: =
DE264133989
 

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


!DSPAM:637,5554e2db213971574413910!

--=20
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail = gesendet. ------=_NextPart_000_010F_01D09081.F13D4610-- From silvia.hagen@sunny.ch Sun May 17 10:28:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CB81A88A3 for ; Sun, 17 May 2015 10:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5MeGCACnyVI for ; Sun, 17 May 2015 10:28:56 -0700 (PDT) Received: from pianosa.iway.ch (pianosa.iway.ch [IPv6:2001:8e0:40:325::37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D151A886E for ; Sun, 17 May 2015 10:28:55 -0700 (PDT) Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9198EE0814; Sun, 17 May 2015 19:28:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/2282.31750); Sun, 17 May 2015 19:28:53 +0200 (CEST) Received: from owa.hextop.ch (owa.hextop.ch [212.25.0.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Sun, 17 May 2015 19:28:53 +0200 (CEST) Received: from HEX02.hextop.ch ([212.25.0.68]) by hex02 ([212.25.0.68]) with mapi id 14.01.0438.000; Sun, 17 May 2015 19:28:52 +0200 From: Silvia Hagen To: Brian E Carpenter , Enno Rey , "v6ops@ietf.org" Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOc1Jlz46hQy0yE3Gbhq1u2w519XioAgAMRA0A= Date: Sun, 17 May 2015 17:28:52 +0000 Message-ID: References: <20150515113728.GH3028@ernw.de> <555658DE.6080402@gmail.com> In-Reply-To: <555658DE.6080402@gmail.com> Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.62.163.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 11:50:44 -0700 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 17:42:48 -0000 Yes Brian, I fully support your viewpoint. Learning to deal with IPv6 takes time, and we have to give it that time. A= nd give the vendors the time to learn where the pain points are and give th= em time but also expect them to find solutions. And they will find solutions. Silvia -----Urspr=FCngliche Nachricht----- Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Brian E Carpenter Gesendet: Freitag, 15. Mai 2015 22:37 An: Enno Rey; v6ops@ietf.org Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices Enno, On 15/05/2015 23:37, Enno Rey wrote: ... > As for the topic itself I'd like to summarize our position as follows: > - it has not happened in the past 17 yrs (since publication of RFC2460) t= hat compelling, Internet-scale use cases of extension headers have been bro= ught up. I object to that logic. Firstly, the timescale is misleading: IPv6 deployme= nt has been so painfully slow that you really can't look at the 17 year spa= n for this argument; it's only within the last 5 years or so that the words= "compelling" and "Internet-scale" could be relevant. That's why the obvious issues in RF= C 2460 were only fixed in 2013, by the way (RFC 7045). We haven't even had = time for those fixes to reach deployment. Secondly, "compelling" is entirely a matter of judgement. There's no possib= ility of a compelling case for something that is undeployable, and it's wel= l known that because of faulty handling of new extension headers by middleb= oxes, no new extension headers are deployable today. > - we're hence quite sceptical as for the "we might see cool use cases in = 15-20 yrs" position someone expressed at the mic. Of course you won't, until middleboxes stop breaking them. Extensibility is= for the future and unpredictable, by definition. > - from a security perspective they turn out to be a nightmare for (a numb= er of) current security architectures and controls. it is hence understanda= ble (and we actually advise to do so) that they are blocked at the _border_= of networks that have not yet managed to identify a compelling use case. That is automatically a self-fulfilling prophecy. The new rules in RFC 7045= were carefully constructed to offer a way out of this. I hope your advice = is to follow those rules and to insist on products that allow this (correct= defaults, for example). > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their= number, order, options, fragmentable vs. unfragmentable part etc.) we do n= ot expect that type of security issues to disappear soon (the main reason w= hy we did not continue the IDPS research was that the involved student even= tually delivered his thesis. one can probably find much more issues provide= d time & resources. following LANGSEC it might be impossible to "fix" all o= f them either). I assume you are following documents like draft-ietf-6man-deprecate-atomfra= g-generation, RFC 7112, RFC 6946, etc. It isn't as if the IETF is unaware of the issues. > Adding more parsing cycles & intelligence (read: silicon) is not an optio= n, at least not for sth that doesn't have a use case. Well, Moore's law is stll with us, so I think that is plain wrong as produc= ts evolve, which is exactly why we should update the standards accordingly.= Of course that applies to vendors, not operators. > - the results of this (blocking) approach have been observed and document= ed by Jen & Fernando and others (Tim Chown). > - now that "this vicious circle" has gained sufficient ground it will be = evfixesen less incentivized to develop a compelling use case. which is why = we do not expect to see one in the future. It's possible, but that doesn't mean that the IETF should give up on extens= ibility. We should continue to mitigate the problems, which is what we've been doing= for several years, since they became apparent. Nobody, I think, is arguing that the extensibility design in IPv6 is middle= box-friendly. But that's history and we have to deal with it. Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun May 17 12:18:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E431A9028 for ; Sun, 17 May 2015 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMYAfZ8M_teY for ; Sun, 17 May 2015 12:18:45 -0700 (PDT) Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325FB1A8BC4 for ; Sun, 17 May 2015 12:18:44 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 5C50A627CD; Sun, 17 May 2015 21:18:42 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 1C7E338F; Sun, 17 May 2015 21:18:42 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id D85D6C2FE5; Sun, 17 May 2015 21:18:41 +0200 (CEST) Date: Sun, 17 May 2015 21:18:41 +0200 From: Enno Rey To: ipv6-wg@ripe.net, v6ops@ietf.org Message-ID: <20150517191841.GA26929@ernw.de> References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 19:18:48 -0000 Hi Silvia, On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: > Hi > > I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. > > Couldn't we update RFC2460 and make this list a strict order? good luck bringing this suggestion to IETF 6man... ;-) > > I would want my firewall to notify me if the EHs in a packet do not follow the list. actually when we tested a number of commercial firewalls in late 2013 (results here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) it turned out that pretty much all of them follow a (from our perspective "reasonable approach", that is dropping "unusal combinations or number of ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently all major vendors follow a line of reasoning similar to ours). so, in short, firewalls "are not affected". > And limiting the number of possible EHs per packet might be a good idea. yes, that _would actually be_ a good idea. I'm cross-posting this to v6ops as there's a related discussion going on right now. pls forgive this potential Usenet etiquette violation. best Enno > > Silvia > > -----Urspr?ngliche Nachricht----- > Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand > Gesendet: Sonntag, 17. Mai 2015 18:39 > An: ipv6-wg@ripe.net > Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > > Hi Enno and list, > > Enno Rey writes: > > > hope everybody had a great #RIPE70 meeting. We did! > > Many thanks to the organizers and chairs! > > and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) > > > If the chairs consider this appropriate we will happily give a > > presentation on this stuff in Bucharest or at another occasion. > > Sounds good to me! > > > - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > > their number, order[...] > > Actually, as far as I'm concerned that's the real core of the problem. > Or more specifically, the first two lines of RFC 2460, section 4.1: > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > > followed on the next page by > > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. > > The impact here is actually at least twofold: > > - It is impossible to implement this as a simple pipeline architecture > in hardware; at least for cases deviating from the "recommendations" > above this effectively becomes either excessively complex to implement > in hardware or an invitation to DoS when implemented in software on an > otherwise hardware router. > > - As I understand it, at least some of the issues you have found are > effectively based on violating the second paragraph quoted, making it > impossible to come up with a lower bound on how long the header chain > can actually get and therefore leading to the fragmentation related > attacks and similar you have discovered. > > The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. > > > Cheers, > > Benedikt > > -- > Benedikt Stockebrand, Stepladder IT Training+Consulting > Dipl.-Inform. http://www.stepladder-it.com/ > > Business Grade IPv6 --- Consulting, Training, Projects > > BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sun May 17 12:50:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CE1A1A68 for ; Sun, 17 May 2015 12:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jfkIYAyt9xL for ; Sun, 17 May 2015 12:50:44 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE20D1A0334 for ; Sun, 17 May 2015 12:50:43 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so119306646pac.2 for ; Sun, 17 May 2015 12:50:43 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RL2Z6zrGHC+AiZXXlnwIykTCJMo4VBKtMkpca7ZqYO8=; b=ZywEWZnoXHuTWMrfmAwGI/WkU3ezK9f91rqyhEy99NWrVJtraOtXlWCsBz8pNkhPVz R2RTB/sNjwkYcSipDCnw1TfpqIrCs/Bqsdxvb6j+TYjbsrnam1vMAYNBa/l6pd6glkRA h7qIEA+gTYT5INveYCDWjZSGp0Nbh0Vv2R82pEQrl8sQE17QoRC4Go/68qHhhDs5Ptgd RwA5qve94jjZVgZoI+bpKoJ7CUqWdoruoBkMtYD4d7AqvXwqRipZi0F0VLdhpGAhc103 kpNQbi3LWjb2x5a9JbIKawcKVn0XvnHLiaCQxffNHBeBQo8oGdajHKB2i+/IRW5BYPyv k2uQ== X-Received: by 10.67.1.98 with SMTP id bf2mr38498725pad.33.1431892243558; Sun, 17 May 2015 12:50:43 -0700 (PDT) Received: from ?IPv6:2406:e007:5d8c:1:28cc:dc4c:9703:6781? ([2406:e007:5d8c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qz3sm7858026pab.19.2015.05.17.12.50.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2015 12:50:42 -0700 (PDT) Message-ID: <5558F0F4.7080707@gmail.com> Date: Mon, 18 May 2015 07:50:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <20150517191841.GA26929@ernw.de> In-Reply-To: <20150517191841.GA26929@ernw.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 19:50:46 -0000 On 18/05/2015 07:18, Enno Rey wrote: > Hi Silvia, > > On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: >> Hi >> >> I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it. >> >> Couldn't we update RFC2460 and make this list a strict order? > > good luck bringing this suggestion to IETF 6man... ;-) Talking to hardware people, I have the impression that a more serious problem is the lack of a single fixed TLV format for all extension headers. The blending of extension headers and payload protocol numbers has also turned out to be a mistake. The fact is that line speed parsing of the headers needs a more complex hardware protocol engine than designers seem ready to accept. Brian > > > >> >> I would want my firewall to notify me if the EHs in a packet do not follow the list. > > actually when we tested a number of commercial firewalls in late 2013 (results here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) it turned out that pretty much all of them follow a (from our perspective "reasonable approach", that is dropping "unusal combinations or number of ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently all major vendors follow a line of reasoning similar to ours). > so, in short, firewalls "are not affected". > > >> And limiting the number of possible EHs per packet might be a good idea. > > yes, that _would actually be_ a good idea. > > > I'm cross-posting this to v6ops as there's a related discussion going on right now. pls forgive this potential Usenet etiquette violation. > > best > > Enno > > > > >> >> Silvia >> >> -----Urspr?ngliche Nachricht----- >> Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand >> Gesendet: Sonntag, 17. Mai 2015 18:39 >> An: ipv6-wg@ripe.net >> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices >> >> Hi Enno and list, >> >> Enno Rey writes: >> >>> hope everybody had a great #RIPE70 meeting. We did! >>> Many thanks to the organizers and chairs! >> >> and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-) >> >>> If the chairs consider this appropriate we will happily give a >>> presentation on this stuff in Bucharest or at another occasion. >> >> Sounds good to me! >> >>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to >>> their number, order[...] >> >> Actually, as far as I'm concerned that's the real core of the problem. >> Or more specifically, the first two lines of RFC 2460, section 4.1: >> >> When more than one extension header is used in the same packet, it is >> recommended that those headers appear in the following order: >> >> followed on the next page by >> >> Each extension header should occur at most once, except for the >> Destination Options header which should occur at most twice (once >> before a Routing header and once before the upper-layer header). >> >> Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such. >> >> The impact here is actually at least twofold: >> >> - It is impossible to implement this as a simple pipeline architecture >> in hardware; at least for cases deviating from the "recommendations" >> above this effectively becomes either excessively complex to implement >> in hardware or an invitation to DoS when implemented in software on an >> otherwise hardware router. >> >> - As I understand it, at least some of the issues you have found are >> effectively based on violating the second paragraph quoted, making it >> impossible to come up with a lower bound on how long the header chain >> can actually get and therefore leading to the fragmentation related >> attacks and similar you have discovered. >> >> The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes. >> >> >> Cheers, >> >> Benedikt >> >> -- >> Benedikt Stockebrand, Stepladder IT Training+Consulting >> Dipl.-Inform. http://www.stepladder-it.com/ >> >> Business Grade IPv6 --- Consulting, Training, Projects >> >> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ >> >> > From nobody Mon May 18 03:23:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71AD1A88B9 for ; Mon, 18 May 2015 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gadT4S3vBqo for ; Mon, 18 May 2015 03:23:39 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872AF1A8879 for ; Mon, 18 May 2015 03:23:36 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 094DF6146; Mon, 18 May 2015 03:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=0G2D99SXFJlBOT5/7hECjAPysxY=; b= V/+OGsEgFd3oRez2qLnALUh+cc+Z9KIY46TU7lcbpcJoSgpW4Ivwy3P82ClBNOts 40W8UzR31n3PHlfDC/Nmx6CFFvY6sK5haSJPHIkjc0eGR6JDEGZGRAJEh5Wya0to qocYO+ccU1ONibk6KEMh7g1UmFGYJ77VDiSjTj9nvJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=s0Zrg1rN/R96YHnVZWiJ3OyVRs gOSr093xzhPY3nz7jbz25p0kMobBvG4PEyxIksWJjAvInfmU7Q02aTtjhCUvigky ggqkO158LWZjajX3vG3tcNOAAT3W8fA6N6FB1rPz2T1XGlZw55iTe1ljs72M4BQh 0vaI5sG51g7pNk6dc= Received: from gomlefisk.localdomain (unknown [173.38.220.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id CA6BD6128; Mon, 18 May 2015 03:23:35 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id EC0A344FCE4B; Mon, 18 May 2015 12:23:33 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9933A365-F4D8-4F6B-BA57-ED05CB3AD304"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Ole Troan In-Reply-To: <20150515113728.GH3028@ernw.de> Date: Mon, 18 May 2015 12:23:33 +0200 Message-Id: <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> References: <20150515113728.GH3028@ernw.de> To: Enno Rey X-Mailer: Apple Mail (2.2100) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 10:23:40 -0000 --Apple-Mail=_9933A365-F4D8-4F6B-BA57-ED05CB3AD304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Enno, [=E2=80=A6] > - it has not happened in the past 17 yrs (since publication of = RFC2460) that compelling, Internet-scale use cases of extension headers = have been brought up. this is clearly wrong. FH, AH, ESP are all widely deployed. any form of tunnelling is essentially either using the IP header as an = extension header. including GRE. > - we're hence quite sceptical as for the "we might see cool use cases = in 15-20 yrs" position someone expressed at the mic. > - from a security perspective they turn out to be a nightmare for (a = number of) current security architectures and controls. it is hence = understandable (and we actually advise to do so) that they are blocked = at the _border_ of networks that have not yet managed to identify a = compelling use case. open communication is a security nightmare. cheers, Ole --Apple-Mail=_9933A365-F4D8-4F6B-BA57-ED05CB3AD304 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVWb2lAAoJEFuJXizso86gM94IAK98P28zn3fhhtvgQc/0dxoN eTGgBtO1olXQyaLzXMZrBLBAatKKyflvuzAEmt6Ep5W1/oRUhT9jWR7h0BHC1KMU X5jUfB6huOyvoIwqL+j+5e1VNVYxryxZnb4EkbYUmismrpGa9z8PD7XqEDhrXKfo b3IYyPzOTv7JXrVHqdtYBbhyhUi2Ci3H5FFANlUdP3g44brxTGxx9VvqLeoE9foJ O+syC8qwSOh2jI3uxO4+xpYCKHRM1z1g5HqNk3shdPEV6b7epo2ElJaDH+J7yeso 5WA6c83VKtQqFIinLLIeUKnakFf3arwXspht+Tu5loanZFZXXTUk7jg8TSWkEH0= =J6Ij -----END PGP SIGNATURE----- --Apple-Mail=_9933A365-F4D8-4F6B-BA57-ED05CB3AD304-- From nobody Mon May 18 04:43:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA751A89C7 for ; Mon, 18 May 2015 04:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lG8L6Dn3L3l for ; Mon, 18 May 2015 04:43:15 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 43E7B1A89E1 for ; Mon, 18 May 2015 04:43:14 -0700 (PDT) Received: (qmail 88144 invoked from network); 18 May 2015 11:43:12 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 18 May 2015 11:43:12 -0000 Date: Mon, 18 May 2015 13:43:12 +0200 (CEST) Message-Id: <20150518.134312.74662992.sthaug@nethelp.no> To: otroan@employees.org From: sthaug@nethelp.no In-Reply-To: <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> 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 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 11:43:18 -0000 > > - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. > > this is clearly wrong. FH, AH, ESP are all widely deployed. > any form of tunnelling is essentially either using the IP header as an extension header. including GRE. AH is in RFC 2402 (1998). ESP is in RFC 2406 (1998). FH is in RFC 2460 (1998). Do we have any examples of Internet-scale use cases where the extension header has been defined *after* RFC 2460? Steinar Haug, AS 2116 From nobody Mon May 18 05:41:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7B1AC43D for ; Mon, 18 May 2015 05:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbHktRABkY1b for ; Mon, 18 May 2015 05:41:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938611AC439 for ; Mon, 18 May 2015 05:41:26 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t4ICfK0F093423 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2015 13:41:21 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5559DDF0.7090000@foobar.org> Date: Mon, 18 May 2015 13:41:20 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sthaug@nethelp.no, otroan@employees.org References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> In-Reply-To: <20150518.134312.74662992.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 12:41:29 -0000 On 18/05/2015 12:43, sthaug@nethelp.no wrote: > AH is in RFC 2402 (1998). AH is nearly a zombie these days. It's a pity the ipsec people won't deprecate it, as it has so few useful applications. Nick > ESP is in RFC 2406 (1998). > FH is in RFC 2460 (1998). > > Do we have any examples of Internet-scale use cases where the extension > header has been defined *after* RFC 2460? > > Steinar Haug, AS 2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 19 00:15:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE42E1ACD98 for ; Tue, 19 May 2015 00:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBQZvDXW_UX0 for ; Tue, 19 May 2015 00:15:24 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910131ACD37 for ; Tue, 19 May 2015 00:15:23 -0700 (PDT) Received: from [190.113.211.203] (helo=[192.168.43.9]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YubkG-0005yg-Ja; Tue, 19 May 2015 09:15:21 +0200 Message-ID: <555AB8FA.2080405@si6networks.com> Date: Tue, 19 May 2015 01:15:54 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mark ZZZ Smith , Enno Rey , "v6ops@ietf.org" References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 07:15:26 -0000 On 05/15/2015 10:22 PM, Mark ZZZ Smith wrote: > So quickly, how have IPv4 options been handled? They too can vary the > location of the TCP/UDP etc. headers in an IPv4 packet. How have the > variety and variable number of TCP options been handled? They too can > vary the location of the TCP segment payload. There are substantial differences here: * The size of IPv4 options is very limited (well under 128 bytes) * IYou only need to look at the IHL of the IPv4 packet to be able to jump to the layer-4 protocol header. -- there's no such a thing in IPv6. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue May 19 11:14:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5681A90C9 for ; Tue, 19 May 2015 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPs8KD0LuE6P for ; Tue, 19 May 2015 11:14:06 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF051A9129 for ; Tue, 19 May 2015 11:14:05 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C2AEDDA00A7; Tue, 19 May 2015 18:14:05 +0000 (UTC) Received: from [10.0.1.29] (8.20.190.66) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 19 May 2015 11:14:05 -0700 References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> MIME-Version: 1.0 (1.0) In-Reply-To: <555AB8FA.2080405@si6networks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Tue, 19 May 2015 14:14:04 -0400 To: Fernando Gont X-Originating-IP: [8.20.190.66] Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:14:07 -0000 On May 19, 2015, at 12:15 AM, Fernando Gont wrote: > * The size of IPv4 options is very limited (well under 128 bytes) >=20 > * IYou only need to look at the IHL of the IPv4 packet to be able to > jump to the layer-4 protocol header. -- there's no such a thing in IPv6. I think it's generally agreed that we can expect devices to be somewhat limi= ted as to how far into the packet they can peek on the fast path, and that w= e may need to tolerate a certain degree of non-compliance in such devices un= til Moore's law fixes the problem, or people become willing to pay more for i= t (which they probably won't absent some significant application). Maybe we should have an extension header that says where the transport heade= r is... ;)= From nobody Tue May 19 11:23:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FAE1A914C for ; Tue, 19 May 2015 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALcHXHn8S3aU for ; Tue, 19 May 2015 11:23:17 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54F81AC3EF for ; Tue, 19 May 2015 11:22:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 639C660782 for ; Tue, 19 May 2015 20:22:41 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 297BF6075B for ; Tue, 19 May 2015 20:22:41 +0200 (CEST) Received: (qmail 14416 invoked by uid 1007); 19 May 2015 20:22:41 +0200 Date: Tue, 19 May 2015 20:22:41 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20150519182241.GL54385@Space.Net> References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:23:19 -0000 Hi, On Tue, May 19, 2015 at 02:14:04PM -0400, Ted Lemon wrote: > Maybe we should have an extension header that says where the transport header is... ;) And document that this SHOULD NOT be incorrect, otherwise an evil bit MUST be set. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue May 19 11:54:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0621AD0CA for ; Tue, 19 May 2015 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIDaCx8c3-i9 for ; Tue, 19 May 2015 11:54:41 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7063A1AC3FE for ; Tue, 19 May 2015 11:54:27 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t4JIpGZb019662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 11:51:19 -0700 (PDT) Message-ID: <555B8622.5000806@isi.edu> Date: Tue, 19 May 2015 11:51:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ted Lemon , Fernando Gont References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:54:42 -0000 On 5/19/2015 11:14 AM, Ted Lemon wrote: > On May 19, 2015, at 12:15 AM, Fernando Gont wrote: >> * The size of IPv4 options is very limited (well under 128 bytes) >> >> * IYou only need to look at the IHL of the IPv4 packet to be able to >> jump to the layer-4 protocol header. -- there's no such a thing in IPv6. > > I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application). > > Maybe we should have an extension header that says where the transport header is... ;) I briefly considered this at various times when this thread keeps reappearing, but it would need to be another "HBH" header because it needs to be examined and/or modified at any hop that modifies any other extension header. IPv4 knows where the transport header is but has limited option space and can't natively support "shim" protocol layers inbetween IP and TCP BUT it can find the transport header with localized info. IPv6 makes the opposite trade-off. Joe From nobody Tue May 19 11:59:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892841ACC8C for ; Tue, 19 May 2015 11:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvSJn1SguYyN for ; Tue, 19 May 2015 11:59:50 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9462C1ACCDE for ; Tue, 19 May 2015 11:59:48 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t4JItGSm020906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 11:55:16 -0700 (PDT) Message-ID: <555B8712.9080906@isi.edu> Date: Tue, 19 May 2015 11:55:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sthaug@nethelp.no, otroan@employees.org References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> In-Reply-To: <20150518.134312.74662992.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:59:52 -0000 On 5/18/2015 4:43 AM, sthaug@nethelp.no wrote: >>> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. >> >> this is clearly wrong. FH, AH, ESP are all widely deployed. >> any form of tunnelling is essentially either using the IP header as an extension header. including GRE. > > AH is in RFC 2402 (1998). > ESP is in RFC 2406 (1998). > FH is in RFC 2460 (1998). > > Do we have any examples of Internet-scale use cases where the extension > header has been defined *after* RFC 2460? The following are defined after 2460: 135 Mobility Header [RFC6275] 139 Host Identity Protocol [RFC7401] 140 Shim6 Protocol [RFC5533] 253 Use for experimentation and testing [RFC3692][RFC4727] 254 Use for experimentation and testing [RFC3692][RFC4727] FWIW. Joe From nobody Tue May 19 13:09:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154471A82E2 for ; Tue, 19 May 2015 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDT71WswkuDe for ; Tue, 19 May 2015 13:09:42 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADE11B317F for ; Tue, 19 May 2015 13:09:39 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 30BAFDA007A; Tue, 19 May 2015 20:09:39 +0000 (UTC) Received: from [10.0.1.29] (8.20.190.66) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 19 May 2015 13:09:38 -0700 References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <20150519182241.GL54385@Space.Net> MIME-Version: 1.0 (1.0) In-Reply-To: <20150519182241.GL54385@Space.Net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Tue, 19 May 2015 16:09:38 -0400 To: Gert Doering X-Originating-IP: [8.20.190.66] Archived-At: Cc: Fernando Gont , "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:09:43 -0000 On May 19, 2015, at 2:22 PM, Gert Doering wrote: > And document that this SHOULD NOT be incorrect, otherwise an evil bit MUST > be set. Exactly! :) From nobody Tue May 19 13:35:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E721A037B for ; Tue, 19 May 2015 13:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8Yer-ZpDTBf for ; Tue, 19 May 2015 13:35:33 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7971A8AD1 for ; Tue, 19 May 2015 13:35:33 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so39894748pdb.0 for ; Tue, 19 May 2015 13:35:33 -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=ZzE2IAqanOGcZEQgX1wgvzUFduC/nA2uM6T15na5qPk=; b=JtabWInMx+/e3eMKDAD+sXBp3QD5MsBAKNk5SeWTsAPrv88kE1DbHfIDNJ+3Vp8I3W 7w/xYViTSvX62LxdORxI4EB69wBZLjJqrOn5gWuVNDJM3Zw61hQ+95nCxqnC4M9/+uu4 TqHjTeVjV8G/rzoliNuVz2H8BYGcvjyjLEKjh60VWMeSZQgSxN3mReHJJYxcMbE63dWP Zvm2WMg6RKHEREwKtHUIlals5O4+zps0AayBoI002PhZXgBaD1eoTnj7GiktZRUg4ORE 9QnqsKF9sLweSK+68lcf5WfHPaqeQTMEA+2tTRUdWjlRbTvbcMpJ8Xy4zi9bA2/T31fY 94HQ== X-Received: by 10.69.19.129 with SMTP id gu1mr57094597pbd.162.1432067732937; Tue, 19 May 2015 13:35:32 -0700 (PDT) Received: from ?IPv6:2406:e007:4858:1:28cc:dc4c:9703:6781? ([2406:e007:4858:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dp4sm13880045pbb.82.2015.05.19.13.35.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 13:35:31 -0700 (PDT) Message-ID: <555B9E93.8040706@gmail.com> Date: Wed, 20 May 2015 08:35:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Joe Touch , sthaug@nethelp.no, otroan@employees.org References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> In-Reply-To: <555B8712.9080906@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:35:35 -0000 On 20/05/2015 06:55, Joe Touch wrote: > > > On 5/18/2015 4:43 AM, sthaug@nethelp.no wrote: >>>> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. >>> >>> this is clearly wrong. FH, AH, ESP are all widely deployed. >>> any form of tunnelling is essentially either using the IP header as an extension header. including GRE. >> >> AH is in RFC 2402 (1998). >> ESP is in RFC 2406 (1998). >> FH is in RFC 2460 (1998). >> >> Do we have any examples of Internet-scale use cases where the extension >> header has been defined *after* RFC 2460? > > The following are defined after 2460: To be clear, there is now an IANA registry for this, defined by RFC 7045: http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header Brian > > 135 Mobility Header [RFC6275] > 139 Host Identity Protocol [RFC7401] > 140 Shim6 Protocol [RFC5533] > 253 Use for experimentation and testing [RFC3692][RFC4727] > 254 Use for experimentation and testing [RFC3692][RFC4727] > > FWIW. > > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 19 13:48:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014541B3205 for ; Tue, 19 May 2015 13:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db3iwJngZEPd for ; Tue, 19 May 2015 13:48:05 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4497A1B323E for ; Tue, 19 May 2015 13:48:05 -0700 (PDT) Received: by padbw4 with SMTP id bw4so39346029pad.0 for ; Tue, 19 May 2015 13:48:05 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/DStZiOSmbJUGmRfDsygcjgF3Pm/D3hv/rym0UIxQgo=; b=D8kx/9YBMPNpVrgLbV2tSb8/yBysfLj1Wlg9w2WQOm+dP82VYqu0AF4K4pyowF4lJU 3mWbEJJqbjveYCOQGoA2dwaIXqbVkAivdWllK4jWl9vQaTAugy2z5p0vYvFt5NveEIwM 04DJ95KUlPCIriGa3Kks1363h+g8Qo7S2GQMRNQji2ktK/YYSc9bKQ5szkW5d2siE2Uu YpWtrm+q1KqLwvYedr0mEIDvFy0K3zzIXOJlGexGxRCU3wVZIfHL6yGDROxjU5nkN3iD LZOlm6GIqcNCjlqAUi1Gtww2VuntSSQauOb2EQDFu78zg7IgyzsYLMwg73ouVYYKYCLQ yxQg== X-Received: by 10.70.127.138 with SMTP id ng10mr57495001pdb.111.1432068485012; Tue, 19 May 2015 13:48:05 -0700 (PDT) Received: from ?IPv6:2406:e007:4858:1:28cc:dc4c:9703:6781? ([2406:e007:4858:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id nn6sm13932507pdb.79.2015.05.19.13.48.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 13:48:03 -0700 (PDT) Message-ID: <555BA184.8080701@gmail.com> Date: Wed, 20 May 2015 08:48:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> In-Reply-To: <555B8622.5000806@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:48:07 -0000 On 20/05/2015 06:51, Joe Touch wrote: > > > On 5/19/2015 11:14 AM, Ted Lemon wrote: >> On May 19, 2015, at 12:15 AM, Fernando Gont wrote: >>> * The size of IPv4 options is very limited (well under 128 bytes) >>> >>> * IYou only need to look at the IHL of the IPv4 packet to be able to >>> jump to the layer-4 protocol header. -- there's no such a thing in IPv6. >> >> I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application). >> >> Maybe we should have an extension header that says where the transport header is... ;) > > I briefly considered this at various times when this thread keeps > reappearing, but it would need to be another "HBH" header because it > needs to be examined and/or modified at any hop that modifies any other > extension header. No. RFC 2460 makes it clear that hops don't modify extension headers (except for shuffling within a routing header). Also, there is a draft for this: https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 (which does discuss the security issue; as with the evil bit, a firewall would be foolish to trust this option). Brian > > IPv4 knows where the transport header is but has limited option space > and can't natively support "shim" protocol layers inbetween IP and TCP > BUT it can find the transport header with localized info. > > IPv6 makes the opposite trade-off. > > Joe > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 19 14:00:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77621B2A9A for ; Tue, 19 May 2015 14:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItXPiKJ1UJJD for ; Tue, 19 May 2015 14:00:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231AD1B2A99 for ; Tue, 19 May 2015 14:00:17 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4JKxid8024029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 13:59:45 -0700 (PDT) Message-ID: <555BA43F.8010303@isi.edu> Date: Tue, 19 May 2015 13:59:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> In-Reply-To: <555BA184.8080701@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t4JKxid8024029 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:00:19 -0000 On 5/19/2015 1:48 PM, Brian E Carpenter wrote: > On 20/05/2015 06:51, Joe Touch wrote: >> >> >> On 5/19/2015 11:14 AM, Ted Lemon wrote: >>> On May 19, 2015, at 12:15 AM, Fernando Gont wrote: >>>> * The size of IPv4 options is very limited (well under 128 bytes) >>>> >>>> * IYou only need to look at the IHL of the IPv4 packet to be able to >>>> jump to the layer-4 protocol header. -- there's no such a thing in IPv6. >>> >>> I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application). >>> >>> Maybe we should have an extension header that says where the transport header is... ;) >> >> I briefly considered this at various times when this thread keeps >> reappearing, but it would need to be another "HBH" header because it >> needs to be examined and/or modified at any hop that modifies any other >> extension header. > > No. RFC 2460 makes it clear that hops don't modify extension headers > (except for shuffling within a routing header). HBH headers are the exception and can be modified in-transit, which would affect a transport-offset header. FWIW, though, RFC2460 also clearly states: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. If that were actually enforced, we would not need a transport-offset header because routers would never be looking there. > Also, there is a draft for this: > https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 > > (which does discuss the security issue; as with the evil bit, a firewall > would be foolish to trust this option). But fails to address the fact that this option might need to be updated whenever any other extension header is modified. Joe From nobody Tue May 19 14:37:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183671B3360 for ; Tue, 19 May 2015 14:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPCwg72LUwq7 for ; Tue, 19 May 2015 14:37:26 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C3E1B3357 for ; Tue, 19 May 2015 14:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 89A3052; Tue, 19 May 2015 23:37:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1432071441; bh=xvMR3heiRw4NeBwNOBgCQV7655NigxpaNMZh/I+Q/lo=; b=M 7EO9VIjwt8S+x+iH3BY9PkLpry4W3PD3TIg4VBATzWFDzcmwhdI2PDGxx08TApJV eA/sq+WozYqXK1ZMmaSLZf0ISYFxM2thcTdHX5Kv4MO+gVQl2bLz7NdwELYb/8uA aF8PmN0t5wQyKqAnvJHRcwshG2zhWp1CW8vzImZVYw= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UI6fjdSbzaSG; Tue, 19 May 2015 23:37:21 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [IPv6:2a00:8640:1:0:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTPSA id 37EF34D; Tue, 19 May 2015 23:37:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <555BA184.8080701@gmail.com> Date: Tue, 19 May 2015 23:37:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <477839EA-7270-4321-AA12-763AD27ADBD9@steffann.nl> References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:37:28 -0000 Hi, > Op 19 mei 2015, om 22:48 heeft Brian E Carpenter = het volgende geschreven: >=20 > No. RFC 2460 makes it clear that hops don't modify extension headers > (except for shuffling within a routing header). >=20 > Also, there is a draft for this: > https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >=20 > (which does discuss the security issue; as with the evil bit, a = firewall > would be foolish to trust this option). What this says is basically that any device that might benefit from this = option would be foolish to trust it :) Cheers, Sander From nobody Tue May 19 16:09:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2AD1B350B for ; Tue, 19 May 2015 16:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qx7N5yO3osf for ; Tue, 19 May 2015 16:09:29 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861281B3507 for ; Tue, 19 May 2015 16:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1432076968; bh=ZlDhnfDcmH6OH24oLGvJQKf5EjgaFIE4VDVWuyZgldc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=itmwB5Folyy1sLyzcm64lD3bnIVBh7s0e4dZmHH3QWGZ6Tb9LyukOXCkINv1qtW16egqArwy+Xl5AQcGzTgFCy8kZfo94aqe6LQMxXJD4u39Eqz1MovSCfCBsKqxNBPTu5e4UWzUZH+neeWefcXpjNzIOLgqZVqVm2mVacRg6N6kl2Nlm0XwUYrwnVIWjBw0EtH/ULv4IakJx+FypIxh2AW0AQL+3BVykdROLPn+aQJXymjlsS4pE6v5diNjKCKN36Xb7RrD7vJov/n1gILB40miUfunEY9IFj7M0pBLbYDtlhhxiPKj5osSaYWX+Sq4c14T6ZRDjBXp29gkALtfvw== Received: from [98.139.215.143] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 19 May 2015 23:09:28 -0000 Received: from [98.139.212.219] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 19 May 2015 23:09:28 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 19 May 2015 23:09:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 401170.85204.bm@omp1028.mail.bf1.yahoo.com X-YMail-OSG: ErZtzMMVM1myIqYgotk_1KhK_ZNyz9c2wo5OZ6ERPvd9bpgZ26_jeyIjoZJUXVv xSg1gW_gC5bWe0dnsWJ6RgT0h6TTnE9zgI.xZyplTLhq.wZKJK5XTTTpai19i7MpJ7cD_raaGPsl hDeHRXOktaKaDMX6M.obKrPifgfUOtKiM9C8xT28R84WWAFu8u2JAtoOglhpxYp7QEgDUyV3l3cI Esy5fSFY0nNzMqnvrjY5mPEwsAsMv4p7OfkOWkaLL1NrYCDdskHpBr_go_6CkmGaWyaEHbdYD1FP vftoEZ_3NEE1e4S.r4CzMXiJI1wNQ1X_fikszfLpZvqS09pZT2RboahnWqE8HYMpfOkoPltouZ7u g0IOhz_VklLcDsLgiytt7C4QsG7Oecel0vg5fsLamVoElpv1x4DTx_FEIHsuFYOLek6nUsROVccw NR65Yg1_ZknUG6LQ.dClaa3ylimEt5iiUdBynxVXdqE1i3ZF2ZgIJCpNiYQK1efy5Qn8hw3AypKm GzExkv4BANFq0Lu__xyYgc29zdzLQjpQgftokXRf2cg-- Received: by 66.196.80.149; Tue, 19 May 2015 23:09:27 +0000 Date: Tue, 19 May 2015 23:09:12 +0000 (UTC) From: Mark ZZZ Smith To: Gert Doering Message-ID: <66133361.2848561.1432076952679.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150516211840.GJ54385@Space.Net> References: <20150516211840.GJ54385@Space.Net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2848560_466985012.1432076952670" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:09:31 -0000 ------=_Part_2848560_466985012.1432076952670 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Gert Doering To: Mark ZZZ Smith =20 Cc: Enno Rey ; "v6ops@ietf.org" =20 Sent: Sunday, 17 May 2015, 7:18 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices =20 Hi, On Sat, May 16, 2015 at 01:22:26AM +0000, Mark ZZZ Smith wrote: > So quickly, how have IPv4 options been handled?=20 > They too can vary the location of the TCP/UDP etc. headers in an IPv4 pac= ket.=20 "Drop packets with IP options". / So you're actively doing that? I've configured routers to drop IPv4 packe= ts with source route options, but not IPv4 packets with any options. > How have the variety and variable number of TCP options been handled? The= y=20 > too can vary the location of the TCP segment payload. But they do not move the location of the TCP port info. / So what do you do with non-TCP or UDP traffic, that doesn't have port num= bers? Drop that too? / What particular problem are you trying to solve with forwarding plane ACL= s? Dropping DDoS traffic? How would you handle a DDoS that doesn't use TCP = or UDP, or for which the TCP/UDP ports aren't accessible? Gert Doering =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USt-IdNr.: DE813= 185279 ------=_Part_2848560_466985012.1432076952670 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
=

= From: Gert Doering <gert= @space.net>
To:<= /span> Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Cc: Enno Rey <erey@e= rnw.de>; "v6ops@ietf.org" <v6ops@ietf.org>
= Sent: Sunday, 17 May 2015, 7:1= 8
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices

Hi,

On Sat, May 16, 2015 at 01:22:26AM +0000, Mark= ZZZ Smith wrote:
> So quickly, how have IPv4 options = been handled?
> They too can vary the location of the= TCP/UDP etc. headers in an IPv4 packet.

"Drop packets with IP options".

/ So you're ac= tively doing that? I've configured routers to drop IPv4 packets with source= route options, but not IPv4 packets with any options.


> How have the variety and variable number of TCP o= ptions been handled? They
> too can vary the location= of the TCP segment payload.


But= they do not move the location of the TCP port info.

/ So what do you do with = non-TCP or UDP traffic, that doesn't have port numbers? Drop that too?

/ What = particular problem are you trying to solve with forwarding plane ACLs? Drop= ping DDoS traffic? How would you handle a DDoS that doesn't use TCP or UDP,= or for which the TCP/UDP ports aren't accessible?



Gert Doering
    =     -- NetMaster
--
have you= enabled IPv6 on something today...?

S= paceNet AG                  &n= bsp;     Vorstand: Sebastian v. Bomhard
Joseph-= Dollinger-Bogen 14          Aufsichtsratsvors.: A.= Grundner-Culemann
D-80807 Muenchen      &= nbsp;           HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444          USt-= IdNr.: DE813185279



<= /div>
------=_Part_2848560_466985012.1432076952670-- From nobody Tue May 19 16:52:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350191A873D for ; Tue, 19 May 2015 16:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlxFs3PvyGwR for ; Tue, 19 May 2015 16:52:21 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA05E1A1A77 for ; Tue, 19 May 2015 16:52:21 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so45471051pdb.1 for ; Tue, 19 May 2015 16:52:21 -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=16XvM0z/vSbfc42I21BQ/pGTm2hjpedb2/Xs3ukoK64=; b=riyXXXK5dT4UhQZG5tjBZrhKxZN84so0mVPEe92asmZOlz5u1gcQG5lusDAn2rcOuY wVGOvViCJ/EmFURtQMQMwi+POhOTLzVN/tHIVPhZ49PkkCVGKK9GOW9ZXcJKF0eFIG5g hCkg+1FLUAbt1qonvKuniLsZ7bOibRmN70pJoHSb9wSzjIGEmmUegGqXx7GpCb+PnFvJ HauSPmq23Od3JCteUZfp19tMvoNOERqUJJWJVtsk3+OquQzq6kb+IBv5bv/05YQj/MrO hIXdLNBb3RxzbevUa7FeB6Qmsu1Evrq80Go9MhN7uCZoa7Dl9wNsX8+HiHtJcQUasCV3 mm9A== X-Received: by 10.70.128.110 with SMTP id nn14mr58958100pdb.135.1432079541263; Tue, 19 May 2015 16:52:21 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id bc3sm14117922pbb.47.2015.05.19.16.52.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 16:52:20 -0700 (PDT) Message-ID: <555BCCB3.9050103@gmail.com> Date: Wed, 20 May 2015 11:52:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sander Steffann References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <477839EA-7270-4321-AA12-763AD27ADBD9@steffann.nl> In-Reply-To: <477839EA-7270-4321-AA12-763AD27ADBD9@steffann.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:52:23 -0000 On 20/05/2015 09:37, Sander Steffann wrote: > Hi, > >> Op 19 mei 2015, om 22:48 heeft Brian E Carpenter het volgende geschreven: >> >> No. RFC 2460 makes it clear that hops don't modify extension headers >> (except for shuffling within a routing header). >> >> Also, there is a draft for this: >> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >> >> (which does discuss the security issue; as with the evil bit, a firewall >> would be foolish to trust this option). > > What this says is basically that any device that might benefit from this option would be foolish to trust it :) No, things like load balancers and diffserv classifiers could use it (inside a suitably paranoid firewall, indeed). Brian From nobody Tue May 19 22:41:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92EF1B3593; Tue, 19 May 2015 22:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDdNvwu_lpZd; Tue, 19 May 2015 22:40:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D238D1B3594; Tue, 19 May 2015 22:40:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150520054056.9122.82483.idtracker@ietfa.amsl.com> Date: Tue, 19 May 2015 22:40:56 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 05:40:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB) Authors : Matt Byerly Matt Hite Joel Jaeggli Filename : draft-ietf-v6ops-pmtud-ecmp-problem-01.txt Pages : 8 Date : 2015-05-19 Abstract: This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 20 01:14:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5537B1ACD9A for ; Wed, 20 May 2015 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7g7vBHnRBfu for ; Wed, 20 May 2015 01:14:34 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4801ACAD8 for ; Wed, 20 May 2015 01:14:33 -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 t4K8EOAs017511; Wed, 20 May 2015 09:14:24 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t4K8EOAs017511 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1432109666; bh=oFVzuigiaVBwGWlDWD9LznOGEvc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=tCsjf7dSuvWZ+0SE0dwkgGzk3PRXb9yfn5otP9FRPFXFLxVRI5CmIzfPQ2nb3QEwT 21lPfgcSUFBrVF5kgTBINsz66Oufuu1lIVVzjt8OF0WpISKEnmUMUW4rIvt2wk0U20 C1shDkqmlSds+z8+tloN41F9vE/JX6Ab1ToG5Ch0= 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 r4J9EO20289021256q ret-id none; Wed, 20 May 2015 09:14:26 +0100 Received: from [IPv6:2001:630:d0:f111:d141:a0df:b442:ece1] ([IPv6:2001:630:d0:f111:d141:a0df:b442:ece1]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t4K8ENxg009687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 09:14:24 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Tim Chown In-Reply-To: <555B8712.9080906@isi.edu> Date: Wed, 20 May 2015 09:14:25 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> <1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk> To: Joe Touch X-Mailer: Apple Mail (2.2098) X-smtpf-Report: sid=r4J9EO202890212500; tid=r4J9EO20289021256q; 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: t4K8EOAs017511 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:14:37 -0000 > On 19 May 2015, at 19:55, Joe Touch wrote: >=20 > On 5/18/2015 4:43 AM, sthaug@nethelp.no wrote: >>>> - it has not happened in the past 17 yrs (since publication of = RFC2460) that compelling, Internet-scale use cases of extension headers = have been brought up. >>>=20 >>> this is clearly wrong. FH, AH, ESP are all widely deployed. >>> any form of tunnelling is essentially either using the IP header as = an extension header. including GRE. >>=20 >> AH is in RFC 2402 (1998). >> ESP is in RFC 2406 (1998). >> FH is in RFC 2460 (1998). >>=20 >> Do we have any examples of Internet-scale use cases where the = extension >> header has been defined *after* RFC 2460? >=20 > The following are defined after 2460: >=20 > 135 Mobility Header [RFC6275] > 139 Host Identity Protocol [RFC7401] > 140 Shim6 Protocol [RFC5533] > 253 Use for experimentation and testing [RFC3692][RFC4727] > 254 Use for experimentation and testing [RFC3692][RFC4727] >=20 > FWIW. Which, as I think you imply, haven=E2=80=99t exactly been widely = implemented or successfully used. The other question is what existing work is being done that relies on = the correct (desired) operation of EHs? The two that would spring out = would be segment routing and sfc, at least one of which is using the = existing Routing Header. If such protocols are constrained to specific = administrative domains then their successful operation I would assume is = down to specific EH handling in the equipment in that domain, and its = capabilities, rather than (undesired) operator filtering somewhere = between sender and receiver. Tim= From nobody Wed May 20 05:28:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A30C1A0067 for ; Wed, 20 May 2015 05:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uty5FVsa0Nan for ; Wed, 20 May 2015 05:28:35 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C815E1A0055 for ; Wed, 20 May 2015 05:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1432124913; x=1433334513; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OFJFA7Umekv/TEAuDctuupotfIoBbPID4dMDs+ClKWo=; b=OO0SsdnvfNv0vWfh+tMYtCAi+ucyjzu4jVq8uC4fNMlRJ9u0zbtEK+Jf yJ78/7CoSEfpId/+iKSJS6YO2k8qN6zCxk+wYxwb1jJTnTeaCwIgbsZ0W 3KoWD7cthW64GtEVbYVOrlo5nx7Wg5EPyNJHUOSwIzHWAlThmL7XmkhBc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBADTfFxV/4cNJK1cDoMCgTIGgxjBXQmHUQIcgR04FAEBAQEBAQGBCoQjAQEEIxFFEAIBCA4KAgImAgICMBUQAgQBDQWILKgtpB0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKGYRqGweCaIFFAQSScIsAlxQjgWaBVD5vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,464,1427760000"; d="scan'208";a="151793223" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 May 2015 12:28:32 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4KCSWnC009079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 12:28:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 20 May 2015 07:28:32 -0500 From: "Eric Vyncke (evyncke)" To: Tim Chown , Joe Touch Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52B3yyAgAAWQQCAAgsLAIAA30qAgABohAA= Date: Wed, 20 May 2015 12:28:31 +0000 Message-ID: References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> <1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.69] Content-Type: text/plain; charset="utf-8" Content-ID: <9DDB68C196581545A8BBEB0EE7268DD3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 12:28:36 -0000 T24gMjAvMDUvMTUgMTA6MTQsICJUaW0gQ2hvd24iIDx0amNAZWNzLnNvdG9uLmFjLnVrPiB3cm90 ZToNCj4NCj5UaGUgb3RoZXIgcXVlc3Rpb24gaXMgd2hhdCBleGlzdGluZyB3b3JrIGlzIGJlaW5n IGRvbmUgdGhhdCByZWxpZXMgb24gdGhlDQo+Y29ycmVjdCAoZGVzaXJlZCkgb3BlcmF0aW9uIG9m IEVIcz8gVGhlIHR3byB0aGF0IHdvdWxkIHNwcmluZyBvdXQgd291bGQNCj5iZSBzZWdtZW50IHJv dXRpbmcgYW5kIHNmYywgYXQgbGVhc3Qgb25lIG9mIHdoaWNoIGlzIHVzaW5nIHRoZSBleGlzdGlu Zw0KPlJvdXRpbmcgSGVhZGVyLiBJZiBzdWNoIHByb3RvY29scyBhcmUgY29uc3RyYWluZWQgdG8g c3BlY2lmaWMNCj5hZG1pbmlzdHJhdGl2ZSBkb21haW5zIHRoZW4gdGhlaXIgc3VjY2Vzc2Z1bCBv cGVyYXRpb24gSSB3b3VsZCBhc3N1bWUgaXMNCj5kb3duIHRvIHNwZWNpZmljIEVIIGhhbmRsaW5n IGluIHRoZSBlcXVpcG1lbnQgaW4gdGhhdCBkb21haW4sIGFuZCBpdHMNCj5jYXBhYmlsaXRpZXMs IHJhdGhlciB0aGFuICh1bmRlc2lyZWQpIG9wZXJhdG9yIGZpbHRlcmluZyBzb21ld2hlcmUNCj5i ZXR3ZWVuIHNlbmRlciBhbmQgcmVjZWl2ZXIuDQoNClRoZSBwcmltYXJ5IHVzZSBjYXNlIG9mIHNl Z21lbnQgcm91dGluZyBpcyBpbmRlZWQgd2l0aGluIGEgc2luZ2xlDQphZG1pbmlzdHJhdGl2ZSBk b21haW4sIHNvLCBFSCBkb2VzIG5vdCBjYXVzZSBhIHByb2JsZW0uDQoNCk9UT0gsIHRoaXMgd2hv bGUgZGlzY3Vzc2lvbiBpcyBwcmV0dHkgY2xvc2UgdG8gaGF2aW5nIGEgZGlzY3Vzc2lvbiBvbg0K d2hldGhlciBhbiBJU1Agc2hvdWxkIGJsb2NrIGV2ZXJ5dGhpbmcgd2hpY2ggaXMgbmVpdGhlciBV RFAgbm9yIFRDUD8gT3INCmJsb2NrIGN1cnJlbnRseS11bmFsbG9jYXRlZCBUQ1AvVURQIHBvcnRz PyAoYW5kIEkgYXBwcmVjaWF0ZSB0aGF0IHRoZXJlDQphcmUgZGlmZmVyZW5jZXMgb2YgY291cnNl KS4NCg0KVG8gRW5ubydzIG9yaWdpbmFsIHBvaW50OiBpdCBpcyBmYWlyIGZvciBhIGRlc3RpbmF0 aW9uIGRvbWFpbiB0byBoYW5kbGUNCihwZXJtaXQsIGRyb3AsIGxvZywgaW5zcGVjdCkgaW5jb21p bmcgKG9yIG91dGdvaW5nIEJUVykgcGFja2V0cyBiYXNlZCBvbg0KbGF5ZXItNCBwb3J0cywgbGF5 ZXItNCBwcm90b2NvbHMgb3IgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoaXMgaXMgdGhlaXIgb3duDQpy ZXNwb25zaWJpbGl0eQ0KDQotw6lyaWMNCg0K From nobody Wed May 20 08:43:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A899B1A88CF; Wed, 20 May 2015 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvxDSO55CxAi; Wed, 20 May 2015 08:43:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id F36FA1A88C9; Wed, 20 May 2015 08:43:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E8D5B180207; Wed, 20 May 2015 08:41:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150520154121.E8D5B180207@rfc-editor.org> Date: Wed, 20 May 2015 08:41:21 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] BCP 196, RFC 7526 on Deprecating the Anycast Prefix for 6to4 Relay Routers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:43:07 -0000 A new Request for Comments is now available in online RFC libraries. BCP 196 RFC 7526 Title: Deprecating the Anycast Prefix for 6to4 Relay Routers Author: O. Troan, B. Carpenter, Ed. Status: Best Current Practice Stream: IETF Date: May 2015 Mailbox: ot@cisco.com, brian.e.carpenter@gmail.com Pages: 10 Characters: 20894 Obsoletes: RFC 3068, RFC 6732 See Also: BCP 196 I-D Tag: draft-ietf-v6ops-6to4-to-historic-11.txt URL: https://www.rfc-editor.org/info/rfc7526 DOI: http://dx.doi.org/10.17487/RFC7526 Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343. This document is a product of the IPv6 Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 21 07:38:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6641A1BC6 for ; Thu, 21 May 2015 07:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh_nsBhHo5o7 for ; Thu, 21 May 2015 07:38:54 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3861A1AA8 for ; Thu, 21 May 2015 07:38:12 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CA673340817; Thu, 21 May 2015 16:38:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/10415.1968); Thu, 21 May 2015 16:38:07 +0200 (CEST) Received: from owa.hextop.ch (owa.hextop.ch [212.25.0.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 21 May 2015 16:38:07 +0200 (CEST) Received: from HEX02.hextop.ch ([212.25.0.68]) by hex02 ([212.25.0.68]) with mapi id 14.01.0438.000; Thu, 21 May 2015 16:38:07 +0200 From: Silvia Hagen To: "Eric Vyncke (evyncke)" , Tim Chown , Joe Touch Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOc1Jlz46hQy0yE3Gbhq1u2w52BadSAgAAWQQCAAgsKAIAA30qAgABG/4CAAdb2wA== Date: Thu, 21 May 2015 14:38:07 +0000 Message-ID: References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> <1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk> In-Reply-To: Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:120b:c3ea:36c0:d4ab:4fca:ffb5:a17f] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:38:56 -0000 U28gdG8gc3VtbWFyaXplOg0KDQpFSCBzdWNoIGFzIGRlc3RpbmF0aW9uIG9wdGlvbiBhbmQgZnJh Z21lbnQgaXMgbm8gaXNzdWUgaW4gdGhlIEludGVybmV0IGFuZCBtdXN0IG5vdCBiZSBmaWx0ZXJl ZCwgbm9yIGFuYWx5emVkLCBzaW1wbHkgZm9yd2FyZGVkIGluIGhhcmR3YXJlIGJhc2VkIG9uIHRo ZSBpbmZvcm1hdGlvbiBpbiB0aGUgSVB2NiBoZWFkZXIuDQpBbmQgd2hhdCB0aGUgYWRtaW5pc3Ry YXRvciBkb2VzIHdpdGhpbiBoaXMgYWRtaW5pc3RyYXRpdmUgZG9tYWluIGlzIHVwIHRvIGhpcyBj aG9pY2UgYW5kIHRoZSBJbnRlcm5ldCBuZWVkcyBub3QgY2FyZSBhYm91dCBpdA0KDQpJcyB0aGF0 IGNvcnJlY3Q/DQpJZiB5ZXMsIHdoYXQgaXMgdGhlIHByb2JsZW0/DQoNCklmIHRoYXQgaXMgaG93 IGl0IGlzIHN1cHBvc2VkIHRvIHdvcmsgd2UgbmVlZCB0byBlZHVjYXRlIHBlb3BsZSB0aGF0IGZl ZWwgdGhhdCBFSHMgbXVzdCBiZSBmaWx0ZXJlZCBpbiB0aGUgSW50ZXJuZXQuDQpOb3cgaG9wLWJ5 LWhvcCBpcyBvYnZpb3VzbHkgZGlmZmZlcmVudC4gQnV0IGlzIGl0IG5lZWRlZCBpbiB0aGUgSW50 ZXJuZXQ/IEFnYWluLCB3aGF0IEkgZG8gaW50ZXJuYWxseSwgbm9ib2R5IG91dCB0aGVyZSBjYXJl cy4NCg0KU2lsdmlhDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9u OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEVy aWMgVnluY2tlIChldnluY2tlKQ0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAyMC4gTWFpIDIwMTUgMTQ6 MjkNCkFuOiBUaW0gQ2hvd247IEpvZSBUb3VjaA0KQ2M6IHY2b3BzQGlldGYub3JnDQpCZXRyZWZm OiBSZTogW3Y2b3BzXSBFeHRlbnNpb24gSGVhZGVycyAvIEltcGFjdCBvbiBTZWN1cml0eSBEZXZp Y2VzDQoNCk9uIDIwLzA1LzE1IDEwOjE0LCAiVGltIENob3duIiA8dGpjQGVjcy5zb3Rvbi5hYy51 az4gd3JvdGU6DQo+DQo+VGhlIG90aGVyIHF1ZXN0aW9uIGlzIHdoYXQgZXhpc3Rpbmcgd29yayBp cyBiZWluZyBkb25lIHRoYXQgcmVsaWVzIG9uIA0KPnRoZSBjb3JyZWN0IChkZXNpcmVkKSBvcGVy YXRpb24gb2YgRUhzPyBUaGUgdHdvIHRoYXQgd291bGQgc3ByaW5nIG91dCANCj53b3VsZCBiZSBz ZWdtZW50IHJvdXRpbmcgYW5kIHNmYywgYXQgbGVhc3Qgb25lIG9mIHdoaWNoIGlzIHVzaW5nIHRo ZSANCj5leGlzdGluZyBSb3V0aW5nIEhlYWRlci4gSWYgc3VjaCBwcm90b2NvbHMgYXJlIGNvbnN0 cmFpbmVkIHRvIHNwZWNpZmljIA0KPmFkbWluaXN0cmF0aXZlIGRvbWFpbnMgdGhlbiB0aGVpciBz dWNjZXNzZnVsIG9wZXJhdGlvbiBJIHdvdWxkIGFzc3VtZSANCj5pcyBkb3duIHRvIHNwZWNpZmlj IEVIIGhhbmRsaW5nIGluIHRoZSBlcXVpcG1lbnQgaW4gdGhhdCBkb21haW4sIGFuZCANCj5pdHMg Y2FwYWJpbGl0aWVzLCByYXRoZXIgdGhhbiAodW5kZXNpcmVkKSBvcGVyYXRvciBmaWx0ZXJpbmcg c29tZXdoZXJlIA0KPmJldHdlZW4gc2VuZGVyIGFuZCByZWNlaXZlci4NCg0KVGhlIHByaW1hcnkg dXNlIGNhc2Ugb2Ygc2VnbWVudCByb3V0aW5nIGlzIGluZGVlZCB3aXRoaW4gYSBzaW5nbGUgYWRt aW5pc3RyYXRpdmUgZG9tYWluLCBzbywgRUggZG9lcyBub3QgY2F1c2UgYSBwcm9ibGVtLg0KDQpP VE9ILCB0aGlzIHdob2xlIGRpc2N1c3Npb24gaXMgcHJldHR5IGNsb3NlIHRvIGhhdmluZyBhIGRp c2N1c3Npb24gb24gd2hldGhlciBhbiBJU1Agc2hvdWxkIGJsb2NrIGV2ZXJ5dGhpbmcgd2hpY2gg aXMgbmVpdGhlciBVRFAgbm9yIFRDUD8gT3IgYmxvY2sgY3VycmVudGx5LXVuYWxsb2NhdGVkIFRD UC9VRFAgcG9ydHM/IChhbmQgSSBhcHByZWNpYXRlIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVuY2Vz IG9mIGNvdXJzZSkuDQoNClRvIEVubm8ncyBvcmlnaW5hbCBwb2ludDogaXQgaXMgZmFpciBmb3Ig YSBkZXN0aW5hdGlvbiBkb21haW4gdG8gaGFuZGxlIChwZXJtaXQsIGRyb3AsIGxvZywgaW5zcGVj dCkgaW5jb21pbmcgKG9yIG91dGdvaW5nIEJUVykgcGFja2V0cyBiYXNlZCBvbg0KbGF5ZXItNCBw b3J0cywgbGF5ZXItNCBwcm90b2NvbHMgb3IgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoaXMgaXMgdGhl aXIgb3duIHJlc3BvbnNpYmlsaXR5DQoNCi3DqXJpYw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu May 21 08:00:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14D61A6FF1 for ; Thu, 21 May 2015 08:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlmaMDOnWfqf for ; Thu, 21 May 2015 08:00:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDB41A6FEB for ; Thu, 21 May 2015 08:00:26 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t4LF0Nxg073213 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 May 2015 16:00:24 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <555DF307.9010109@foobar.org> Date: Thu, 21 May 2015 16:00:23 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org> <20150518.134312.74662992.sthaug@nethelp.no> <555B8712.9080906@isi.edu> <1A7F7D26-BBFD-4981-BF1C-978115C0B90A@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:00:29 -0000 Your summary is not correct. The problems with EHs have been discussed extensively on this mailing list. Please see the archives for what the problems are. Nick On 21/05/2015 15:38, Silvia Hagen wrote: > So to summarize: > > EH such as destination option and fragment is no issue in the Internet and must not be filtered, nor analyzed, simply forwarded in hardware based on the information in the IPv6 header. > And what the administrator does within his administrative domain is up to his choice and the Internet needs not care about it > > Is that correct? > If yes, what is the problem? > > If that is how it is supposed to work we need to educate people that feel that EHs must be filtered in the Internet. > Now hop-by-hop is obviously diffferent. But is it needed in the Internet? Again, what I do internally, nobody out there cares. > > Silvia > > > -----Ursprüngliche Nachricht----- > Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Eric Vyncke (evyncke) > Gesendet: Mittwoch, 20. Mai 2015 14:29 > An: Tim Chown; Joe Touch > Cc: v6ops@ietf.org > Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices > > On 20/05/15 10:14, "Tim Chown" wrote: >> >> The other question is what existing work is being done that relies on >> the correct (desired) operation of EHs? The two that would spring out >> would be segment routing and sfc, at least one of which is using the >> existing Routing Header. If such protocols are constrained to specific >> administrative domains then their successful operation I would assume >> is down to specific EH handling in the equipment in that domain, and >> its capabilities, rather than (undesired) operator filtering somewhere >> between sender and receiver. > > The primary use case of segment routing is indeed within a single administrative domain, so, EH does not cause a problem. > > OTOH, this whole discussion is pretty close to having a discussion on whether an ISP should block everything which is neither UDP nor TCP? Or block currently-unallocated TCP/UDP ports? (and I appreciate that there are differences of course). > > To Enno's original point: it is fair for a destination domain to handle (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on > layer-4 ports, layer-4 protocols or extension headers. This is their own responsibility > > -éric > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu May 21 21:48:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD521A9108; Thu, 21 May 2015 21:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTvfUoZrIH7g; Thu, 21 May 2015 21:48:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A35211A9100; Thu, 21 May 2015 21:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150522044802.6573.47203.idtracker@ietfa.amsl.com> Date: Thu, 21 May 2015 21:48:02 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 04:48:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-v6ops-cidr-prefix-02: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Only editorial comments here, for your consideration. The one about "barring" is the most important one. -- Section 1 -- In the second paragraph, I suggest removing the parentheses from "(mis)". In the fourth paragraph, I had to read the first sentence several times in order to parse it. The word order confused me, making me think "link routing", rather than "to link". You can easily fix that by changing "to not link" to "not to link". In the fifth paragraph, "barring" is ambiguous: I don't know whether you mean that because IPv6 forwarding must follow the longest-match-first rule, configuration of an overriding policy is barred (forbidden), or whether you mean that IPv6 forwarding must follow the longest-match-first rule *unless* an overriding policy is configured. I'm guessing it's the latter, but you should reword this either way, to make it clear. In the last paragraph, what does "a historical reminder" mean? -- Section 2 -- In the second paragraph, I note that too many attributive nouns put together make for awkwardness and confusion. I suggest changing "Forwarding decision-making processes" to "Decision-making processes for forwarding", so it's clear that "forwarding" is a gerund (noun), not a participle (verb). I suggest removing the word "obviously" from the third paragraph: if it's really obvious, it needn't be said at all, and the word makes it sound haughty. From nobody Mon May 25 22:27:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2C1A7022 for ; Mon, 25 May 2015 22:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.201 X-Spam-Level: *** X-Spam-Status: No, score=3.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-S1Fa652kCU for ; Mon, 25 May 2015 22:27:04 -0700 (PDT) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359AF1A6FE9 for ; Mon, 25 May 2015 22:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1432618023; bh=Y45c2NWzTVgDewEvFTGg8zop6wf33QWXXz4cyKDBs6s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WqC2HGRQg4O21Aa85OFSCZa50JVJivYXRgGo+ulkgU0nLnHWcavEtPq9l4r1KfHqzLe+UMoHgQzivJKKUxKtaVtBbzLk19G7HPLHlnSibqbrrJfFXhdxYkscKkLdZhD51RO3YSvdO2Cy+OIRjX9dv5bf6ePAmBPL4oIqZkPYSbLGWC0o0N5jmw3B06End8PjWiAJSXKh4BK2PfSFJaMYEeB8Zgrni6Xw7ptqdAOKwyIGbAnx1vFrYHy1d+7TllZHuPjaGWGByJcvu80uXlSs0McJeXsErs5/7AjhMpgoj/wKq/k2m6cBRHvsRu7BnDbstJEqg+AhntyWJko/fLWaig== Received: from [98.139.214.32] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000 Received: from [98.139.212.210] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000 Received: from [127.0.0.1] by omp1019.mail.bf1.yahoo.com with NNFMP; 26 May 2015 05:27:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 479974.11340.bm@omp1019.mail.bf1.yahoo.com X-YMail-OSG: rUc_2i0VM1mPhjhuNu8vINsh5.LsaQ4XKT8d7VV4SXOThugNDDnqvZ9OVo1_cl3 ejPp.6oaLrNTmyq6AjJocuohgNKf0A.CZcHAWD3RqWB4tTOAJFEUBvnehggAM8P4DGWavnZEc_JR SGuyVHywTwt52FcT1nVl0bQ7dwSihh0wUh2kfgWCopclg__OHJifBYS89227pi6T5FMjW5aKhpyI pb9SXRpB7uRvMqIrKo.TnISP81lT6xm5BqAHSqnVWPhbWKu8xXMaEalLA.WpSgcF4nK1pALe_C3I jf673hm.taz6VjRg8FIu31CRTDuQ7P3PS6uyUg5cZXOYrbjsTxcxgLoB29ZbH5PongjcfN134KZm yYE1msWYvpStD_HPispGQ5C341LIU1DSQJMLD938FvuQ1mYqLRuz.eU2H7gY7UWU0_cNt_.X0AMp 8HDrmynriAWGew2gL4HIIwZ21KumWY0HKzGgdZxISB_D66fGOXxFkAv4pvbhifZCVPikeC0HtLHA J_IPLU0.YF9v_SYmTEFiuWmhGZzm6RFqVw3.h1unc570- Received: by 76.13.26.108; Tue, 26 May 2015 05:27:03 +0000 Date: Tue, 26 May 2015 05:27:00 +0000 (UTC) From: Mark ZZZ Smith To: "Eric Vyncke (evyncke)" , Tim Chown , Joe Touch Message-ID: <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 05:27:05 -0000 ________________________________ From: Eric Vyncke (evyncke) To: Tim Chown ; Joe Touch =20 Cc: "v6ops@ietf.org" =20 Sent: Wednesday, 20 May 2015, 22:28 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices On 20/05/15 10:14, "Tim Chown" wrote: > >The other question is what existing work is being done that relies on the >correct (desired) operation of EHs? The two that would spring out would >be segment routing and sfc, at least one of which is using the existing >Routing Header. If such protocols are constrained to specific >administrative domains then their successful operation I would assume is >down to specific EH handling in the equipment in that domain, and its >capabilities, rather than (undesired) operator filtering somewhere >between sender and receiver. The primary use case of segment routing is indeed within a single administrative domain, so, EH does not cause a problem. OTOH, this whole discussion is pretty close to having a discussion on whether an ISP should block everything which is neither UDP nor TCP? Or block currently-unallocated TCP/UDP ports? (and I appreciate that there are differences of course). / +1 / In my opinion a huge amount of security context is missing from this disc= ussion, to the point where the question has been simplified to a too simpli= stic and binary EHs or not question, and there is never going to be consens= us on that question. / There seems to be an underlying and unstated set of assumptions behind th= e sorts of "block EHs","must be able to look at TCP/UDP headers in the netw= ork" questions/statements :=20 / (a) the network is the only place that network, host and application secu= rity can and must be done, implying that hosts and applications do nothing = to protect themselves / (b) that the contents of packets will always remain transparent to the ne= twork, allowing them to be inspected in the network / and (c) that all traffic to and from a host/application will always trave= rse a single inspection/choke point in the network and will always use the = same Internet protocol. / I think all of the above assumptions were true up until about the mid 199= 0s (if I remember well enough). Since then, they've all become false to var= ying degrees. Consequently, a choke point in the network may not be the bes= t place to perform all network, host and application security measures, and= in some cases persisting with that model will cause security failures. (Fo= r example, it seems that hosts aren't the lowest hanging fruit for network = delivered malware any more, it is residential CPE itself - the device that = is supposed to be so effective at providing "security" (including implicitl= y via NAT) that theoretically downstream hosts don't need firewalls at all.= ) To Enno's original point: it is fair for a destination domain to handle (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on layer-4 ports, layer-4 protocols or extension headers. This is their own responsibility -=C3=A9ric _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 26 00:56:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87071B2A1C; Tue, 26 May 2015 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9CiZDp5qF4g; Tue, 26 May 2015 00:56:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 898FA1B2A1F; Tue, 26 May 2015 00:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526075615.31288.36436.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 00:56:15 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-cidr-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 07:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Prefix Length Recommendation for Forwarding Authors : Mohamed Boucadair Alexandre Petrescu Fred Baker Filename : draft-ietf-v6ops-cidr-prefix-03.txt Pages : 5 Date : 2015-05-26 Abstract: IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cidr-prefix-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 01:02:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478F71B2A2D; Tue, 26 May 2015 01:01:56 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOw3G8cH0cWx; Tue, 26 May 2015 01:01:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3181B2A2B; Tue, 26 May 2015 01:01:53 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id ABDB532406B; Tue, 26 May 2015 10:01:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 87BAA238062; Tue, 26 May 2015 10:01:51 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Tue, 26 May 2015 10:01:51 +0200 From: To: Barry Leiba Thread-Topic: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) Thread-Index: AQHQlEqHzgyl5kK/W06rrZfu1i+EEJ2N6zpA Date: Tue, 26 May 2015 08:01:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330053156A8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150522044802.6573.47203.idtracker@ietfa.amsl.com> In-Reply-To: <20150522044802.6573.47203.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.26.71517 Archived-At: Cc: "v6ops@ietf.org" , The IESG Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:01:56 -0000 Dear Barry, Many thanks for the careful review.=20 An updated version is available online. A diff is available at: https://www= .ietf.org/rfcdiff?url1=3Ddraft-ietf-v6ops-cidr-prefix-02&url2=3Ddraft-ietf-= v6ops-cidr-prefix-03=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Barry Leiba > Envoy=E9=A0: vendredi 22 mai 2015 06:48 > =C0=A0: The IESG > Cc=A0: v6ops@ietf.org > Objet=A0: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr- > prefix-02: (with COMMENT) >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-v6ops-cidr-prefix-02: No Objection >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Only editorial comments here, for your consideration. The one about > "barring" is the most important one. >=20 > -- Section 1 -- > In the second paragraph, I suggest removing the parentheses from > "(mis)". >=20 > In the fourth paragraph, I had to read the first sentence several times > in order to parse it. The word order confused me, making me think "link > routing", rather than "to link". You can easily fix that by changing "to > not link" to "not to link". >=20 > In the fifth paragraph, "barring" is ambiguous: I don't know whether you > mean that because IPv6 forwarding must follow the longest-match-first > rule, configuration of an overriding policy is barred (forbidden), or > whether you mean that IPv6 forwarding must follow the longest-match-first > rule *unless* an overriding policy is configured. I'm guessing it's the > latter, but you should reword this either way, to make it clear. >=20 > In the last paragraph, what does "a historical reminder" mean? >=20 > -- Section 2 -- > In the second paragraph, I note that too many attributive nouns put > together make for awkwardness and confusion. I suggest changing > "Forwarding decision-making processes" to "Decision-making processes for > forwarding", so it's clear that "forwarding" is a gerund (noun), not a > participle (verb). >=20 > I suggest removing the word "obviously" from the third paragraph: if it's > really obvious, it needn't be said at all, and the word makes it sound > haughty. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 26 05:46:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DC1B2B2F; Tue, 26 May 2015 05:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSWjd9QCeMrC; Tue, 26 May 2015 05:46:13 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B6F1A701A; Tue, 26 May 2015 05:46:13 -0700 (PDT) Received: by iepj10 with SMTP id j10so90717306iep.3; Tue, 26 May 2015 05:46:12 -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:message-id:subject :from:to:cc:content-type; bh=nQtyFSn49HElp9TPHXxWy05mJNkeIfbMlSwdKgg6LRE=; b=xGqXfYKkQLJCK0QwYyQ96R7itVmhGw8cIHLoPVJXP2P/Lme+Eh/EH9jh2sQ9IGGB1I kz0i/qApgvYnvBBcfE9vQ/nSRRjmKtB/FDISS7aZDLqYXx5vxVEIDdJErhPGj9WM8MrX pu9qABhh1vex3tsoGGk2SWHi8u06nlF7yRtPZ7Oww18Hq1hJPQJWhmau+/Kgg4BO5KRx LQ8Wx0y4ifBHtujkqlsQML82xO5uKJIXHLDKKJkK16zjZ1sJR/6GQwWUYm+NUr7qFNnw Ha+nm93/NWdcBSNrRfGh98U4bsK92l1YJMZLhx9TYOPWw7vVYqYD3uJJ4I+wIcRjojs0 hsPQ== MIME-Version: 1.0 X-Received: by 10.43.34.205 with SMTP id st13mr29500629icb.4.1432644372846; Tue, 26 May 2015 05:46:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Tue, 26 May 2015 05:46:12 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053156A8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150522044802.6573.47203.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053156A8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 26 May 2015 08:46:12 -0400 X-Google-Sender-Auth: 6cS3OWjj0lRK882FgZ8jQu2Ij5U Message-ID: From: Barry Leiba To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , The IESG Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 12:46:14 -0000 > Many thanks for the careful review. You're welcome, and thanks for addressing my comments. I've had a look at the revision, and it looks good. Barry From nobody Tue May 26 16:02:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95A1B32DC for ; Tue, 26 May 2015 16:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dXPq7IIWnu7 for ; Tue, 26 May 2015 16:02:13 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B811B32D8 for ; Tue, 26 May 2015 16:02:13 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so103343867pac.2 for ; Tue, 26 May 2015 16:02:12 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6dwsuZXZdaH9N30B5JKYIC602kgchQu6LFdIGkJ0BeE=; b=cuqcXk3/r6Ax3rA3Y7bMYGyOieZUoVy3IDve2xm2zhZOiQyywr1/wB6Ch+rwL+kG+1 DkPmbjp3IPVnW14hwXkrm+L0LmT+xdZsKWGeWuEeObaVp4G79bNT4LCblr5BMhgbNi0T KDSN2+gldeTlmv1DQSI2lIyM5jyK3LVipwZVB+pRUi8BUUSrso8+lC+dvjsWkz0hzZ/a 8VQA1teiMUgfnHiaKgLhsxxpczSzFZFfYRQztpN+oiypMMMSqiCczA6dyuNhjrOlttNq oxldT/wIDaWV7e3gE4ldQFFx8d5RABr95wQX9zRkV2QfpLk6dONvsfL4dds20rSspiXH Ng+A== X-Received: by 10.68.204.133 with SMTP id ky5mr53216971pbc.67.1432681332705; Tue, 26 May 2015 16:02:12 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id pw9sm14184395pac.27.2015.05.26.16.02.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:02:10 -0700 (PDT) Message-ID: <5564FB74.5020303@gmail.com> Date: Wed, 27 May 2015 11:02:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joe Touch , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> In-Reply-To: <555BA43F.8010303@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:02:14 -0000 On 20/05/2015 08:59, Joe Touch wrote: > > > On 5/19/2015 1:48 PM, Brian E Carpenter wrote: >> On 20/05/2015 06:51, Joe Touch wrote: >>> >>> >>> On 5/19/2015 11:14 AM, Ted Lemon wrote: >>>> On May 19, 2015, at 12:15 AM, Fernando Gont wrote: >>>>> * The size of IPv4 options is very limited (well under 128 bytes) >>>>> >>>>> * IYou only need to look at the IHL of the IPv4 packet to be able to >>>>> jump to the layer-4 protocol header. -- there's no such a thing in IPv6. >>>> >>>> I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application). >>>> >>>> Maybe we should have an extension header that says where the transport header is... ;) >>> >>> I briefly considered this at various times when this thread keeps >>> reappearing, but it would need to be another "HBH" header because it >>> needs to be examined and/or modified at any hop that modifies any other >>> extension header. >> >> No. RFC 2460 makes it clear that hops don't modify extension headers >> (except for shuffling within a routing header). > > HBH headers are the exception and can be modified in-transit, which > would affect a transport-offset header. I don't get where RFC 2460 allows that. > > FWIW, though, RFC2460 also clearly states: > > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > > If that were actually enforced, we would not need a transport-offset > header because routers would never be looking there. > >> Also, there is a draft for this: >> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01 >> >> (which does discuss the security issue; as with the evil bit, a firewall >> would be foolish to trust this option). > > But fails to address the fact that this option might need to be updated > whenever any other extension header is modified. s/updated/hacked/ s/modified/hacked/ Yes, anyone who munges headers en route has to deal with the consequences. That isn't news. Brian > > Joe > > From nobody Tue May 26 16:06:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021CF1B32F5 for ; Tue, 26 May 2015 16:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF0VU2Sh_xfG for ; Tue, 26 May 2015 16:06:22 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DF31B32F3 for ; Tue, 26 May 2015 16:06:22 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so103411429pac.2 for ; Tue, 26 May 2015 16:06:22 -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=rp9ZDxrtmNstj7VV77NgAcYnU+4Zc1hJe0bKQtH4oHQ=; b=k6HgjYGHMcQ1ZvrMUzcmgz2hoh3eoFATsWPMSp68Mr7ri0x9t6swi1JdFoaUxbkUep UjkrZq6p2RHebkDx9CMw2ix9gg7ZyZtsdj6CGMClk4CSV2dh/wlhAzaQGOD68JzzuLO2 Vmu9oLK9CjESZxT5c6S9z9w2adzkmbIx3kv5EtsHt2P89W0IiK+8uocnSSbSdjvhZ8a4 ol/xng8dReKOkEjcOpOzlgOm3Lj+Es7enDhFPqInhwoXbADFF6W204l+lPF1Iqx5OWL9 iOVdaGrpKwje9uiMuFMt7Js02LdMyt/53DgEXGh4fiLUVu4gW4YOCW3wUnOtBV5Nv8oJ rOzA== X-Received: by 10.68.138.230 with SMTP id qt6mr53727323pbb.160.1432681582245; Tue, 26 May 2015 16:06:22 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id da3sm14142484pdb.8.2015.05.26.16.06.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:06:21 -0700 (PDT) Message-ID: <5564FC6C.2040604@gmail.com> Date: Wed, 27 May 2015 11:06:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark ZZZ Smith , "Eric Vyncke (evyncke)" , Tim Chown , Joe Touch References: <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:06:25 -0000 On 26/05/2015 17:27, Mark ZZZ Smith wrote: >=20 >=20 >=20 >=20 > ________________________________ > From: Eric Vyncke (evyncke) > To: Tim Chown ; Joe Touch =20 > Cc: "v6ops@ietf.org" =20 > Sent: Wednesday, 20 May 2015, 22:28 > Subject: Re: [v6ops] Extension Headers / Impact on Security Devices >=20 >=20 > On 20/05/15 10:14, "Tim Chown" wrote: >> >> The other question is what existing work is being done that relies on = the >> correct (desired) operation of EHs? The two that would spring out woul= d >> be segment routing and sfc, at least one of which is using the existin= g >> Routing Header. If such protocols are constrained to specific >> administrative domains then their successful operation I would assume = is >> down to specific EH handling in the equipment in that domain, and its >> capabilities, rather than (undesired) operator filtering somewhere >> between sender and receiver. >=20 > The primary use case of segment routing is indeed within a single > administrative domain, so, EH does not cause a problem. I've lost track of who wrote that (Tim?), but it's only true if all middleboxes respect RFC 7045, especially the bits about what needs to be configurable and what the factory defaults should be. > OTOH, this whole discussion is pretty close to having a discussion on > whether an ISP should block everything which is neither UDP nor TCP? Or= > block currently-unallocated TCP/UDP ports? (and I appreciate that there= > are differences of course). Again: all these choices need to be configurable, so that providers can make their own choices and decide what to break. I assume that discussion belongs in opsec. Brian >=20 >=20 > / +1 >=20 > / In my opinion a huge amount of security context is missing from this = discussion, to the point where the question has been simplified to a too = simplistic and binary EHs or not question, and there is never going to be= consensus on that question. >=20 > / There seems to be an underlying and unstated set of assumptions behin= d the sorts of "block EHs","must be able to look at TCP/UDP headers in th= e network" questions/statements :=20 >=20 > / (a) the network is the only place that network, host and application = security can and must be done, implying that hosts and applications do no= thing to protect themselves > / (b) that the contents of packets will always remain transparent to th= e network, allowing them to be inspected in the network > / and (c) that all traffic to and from a host/application will always t= raverse a single inspection/choke point in the network and will always us= e the same Internet protocol. >=20 >=20 >=20 > / I think all of the above assumptions were true up until about the mid= 1990s (if I remember well enough). Since then, they've all become false = to varying degrees. Consequently, a choke point in the network may not be= the best place to perform all network, host and application security mea= sures, and in some cases persisting with that model will cause security f= ailures. (For example, it seems that hosts aren't the lowest hanging frui= t for network delivered malware any more, it is residential CPE itself - = the device that is supposed to be so effective at providing "security" (i= ncluding implicitly via NAT) that theoretically downstream hosts don't ne= ed firewalls at all.) >=20 > To Enno's original point: it is fair for a destination domain to handle= > (permit, drop, log, inspect) incoming (or outgoing BTW) packets based o= n > layer-4 ports, layer-4 protocols or extension headers. This is their ow= n > responsibility >=20 > -=C3=A9ric >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue May 26 16:14:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3621D1A90FE for ; Tue, 26 May 2015 16:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WluIeZ19Tfa2 for ; Tue, 26 May 2015 16:14:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333A41A90E5 for ; Tue, 26 May 2015 16:14:34 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4QNE8IX015922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 16:14:08 -0700 (PDT) Message-ID: <5564FE3F.4050102@isi.edu> Date: Tue, 26 May 2015 16:14:07 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> In-Reply-To: <5564FB74.5020303@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:14:35 -0000 On 5/26/2015 4:02 PM, Brian E Carpenter wrote: > On 20/05/2015 08:59, Joe Touch wrote: ... >>> No. RFC 2460 makes it clear that hops don't modify extension headers >>> (except for shuffling within a routing header). >> >> HBH headers are the exception and can be modified in-transit, which >> would affect a transport-offset header. > > I don't get where RFC 2460 allows that. Section 4 states: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. ... The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that must be examined and processed by every node along a packet's delivery path, including the source and destination nodes. In addition, RFC2460 defines a bit to handle when changes to such options occurs en-route: 1 - Option Data may change en-route What is the purpose of that bit if the data can never change en-route? Such changes can affect the content and *length* of these options. Joe From nobody Tue May 26 16:37:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611661B3323 for ; Tue, 26 May 2015 16:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiQw7OBTc6yM for ; Tue, 26 May 2015 16:37:52 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A121B3321 for ; Tue, 26 May 2015 16:37:52 -0700 (PDT) Received: by pdea3 with SMTP id a3so101526536pde.2 for ; Tue, 26 May 2015 16:37:51 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tll4YF9tKtzh+RGq2e35iJf7HJWWKWIc9nD9FHn2/EM=; b=IN3EufuchSR8kjCBiZ7zBkasvqP8x5+pKvJWXWLT9HnM3ylHMvMUpSnJAOupOmeM0i rhdDwa8XWv6frz3tX8zKoElUfrW7bqUy17mydyo8Iu+VOkRHIhfuneFu2/A7kUhrp6oG aw6o6r9zsFmYEkinZuJk0ia/lPI2COV6E/TeIHwmozUXOuo7VeOoOgeMTXxXpalM7EK4 xrawK+6V3Zcsta64V2YFR6weewCmTEd6N3C3F+7yCijjw3f6cuxMm84+3NJdSZH64uJM 7aruhumPadMkEP1Kce9/SyZuXDzI0I0HQAR3N4Ym2ciAfwXEqNXcFQFDGwshovRelZiK QW+g== X-Received: by 10.66.142.169 with SMTP id rx9mr54140799pab.84.1432683471749; Tue, 26 May 2015 16:37:51 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id bn7sm14218953pac.22.2015.05.26.16.37.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:37:50 -0700 (PDT) Message-ID: <556503CF.4030101@gmail.com> Date: Wed, 27 May 2015 11:37:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joe Touch , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> In-Reply-To: <5564FE3F.4050102@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:37:53 -0000 On 27/05/2015 11:14, Joe Touch wrote: > > > On 5/26/2015 4:02 PM, Brian E Carpenter wrote: >> On 20/05/2015 08:59, Joe Touch wrote: > ... >>>> No. RFC 2460 makes it clear that hops don't modify extension headers >>>> (except for shuffling within a routing header). >>> >>> HBH headers are the exception and can be modified in-transit, which >>> would affect a transport-offset header. >> >> I don't get where RFC 2460 allows that. > > Section 4 states: > > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > ... > > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that must be examined > and processed by every node along a packet's delivery path, including > the source and destination nodes. > > In addition, RFC2460 defines a bit to handle when changes to such > options occurs en-route: > > 1 - Option Data may change en-route > > What is the purpose of that bit if the data can never change en-route? > > Such changes can affect the content and *length* of these options. Oh yuck. I suspect that allowing a length change is an unintended side effect, but you're correct that it isn't forbidden. I've certainly always read that text as allowing an update of the current value of the content, not an increase in the length. Brian From nobody Tue May 26 16:56:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625C61B332A for ; Tue, 26 May 2015 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F218TArDzegi for ; Tue, 26 May 2015 16:56:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1862F1ACD77 for ; Tue, 26 May 2015 16:56:40 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4QNuIKq020840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 16:56:18 -0700 (PDT) Message-ID: <55650821.4060907@isi.edu> Date: Tue, 26 May 2015 16:56:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> In-Reply-To: <556503CF.4030101@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:56:41 -0000 On 5/26/2015 4:37 PM, Brian E Carpenter wrote: > On 27/05/2015 11:14, Joe Touch wrote: >> >> >> On 5/26/2015 4:02 PM, Brian E Carpenter wrote: >>> On 20/05/2015 08:59, Joe Touch wrote: >> ... >>>>> No. RFC 2460 makes it clear that hops don't modify extension headers >>>>> (except for shuffling within a routing header). >>>> >>>> HBH headers are the exception and can be modified in-transit, which >>>> would affect a transport-offset header. >>> >>> I don't get where RFC 2460 allows that. >> >> Section 4 states: >> >> With one exception, extension headers are not examined or processed >> by any node along a packet's delivery path, until the packet reaches >> the node (or each of the set of nodes, in the case of multicast) >> identified in the Destination Address field of the IPv6 header. >> ... >> >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that must be examined >> and processed by every node along a packet's delivery path, including >> the source and destination nodes. >> >> In addition, RFC2460 defines a bit to handle when changes to such >> options occurs en-route: >> >> 1 - Option Data may change en-route >> >> What is the purpose of that bit if the data can never change en-route? >> >> Such changes can affect the content and *length* of these options. > > Oh yuck. I suspect that allowing a length change is an unintended side > effect, but you're correct that it isn't forbidden. I've certainly > always read that text as allowing an update of the current value > of the content, not an increase in the length. FWIW, I don't see anything that prohibits adding headers either. Not that I think that's a great thing to play with, but seems in-scope too. Joe From nobody Tue May 26 17:23:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4611ACE66 for ; Tue, 26 May 2015 17:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXkXWzeduPit for ; Tue, 26 May 2015 17:23:32 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4541ACE65 for ; Tue, 26 May 2015 17:23:31 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so104610412pac.2 for ; Tue, 26 May 2015 17:23: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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9TeDkiGS3KioRhwGKx0ZZY6HewnPJk7t1Rrs4izvCxM=; b=ktuli0FMiOmwO552BCBTgtqR57B4V1YJ48lMu1J2e3NroSe3ilCXrVNP1mUr152Fdx 2mYks4sfn64CUUAhlEz/Y8IWZhfwC5q2TGmJegi9U5HAPrPzdbkjWXvvAC9DsNgfmLTW QQlwmcAxKOD540PHnPRxS8X2Wnej6ah7z+Ip4LNeSHd9wXYhoxqcRlEtFr+mYCGlYa+z bVNwXTf2R22Z6xINHOPAd0a+fRSKBLqg+kbmqZStlFfbFoE6K4ameQwJqi4WxYGAO8JV oBmD1gxxYkMzoCqpt5iVwX8LaL3wGgvGoRW9s0HWAmnJnxvRLnczaeOHFvSxrR2vt+lH uMeQ== X-Received: by 10.66.66.173 with SMTP id g13mr54537340pat.155.1432686211030; Tue, 26 May 2015 17:23:31 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id a10sm11560118pdn.57.2015.05.26.17.23.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 17:23:29 -0700 (PDT) Message-ID: <55650E82.3090407@gmail.com> Date: Wed, 27 May 2015 12:23:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joe Touch , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> In-Reply-To: <55650821.4060907@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 00:23:34 -0000 On 27/05/2015 11:56, Joe Touch wrote: > > > On 5/26/2015 4:37 PM, Brian E Carpenter wrote: >> On 27/05/2015 11:14, Joe Touch wrote: >>> >>> >>> On 5/26/2015 4:02 PM, Brian E Carpenter wrote: >>>> On 20/05/2015 08:59, Joe Touch wrote: >>> ... >>>>>> No. RFC 2460 makes it clear that hops don't modify extension headers >>>>>> (except for shuffling within a routing header). >>>>> >>>>> HBH headers are the exception and can be modified in-transit, which >>>>> would affect a transport-offset header. >>>> >>>> I don't get where RFC 2460 allows that. >>> >>> Section 4 states: >>> >>> With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header. >>> ... >>> >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that must be examined >>> and processed by every node along a packet's delivery path, including >>> the source and destination nodes. >>> >>> In addition, RFC2460 defines a bit to handle when changes to such >>> options occurs en-route: >>> >>> 1 - Option Data may change en-route >>> >>> What is the purpose of that bit if the data can never change en-route? >>> >>> Such changes can affect the content and *length* of these options. >> >> Oh yuck. I suspect that allowing a length change is an unintended side >> effect, but you're correct that it isn't forbidden. I've certainly >> always read that text as allowing an update of the current value >> of the content, not an increase in the length. > > FWIW, I don't see anything that prohibits adding headers either. "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." To me that clearly implies not adding (which is a form of processing). Brian > Not that I think that's a great thing to play with, but seems in-scope too. > > Joe > From nobody Tue May 26 17:33:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848741ACE9B for ; Tue, 26 May 2015 17:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGx3iwF6OOJC for ; Tue, 26 May 2015 17:33:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAB41B3357 for ; Tue, 26 May 2015 17:33:01 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4R0WTI4024910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 17:32:29 -0700 (PDT) Message-ID: <5565109C.8080603@isi.edu> Date: Tue, 26 May 2015 17:32:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian E Carpenter , v6ops@ietf.org References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> In-Reply-To: <55650E82.3090407@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 00:33:03 -0000 On 5/26/2015 5:23 PM, Brian E Carpenter wrote: > On 27/05/2015 11:56, Joe Touch wrote: ... >> FWIW, I don't see anything that prohibits adding headers either. > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header." > > To me that clearly implies not adding (which is a form of processing). The "one exception" are HBH headers - as a class. I.e., this is just restating that non-HBH header classes don't change en-route. It doesn't prohibit adding/removing HBH headers, but gives no examples because the only HBH header types defined by 2460 are NOP fillers. Joe From nobody Tue May 26 23:00:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407C1A014E for ; Tue, 26 May 2015 23:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzEYqDg8Kr5z for ; Tue, 26 May 2015 23:00:32 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2A26F1A0127 for ; Tue, 26 May 2015 23:00:32 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 27 May 2015 01:00:27 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f179.google.com [209.85.213.179] #+LO+TS+TR X-Umn-Classification: local Received: by igcau1 with SMTP id au1so6242551igc.1 for ; Tue, 26 May 2015 23:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qv4lT0Kpibb4fEFIvA/lxOfx8+OBwjmnebheH8E71L8=; b=lLsJvUBcEPoV1L1/jMrH6P2Ay0Sm99En/iGelnWYeYeE9qpLEN+t1SjTMfQU8z4bMU lultfau3zTMfGIM9L7qxTqzze6wghp2PbpbkBu/7NWMcJIFB14HZ6xv4ZPs0h2ozt19W CWzU+OoOsQq9CBW8lsTbbMYEtWxRCZoVVsRzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Qv4lT0Kpibb4fEFIvA/lxOfx8+OBwjmnebheH8E71L8=; b=YMwfnTpNsfM+di/QnPPiu/XcUD5CJtsjPIjFMOMVOCvOcd7JEWDpgYW8YL3Ze054n9 Ho0O8bIvPtMJ+wxQwuCJuP5oV9vxMPWwP06fyomQGMP6mupCJlAcOprfQAbwlSD5FN1d cdlqRQsECG0wmOLlRUkW9EcvQxZjRaXovBpRWkEG3YQmJ5MYvtfpc7gLh9XhZtkhmrDr F8FN4N0WliqpSg3qVrUafZfibbsT+qfoXjSjG0w1RTv3MgYUetCSkhIT05GJZQ6W43Va Ham5pFYFX0Riq5OcP1pfDmXYih4zKZEAVURByF8Kpnb+tVWWe7nH0NYWPfEU3Eb4cB/k B5bA== X-Gm-Message-State: ALoCoQkMdgJ0NbIcdUhQN8rNZPbJP3sXa6+GrpGBuUCs2A1RSOIt0BOhTBbA4FNV2VEUzv0dhGscIjoEG8/EGAx7y3lQoLA/uuZ0I1q084NZ46++KLjW9ibyCeu6QWGSvXmw/eDh2s2M X-Received: by 10.107.133.9 with SMTP id h9mr35678857iod.47.1432706426640; Tue, 26 May 2015 23:00:26 -0700 (PDT) X-Received: by 10.107.133.9 with SMTP id h9mr35678797iod.47.1432706425965; Tue, 26 May 2015 23:00:25 -0700 (PDT) Received: from oit201651646.local (173-11-44-230-Minnesota.hfc.comcastbusiness.net. [173.11.44.230]) by mx.google.com with ESMTPSA id v3sm1138703igk.1.2015.05.26.23.00.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 23:00:24 -0700 (PDT) Message-ID: <55655D76.7000402@umn.edu> Date: Wed, 27 May 2015 01:00:22 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Barry Leiba References: <20150522044802.6573.47203.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053156A8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053156A8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , The IESG Subject: Re: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cidr-prefix-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 06:00:35 -0000 On 5/26/15 03:01 , mohamed.boucadair@orange.com wrote: > Dear Barry, > > Many thanks for the careful review. > > An updated version is available online. A diff is available at: https://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-cidr-prefix-02&url2=draft-ietf-v6ops-cidr-prefix-03 > > Cheers, > Med ... >> -- Section 2 -- >> In the second paragraph, I note that too many attributive nouns put >> together make for awkwardness and confusion. I suggest changing >> "Forwarding decision-making processes" to "Decision-making processes for >> forwarding", so it's clear that "forwarding" is a gerund (noun), not a >> participle (verb). This same phrase is at the end of the first sentence of the first paragraph in the introduction as well, maybe change it there too. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed May 27 00:39:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866431A88A7 for ; Wed, 27 May 2015 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIWK_dpl_hU5 for ; Wed, 27 May 2015 00:39:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912461A88B4 for ; Wed, 27 May 2015 00:39:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C6EE9608E5 for ; Wed, 27 May 2015 09:39:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 89FB0608CF for ; Wed, 27 May 2015 09:39:43 +0200 (CEST) Received: (qmail 94666 invoked by uid 1007); 27 May 2015 09:39:43 +0200 Date: Wed, 27 May 2015 09:39:43 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20150527073943.GA54385@Space.Net> References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55650E82.3090407@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 07:39:48 -0000 Hi, On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: > > FWIW, I don't see anything that prohibits adding headers either. > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header." > > To me that clearly implies not adding (which is a form of processing). So how do the SR folks handle that? From what I heard, the intended deployment really is "inside your administrative domain, SR headers get added, processed, and when the packet leaves your domain, they can be (optionally) removed again to not upset your neighbours"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed May 27 04:08:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041E01ACDD1 for ; Wed, 27 May 2015 04:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxFUCUaGke25 for ; Wed, 27 May 2015 04:08:37 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 967961ACDC2 for ; Wed, 27 May 2015 04:08:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7CB3D401AE; Wed, 27 May 2015 13:08:35 +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 8raS6MN1PmoQ; Wed, 27 May 2015 13:08:33 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 255B7401AD; Wed, 27 May 2015 13:08:33 +0200 (CEST) Message-ID: <5565A588.708@globis.net> Date: Wed, 27 May 2015 13:07:52 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brian E Carpenter References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> In-Reply-To: <55650E82.3090407@gmail.com> Content-Type: multipart/alternative; boundary="------------020807060505080605050702" Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 11:08:39 -0000 This is a multi-part message in MIME format. --------------020807060505080605050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > On 27/05/2015 11:56, Joe Touch wrote: >> On 5/26/2015 4:37 PM, Brian E Carpenter wrote: >>> On 27/05/2015 11:14, Joe Touch wrote: >>>> On 5/26/2015 4:02 PM, Brian E Carpenter wrote: >>>>> On 20/05/2015 08:59, Joe Touch wrote: >>>> ... >>>>>>> No. RFC 2460 makes it clear that hops don't modify extension headers >>>>>>> (except for shuffling within a routing header). >>>>>> HBH headers are the exception and can be modified in-transit, which >>>>>> would affect a transport-offset header. >>>>> I don't get where RFC 2460 allows that. >>>> Section 4 states: >>>> >>>> With one exception, extension headers are not examined or processed >>>> by any node along a packet's delivery path, until the packet reaches >>>> the node (or each of the set of nodes, in the case of multicast) >>>> identified in the Destination Address field of the IPv6 header. >>>> ... >>>> >>>> The exception referred to in the preceding paragraph is the Hop-by- >>>> Hop Options header, which carries information that must be examined >>>> and processed by every node along a packet's delivery path, including >>>> the source and destination nodes. >>>> >>>> In addition, RFC2460 defines a bit to handle when changes to such >>>> options occurs en-route: >>>> >>>> 1 - Option Data may change en-route >>>> >>>> What is the purpose of that bit if the data can never change en-route? >>>> >>>> Such changes can affect the content and *length* of these options. >>> Oh yuck. I suspect that allowing a length change is an unintended side >>> effect, but you're correct that it isn't forbidden. I've certainly >>> always read that text as allowing an update of the current value >>> of the content, not an increase in the length. >> FWIW, I don't see anything that prohibits adding headers either. > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header." > > To me that clearly implies not adding (which is a form of processing). > > Brian > I don't see how that text prohibits adding additional hop by hop headers though. e.g. If none are present, then one could theoretcially be added en route. That could form the basis of a nice resource depletion attack for all downstream devices. [not that I expect anyone to actually process hop by hop headers in the real world] >> Not that I think that's a great thing to play with, but seems in-scope too. >> >> Joe >> > > --------------020807060505080605050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote: 
On 27/05/2015 11:56, Joe Touch wrote:

On 5/26/2015 4:37 PM, Brian E Carpenter wrote:

On 27/05/2015 11:14, Joe Touch wrote:

On 5/26/2015 4:02 PM, Brian E Carpenter wrote:

On 20/05/2015 08:59, Joe Touch wrote:

...

No. RFC 2460 makes it clear that hops don't modify extension headers
(except for shuffling within a routing header).

HBH headers are the exception and can be modified in-transit, which
would affect a transport-offset header.

I don't get where RFC 2460 allows that.

Section 4 states:

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.
...

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.

In addition, RFC2460 defines a bit to handle when changes to such
options occurs en-route:

      1 - Option Data may change en-route

What is the purpose of that bit if the data can never change en-route?

Such changes can affect the content and *length* of these options.

Oh yuck. I suspect that allowing a length change is an unintended side
effect, but you're correct that it isn't forbidden. I've certainly
always read that text as allowing an update of the current value
of the content, not an increase in the length.

FWIW, I don't see anything that prohibits adding headers either.


"With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header."

To me that clearly implies not adding (which is a form of processing).

   Brian
I don't see how that text prohibits adding additional hop by hop headers though.

e.g. If none are present, then one could theoretcially be added en route.

That could form the basis of a nice resource depletion attack for all downstream devices.

[not that I expect anyone to actually process hop by hop headers in the real world]
Not that I think that's a great thing to play with, but seems in-scope too.

Joe
--------------020807060505080605050702-- From nobody Wed May 27 04:35:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3351ACE08 for ; Wed, 27 May 2015 04:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_35Et1BHlcU for ; Wed, 27 May 2015 04:34:57 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BA31ACE0D for ; Wed, 27 May 2015 04:34:57 -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 t4RBYo9a005446 for ; Wed, 27 May 2015 12:34:50 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t4RBYo9a005446 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1432726490; bh=d6AajLCkOgVvCguDyWA+0yagcdY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=az7qX333sCkMoJ5iUuPk2x3WXmcN+Crjh5dLyy54wWdnZ1y14kQ+5BFUKRLF+Bg5+ 21M5mz+1TaowP6QhdnFrMWOzjEybND2GYFH0sBDGflmSo33EftbMrOrz4eY0BUCbPX bhilMBOcf7MA4/57HCJRAAldiPKZbEnOb9oLMp4E= 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 r4QCYo0803206396bs ret-id none; Wed, 27 May 2015 12:34:50 +0100 Received: from [IPv6:2001:630:d0:f111:ed71:8eeb:6cb1:d085] ([IPv6:2001:630:d0:f111:ed71:8eeb:6cb1:d085]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t4RBYoJO014096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 May 2015 12:34:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Tim Chown In-Reply-To: <5564FC6C.2040604@gmail.com> Date: Wed, 27 May 2015 12:34:50 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1975702461.1639631.1432618020136.JavaMail.yahoo@mail.yahoo.com> <5564FC6C.2040604@gmail.com> <8A935D04-5BBB-4B2A-BB44-C9D9BECE514E@ecs.soton.ac.uk> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.2098) X-smtpf-Report: sid=r4QCYo080320639600; tid=r4QCYo0803206396bs; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t4RBYo9a005446 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 11:35:04 -0000 Hi, > On 27 May 2015, at 00:06, Brian E Carpenter = wrote: >=20 > On 26/05/2015 17:27, Mark ZZZ Smith wrote: >>=20 >> ______________________________ >> From: Eric Vyncke (evyncke) >> To: Tim Chown ; Joe Touch =20 >> Cc: "v6ops@ietf.org" =20 >> Sent: Wednesday, 20 May 2015, 22:28 >> Subject: Re: [v6ops] Extension Headers / Impact on Security Devices >>=20 >>=20 >> On 20/05/15 10:14, "Tim Chown" wrote: >>>=20 >>> The other question is what existing work is being done that relies = on the >>> correct (desired) operation of EHs? The two that would spring out = would >>> be segment routing and sfc, at least one of which is using the = existing >>> Routing Header. If such protocols are constrained to specific >>> administrative domains then their successful operation I would = assume is >>> down to specific EH handling in the equipment in that domain, and = its >>> capabilities, rather than (undesired) operator filtering somewhere >>> between sender and receiver. >>=20 >> The primary use case of segment routing is indeed within a single >> administrative domain, so, EH does not cause a problem. >=20 > I've lost track of who wrote that (Tim?), but it's only true if > all middleboxes respect RFC 7045, especially the bits about what > needs to be configurable and what the factory defaults should be. I think the point is that drops caused by administrative configuration = should not be an issue within a domain under your full control. Which is = presumably why sfc/spring are limiting their primary use cases in this = way. The exposure is presumably then only equipment within their domain = that has some limitation in EH handling. >> OTOH, this whole discussion is pretty close to having a discussion on >> whether an ISP should block everything which is neither UDP nor TCP? = Or >> block currently-unallocated TCP/UDP ports? (and I appreciate that = there >> are differences of course). >=20 > Again: all these choices need to be configurable, so that providers > can make their own choices and decide what to break. I assume that > discussion belongs in opsec. With the caveat that you can=E2=80=99t control what you can=E2=80=99t = control. Tim >=20 > Brian >=20 >>=20 >>=20 >> / +1 >>=20 >> / In my opinion a huge amount of security context is missing from = this discussion, to the point where the question has been simplified to = a too simplistic and binary EHs or not question, and there is never = going to be consensus on that question. >>=20 >> / There seems to be an underlying and unstated set of assumptions = behind the sorts of "block EHs","must be able to look at TCP/UDP headers = in the network" questions/statements :=20 >>=20 >> / (a) the network is the only place that network, host and = application security can and must be done, implying that hosts and = applications do nothing to protect themselves >> / (b) that the contents of packets will always remain transparent to = the network, allowing them to be inspected in the network >> / and (c) that all traffic to and from a host/application will always = traverse a single inspection/choke point in the network and will always = use the same Internet protocol. >>=20 >>=20 >>=20 >> / I think all of the above assumptions were true up until about the = mid 1990s (if I remember well enough). Since then, they've all become = false to varying degrees. Consequently, a choke point in the network may = not be the best place to perform all network, host and application = security measures, and in some cases persisting with that model will = cause security failures. (For example, it seems that hosts aren't the = lowest hanging fruit for network delivered malware any more, it is = residential CPE itself - the device that is supposed to be so effective = at providing "security" (including implicitly via NAT) that = theoretically downstream hosts don't need firewalls at all.) >>=20 >> To Enno's original point: it is fair for a destination domain to = handle >> (permit, drop, log, inspect) incoming (or outgoing BTW) packets based = on >> layer-4 ports, layer-4 protocols or extension headers. This is their = own >> responsibility >>=20 >> -=C3=A9ric >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From nobody Wed May 27 10:24:51 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9711A883C for ; Wed, 27 May 2015 10:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09Ap5QWlONHP for ; Wed, 27 May 2015 10:24:49 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736601A8834 for ; Wed, 27 May 2015 10:24:49 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4RHO1R1025079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2015 10:24:01 -0700 (PDT) Message-ID: <5565FDB1.2070307@isi.edu> Date: Wed, 27 May 2015 10:24:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Gert Doering , Brian E Carpenter References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> In-Reply-To: <20150527073943.GA54385@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t4RHO1R1025079 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 17:24:50 -0000 On 5/27/2015 12:39 AM, Gert Doering wrote: > Hi, > > On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>> FWIW, I don't see anything that prohibits adding headers either. >> >> "With one exception, extension headers are not examined or processed >> by any node along a packet's delivery path, until the packet reaches >> the node (or each of the set of nodes, in the case of multicast) >> identified in the Destination Address field of the IPv6 header." >> >> To me that clearly implies not adding (which is a form of processing). > > So how do the SR folks handle that? From what I heard, the intended > deployment really is "inside your administrative domain, SR headers get > added, processed, and when the packet leaves your domain, they can be > (optionally) removed again to not upset your neighbours"... AFAICT, SR headers are destination options, and aren't supposed to be modified by anything but the endpoints (where each addressed hop in such a route is such an endpoint). So I would think that they MUST NOT be added to IPv6 datagrams except by the source. In many of the cases we're discussing, the nodes inside an AD act "on behalf" of a source or sink, and that's the logic by which they are allowed such modification. HOWEVER, whenever you act on behalf of a source or sink, you ARE effectively a source or sink and thus beholden to the source/sink requirements, not merely router requirements. I.e., if you want the performance of a router, act like a router and nothing more. If you want to act like a host, you need will have the performance of a host. Joe From nobody Wed May 27 13:29:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58A1A8A67 for ; Wed, 27 May 2015 13:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z53aIZN6rByL for ; Wed, 27 May 2015 13:29:36 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3B41A005B for ; Wed, 27 May 2015 13:29:35 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so24954445pdb.0 for ; Wed, 27 May 2015 13:29:35 -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=zFTtECNn6x/cw97aHMKNqrB7/6K/qlp1ffTxCJKABvQ=; b=kX5qIx6h92fqxmIt8r4iBvoahn7xfMhvgAD0rQTyDPTQuX9GUAjyD6hCTzUwpe2O5v bUoGZ5enRGsALSMykBj5Bhr11nXgxJYkW2/voUZruaotKeLGhdFD2kZRteMe/5tc5Cv4 edz6ViuFs3wZge7PXmpwBP7QxgwOPdBLNy2lstzLyvjf1j6kK8O8mNTyTvVGwFjf3bpn uOplgecKREX2hX/gfbF1LTFGy9qw5UK2uLlRI4tghkmYMXFvCpIddN4kgddGpVWHulHy nOj5sVRqaPy/t2sy4NvZsD2Hetl2zx9GCOpR5VZ1ua0sOC0LQVcRM5IF8WqUEVB3Ekhc 5Y6Q== X-Received: by 10.68.133.200 with SMTP id pe8mr54318184pbb.133.1432758575534; Wed, 27 May 2015 13:29:35 -0700 (PDT) Received: from ?IPv6:2406:e007:4eff:1:28cc:dc4c:9703:6781? ([2406:e007:4eff:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ph4sm41420pdb.43.2015.05.27.13.29.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 13:29:34 -0700 (PDT) Message-ID: <55662931.1030109@gmail.com> Date: Thu, 28 May 2015 08:29:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joe Touch , Gert Doering References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <5565FDB1.2070307@isi.edu> In-Reply-To: <5565FDB1.2070307@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 20:29:37 -0000 On 28/05/2015 05:24, Joe Touch wrote: > > > On 5/27/2015 12:39 AM, Gert Doering wrote: >> Hi, >> >> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>>> FWIW, I don't see anything that prohibits adding headers either. >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." >>> >>> To me that clearly implies not adding (which is a form of processing). >> >> So how do the SR folks handle that? From what I heard, the intended >> deployment really is "inside your administrative domain, SR headers get >> added, processed, and when the packet leaves your domain, they can be >> (optionally) removed again to not upset your neighbours"... > > AFAICT, SR headers are destination options, and aren't supposed to be > modified by anything but the endpoints (where each addressed hop in such > a route is such an endpoint). > > So I would think that they MUST NOT be added to IPv6 datagrams except by > the source. I agree, but I think the SR people prefer to think otherwise, which just stacks up MTU problems for the future. We know that features designed for "local" use have a tendency to be deployed much more widely than their designers intended. Brian > In many of the cases we're discussing, the nodes inside an AD act "on > behalf" of a source or sink, and that's the logic by which they are > allowed such modification. HOWEVER, whenever you act on behalf of a > source or sink, you ARE effectively a source or sink and thus beholden > to the source/sink requirements, not merely router requirements. > > I.e., if you want the performance of a router, act like a router and > nothing more. If you want to act like a host, you need will have the > performance of a host. > > Joe > From nobody Wed May 27 13:32:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DAF1AC3A0 for ; Wed, 27 May 2015 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVlhxWsrQexE for ; Wed, 27 May 2015 13:32:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A071ABD39 for ; Wed, 27 May 2015 13:32:43 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4RKVwR6007224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2015 13:31:58 -0700 (PDT) Message-ID: <556629BE.3090705@isi.edu> Date: Wed, 27 May 2015 13:31:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian E Carpenter , Gert Doering References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <5565FDB1.2070307@isi.edu> <55662931.1030109@gmail.com> In-Reply-To: <55662931.1030109@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 20:32:44 -0000 On 5/27/2015 1:29 PM, Brian E Carpenter wrote: > On 28/05/2015 05:24, Joe Touch wrote: >> >> >> On 5/27/2015 12:39 AM, Gert Doering wrote: >>> Hi, >>> >>> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>>>> FWIW, I don't see anything that prohibits adding headers either. >>>> >>>> "With one exception, extension headers are not examined or processed >>>> by any node along a packet's delivery path, until the packet reaches >>>> the node (or each of the set of nodes, in the case of multicast) >>>> identified in the Destination Address field of the IPv6 header." >>>> >>>> To me that clearly implies not adding (which is a form of processing). >>> >>> So how do the SR folks handle that? From what I heard, the intended >>> deployment really is "inside your administrative domain, SR headers get >>> added, processed, and when the packet leaves your domain, they can be >>> (optionally) removed again to not upset your neighbours"... >> >> AFAICT, SR headers are destination options, and aren't supposed to be >> modified by anything but the endpoints (where each addressed hop in such >> a route is such an endpoint). >> >> So I would think that they MUST NOT be added to IPv6 datagrams except by >> the source. > > I agree, but I think the SR people prefer to think otherwise, which just > stacks up MTU problems for the future. We know that features designed > for "local" use have a tendency to be deployed much more widely than > their designers intended. See the rest of my response below, then. Joe > Brian > >> In many of the cases we're discussing, the nodes inside an AD act "on >> behalf" of a source or sink, and that's the logic by which they are >> allowed such modification. HOWEVER, whenever you act on behalf of a >> source or sink, you ARE effectively a source or sink and thus beholden >> to the source/sink requirements, not merely router requirements. >> >> I.e., if you want the performance of a router, act like a router and >> nothing more. If you want to act like a host, you need will have the >> performance of a host. >> >> Joe >> From nobody Thu May 28 05:44:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551081A9140; Thu, 28 May 2015 05:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPp9C3LYNVDL; Thu, 28 May 2015 05:44:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE571A9112; Thu, 28 May 2015 05:44:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528124401.22522.68783.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 05:44:01 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-cidr-prefix-03: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 12:44:03 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-v6ops-cidr-prefix-03: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for documenting this! From nobody Thu May 28 08:26:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CBE1ACD5F for ; Thu, 28 May 2015 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZTQDvpi64BG for ; Thu, 28 May 2015 08:26:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86071B2B52 for ; Thu, 28 May 2015 08:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2936; q=dns/txt; s=iport; t=1432826767; x=1434036367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V2opCpsLJv+DpWocsCjN1NiO+B17eiPXyZNt+DdyheA=; b=UgH2Qccrj+LzQpoCrkOwqFwMZqfWsTnhBMpgWQ1ag704WAtXePT7VG9S LHp7F5uuxYCRYDvfxX/a6A05blxfq4OIlhDZDg7XJ35A+DHye6uB6vxAe C34wudsM9pF2oMsqZt45ExixS0XYL5TEm/iSioblVK9yhz6mEJR31bAyt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AwCbMmdV/40NJK1cgxBUXgaDGLpMCYFQCoV3AhyBMDgUAQEBAQEBAYEKhCMBAQQBAQELFRExCQsQAgEIGAICJgICAiULFRACBAENBYgtDbB4pBQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiiKEUxgbB4JogUUFkwiLD4Epki2DWSOBZoISb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="2559043" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 28 May 2015 15:26:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4SFQ6LR029585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 15:26:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 28 May 2015 10:26:06 -0500 From: "Eric Vyncke (evyncke)" To: Gert Doering , Brian E Carpenter Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52O8gsqgABXE4CAAAaigIAABSaAgAAHmwCAAHnhgIACNimA Date: Thu, 28 May 2015 15:26:06 +0000 Message-ID: References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> In-Reply-To: <20150527073943.GA54385@Space.Net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.55.185.68] Content-Type: text/plain; charset="utf-8" Content-ID: <0EEE50444BC38B4A8D5D294570900137@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:26:12 -0000 U2VnbWVudCBSb3V0aW5nIEhlYWRlciBpcyBjdXJyZW50bHkgZHJhZnRlZCBhcyBhbm90aGVyIHR5 cGUgb2Ygcm91dGluZw0KaGVhZGVyIGFuZCBhcmUgZHJhZnRlZCB0byBiZSBpbnNlcnRlZCBlaXRo ZXIgYnkgdGhlIHNvdXJjZSBvciBieSB0aGUNCmluZ3Jlc3Mgcm91dGVyIG9mIGEgU1ItY29uZmln dXJlZCBkb21haW4gKHRoZW4gYmVpbmcgcmVtb3ZlZCBhdCB0aGUgZXhpdA0Kb2YgdGhlIFNSLWRv bWFpbikuIERlc3RpbmF0aW9uIE9wdGlvbiBpcyBub3QgdXNlZnVsIGhlcmUgYXMgaXQgaXMNCmlu c3BlY3RlZC9wcm9jZXNzZWQgb25seSBieSB0aGUgZGVzdGluYXRpb24gd2hpbGUgdGhlIGludGVu dCBvZiBTUiBpcyB0bw0KaGF2ZSB0aGlzIGluZm9ybWF0aW9uIHByb2Nlc3NlZCBieSBhIGNvdXBs ZSBvZiBpbnRlcm1lZGlhdGUgcm91dGVycyAod2hpY2gNCmhhdmUgYSBzcGVjaWZpYyBjb25maWd1 cmF0aW9uIGFzIFNSSCBpcyBub3QgZW5hYmxlZCBieSBkZWZhdWx0KS4NCg0KT2YgY291cnNlLCB0 aGlzIGNhdXNlcyBNVFUgaXNzdWVzIChwcmV0dHkgbXVjaCBsaWtlIE1QTFMgYnV0IGF0IGENCmRp ZmZlcmVudCBsYXllcikgd2l0aGluIG9uZSBkb21haW4gd2hpY2ggaXMgc29sdmFibGUuIFRoZSBw ZXJmb3JtYW5jZQ0KaXNzdWVzIG5lZWQgdG8gYmUgaGFuZGxlZCAoYXMgSm9lIHdyb3RlKS4gQnV0 LCBhcyBsb25nIGFzIHRoZSBwcm9zL2NvbnMNCmJhbGFuY2UgaXMgb24gdGhlIHBybyBzaWRlLCB0 aGVuIGl0IGlzIHZhbHVhYmxlLg0KDQotw6lyaWMNCg0KDQpPbiAyNy8wNS8xNSAwOTozOSwgIkdl cnQgRG9lcmluZyIgPGdlcnRAc3BhY2UubmV0PiB3cm90ZToNCg0KPkhpLA0KPg0KPk9uIFdlZCwg TWF5IDI3LCAyMDE1IGF0IDEyOjIzOjMwUE0gKzEyMDAsIEJyaWFuIEUgQ2FycGVudGVyIHdyb3Rl Og0KPj4gPiBGV0lXLCBJIGRvbid0IHNlZSBhbnl0aGluZyB0aGF0IHByb2hpYml0cyBhZGRpbmcg aGVhZGVycyBlaXRoZXIuDQo+PiANCj4+ICJXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBo ZWFkZXJzIGFyZSBub3QgZXhhbWluZWQgb3IgcHJvY2Vzc2VkDQo+PiBieSBhbnkgbm9kZSBhbG9u ZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgsIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcw0KPj4g dGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4gdGhlIGNhc2Ugb2YgbXVs dGljYXN0KQ0KPj4gaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBv ZiB0aGUgSVB2NiBoZWFkZXIuIg0KPj4gDQo+PiBUbyBtZSB0aGF0IGNsZWFybHkgaW1wbGllcyBu b3QgYWRkaW5nICh3aGljaCBpcyBhIGZvcm0gb2YgcHJvY2Vzc2luZykuDQo+DQo+U28gaG93IGRv IHRoZSBTUiBmb2xrcyBoYW5kbGUgdGhhdD8gIEZyb20gd2hhdCBJIGhlYXJkLCB0aGUgaW50ZW5k ZWQNCj5kZXBsb3ltZW50IHJlYWxseSBpcyAiaW5zaWRlIHlvdXIgYWRtaW5pc3RyYXRpdmUgZG9t YWluLCBTUiBoZWFkZXJzIGdldA0KPmFkZGVkLCBwcm9jZXNzZWQsIGFuZCB3aGVuIHRoZSBwYWNr ZXQgbGVhdmVzIHlvdXIgZG9tYWluLCB0aGV5IGNhbiBiZQ0KPihvcHRpb25hbGx5KSByZW1vdmVk IGFnYWluIHRvIG5vdCB1cHNldCB5b3VyIG5laWdoYm91cnMiLi4uDQo+DQo+R2VydCBEb2VyaW5n DQo+ICAgICAgICAtLSBOZXRNYXN0ZXINCj4tLSANCj5oYXZlIHlvdSBlbmFibGVkIElQdjYgb24g c29tZXRoaW5nIHRvZGF5Li4uPw0KPg0KPlNwYWNlTmV0IEFHICAgICAgICAgICAgICAgICAgICAg ICAgVm9yc3RhbmQ6IFNlYmFzdGlhbiB2LiBCb21oYXJkDQo+Sm9zZXBoLURvbGxpbmdlci1Cb2dl biAxNCAgICAgICAgICBBdWZzaWNodHNyYXRzdm9ycy46IEEuDQo+R3J1bmRuZXItQ3VsZW1hbm4N Cj5ELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAgICAgICAgIEhSQjogMTM2MDU1IChBRyBNdWVu Y2hlbikNCj5UZWw6ICs0OSAoMCk4OS8zMjM1Ni00NDQgICAgICAgICAgIFVTdC1JZE5yLjogREU4 MTMxODUyNzkNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Thu May 28 11:15:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BD91B2C3A for ; Thu, 28 May 2015 11:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehn1N-DozFCg for ; Thu, 28 May 2015 11:15:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6561B2CA5 for ; Thu, 28 May 2015 11:15:11 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4SIE4oH003871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 May 2015 11:14:04 -0700 (PDT) Message-ID: <55675AEC.10602@isi.edu> Date: Thu, 28 May 2015 11:14:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" , Gert Doering , Brian E Carpenter References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t4SIE4oH003871 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:15:16 -0000 On 5/28/2015 8:26 AM, Eric Vyncke (evyncke) wrote: > Segment Routing Header is currently drafted as another type of routing > header and are drafted to be inserted either by the source or by the > ingress router of a SR-configured domain (then being removed at the exit > of the SR-domain). Destination Option is not useful here as it is > inspected/processed only by the destination while the intent of SR is to > have this information processed by a couple of intermediate routers (which > have a specific configuration as SRH is not enabled by default). Agreed, but note that some Dest Options can occur before the Routing Header options (RFC 2460 Sec 4.1), e.g., where those DOs are relevant to the next router as a "destination" - i.e., those DOs are processed before the RH. > Of course, this causes MTU issues (pretty much like MPLS but at a > different layer) within one domain which is solvable Which is slightly more problematic because the Frag Header comes *after* the Routing Headers, but - as you note - solvable using context. Joe > The performance > issues need to be handled (as Joe wrote). But, as long as the pros/cons > balance is on the pro side, then it is valuable. > > -éric > > > On 27/05/15 09:39, "Gert Doering" wrote: > >> Hi, >> >> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>>> FWIW, I don't see anything that prohibits adding headers either. >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." >>> >>> To me that clearly implies not adding (which is a form of processing). >> >> So how do the SR folks handle that? From what I heard, the intended >> deployment really is "inside your administrative domain, SR headers get >> added, processed, and when the packet leaves your domain, they can be >> (optionally) removed again to not upset your neighbours"... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri May 29 09:56:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA221A0264 for ; Thu, 28 May 2015 09:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wixUXowUJ9u2 for ; Thu, 28 May 2015 09:43:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9858E1A1A40 for ; Thu, 28 May 2015 09:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2561; q=dns/txt; s=iport; t=1432831435; x=1434041035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i1OmtaVh+sQ5eJfw7BHAhyshUv/GjqPoUxN1doPZ3n4=; b=bShU/rIw3f5Fm86zKPELR/RBanb3N+01nffyDiv4JDLTMrnV2b25okRP IJ2552BQTFNp8RBuPp51EyrQ5h/2uK5oK5zMvt/q5tFQRgyGIf/XjpK/t i+qqaUkk2NC8f3gbFUB04i3trniK4mB8w5LgvYsgew+2jLxr5FHgwbsa/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQBmRWdV/5tdJa1cgxBUUQ0GvQSCPwqFdwKBTEwBAQEBAQGBC4QiAQEBAwEBAQELVwkLBQsCAQgYLicLJQIEDgWIJQgN1ToBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItDhFMzB4MXgRYFjAqEQoI8iw+BKZItg1kjgWaCEm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="423382486" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2015 16:43:52 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4SGhqp5005535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 16:43:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.227]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 28 May 2015 11:43:52 -0500 From: "Stefano Previdi (sprevidi)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52O8gsqgABXE4CAAAaigIAABSaAgAAHmwCAAHnhgIACNimA///0LwA= Date: Thu, 28 May 2015 16:43:51 +0000 Message-ID: <598DB10C-41F9-4297-BD43-EA1F99982AED@cisco.com> References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.215.40] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <44E977BA8882C84F96DA113BE7582C23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 09:56:19 -0700 Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:43:57 -0000 On May 28, 2015, at 5:26 PM, "Eric Vyncke (evyncke)" wrote: > Segment Routing Header is currently drafted as another type of routing > header and are drafted to be inserted either by the source or by the > ingress router of a SR-configured domain (then being removed at the exit > of the SR-domain). correct. packet classification at ingress may result into a new SRH (segment routing= header). Very similar (well, mostly the same) to what ipv4/6 packet get with a label= stack. s. > Destination Option is not useful here as it is > inspected/processed only by the destination while the intent of SR is to > have this information processed by a couple of intermediate routers (whic= h > have a specific configuration as SRH is not enabled by default). >=20 > Of course, this causes MTU issues (pretty much like MPLS but at a > different layer) within one domain which is solvable. The performance > issues need to be handled (as Joe wrote). But, as long as the pros/cons > balance is on the pro side, then it is valuable. >=20 > -=E9ric >=20 >=20 > On 27/05/15 09:39, "Gert Doering" wrote: >=20 >> Hi, >>=20 >> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>>> FWIW, I don't see anything that prohibits adding headers either. >>>=20 >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." >>>=20 >>> To me that clearly implies not adding (which is a form of processing). >>=20 >> So how do the SR folks handle that? From what I heard, the intended >> deployment really is "inside your administrative domain, SR headers get >> added, processed, and when the packet leaves your domain, they can be >> (optionally) removed again to not upset your neighbours"... >>=20 >> Gert Doering >> -- NetMaster >> --=20 >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri May 29 09:56:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62281A1BDB for ; Thu, 28 May 2015 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbIckIuqvRQ5 for ; Thu, 28 May 2015 12:01:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13641A8032 for ; Thu, 28 May 2015 12:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3246; q=dns/txt; s=iport; t=1432839666; x=1434049266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4QnAiNQMzpoXrThGAjpx6tDHI3EBipKgCqhLkEWWyNQ=; b=a9guqKuqOlHH3dnzJYH+se+u+2Zg0YAJfOk64BOxX+3piYPFWbOlDUkf a5qyC5QoQjHcQ4n6RJVOyxUdD1660XAGudUZzTup5Oiaha9iqPMT0PFcr n/7WmdtPllrOTlYFwpuOiuxJzsfpH8ajAP0xhXQYXS0q5JYuBxnuuQFqQ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQDLZGdV/5xdJa1cDoMCVF4GvQiCPwqFdwKBTEwBAQEBAQGBC4QiAQEBAwEBAQELVwkLEAIBCBguJwslAgQOBYglCA3VSQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OEUzMHgxeBFgWMCoZ+iw+BKZItg1kjgWaBVD5vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="423442766" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 28 May 2015 19:01:06 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4SJ15gp025641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 19:01:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.227]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 28 May 2015 14:01:05 -0500 From: "Stefano Previdi (sprevidi)" To: Joe Touch Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52O8gsqgABXE4CAAAaigIAABSaAgAAHmwCAAHnhgIACNimAgAANaACAAA0fAA== Date: Thu, 28 May 2015 19:01:05 +0000 Message-ID: <3EBA13CE-8E8A-4969-86B7-CD8047F876F1@cisco.com> References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <55675AEC.10602@isi.edu> In-Reply-To: <55675AEC.10602@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.95.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9680E4CC1AAB1646BF38C170DBDD3E82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 09:56:19 -0700 Cc: "v6ops@ietf.org" , "Mark Townsley \(townsley\)" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 19:01:35 -0000 On May 28, 2015, at 8:14 PM, Joe Touch wrote: >=20 >=20 > On 5/28/2015 8:26 AM, Eric Vyncke (evyncke) wrote: >> Segment Routing Header is currently drafted as another type of routing >> header and are drafted to be inserted either by the source or by the >> ingress router of a SR-configured domain (then being removed at the exit >> of the SR-domain). Destination Option is not useful here as it is >> inspected/processed only by the destination while the intent of SR is to >> have this information processed by a couple of intermediate routers (whi= ch >> have a specific configuration as SRH is not enabled by default). >=20 > Agreed, but note that some Dest Options can occur before the Routing > Header options (RFC 2460 Sec 4.1), e.g., where those DOs are relevant to > the next router as a "destination" - i.e., those DOs are processed > before the RH. >=20 >> Of course, this causes MTU issues (pretty much like MPLS but at a >> different layer) within one domain which is solvable >=20 > Which is slightly more problematic because the Frag Header comes *after* > the Routing Headers, but - as you note - solvable using context. the networking industry already faced the mtu "issue" more than 15 years ag= o with the introduction of the label stack. The reality of network operator= s infrastructure is such that the mtu is not really an issue. s. >=20 > Joe >=20 >> The performance >> issues need to be handled (as Joe wrote). But, as long as the pros/cons >> balance is on the pro side, then it is valuable. >>=20 >> -=E9ric >>=20 >>=20 >> On 27/05/15 09:39, "Gert Doering" wrote: >>=20 >>> Hi, >>>=20 >>> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote: >>>>> FWIW, I don't see anything that prohibits adding headers either. >>>>=20 >>>> "With one exception, extension headers are not examined or processed >>>> by any node along a packet's delivery path, until the packet reaches >>>> the node (or each of the set of nodes, in the case of multicast) >>>> identified in the Destination Address field of the IPv6 header." >>>>=20 >>>> To me that clearly implies not adding (which is a form of processing). >>>=20 >>> So how do the SR folks handle that? From what I heard, the intended >>> deployment really is "inside your administrative domain, SR headers get >>> added, processed, and when the packet leaves your domain, they can be >>> (optionally) removed again to not upset your neighbours"... >>>=20 >>> Gert Doering >>> -- NetMaster >>> --=20 >>> have you enabled IPv6 on something today...? >>>=20 >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>> Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From nobody Fri May 29 11:54:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B3B1AD1A6 for ; Fri, 29 May 2015 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdjU3Jz2qNri for ; Fri, 29 May 2015 11:54:57 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6A1ACF1B for ; Fri, 29 May 2015 11:54:56 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.13,518,1427774400"; d="scan'208";a="259300207" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 May 2015 14:37:42 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 29 May 2015 14:54:54 -0400 From: "Howard, Lee" To: "Stefano Previdi (sprevidi)" , Joe Touch Date: Fri, 29 May 2015 14:54:53 -0400 Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AdCaQPMkIjK8HEc3QEqW2yx+E/bTkw== Message-ID: References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <55675AEC.10602@isi.edu> <3EBA13CE-8E8A-4969-86B7-CD8047F876F1@cisco.com> In-Reply-To: <3EBA13CE-8E8A-4969-86B7-CD8047F876F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:54:58 -0000 On 5/28/15, 3:01 PM, "Stefano Previdi (sprevidi)" wrote: >> >>> Of course, this causes MTU issues (pretty much like MPLS but at a >>> different layer) within one domain which is solvable >> >> Which is slightly more problematic because the Frag Header comes *after* >> the Routing Headers, but - as you note - solvable using context. > > >the networking industry already faced the mtu "issue" more than 15 years >ago with the introduction of the label stack. The reality of network >operators infrastructure is such that the mtu is not really an issue. This statement surprised me so much I thought I should ask: =B3MTU is not really an issue=B2 in general? Lee > >s. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Fri May 29 12:39:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A5C1B2CDF for ; Fri, 29 May 2015 12:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD3aORAlD8Sa for ; Fri, 29 May 2015 12:39:12 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC51D1B2CDC for ; Fri, 29 May 2015 12:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1726; q=dns/txt; s=iport; t=1432928346; x=1434137946; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LW/evEMRdcKFqb4X4COeS7z2xGml9H4G1i5vsU+tFdY=; b=mFiMK+knbXvV51SJQ10F79OVs9XMOkcfPG5xhCauTFEl0YfKr7XQr8sI BsxoE2dhSNuO9nr7jO40ZHSUmH3c7SMOdPyUNddgXJlgyfwJJMco0A0rp UYlNLN19YLQEFzXgp+V4YWzBqus4YRGz/UYeN4RJj930ua6ljw03yu65J Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AwC2v2hV/5RdJa1cDoMCgTIGviUJh1ECgUg4FAEBAQEBAQGBCoQiAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFwjVLAEBAQEBAQEBAQEBAQEBAQEBAQEBGItDhQYHgxeBFgEEkwqCEoFDhz2XMiODOj5vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,519,1427760000"; d="asc'?scan'208";a="154699853" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 29 May 2015 19:39:06 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4TJd6EN027442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 19:39:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.134]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 29 May 2015 14:39:06 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQmkcfWFDVEK2vxUOLrYvhZ1YY8g== Date: Fri, 29 May 2015 19:39:05 +0000 Message-ID: <47D28817-A778-4F1C-99E9-2EEBAA39F5B6@cisco.com> References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <5565FDB1.2070307@isi.edu> In-Reply-To: <5565FDB1.2070307@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_A485377B-7B9B-4B70-A263-6CCBE0F005D7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 19:39:13 -0000 --Apple-Mail=_A485377B-7B9B-4B70-A263-6CCBE0F005D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 27, 2015, at 10:24 AM, Joe Touch wrote: >=20 > So I would think that they MUST NOT be added to IPv6 datagrams except = by > the source. You might consider commenting in Spring, then. They are designed as = something that would be added in, and potentially removed again in, the = network. They are something the ultimate source and destination need = never see. --Apple-Mail=_A485377B-7B9B-4B70-A263-6CCBE0F005D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVWjAV0ayAOS/EQ8MAQIGPBAAt/LQNpYGUGER6JBexqYAFhKjFPlQKWTy 0PpIcDBjruXxlQf3RFijPH1OBNmbBeEC1oiT9AWVB9966PriY4Pb65uwu1Wr1aY+ iwndRua/dMt9sPTiBhyHjm9vu9sDnT5ImaZ3nk801PnjIqUFcs9JYoF4Qv4AsmtY /0ld/gTK8+5AAE5tqnIRsSFF3VbQnM6Vhs/jrpNhp7KcYzuKXNSdRuXCkxbdZe5Y jGdl3TdLHYEzL/4peWC/DwNsfyhmyNvijFkx4Ai58AuNYZsnvSYIhKqHSCoXheEQ Xl0M+//6cBuBAgway8d9XSny9RzmPC1rkP3Vd74IRsciFYj5yMlKzuMHD50mErg8 R01zulYKmMaeICpDAbtweGqW0s+Hd13WlNg+w2YvhvkSMGamiMyA86ET2g9Rl0ct 9duYjy83KrO/Zei0aRjAgezGPohCNd+D7tBRvjau83Nrp4ZDj5CaQduKj58e35fD 5zq16EBRQUGgB4SOSgqc4KmE7vciOAiIJWK8T9chig/vY//wWtg3FbDf66+fpFz/ 63mPdZvPLoNu6UOHJksULQCiRz3otjS+/duY7iFUT9bHMS0r25NyN7cerktqwtMJ Z6Ep1QEnTm4jqNaxv9LEmjPZ6jO0VG9WfkJbTCw+Zzylqb93ErRK8SAAwBhJjRe4 r9fIKsxtkCA= =g2Zg -----END PGP SIGNATURE----- --Apple-Mail=_A485377B-7B9B-4B70-A263-6CCBE0F005D7-- From nobody Fri May 29 12:45:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CCB1B2CE9 for ; Fri, 29 May 2015 12:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVlWtpUY5n3V for ; Fri, 29 May 2015 12:45:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AB31B2CE1 for ; Fri, 29 May 2015 12:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1849; q=dns/txt; s=iport; t=1432928723; x=1434138323; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=26W2diBKpdgJvkgkfIYx6IYJHyPYF3A/DPphI0K23V0=; b=MWZ4q/yMHHKAz+jYBaFXKFQ7sE4LepewsjF7YcsEOG+gNYXikpXWqufF 7xxTJHUKaDRVaezHMqKMYHQLJJUzbd4vjE7V80EJ33DLYfkqjEndVI3Ee acNcJKMLPdwWKeyLq1QPgij2DGfzpbMZYUweoIG9Hh0nfwSdLZ/Qtl4GW k=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQCIwWhV/4UNJK1cgxCBMgbFfwKBSEwBAQEBAQGBC4QiAQEBAwF5BQsCAQgYLjIlAgQOBQ6IFwjVMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4UGB4QtAQSTCoISgUOHPYEpkjCDWSOCBx+BUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,519,1427760000"; d="asc'?scan'208";a="15911469" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 29 May 2015 19:45:22 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4TJjM5p002364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 19:45:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.134]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 29 May 2015 14:45:22 -0500 From: "Fred Baker (fred)" To: "Howard, Lee" Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices Thread-Index: AQHQmkf/WFDVEK2vxUOLrYvhZ1YY8g== Date: Fri, 29 May 2015 19:45:21 +0000 Message-ID: <2611A956-958E-4480-9761-3664400769BE@cisco.com> References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <55675AEC.10602@isi.edu> <3EBA13CE-8E8A-4969-86B7-CD8047F876F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_8DC6A499-2D61-402F-BDA8-4DCBB5CEFAE8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 19:45:24 -0000 --Apple-Mail=_8DC6A499-2D61-402F-BDA8-4DCBB5CEFAE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On May 29, 2015, at 11:54 AM, Howard, Lee = wrote: >=20 >> the networking industry already faced the mtu "issue" more than 15 = years >> ago with the introduction of the label stack. The reality of network >> operators infrastructure is such that the mtu is not really an issue. >=20 > This statement surprised me so much I thought I should ask: > "MTU is not really an issue" in general? It's largely a question of equipment choice and configuration. Equipment = made with merchant chips, and older equipment, may or may not support = MTUs larger than 1500 bytes for an Ethernet frame, but the chips we use = in our current products (I can't really speak for J or H, but AFAIK this = is true of them as well) are quite content with a 9K MTU. If your source = is sending 1500 byte frames, how large do you need the MTU to be? --Apple-Mail=_8DC6A499-2D61-402F-BDA8-4DCBB5CEFAE8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVWjBz59ieig10VPpAQLQaAf+JMSAoBE07jLUKmDfS0nH5CKIo7kGbUmF 5DX9wDAsNiAWDs33WAg6c+iRX20pPkCCUjxJIZfxsVSVH13D6pOI409FQdtxWN22 XNgVo6qJ/cI+NXjN4gPbxW7ngRFD55NK7iNHGN5q/CGnriy3OaPN9SzyyFWe+XCR 5sHqn2ZCh1s/2EMv4wKfvnLFb9wSN+fWsSXmG1j7ugFcdEKjALOQvD0IBOlJHmg0 +rxyWVh0WZIupD0ZBd/HkNTdKtr3eIXqvz1Gkc/AsAUHqkIaE9otRYwILQyzqMvB WRqu9QzhuXXd/dOd4+KGC4MgoRyIN+EUIxS/h5IP3JKKMcQPAp1Nhg== =eQzH -----END PGP SIGNATURE----- --Apple-Mail=_8DC6A499-2D61-402F-BDA8-4DCBB5CEFAE8-- From nobody Fri May 29 13:24:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F60E1B2CFB for ; Fri, 29 May 2015 13:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_j4v0F42Lhu for ; Fri, 29 May 2015 13:24:04 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEB31B2CEF for ; Fri, 29 May 2015 13:24:04 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t4TKNQqB018558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2015 13:23:26 -0700 (PDT) Message-ID: <5568CABD.1030900@isi.edu> Date: Fri, 29 May 2015 13:23:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <555AB8FA.2080405@si6networks.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <5565FDB1.2070307@isi.edu> <47D28817-A778-4F1C-99E9-2EEBAA39F5B6@cisco.com> In-Reply-To: <47D28817-A778-4F1C-99E9-2EEBAA39F5B6@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Extension Headers / Impact on Security Devices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:24:05 -0000 On 5/29/2015 12:39 PM, Fred Baker (fred) wrote: > >> On May 27, 2015, at 10:24 AM, Joe Touch wrote: >> >> So I would think that they MUST NOT be added to IPv6 datagrams except by >> the source. > > You might consider commenting in Spring, then. They are designed as > something that would be added in, and potentially removed again in, the > network. They are something the ultimate source and destination need > never see. As I also noted, adding things "on behalf of" the source is equivalent. If these are things the source never sees and used only on the path, then they are *by definition* HBH options and should be indicated as such. Joe From nobody Sun May 31 11:00:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4FC1A877B for ; Sun, 31 May 2015 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P_teTYCvKwv for ; Sun, 31 May 2015 11:00:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2C61A876D for ; Sun, 31 May 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=632; q=dns/txt; s=iport; t=1433095204; x=1434304804; h=date:from:message-id:to:subject:cc; bh=seFf8QR6WMbJAfhVcgTuKclBPrYWLKCQxni+fo28YJw=; b=LAXt8fhV+Ve7klzPbcVWqD1ZwtYt98pQZs5cxS36+p2JSivhtoWHCIcI IMSKZ9HkyGQhtg0dSmGeazGrotcoNvUVXsOVMz7VM+voqbh6MtIt++9JG 3K9yQ5cI0fNa3J10cyw2Wz/rBgWRTu6CisNRBd4b0to0nYDgPyUT2CjPo E=; X-IronPort-AV: E=Sophos;i="5.13,527,1427760000"; d="scan'208";a="3318173" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 31 May 2015 18:00:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4VI03An025830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2015 18:00:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t4VI02WX026431; Sun, 31 May 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t4VI02Cf026378; Sun, 31 May 2015 11:00:02 -0700 Date: Sun, 31 May 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201505311800.t4VI02Cf026378@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 18:00:05 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun May 31 16:45:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24001B2E8D for ; Sun, 31 May 2015 16:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0tKEZ_niuUO for ; Sun, 31 May 2015 16:45:38 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779AC1B2E8B for ; Sun, 31 May 2015 16:45:38 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so33069716pdb.2 for ; Sun, 31 May 2015 16:45:38 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iNUluuHTcGiCJVctXuWZaoY4wESAjcaU7fvd2TrlJ0A=; b=FSwxjankeprx2foyYoSNAYuYt4Gu0sa01lAF0EcIRs/CZkx1ObVuKNdoLLiUCXCQsS diQ8uE7OQRuE08nArlENTnlGb2TiIT8+JliGGTOMS9FSvildxGjBZAcTkWgpm3404nzy Glz3o+ZtFSMxiT2L5QYLwYfaLPmA39BwHw2A59I4S0ddmYYuGrpp2BnoETossro7Yy+1 3ZCQs4BjH9sGqrxt+JUrrSvOOKEkXUJcs3fGmaeNUy17/m5QWF3F7DY8BCnSRJlDTf4R H64vEnYL7iO1ieqc4AmApdu/2X9vyFuS5+/w/cUQG8ey/uiNcJUb08/LJ/iuyKvBlL1r TgIA== X-Received: by 10.70.54.103 with SMTP id i7mr35817079pdp.134.1433115938116; Sun, 31 May 2015 16:45:38 -0700 (PDT) Received: from ?IPv6:2406:e007:68be:1:28cc:dc4c:9703:6781? ([2406:e007:68be:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fm3sm12289217pdb.28.2015.05.31.16.45.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2015 16:45:36 -0700 (PDT) Message-ID: <556B9D1D.802@gmail.com> Date: Mon, 01 Jun 2015 11:45:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201505311800.t4VI02Cf026378@irp-lnx1.cisco.com> In-Reply-To: <201505311800.t4VI02Cf026378@irp-lnx1.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 23:45:40 -0000 Hi, Generally I think this is useful and almost ready. > 3.1. Alternatives > > As an alternative, it may be appropriate to lower the TCP MSS to 1220 > in order to accommodate 1280 byte MTU. We consider this undesirable > as hosts may not be able to independently set TCP MSS by address- > family thereby impacting IPv4, or alternatively that it relies on a > middle-box to clamp the MSS independently from the end-systems. The "that" in the second sentence doesn't parse. I don't understand what the draft is trying to say about MSS clamping. Also, shouldn't we say "undesirable but possibly necessary in some cases"? A server at the mercy of an ISP might *need* to apply MSS clamping. Nit: It's confusing to have these two sections with identical titles: > 3.1. Alternatives > 3.2.1. Alternatives Maybe 3.1 should be "MSS-based Alternatives" and 3.2.1 "Distributed Proxy Alternatives" Brian On 01/06/2015 06:00, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >