From nobody Fri Jul 1 06:00:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9812D12B for ; Fri, 1 Jul 2016 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RH4SeVsjrzNo for ; Fri, 1 Jul 2016 06:00:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB4612D5DB for ; Fri, 1 Jul 2016 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=635; q=dns/txt; s=iport; t=1467378040; x=1468587640; h=date:from:message-id:to:subject; bh=dYRNyQv7mtVTTLVw/rk8C40JGdajpE1lyNbPeOgThCQ=; b=VpIeaeOui7WD/V0jFWG3E50bRxWunzLId3Q4/sLuip5FRtmxRRROde5C 3+mrmApqickeTXkBduRDOholzmxFr4KWuCk3VGpwNZWsO4IZZoA1dA5Wb nz0UVnbuep1XBHhnouq6H4Wmu0tGzoDaJeJUi5UeKZPlbcK4MPEr/Cn0q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAdaXZX/5xdJa1dgz6qHZEFgXuHS?= =?us-ascii?q?TgUAQEBAQEBAWUnhgg0iRABpC+fegEBAQcBAQEBAQEhkAGFDwWOdYobgTGOZ41?= =?us-ascii?q?WkAkeNoQQiUIBAQE?= X-IronPort-AV: E=Sophos;i="5.26,557,1459814400"; d="scan'208";a="292383583" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 13:00:36 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u61D0Zrj012795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2016 13:00:36 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 u61D0ZvI011451 for ; Fri, 1 Jul 2016 06:00:35 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u61D0Z2m011450 for v6ops@ietf.org; Fri, 1 Jul 2016 06:00:35 -0700 Date: Fri, 1 Jul 2016 06:00:35 -0700 From: fred@cisco.com Message-Id: <201607011300.u61D0Z2m011450@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:00:57 -0000 RFC Editor: AUTH48 2016-05-27 draft-ietf-v6ops-host-addr-availability WG: Unupdated WG Document 2016-02-16 draft-ietf-v6ops-dhcpv6-slaac-problem 2016-02-08 draft-ietf-v6ops-ula-usage-considerations Individual Submission: Unupdated 2016-03-21 draft-ybai-v6ops-ipv6-for-openstack 2016-03-11 draft-gont-v6ops-ipv6-ehs-packet-drops 2016-02-27 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment Individual Submission: Updated 2016-06-27 draft-templin-v6ops-pdhost 2016-06-20 draft-anderson-v6ops-v4v6-xlat-prefix From nobody Mon Jul 4 11:17:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC53B12D10F for ; Mon, 4 Jul 2016 11:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 Hw2tZjQlxXIL for ; Mon, 4 Jul 2016 11:16:58 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67BA12D53C for ; Mon, 4 Jul 2016 11:16:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u64IGoOM013229; Mon, 4 Jul 2016 20:16:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 860CE2067C6; Mon, 4 Jul 2016 20:17:58 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 76983206738; Mon, 4 Jul 2016 20:17:58 +0200 (CEST) Received: from [132.166.84.110] ([132.166.84.110]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u64IGoxd020956; Mon, 4 Jul 2016 20:16:50 +0200 To: Joe Touch , Owen DeLong References: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> From: Alexandre Petrescu Message-ID: <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> Date: Mon, 4 Jul 2016 20:16:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 18:17:00 -0000 Le 23/06/2016 à 22:51, Joe Touch a écrit : > > > On 6/23/2016 1:33 PM, Owen DeLong wrote: >>> So I think we should suggest to use 33:33::1 MAC address instead >>> of the ff:ff:ff:ff:ff:ff MAC address when IPv6 is used over >>> these links. I will put that in some draft. >> That’s probably a good start. > > IMO, it'd be better to say you're using "all nodes" and cite RFC2464 > rather than opaquely using the MAC that results. Well "all nodes" direction sounds better compared to previous "all cars". But RFC2464 does not define such MAC address, neither such IP address, so one wouldnt cite RFC2464 meaningfully. The Group ID "all nodes" for an IP address is defined in RFC4291 and the allocations are managed at http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml But "all nodes" means actually any IP-capable node, not necessarily those that run 802.11-OCB (aka 802.11p) - i.e. WiFi, LTE and others. I could not find a MAC address "all nodes" defined at IEEE. At IEEE I found a 48bit "All Multicast Capable End Systems Address" 01-80-C2-00-00-1B; it is listed there: https://standards.ieee.org/develop/regauth/grpmac/public.html Remark (1) I have never seen this 48bit IEEE address in vehicular network trials and (2) it is not a "33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6 vehicular prototypes. In this context, I believe it can make sense to think of requesting IANA (rather than IEEE) for an allocation of a 112bit Group ID named "All 802.11-OCB interfaces"; this Group ID could then be used with scope link, or site, or admin - to make a full multicast IP address. Then it would come down to define a link scope to be the scope between a few nearby cars, site scope to be the scope between one platoon, and so on. What do you think? Alex > > Joe > From nobody Mon Jul 4 17:53:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0A12B010 for ; Mon, 4 Jul 2016 17:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nhII6pU60Ruh for ; Mon, 4 Jul 2016 17:53:05 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 C57D11288B8 for ; Mon, 4 Jul 2016 17:53:05 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id g4so30497585ith.1 for ; Mon, 04 Jul 2016 17:53:05 -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; bh=MUuvPd8/fwBpMMdm7numuNWrSNx16pQk5Upb8wAgXQc=; b=GoVEc8WxJjVCHX3o2K+aGBEt14RivTjs7dFQraB3enTKDalT0WTXaq6iQxVg8wuZRY CKwjZKpn60SVg1rSG1DklHF2lJhsmlzfiLguNL8tR7sxQGU51ay2UR41Ehwt7nn8EDyy 1JIxnTrxk2POee6nLAZ0Cu9XkGGwt/WIB1tjR0h+JX/vlPX3YuWudTjnZ6TPqaPcH9v6 lIAfMKIyBbNparzKQ9SPehU49sh4HoU+7kAdcD7+uJnPvKvDwB4+/Ub9PLfw/1qYDRBk D/49B+9PMpAjltzlyPI/+J+1YFmd9nm6RVRTuOJQxsXx9TuExxwhcEEmvDCSz1sau/S0 sg2Q== 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; bh=MUuvPd8/fwBpMMdm7numuNWrSNx16pQk5Upb8wAgXQc=; b=Tjnd3d4He2PhH3CuWaZvMXfEj6YFYC+Qp++LBOm0vFkHvrSeOWebD+Owkz2+kkR7WY Nhc+9/rg86y/+VPvlBrlEeb/V1Y3mo9RVi7e6NzpZOs8QlYcvLkA3fXkR/5cU7zZmnB3 LWF09MuiYvrrmpi/8DPceuaTpfwwFfRo4mb2nnVa7cMH4zSlA3T0PYFl6W4MpMyWYZj+ p6wssNHMPTfdnXgqv6lhUi58qWzb0tks7mTfoE0zPZhGL+Oa23Z+7LeXyDM7zrBDKL8s B2CWm94RG3JGv9IBV9Y1bKGxalb+QN+NMKY+ulJGp8+GRkYhs9sAICoeZdrtA16DkkCc Uaqg== X-Gm-Message-State: ALyK8tIMahtEDM28KaGMdmMXi6msICFmTcHy5Gi7Q96M9Ewp3Jqri4eUKDNV924MQMY0Qx2hPC0RXMZbsY3ZbTvR X-Received: by 10.36.149.130 with SMTP id m124mr11858632itd.94.1467679984989; Mon, 04 Jul 2016 17:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.74 with HTTP; Mon, 4 Jul 2016 17:52:45 -0700 (PDT) In-Reply-To: <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> References: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> From: Erik Marcus Kline Date: Tue, 5 Jul 2016 09:52:45 +0900 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 00:53:08 -0000 > What do you think? I think that until the subnet model is understood, i.e. this section needs to be completed: https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04#section-5.6 the meaningful mapping of addresses cannot claimed to be understood, i.e. this section is incomplete/inaccurate until the subnet model is understood: https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04#section-5.4 From nobody Tue Jul 5 02:07:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20B412D190 for ; Tue, 5 Jul 2016 02:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 0hjFYbVAL5gN for ; Tue, 5 Jul 2016 02:07:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF2712D187 for ; Tue, 5 Jul 2016 02:07:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DCFE4B80B94; Tue, 5 Jul 2016 02:07:14 -0700 (PDT) To: dwing@cisco.com, ayourtch@cisco.com, bclaise@cisco.com, joelja@bogus.com, lee@asgard.org, fred.baker@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160705090714.DCFE4B80B94@rfc-editor.org> Date: Tue, 5 Jul 2016 02:07:14 -0700 (PDT) Archived-At: Cc: stefan.winter@restena.lu, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Editorial Errata Reported] RFC6555 (4728) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:07:17 -0000 The following errata report has been submitted for RFC6555, "Happy Eyeballs: Success with Dual-Stack Hosts". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6555&eid=4728 -------------------------------------- Type: Editorial Reported by: Stefan Winter Section: 1 Original Text ------------- However, this does not scale well (to the number of DNS servers worldwide or the number of content providers worldwide) and does react to intermittent network path outages. Corrected Text -------------- However, this does not scale well (to the number of DNS servers worldwide or the number of content providers worldwide) and does not react to intermittent network path outages. Notes ----- The introduction makes a case against a whitelist of DNS servers because it does not scale well and is not flexible. DNS server whitelists indeed to not react to intermittent network outages, so the only logical sentence to form is to state that they do not. The "not" has been omitted, reversing the logical meaning of the sentence. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6555 (draft-ietf-v6ops-happy-eyeballs-07) -------------------------------------- Title : Happy Eyeballs: Success with Dual-Stack Hosts Publication Date : April 2012 Author(s) : D. Wing, A. Yourtchenko Category : PROPOSED STANDARD Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Jul 5 10:04:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2098112D664 for ; Tue, 5 Jul 2016 10:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 tejiaExAT0iq for ; Tue, 5 Jul 2016 10:04:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 6C38112D663 for ; Tue, 5 Jul 2016 10:04:00 -0700 (PDT) Received: from [128.9.184.115] ([128.9.184.115]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u65H3JDt003885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Jul 2016 10:03:19 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> From: Joe Touch Message-ID: <577BE854.2050002@isi.edu> Date: Tue, 5 Jul 2016 10:03:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:04:04 -0000 On 7/4/2016 11:16 AM, Alexandre Petrescu wrote: > > > Le 23/06/2016 à 22:51, Joe Touch a écrit : >> ... >> IMO, it'd be better to say you're using "all nodes" and cite RFC2464 >> rather than opaquely using the MAC that results. > > Well "all nodes" direction sounds better compared to previous "all > cars". But RFC2464 does not define such MAC address, neither such IP > address, so one wouldnt cite RFC2464 meaningfully. > > The Group ID "all nodes" for an IP address is defined in RFC4291 and the > allocations are managed at > http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > > > But "all nodes" means actually any IP-capable node, not necessarily > those that run 802.11-OCB (aka 802.11p) - i.e. WiFi, LTE and others. That's because IP multicast addresses are assigned based on protocols that run OVER IP, not those that operate underneath. > > I could not find a MAC address "all nodes" defined at IEEE. That's usually what all 1's is used for. At the link layer, there isn't much difference between broadcast and multicast "all nodes". > At IEEE I found a 48bit "All Multicast Capable End Systems Address" > 01-80-C2-00-00-1B; it is listed there: > https://standards.ieee.org/develop/regauth/grpmac/public.html That's listed as LLDP too - and that makes sense if you want to use a link address over which to find 802.11p-capable nodes. > Remark (1) I have never seen this 48bit IEEE address in vehicular > network trials and (2) it is not a "33-33-XX-XX-XX-XX" address, which > _is_ present in some IPv6 vehicular prototypes. > > In this context, I believe it can make sense to think of requesting IANA > (rather than IEEE) for an allocation of a 112bit Group ID named "All > 802.11-OCB interfaces"; There are no other IPv6 multicast addresses that group nodes by link type. This sort of request doesn't make sense to me at all; it's a bit backwards. AFAICT, you either really want to use LLDP at the link layer or the existing SSDP IPv6 multicast address to identify your service. Joe From nobody Tue Jul 5 17:24:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4093B12B02D for ; Tue, 5 Jul 2016 02:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 oeKviYZWDomx for ; Tue, 5 Jul 2016 02:56:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97BF126FDC for ; Tue, 5 Jul 2016 02:56:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8A734B80323; Tue, 5 Jul 2016 02:56:50 -0700 (PDT) To: fgont@si6networks.com, furry@google.com, tim.chown@jisc.ac.uk, liushucheng@huawei.com, bclaise@cisco.com, joelja@bogus.com, lee@asgard.org, fred.baker@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160705095650.8A734B80323@rfc-editor.org> Date: Tue, 5 Jul 2016 02:56:50 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Tue, 05 Jul 2016 17:24:26 -0700 Cc: bortzmeyer+ietf@nic.fr, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Editorial Errata Reported] RFC7872 (4729) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 09:56:52 -0000 The following errata report has been submitted for RFC7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7872&eid=4729 -------------------------------------- Type: Editorial Reported by: Stéphane Bortzmeyer Section: A.1 Original Text ------------- The domain names corresponding to the WIPv6LD dataset is available at . Corrected Text -------------- [Correct URL] Notes ----- % wget http://www.si6networks.com/datasets/wipv6day-domains.txt --2016-07-05 11:56:27-- http://www.si6networks.com/datasets/wipv6day-domains.txt Resolving www.si6networks.com (www.si6networks.com)... 2001:67c:27e4::14, 91.239.96.14 Connecting to www.si6networks.com (www.si6networks.com)|2001:67c:27e4::14|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.si6networks.com/datasets/wipv6day-domains.txt [following] --2016-07-05 11:56:28-- https://www.si6networks.com/datasets/wipv6day-domains.txt Connecting to www.si6networks.com (www.si6networks.com)|2001:67c:27e4::14|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2016-07-05 11:56:28 ERROR 404: Not Found. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7872 (draft-ietf-v6ops-ipv6-ehs-in-real-world-02) -------------------------------------- Title : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Publication Date : June 2016 Author(s) : F. Gont, J. Linkova, T. Chown, W. Liu Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Jul 6 09:41:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BAB12D13D for ; Wed, 6 Jul 2016 09:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.927 X-Spam-Level: X-Spam-Status: No, score=-115.927 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YUQ0HVARDw2V for ; Wed, 6 Jul 2016 09:41:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB3C12D1A7 for ; Wed, 6 Jul 2016 09:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4274; q=dns/txt; s=iport; t=1467822800; x=1469032400; h=from:to:cc:subject:date:message-id:references: mime-version; bh=RIo7faBthOQFF+ZCokurhyy9J07OhFd3tCmryv8MDOM=; b=FRQtQO1pF2WY3B5aykRPN0z2l4exoBpHYkZ7Zqh5fTKeKufLfSODfnkq iqzMzK1uMF8y5/Og3Z2gKM5HECZbD/F08BWIPbIsZVGfRTpce+VRcU6Ha /SZSXYqrVkzJ/p08JyOBoJxqdhALqcGe39nkA+1yQAVcqP92NmG9KZFqf 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsBQDBMX1X/51dJa1dgz5WfAa5FYF3J?= =?us-ascii?q?IV0AoEqORMBAQEBAQEBZRwLhEwBAQQBdwIFCwIBGQMBAhYZMhsCCAIEDgUODYg?= =?us-ascii?q?NCA68HAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OiB8Igk2EYB4Bgm2CLwWOBIsPA?= =?us-ascii?q?YMugWxuiD6Bak6ECIhqkAkBIAEzggM4gTVuAYdyfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="asc'?scan'208";a="294455716" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 16:33:19 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u66GXJfB026133 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 16:33:19 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 11:33:19 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 11:33:18 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt Thread-Index: AQHR1yGHpV/N7071yUi9iFfm+i92VA== Date: Wed, 6 Jul 2016 16:33:18 +0000 Message-ID: <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_931C3748-2C93-41A1-9DA3-CA5D6B677951"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Jen Linkova , Chris Bowers Subject: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 16:41:12 -0000 --Apple-Mail=_931C3748-2C93-41A1-9DA3-CA5D6B677951 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At IETF 94, this working group advised the routing ADs and Routing = Working Group that PA multihoming would not work without a = source/destination routing solution. This draft was developed in = response. Routing Working Group requests v6ops review. > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > Date: July 5, 2016 at 5:58:25 PM PDT > To: Chris Bowers , Jen Linkova = , "Fred Baker" , "J. Linkova" = >=20 >=20 > A new version of I-D, = draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. >=20 > Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming > Revision: 00 > Title: Enterprise Multihoming using Provider-Assigned = Addresses without Network Prefix Translation: Requirements and Solution > Document date: 2016-07-05 > Group: Individual Submission > Pages: 44 > URL: = https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-m= ultihoming-00.txt > Status: = https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multi= homing/ > Htmlized: = https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihomin= g-00 >=20 >=20 > Abstract: > Connecting an enterprise site to multiple ISPs using provider- > assigned addresses is difficult without the use of some form of > Network Address Translation (NAT). Much has been written on this > topic over the last 10 to 15 years, but it still remains a problem > without a clearly defined or widely implemented solution. Any > multihoming solution without NAT requires hosts at the site to have > addresses from each ISP and to select the egress ISP by selecting a > source address for outgoing packets. It also requires routers at the > site to take into account those source addresses when forwarding > packets out towards the ISPs. >=20 > This document attempts to define a complete solution to this problem. > It covers the behavior of routers to forward traffic taking into > account source address, and it covers the behavior of host to select > appropriate source addresses. It also covers any possible role that > routers might play in providing information to hosts to help them > select appropriate source addresses. In the process of exploring > potential solutions, this documents also makes explicit requirements > for how the solution would be expected to behave from the perspective > of an enterprise site network administrator . >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_931C3748-2C93-41A1-9DA3-CA5D6B677951 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 iQIVAwUBV30yzEayAOS/EQ8MAQJ+8w/+Nh/WlnMwELggbbTx3X39WJCplF5+PaBi oL0EHY6TlaLA1qucunf5d3tnK/eUcHfC0AVyA1kzR9NhMb3fcE1QLG68sV9UonvF rrnhPtFGAAahhNPXdiqX+L/MeU1UyddS23DYkkmgKS8TdscFWRDrz3t1WLU47vYY HpoMfogMgftTcBlbjkQAUh+MB9Q/7HVhmyyA4dvSdnGJxXY9SrZbc0qG7cnPdOkG nIduMEW3Dxp9c4FgQw506mKXUrbUeYGpHz0FIx1GxFeU3mryGfnu6DWK3WpmFu8/ 7RWNIFhCxUrIkt9YsmrN/Fs3nxVouHBoF200g+ZOzeI7JghURN/vxeLSaRuExvjR 6nag91c1bjA4C/RiOtPCQIUfjztrzekAH7mCMHgjmUw5ynv8lcko9mFKI4mVexqK TtnFXG+pe85AXOtPGIbq1iOKqHuojlIM7fq/3Grl+IDJDCxD7m3ZXju0yB/t5Jkg BtYfMnS+S0xl+z2p5AxjVUt4JymqqhgPEuMPU9n4K5eU/hJV2Q372L8NFBaZfIXT kM0fZTMG78gmzJ/plmY9ZIklCrLXXQqZN3pOGGdXfzVoXz22pb+mZyKZCY65djYQ 0RcXc59sTCwho6ayySmHZUh85N0TRw0521uGpfZZieM6QdDEygk2XoPwA285hZIO flkmfbp1zE4= =T0Ru -----END PGP SIGNATURE----- --Apple-Mail=_931C3748-2C93-41A1-9DA3-CA5D6B677951-- From nobody Thu Jul 7 05:19:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CECB12D17E for ; Thu, 7 Jul 2016 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 uH1j_kNiN1bQ for ; Thu, 7 Jul 2016 05:19:12 -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 D0E4712D122 for ; Thu, 7 Jul 2016 05:19:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u67CJ5Z5011121; Thu, 7 Jul 2016 14:19:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 79EC1204C14; Thu, 7 Jul 2016 14:19:05 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6A4E12048D0; Thu, 7 Jul 2016 14:19:05 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u67CJ40i020517; Thu, 7 Jul 2016 14:19:05 +0200 To: Joe Touch , Owen DeLong References: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> From: Alexandre Petrescu Message-ID: <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> Date: Thu, 7 Jul 2016 14:19:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <577BE854.2050002@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 12:19:14 -0000 Le 05/07/2016 à 19:03, Joe Touch a écrit : > > > On 7/4/2016 11:16 AM, Alexandre Petrescu wrote: >> >> >> Le 23/06/2016 à 22:51, Joe Touch a écrit : >>> ... >>> IMO, it'd be better to say you're using "all nodes" and cite RFC2464 >>> rather than opaquely using the MAC that results. >> >> Well "all nodes" direction sounds better compared to previous "all >> cars". But RFC2464 does not define such MAC address, neither such IP >> address, so one wouldnt cite RFC2464 meaningfully. >> >> The Group ID "all nodes" for an IP address is defined in RFC4291 and the >> allocations are managed at >> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml >> >> >> But "all nodes" means actually any IP-capable node, not necessarily >> those that run 802.11-OCB (aka 802.11p) - i.e. WiFi, LTE and others. > > That's because IP multicast addresses are assigned based on protocols > that run OVER IP, not those that operate underneath. Yes, IP multicast addresses are so assigned. But some IP multicast addresses correspond to some MAC group addresses, on a 1-to-1 basis: for the 'all-nodes' link-scoped IP multicast address there is a 'all-nodes' MAC group address. The other way around too: for a 'all-nodes' MAC group address there is an IP multicast address called 'all-nodes' with link scope. And, over 802.11p too a MAC multicast address corresponds to an IP multicast address. >> I could not find a MAC address "all nodes" defined at IEEE. > > That's usually what all 1's is used for. At the link layer, there isn't > much difference between broadcast and multicast "all nodes". No no, there _is_ a difference. IPv6 does not work with all 1s MAC broadcast address, it only works with 33-33-0-0-0-1 MAC multicast address. IPv4 only works with all 1s MAC broadcast address. >> At IEEE I found a 48bit "All Multicast Capable End Systems Address" >> 01-80-C2-00-00-1B; it is listed there: >> https://standards.ieee.org/develop/regauth/grpmac/public.html > > That's listed as LLDP too - and that makes sense if you want to use a > link address over which to find 802.11p-capable nodes. A-ha, it makes sense. So the question is: which group MAC address should IPv6-over-80211p use: - ff:ff:ff:ff:ff:ff - obviously the answer is no. - 33:33:00:00:00:01 - like IPv6-over-WiFi does - 01-80-C2-00-00-1B - like LLDP does - request a new one? >> Remark (1) I have never seen this 48bit IEEE address in vehicular >> network trials and (2) it is not a "33-33-XX-XX-XX-XX" address, which >> _is_ present in some IPv6 vehicular prototypes. >> >> In this context, I believe it can make sense to think of requesting IANA >> (rather than IEEE) for an allocation of a 112bit Group ID named "All >> 802.11-OCB interfaces"; > > There are no other IPv6 multicast addresses that group nodes by link > type. This sort of request doesn't make sense to me at all; it's a bit > backwards. I agree there are no other IPv6 multicast addresses that group the nodes by link type (you dont have an address called "all Ethernet nodes" for example). However, 802.11p is not really a particular link type - it is WiFi. Moreover, we are not concerned here with a request to IEEE. An IPv6-over-foo I-D describes _mappings_, i.e. what number gets mapped from IETF to IEEE identifier. As such, it is reasonable to request at IETF a 112bit Group Identifier, parts of which may get mapped to some bytes of a group multicast address. The overall goal is that people stop using the MAC broadcast address on 802.11p (all 1s) and start using a single MAC group address (not various). > AFAICT, you either really want to use LLDP at the link layer or the > existing SSDP IPv6 multicast address to identify your service. YEs, later, when we discuss application-level services that is a very good direction. For example we need to identify a group of all taxis in a cell to send them a call. But for now we need a group MAC address on 802.11p on which we can send network-layer messages like Router Advertisements. Alex > > Joe > From nobody Thu Jul 7 08:36:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1460912D7EC; Thu, 7 Jul 2016 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lZDrGrp1uEAt; Thu, 7 Jul 2016 08:36:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C0A12D7DB; Thu, 7 Jul 2016 08:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43700; q=dns/txt; s=iport; t=1467905760; x=1469115360; h=from:to:cc:subject:date:message-id:mime-version; bh=BGsr6uUXEBpPftyIlfqopOCNYWCdJHxpwWRD9XCj/Sk=; b=WPFWMU3sHYusSMEjMWtuoklZwPgMrjX5NOj4vFqAZDSGQOe3vLPsMsKf NjrUbAbzz9zAeZl0lq2QGq3/E62WCNdTr78NxFf7bm0xTCGBAsROF80Be K5MWNv+Ftrz3R+c+d3/+Phne1ixWPc4kJant9thdcbv78LG/lf8tVKYEP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQBQDHdX5X/4kNJK1cgnBOVnwGuwQih?= =?us-ascii?q?XYCHIEOOxEBAQEBAQEBZSeETAEBBSMEUhIBCBEDAQIhAQYDAgQwFAkKBA4FiDA?= =?us-ascii?q?OrUKGJokNAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNhFcJFoJLgloFmRMBh?= =?us-ascii?q?giIPoFqjUCGV4kyATQgggkcgUxuh31/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,324,1464652800"; d="scan'208,217";a="294798399" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2016 15:35:59 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u67FZwVT032757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jul 2016 15:35:59 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 7 Jul 2016 11:35:57 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 7 Jul 2016 11:35:58 -0400 From: "Eric Vyncke (evyncke)" To: Markus deBruen Thread-Topic: Aw: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHR2GVBi5ZDkDzj802jyMIukJSwZQ== Date: Thu, 7 Jul 2016 15:35:58 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.159.132] Content-Type: multipart/alternative; boundary="_000_D3A3CD7A7721Aevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "fgont@si6networks.com" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:36:03 -0000 --_000_D3A3CD7A7721Aevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFya3VzDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3LCBJIGtub3cgaXQgdGFr ZXMgdGltZSB0byBkby4NCg0KSSBoYXZlIGFjY2VwdGVkIG1vc3Qgb2YgdGhlbSBleGNlcHQgdGhv c2UgbWFya2VkIHdpdGggRVZZPj4NCg0KVGhhbmtzIGFnYWluIGFuZCBzZWUgeW91IGluIEJlcmxp biwgeW91ciA6OjEgOy0pDQoNCi3DqXJpYw0KDQoNCkZyb206IE1hcmt1cyBkZUJydWVuIDxsaW5r ZWRpbkB4bi0tZGVicm4tbnZhLmRlPG1haWx0bzpsaW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlPj4N CkRhdGU6IFdlZG5lc2RheSAxNSBKdW5lIDIwMTYgYXQgMDc6MDQNClRvOiBFcmljIFZ5bmNrZSA8 ZXZ5bmNrZUBjaXNjby5jb208bWFpbHRvOmV2eW5ja2VAY2lzY28uY29tPj4NCkNjOiAib3BzZWNA aWV0Zi5vcmc8bWFpbHRvOm9wc2VjQGlldGYub3JnPiIgPG9wc2VjQGlldGYub3JnPG1haWx0bzpv cHNlY0BpZXRmLm9yZz4+LCAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiIg PHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+LCBGcmVkIEJha2VyIDxmcmVk QGNpc2NvLmNvbTxtYWlsdG86ZnJlZEBjaXNjby5jb20+PiwgImZnb250QHNpNm5ldHdvcmtzLmNv bTxtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tPiIgPGZnb250QHNpNm5ldHdvcmtzLmNvbTxt YWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tPj4sICJIb3dhcmQsIExlZSIgPGxlZS5ob3dhcmRA dHdjYWJsZS5jb208bWFpbHRvOmxlZS5ob3dhcmRAdHdjYWJsZS5jb20+PiwgImRyYWZ0LWlldGYt b3BzZWMtdjZAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc+IiA8 ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy12NkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBBdzogQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1pZXRm LW9wc2VjLXY2LTA4DQoNCkhpIEVyaWMsDQoNCnRoZSBkcmFmdCBpcyB2ZXJ5IHdlbGwgd3JpdHRl biBhbmQgY29udGFpbnMgdXNlZnVsIGd1aWRhbmNlL3JlY29tbWVuZGF0aW9ucy4gU2VjdGlvbnMg Mi40IGFuZCAyLjUgZG8gbm90IGNvbnRhaW4gbXVjaCBJUHY2LXNwZWNpZmljIGluZm9ybWF0aW9u IGFuZCBzZWN0aW9ucyAyLjcuMi4qIGRvIG5vdCBnaXZlIG11Y2ggZ3VpZGFuY2UuIEhvd2V2ZXIs IHRoZXNlIHRocmVlIHNlY3Rpb25zIHRvZ2V0aGVyIGFtb3VudCB0byB+MTEgcGFnZXMgKDEvMyBv ZiB0aGUgZG9jdW1lbnQpLiBJZiB5b3UgY291bGQgc2hvcnRlbiB0aGVzZSBzZWN0aW9ucywgdGhl IGRvY3VtZW50IHdvdWxkIGJlY29tZSBtb3JlIG1hbmFnZWFibGUuDQoNCkVWWT4+IGh1bSBnb29k IGlkZWE6IHdlIHRoZSBhdXRob3JzIGFsc28gZmVlbCB0aGF0IHRoZSBvdmVyYWxsIHRleHQgY291 bGQgYmUgaW1wcm92ZWQgaW4gdGhlIGZvcm0gKGtlZXBpbmcgdGhlIGNvbnRlbnQpLCBhbGFzLCB3 ZSBhbHNvIGxhY2sgdGltZSB0byByZWRvIG11Y2ggb2YgaXQuLi4gKHNlZSBteSByZXBseSA0IHdl ZWtzIGFmdGVyIHlvdXIgcmV2aWV3ISkNCg0KU29tZSBtaW5vciBjb21tZW50cyBhbmQgbml0czoN CjIuMS4yDQoiLi4uIFRoZSBsYXR0ZXIgd291bGQgYmUgcHJvYmxlbWF0aWMuIg0KSSBzdXNwZWN0 IGJ5ICJsYXR0ZXIiIHlvdSBtZWFuIE5QVHY2LiBCZXR0ZXIgbWFrZSB0aGF0IGV4cGxpY2l0Lg0K DQpFVlk+PiBhY3R1YWxseSwgd2UgbWVhbnQgdGhhdCBJUHY2IE5BUFQgaXMgcHJvYmxlbWF0aWMg cmVnYXJkaW5nIGxvZ2dpbmcuLi4gVGhhbmtzDQoNCg0KDQoiQSB0eXBpY2FsIGFyZ3VtZW50IGlz IHRoYXQgdGhlcmUgYXJlIHRvbyBtYW55IG1pc3Rha2VzIG1hZGUgd2l0aCBmaWx0ZXJzIGFuZA0K VUxBcyBtYWtlIHRoaW5ncyBlYXNpZXIgdG8gaGlkZSBtYWNoaW5lcy4iDQpXaHkgInRvIGhpZGUg bWFjaGllbmVzIj8gSSB3b3VsZCBzdWdnZXN0ICJ0byBzZXQgZmlsdGVycyIuDQoNCjIuMS40DQoi Li4uIHByaXZhY3kgZXh0ZW5zaW9uIGFkZHJlc3NlcyBzaG91bGQgYmUgdXNlZCINClB1bmN0dWF0 aW9uIG1hcmsgaXMgbWlzc2luZy4NCg0KMi4yDQpzdGlsbCBUQkQNCg0KRVZZPj4gYXJnaCBpbmRl ZWQsIGNhbm5vdCBmaXggaXQgaW4gLTA5LCBzbywgYSAtMTAgaXMgdG8gYmUgZXhwZWN0ZWQNCg0K Mi4zLjINCiIuLi4gZm9yIHByb3RlY3RpbmcgaG9zdHMgY29ubmVjdGVkIGFnYWluc3QuLi4iDQoi Q29ubmVjdGVkIGhvc3RzIiBtYXliZSE/DQoNCjIuMy40DQoiUkZDNjk4MCBbUkZDNjk4MF0gYWlt cyB0byB1cGRhdGUgUkZDNDg2MSBbUkZDNDg2MV0iDQoiW1JGQzY5ODBdIHVwZGF0ZXMgW1JGQzQ4 NjFdIg0KDQpFVlk+Pj4gdGltZSBmbGllcy4uLiBUaGUgb3JpZ2luYWwgc2VudGVuY2Ugd2FzIHdy aXR0ZW4gd2hlbiBSRkMgNjk4MCB3YXMgc3RpbGwgYSBkcmFmdC4uLg0KDQoNCjIuNy4yDQoiZW1i ZWIiIC0+IGVtYmVkDQoNCjIuNy4yLjQNCiIuLi4gb3BlcmF0aW9uYWwgcHJvYmxlbXMiDQpQdW5j dHVhdGlvbiBtYXJrIGlzIG1pc3NpbmcuDQoNCkVWWT4+IFNpZ2guLi4gV29ya2luZyBpbiBYTUwg ZG9lcyBub3QgaGVscCA6LSggVGhhbmtzDQoNCg0KDQoyLjcuMi44DQpUaGUgc2Vjb25kICJNQVAt RSIgc2hvdWxkIGJlICJNQVAtVCIuDQoNCjIuOA0KImRldmljZSB0byBhdXRoZW50aWNhdGVkIiAt PiAiZGV2aWNlIGF1dGhlbnRpY2F0ZWQiDQoNCkVWWT4+ID8/PyBXZSB3YW50ZWQgdG8gc2F5IHRo YXQgb25seSBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3Jpc2VkIHVzZXIgY2FuIG1hbmFnZSB0aGUg ZGV2aWNlcyAoY2hhbmdlZCB0aGUgdGV4dCB0byAiYXV0aG9yaXNlZCB1c2VycyIgYXMgYXV0aG9y aXNhdGlvbiByZXF1aXJlcyBhdXRoZW50aWNhdGlvbikNCg0KDQoNCjMuMQ0KImJvZ29uIGFuZCBy ZXNlcnZlZCBzcGFjZSINClNvbWUgbGlua3MgbWlnaHQgYmUgaGVscGZ1bCAoZS5nLiB0byBJQU5B KS4NCg0KNQ0KIltSRkM3MDg0XSAod2hpY2ggb2Jzb2xldGVzIFtSRkM2MjA0XSINCk1pc3Npbmcg IikiDQoNCiJbUkZDNzA4NF0gc3RhdGVzIHRoYXQgYSBjbGVhciBjaG9pY2UgbXVzdCBiZSBnaXZl biB0byB0aGUgdXNlciB0byBzZWxlY3Qgb25lDQpvZiB0aG9zZSB0d28gcG9saWNpZXMuIg0KRG9l cyBpdD8gSSBkaWQgbm90IGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcgcGFzc2FnZS4NCg0KRVZZPj4g Z29vZCBjYXRjaCwgaXQgaXMgUkVDLTQ5IG9mIFJGQyA2MDkyDQoNCg0KVGhyb3VnaG91dCB0aGUg ZG9jdW1lbnQgdGhlcmUgYXJlIHNvbWUgIklQVjYiLCAiRE9TIiBhbmQgIiAiLCB3aGljaCBzaG91 bGQgYmUNCnJlcGxhY2VkIHdpdGggIklQdjYiLCAiRG9TIiBhbmQgIiAiLg0KDQpJIGhvcGUgdGhl c2UgY29tbWVudHMgYXJlIGhlbHBmdWwuDQoNCkNoZWVycywNCk1hcmt1cw0KDQoNCg0KLS0tLSBF aW4gTWksIDE1IEp1biAyMDE2IDEyOjUwOjI5ICswMjAwIEVyaWMgVnluY2tlIChldnluY2tlKTxl dnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20+PiBoYXQgZ2VzY2hyaWVi ZW4gLS0tLQ0KVGhlIGF1dGhvcnMgKGFuZCBPUFNFQyBXRyBjaGFpcnMpIHdvdWxkIHJlYWxseSBh cHByZWNpYXRlIGlmIGEgcmV2aWV3IG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9wc2VjLXY2LTA4IGlzIGRvbmUgaW4gdGhlIGNvbWluZyBkYXlzL3dlZWtzIChpbiB0 aW1lIHRvIHN1Ym1pdCBhIC0wOSBpbiBjYXNlIGl0IG5lZWRzIHRvIGJlIGFtZW5kZWQpLg0KDQpU aGlzIEktRCBpcyBhYm91dCB0aGUgb3BlcmF0aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdo ZW4gb3BlcmF0aW5nIGFuIElQdjYgbmV0d29yayAoYm90aCBhcyBTZXJ2aWNlIFByb3ZpZGVyIGFu ZCBlbnRlcnByaXNlL3N1YnNjcmliZXIpLg0KDQpUaGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3Ig eW91ciByZXZpZXcgYW5kIGJlIHN1cmUgdG8gaW5jbHVkZSBvcHNlY0BpZXRmLm9yZzxtYWlsdG86 b3BzZWNAaWV0Zi5vcmc+IGluIHlvdXIgcmVwbHkuDQoNCi0gdGhlIGF1dGhvcnMgKE1lcmlrZSwg S0sgYW5kIEVyaWMpDQotIHRoZSBjaGFpcm1lbiAoR3VudGVyIGFuZCBFcmljKQ0KDQpQUzogTWFy a3VzLCBGcmVkLCBGZXJuYW5kbyBhbmQgTGVlLCBhcyB5b3Uga2luZGx5IHZvbHVudGVlcmVkIHRv IHJldmlldyBpdCBkdXJpbmcgSUVURi05NSwgSSBhbHNvIHB1dCB5b3VyIG5hbWVzIDstKQ0KDQoN Cg0KDQoNCg== --_000_D3A3CD7A7721Aevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1184F9559E56B64DA9DDDA85889A8BFD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5NYXJrdXM8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2 aWV3LCBJIGtub3cgaXQgdGFrZXMgdGltZSB0byBkby48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkkgaGF2ZSBhY2NlcHRlZCBtb3N0IG9mIHRoZW0gZXhjZXB0IHRob3NlIG1hcmtlZCB3 aXRoIEVWWSZndDsmZ3Q7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgYWdh aW4gYW5kIHNlZSB5b3UgaW4gQmVybGluLCB5b3VyIDo6MSA7LSk8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pi3DqXJpYzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+TWFya3VzIGRlQnJ1ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5rZWRp bkB4bi0tZGVicm4tbnZhLmRlIj5saW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAx NSBKdW5lIDIwMTYgYXQgMDc6MDQ8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ VG86IDwvc3Bhbj5FcmljIFZ5bmNrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28u Y29tIj5ldnluY2tlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3Jn Ij5vcHNlY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRm Lm9yZyI+b3BzZWNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OywgRnJlZA0KIEJha2VyICZsdDs8 YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNjby5jb20iPmZyZWRAY2lzY28uY29tPC9hPiZndDssICZx dW90OzxhIGhyZWY9Im1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20iPmZnb250QHNpNm5ldHdv cmtzLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5j b20iPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCAmcXVvdDtIb3dhcmQsIExlZSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlZS5ob3dhcmRAdHdjYWJsZS5jb20iPmxlZS5ob3dhcmRA dHdjYWJsZS5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1v cHNlYy12NkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnIj5kcmFmdC1p ZXRmLW9wc2VjLXY2QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPkF3OiBBc2tpbmcgZm9yIGEgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtb3BzZWMtdjYtMDg8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRF Ui1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5I aQ0KIEVyaWMsJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+DQo8YnIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPnRoZQ0KIGRyYWZ0IGlzIHZlcnkgd2VsbCB3cml0dGVuIGFuZCBjb250YWlucyB1c2Vm dWwgZ3VpZGFuY2UvPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij5yZWNvbW1lbmRhdGlvbnMuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LWZhbWlseTog VmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5TZWN0aW9ucw0KIDIuNCBhbmQg Mi41IGRvIG5vdCBjb250YWluIG11Y2ggSVB2Ni1zcGVjaWZpYyZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1m YW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+aW5mb3JtYXRpb24N CiBhbmQgc2VjdGlvbnMgMi43LjIuKiBkbyBub3QgZ2l2ZSBtdWNoIGd1aWRhbmNlLiBIb3dldmVy LCB0aGVzZSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+dGhyZWUNCiBzZWN0aW9ucyB0b2dldGhlciBhbW91bnQgdG8gfjExIHBh Z2VzICgxLzMgb2YgdGhlIGRvY3VtZW50KS4gSWYgeW91Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LWZhbWls eTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5jb3VsZA0KIHNob3J0ZW4g dGhlc2Ugc2VjdGlvbnMsIHRoZSBkb2N1bWVudCB3b3VsZCBiZWNvbWUgbW9yZSBtYW5hZ2VhYmxl LiZuYnNwOzwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5FVlkmZ3Q7Jmd0OyBodW0gZ29vZCBpZGVhOiB3ZSB0aGUgYXV0aG9ycyBhbHNvIGZlZWwg dGhhdCB0aGUgb3ZlcmFsbCB0ZXh0IGNvdWxkIGJlIGltcHJvdmVkIGluIHRoZSBmb3JtIChrZWVw aW5nIHRoZSBjb250ZW50KSwgYWxhcywgd2UgYWxzbyBsYWNrIHRpbWUgdG8gcmVkbyBtdWNoIG9m IGl0Li4uIChzZWUgbXkgcmVwbHkgNCB3ZWVrcyBhZnRlciB5b3VyIHJldmlldyEpPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1 IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IGZsb2F0OiBub25lOyI+PC9zcGFuPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5Tb21lIG1pbm9yIGNvbW1lbnRzIGFuZCBuaXRzOiZuYnNw Ozwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPjIuMS4yJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+JnF1 b3Q7Li4uIFRoZSBsYXR0ZXIgd291bGQgYmUgcHJvYmxlbWF0aWMuJnF1b3Q7Jm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+SSBzdXNwZWN0IGJ5ICZxdW90O2xhdHRlciZxdW90OyB5b3UgbWVhbiBO UFR2Ni4gQmV0dGVyIG1ha2UgdGhhdCBleHBsaWNpdC4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5FVlkmZ3Q7Jmd0OyBh Y3R1YWxseSwgd2UgbWVhbnQgdGhhdCBJUHY2IE5BUFQgaXMgcHJvYmxlbWF0aWMgcmVnYXJkaW5n IGxvZ2dpbmcuLi4gVGhhbmtzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJV VElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFE RElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIHN0eWxl PSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyI+JnF1b3Q7QSB0eXBpY2FsIGFyZ3VtZW50IGlzIHRoYXQgdGhlcmUgYXJlIHRv byBtYW55IG1pc3Rha2VzIG1hZGUgd2l0aCBmaWx0ZXJzIGFuZCZuYnNwOzwvc3Bhbj48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPlVMQXMgbWFrZSB0aGluZ3MgZWFzaWVyIHRvIGhpZGUgbWFjaGluZXMuJnF1b3Q7Jm5i c3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+V2h5ICZxdW90O3RvIGhpZGUgbWFjaGllbmVzJnF1b3Q7 PyBJIHdvdWxkIHN1Z2dlc3QgJnF1b3Q7dG8gc2V0IGZpbHRlcnMmcXVvdDsuJm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPjIuMS40Jm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+JnF1 b3Q7Li4uIHByaXZhY3kgZXh0ZW5zaW9uIGFkZHJlc3NlcyBzaG91bGQgYmUgdXNlZCZxdW90OyZu YnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlB1bmN0dWF0aW9uIG1hcmsgaXMgbWlzc2luZy4mbmJz cDs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEs IGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+Mi4yJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+c3RpbGwgVEJEJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEs IGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkVWWSZndDsmZ3Q7IGFyZ2ggaW5kZWVkLCBj YW5ub3QgZml4IGl0IGluIC0wOSwgc28sIGEgLTEwIGlzIHRvIGJlIGV4cGVjdGVkPC9kaXY+DQo8 c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1 IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiPjIuMy4yJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+JnF1b3Q7Li4u IGZvciBwcm90ZWN0aW5nIGhvc3RzIGNvbm5lY3RlZCBhZ2FpbnN0Li4uJnF1b3Q7Jm5ic3A7PC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI1NSwgMjU1LCAyNTUpOyI+JnF1b3Q7Q29ubmVjdGVkIGhvc3RzJnF1b3Q7IG1heWJlIT8mbmJz cDs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEs IGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+Mi4zLjQmbmJzcDs8L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1 NSk7Ij4mcXVvdDtSRkM2OTgwIFtSRkM2OTgwXSBhaW1zIHRvIHVwZGF0ZSBSRkM0ODYxIFtSRkM0 ODYxXSZxdW90OyZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBh cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBW ZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPiZxdW90O1tSRkM2OTgwXSB1cGRh dGVzIFtSRkM0ODYxXSZxdW90OyZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBW ZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5FVlkmZ3Q7Jmd0OyZndDsgdGlt ZSBmbGllcy4uLiBUaGUgb3JpZ2luYWwgc2VudGVuY2Ugd2FzIHdyaXR0ZW4gd2hlbiBSRkMgNjk4 MCB3YXMgc3RpbGwgYSBkcmFmdC4uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+Mi43LjImbmJzcDs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFu YSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4mcXVvdDtlbWJlYiZxdW90 OyAtJmd0OyBlbWJlZCZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5h LCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog VmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4yLjcuMi40Jm5i c3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+JnF1b3Q7Li4uIG9wZXJhdGlvbmFsIHByb2JsZW1zJnF1 b3Q7Jm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEs IGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+UHVuY3R1YXRpb24gbWFyayBpcyBtaXNzaW5n LiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkVWWSZndDsmZ3Q7IFNpZ2guLi4gV29ya2luZyBpbiBYTUwgZG9lcyBub3Qg aGVscCA6LSggVGhhbmtzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIHN0eWxlPSJm b250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+Mi43LjIuOCZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJk YW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEy cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlRoZSBzZWNvbmQgJnF1 b3Q7TUFQLUUmcXVvdDsgc2hvdWxkIGJlICZxdW90O01BUC1UJnF1b3Q7LiZuYnNwOzwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1 KTsiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7Ij4yLjgmbmJzcDs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4mcXVvdDtk ZXZpY2UgdG8gYXV0aGVudGljYXRlZCZxdW90OyAtJmd0OyAmcXVvdDtkZXZpY2UgYXV0aGVudGlj YXRlZCZxdW90OyZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkVWWSZndDsmZ3Q7ID8/PyBXZSB3YW50ZWQgdG8gc2F5IHRo YXQgb25seSBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3Jpc2VkIHVzZXIgY2FuIG1hbmFnZSB0aGUg ZGV2aWNlcyAoY2hhbmdlZCB0aGUgdGV4dCB0byAmcXVvdDthdXRob3Jpc2VkIHVzZXJzJnF1b3Q7 IGFzIGF1dGhvcmlzYXRpb24gcmVxdWlyZXMgYXV0aGVudGljYXRpb24pPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3Rl IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxF RlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZl cmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+My4xJm5ic3A7PC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+JnF1b3Q7Ym9nb24gYW5kIHJlc2VydmVkIHNwYWNlJnF1b3Q7Jm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+U29tZSBsaW5rcyBtaWdodCBiZSBoZWxwZnVsIChlLmcuIHRvIElBTkEp LiZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJp YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVy ZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij41Jm5ic3A7PC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+JnF1b3Q7W1JGQzcwODRdICh3aGljaCBvYnNvbGV0ZXMgW1JGQzYyMDRdJnF1b3Q7Jm5i c3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+TWlzc2luZyAmcXVvdDspJnF1b3Q7Jm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPiZxdW90O1tSRkM3MDg0XSBzdGF0ZXMgdGhhdCBhIGNsZWFy IGNob2ljZSBtdXN0IGJlIGdpdmVuIHRvIHRoZSB1c2VyIHRvIHNlbGVjdCBvbmUmbmJzcDs8L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUs IDI1NSk7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZl dGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7Ij5vZiB0aG9zZSB0d28gcG9saWNpZXMuJnF1b3Q7Jm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+RG9lcyBpdD8gSSBkaWQgbm90IGZpbmQgdGhlIGNvcnJlc3BvbmRpbmcg cGFzc2FnZS4mbmJzcDs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJp YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RVZZJmd0OyZndDsgZ29vZCBjYXRjaCwgaXQgaXMg UkVDLTQ5IG9mIFJGQyA2MDkyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJV VElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFE RElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGJyIHN0eWxl PSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1 NSk7Ij5UaHJvdWdob3V0IHRoZSBkb2N1bWVudCB0aGVyZSBhcmUgc29tZSAmcXVvdDtJUFY2JnF1 b3Q7LCAmcXVvdDtET1MmcXVvdDsgYW5kICZxdW90OyAmcXVvdDssIHdoaWNoIHNob3VsZCBiZSZu YnNwOzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPnJlcGxhY2VkIHdpdGggJnF1b3Q7SVB2NiZxdW90Oywg JnF1b3Q7RG9TJnF1b3Q7IGFuZCAmcXVvdDsgJnF1b3Q7LiZuYnNwOzwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPg0KPGJy IHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij5JIGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIGhlbHBmdWwuJm5ic3A7PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmEsIGFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBhcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPkNoZWVycywmbmJzcDs8L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogVmVyZGFuYSwgYXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5N YXJrdXMmbmJzcDs8L3NwYW4+DQo8ZGl2Pjxmb250IGZhY2U9IlZlcmRhbmEsYXJpYWwsSGVsdmV0 aWNhLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJWZXJkYW5hLGFyaWFsLEhlbHZldGlj YSxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFu PjwvZm9udD4NCjxkaXYgY2xhc3M9InptYWlsX2V4dHJhIj4NCjxkaXYgaWQ9IjEiPjxicj4NCi0t LS0gRWluIE1pLCAxNSBKdW4gMjAxNiAxMjo1MDoyOSAmIzQzOzAyMDA8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+RXJpYyBWeW5ja2UgKGV2eW5ja2Up Jmx0OzxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSI+ZXZ5bmNrZUBjaXNjby5jb208 L2E+Jmd0OzwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+aGF0IGdlc2NocmllYmVuIC0tLS08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxl ZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xv cjogcmdiKDAsIDAsIDI1NSk7IHBhZGRpbmctbGVmdDogNnB4OyBtYXJnaW46IDBweCAwcHggMHB4 IDVweDsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGUgYXV0aG9ycyAo YW5kIE9QU0VDIFdHIGNoYWlycykgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgaWYgYSByZXZpZXcg b2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v cHNlYy12Ni0wOCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9wc2VjLXY2LTA4PC9hPiZuYnNwO2lzIGRvbmUgaW4gdGhlIGNvbWluZyBkYXlz L3dlZWtzIChpbiB0aW1lIHRvIHN1Ym1pdA0KIGEgLTA5IGluIGNhc2UgaXQgbmVlZHMgdG8gYmUg YW1lbmRlZCkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIEktRCBpcyBhYm91 dCB0aGUgb3BlcmF0aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gb3BlcmF0aW5nIGFu IElQdjYgbmV0d29yayAoYm90aCBhcyBTZXJ2aWNlIFByb3ZpZGVyIGFuZCBlbnRlcnByaXNlL3N1 YnNjcmliZXIpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGEgbG90IGlu IGFkdmFuY2UgZm9yIHlvdXIgcmV2aWV3IGFuZCBiZSBzdXJlIHRvIGluY2x1ZGU8c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9w c2VjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbWFpbGlkPSJvcHNlYyU0MGlldGYub3JnIiBz dWJqPSIiPm9wc2VjQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5pbg0KIHlvdXIgcmVwbHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4tIHRoZSBhdXRob3JzIChNZXJpa2UsIEtLIGFuZCBFcmljKTwvZGl2Pg0KPGRpdj4t IHRoZSBjaGFpcm1lbiAoR3VudGVyIGFuZCBFcmljKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+UFM6IE1hcmt1cywgRnJlZCwgRmVybmFuZG8gYW5kIExlZSwgYXMgeW91IGtpbmRseSB2 b2x1bnRlZXJlZCB0byByZXZpZXcgaXQgZHVyaW5nIElFVEYtOTUsIEkgYWxzbyBwdXQgeW91ciBu YW1lcyA7LSk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvYmxv Y2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3A3CD7A7721Aevynckeciscocom_-- From nobody Thu Jul 7 08:41:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6512D0A4; Thu, 7 Jul 2016 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 dW5iYVQE0uOh; Thu, 7 Jul 2016 08:41:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959AB12D08C; Thu, 7 Jul 2016 08:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1467906100; x=1469115700; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dUsEsosyrqI/s3bchjOiG5COF2Ywi1Fu9NbLT/5CAds=; b=h5+EKqjKT5vwUSev78FwNNdkr9v7Mx6Enm6NFoyD5Fb1czLedAnyPO59 5gk0aI0Ab2TKrkYwJRGNERSEM/4TfcKmu2u2eETQjXlYsvl7f/jLHMtT4 FMKq6nxLpRfVNtUliqgMbavVY4oEV7JK7QkCkEDNnswXddqyF6ZaIUJ5X Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMBQDhd35X/49dJa1cgz6BUga5CYF7h?= =?us-ascii?q?hgCHIEOOhIBAQEBAQEBZSeETQEFIxFFEAIBCA4MAiYCAgIwFRACBA4FiDCtR48?= =?us-ascii?q?yAQEBAQEBAQEBAQEBAQEBAQEBH4EBhSaETYRAF4JqgloBBJkTAY5GjyqQCQElD?= =?us-ascii?q?CODcW6HfX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,324,1464652800"; d="scan'208";a="294942663" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2016 15:41:27 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u67FfRDK020489 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jul 2016 15:41:27 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 7 Jul 2016 11:41:26 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 7 Jul 2016 11:41:26 -0400 From: "Eric Vyncke (evyncke)" To: Erik Kline Thread-Topic: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/rMhmAgCHqgoA= Date: Thu, 7 Jul 2016 15:41:26 +0000 Message-ID: References: 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.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.159.132] Content-Type: text/plain; charset="utf-8" Content-ID: <4D195856320BA4449589E1A3D66A69BB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "v6ops@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:41:42 -0000 RXJpaw0KDQpUaGFua3MgZm9yIHlvdSByZXZpZXcgKGFuZCBCVFcsIEkgYW0gb3V0IG9mIHN0ZWFt L3RpbWUgdG8gcHJvY2VzcyBtb3JlDQpjb21tZW50cyBvbiB0aGlzIHRocmVhZCBiZWZvcmUgcG9z dGluZyB0aGUgLTA5ID0+IEkgd2lsbCBwcm9jZXNzIF9BTExfDQpjb21tZW50cyBsYXRlcikNCg0K LcOpcmljDQoNCg0KT24gMTUvMDYvMTYgMjE6NDUsICJFcmlrIEtsaW5lIiA8ZWtAZ29vZ2xlLmNv bT4gd3JvdGU6DQoNCj5TZWN0aW9uIDIuMS4yIGlzIGZhciB0b28gcGVybWlzc2l2ZSBmb3IgbXkg dGFzdGVzLiAgV2UgbmVlZCB0byBiZSBhYmxlDQo+dG8gc2F5IHRoYXQgVUxBK0lQdjYgTkFUIGlz IE5PVCBSRUNPTU1FTkRFRCBieSB0aGUgSUVURi4NCg0KSSBjaGFuZ2VkIHRoZSBlbmQgb2YgdGhl IHNlY3Rpb24gMi4xLjIgdG8gcmVmbGVjdCB0aGlzLiBBbGJlaXQsIEkgYW0NCnVuc3VyZSB3aGV0 aGVyIHRoZXJlIGlzIGEgY2xlYXIgc3RhdGVtZW50IGJ5IHRoZSBJRVRGIGFib3V0IG5vdCB1c2lu ZyBVTEENCisgTlBUdjYgKGFuZCBJIHdvdWxkIExPVkUgdG8gc2VlIHN1Y2ggYSBzdGF0ZW1lbnQp DQoNCj4NCj5TZWN0aW9uIDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhlIFNBVkkgc3R1ZmYgYSBi aXQgbW9yZSBhcyB3ZWxsLiAgV2UNCj5zaG91bGQsIGluIG15IG9waW5pb24sIG1ha2UgaXQgcGFp bmZ1bGx5IGNsZWFyIHRoYXQgREhDUCAob2YgYW55DQo+cHJvdG9jb2wpIGluIHRoZSBhYnNlbmNl IG9mIGxpbmstbGF5ZXIgc2VjdXJpdHkvYXVkaXRhYmlsaXR5IGZlYXR1cmVzDQo+ZG9lcyBub3Qg cHJvdmlkZSBhbnkgc2F0aXNmYWN0b3J5IHdheSAidG8gZW5zdXJlIGF1ZGliaWxpdHkgYW5kDQo+ dHJhY2VhYmlsaXR5IiBbU2VjdGlvbiAyLjEuNl0uDQoNCkRvbmUNCg0KDQo+DQoNCg== From nobody Thu Jul 7 15:08:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD48812D107 for ; Thu, 7 Jul 2016 15:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 ONiiwDljHHnY for ; Thu, 7 Jul 2016 15:08:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AFD2412D529 for ; Thu, 7 Jul 2016 15:08:55 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u67M8JXO011670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jul 2016 15:08:20 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> From: Joe Touch Message-ID: <577ED2D0.1030706@isi.edu> Date: Thu, 7 Jul 2016 15:08:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:08:58 -0000 On 7/7/2016 5:19 AM, Alexandre Petrescu wrote: > > > Le 05/07/2016 à 19:03, Joe Touch a écrit : >> >> >> On 7/4/2016 11:16 AM, Alexandre Petrescu wrote: >>> >>> >>> Le 23/06/2016 à 22:51, Joe Touch a écrit : >>>> ... >>>> IMO, it'd be better to say you're using "all nodes" and cite RFC2464 >>>> rather than opaquely using the MAC that results. >>> >>> Well "all nodes" direction sounds better compared to previous "all >>> cars". But RFC2464 does not define such MAC address, neither such IP >>> address, so one wouldnt cite RFC2464 meaningfully. >>> >>> The Group ID "all nodes" for an IP address is defined in RFC4291 and >>> the >>> allocations are managed at >>> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml >>> >>> >>> >>> But "all nodes" means actually any IP-capable node, not necessarily >>> those that run 802.11-OCB (aka 802.11p) - i.e. WiFi, LTE and others. >> >> That's because IP multicast addresses are assigned based on protocols >> that run OVER IP, not those that operate underneath. > > Yes, IP multicast addresses are so assigned. > > But some IP multicast addresses correspond to some MAC group > addresses, on a 1-to-1 basis: for the 'all-nodes' link-scoped IP > multicast address there is a 'all-nodes' MAC group address. > > The other way around too: for a 'all-nodes' MAC group address there is > an IP multicast address called 'all-nodes' with link scope. That's not really "the other way around"; that happened because the corresponding IP multicast "all nodes" address within link scope was defined as such. > > And, over 802.11p too a MAC multicast address corresponds to an IP > multicast address. AFAICT, IP multicast addresses are explicitly assigned. That's why the table here includes corresponding IPv6 addresses for only a subset of Ethernet multiacast addresses: https://en.wikipedia.org/wiki/Multicast_address#IPv6 > > >>> I could not find a MAC address "all nodes" defined at IEEE. >> >> That's usually what all 1's is used for. At the link layer, there isn't >> much difference between broadcast and multicast "all nodes". > > No no, there _is_ a difference. IPv6 does not work with all 1s MAC > broadcast address, it only works with 33-33-0-0-0-1 MAC multicast > address. IPv4 only works with all 1s MAC broadcast address. I was speaking of "all 1's" as representing "link broadcast", i.e., as behaving like all 1's in IPv4. Yes, that's not the address used for IPv6. > >>> At IEEE I found a 48bit "All Multicast Capable End Systems Address" >>> 01-80-C2-00-00-1B; it is listed there: >>> https://standards.ieee.org/develop/regauth/grpmac/public.html >> >> That's listed as LLDP too - and that makes sense if you want to use a >> link address over which to find 802.11p-capable nodes. > > A-ha, it makes sense. So the question is: which group MAC address > should IPv6-over-80211p use: > > - ff:ff:ff:ff:ff:ff - obviously the answer is no. But the correct corresponding "all nodes" might be appropriate: ff02::1 > - 33:33:00:00:00:01 - like IPv6-over-WiFi does All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, but I don't see anywhere where any of these addresses are assigned (or assignable) to a single protocol. > - 01-80-C2-00-00-1B - like LLDP does > - request a new one? > >>> Remark (1) I have never seen this 48bit IEEE address in vehicular >>> network trials and (2) it is not a "33-33-XX-XX-XX-XX" address, which >>> _is_ present in some IPv6 vehicular prototypes. >>> >>> In this context, I believe it can make sense to think of requesting >>> IANA >>> (rather than IEEE) for an allocation of a 112bit Group ID named "All >>> 802.11-OCB interfaces"; >> >> There are no other IPv6 multicast addresses that group nodes by link >> type. This sort of request doesn't make sense to me at all; it's a bit >> backwards. > > I agree there are no other IPv6 multicast addresses that group the > nodes by link type (you dont have an address called "all Ethernet > nodes" for example). However, 802.11p is not really a particular link > type - it is WiFi. To IP, WiFi is a link type. Granted, it may have a variety of physical layers underneath and include various subsets of extensions, but WiFi is not a network-layer protocol or higher-layer (e.g., app-layer) service, e.g., as routing or DHCP are. > Moreover, we are not concerned here with a request to IEEE. An > IPv6-over-foo I-D describes _mappings_, i.e. what number gets mapped > from IETF to IEEE identifier. It's exactly because you'd need this assigned by IETF that it makes no sense. > > As such, it is reasonable to request at IETF a 112bit Group > Identifier, parts of which may get mapped to some bytes of a group > multicast address. In a general sense, yes, IANA would be the right party to assign a group ID here, but that assumes that a group ID should be allocated to a link type. There is no precedent for that. > > The overall goal is that people stop using the MAC broadcast address > on 802.11p (all 1s) and start using a single MAC group address (not > various). Although I understand your goal, I don't see why a separate *IP* multicast group is the right way to solve it. If you want to reach all nodes, you already can on IPv6 using ff02::1 If you want to reach all 802.11p nodes, you need to define an IP-visible service that selects for that property, and ask for a group ID *for that service*, IMO. > >> AFAICT, you either really want to use LLDP at the link layer or the >> existing SSDP IPv6 multicast address to identify your service. > > YEs, later, when we discuss application-level services that is a very > good direction. For example we need to identify a group of all taxis > in a cell to send them a call. > > But for now we need a group MAC address on 802.11p on which we can > send network-layer messages like Router Advertisements. If you want to send router advertisements, send them to ff02::2 (all routers). If you want to specify a subset of those routers, you really ought to do so the same way as everyone else - by the IP-layer *routing protocol* spoken (e.g., OSPF, RIP, etc.). Joe From nobody Fri Jul 8 01:36:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D601C126579 for ; Fri, 8 Jul 2016 01:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 t7VKBpm_ihow for ; Fri, 8 Jul 2016 01:36:45 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 F26B012B006 for ; Fri, 8 Jul 2016 01:36:43 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id i186so39591997iof.1 for ; Fri, 08 Jul 2016 01:36:43 -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; bh=r0Kcudw/kG3llxcH4TkxY5WZdKdUckrR0TSUn52scLQ=; b=kO6opAYuOhEztOR9MiLEnaLg3Ai01NHfzD75bLc6WmSesauXWTB/Q9n/GVNJ2y8fc9 wV0VgqYbCNA8jQ1pFCBuq+CFYsq3yDo+V7a3vsiGxsyfIE79VWj8WETg8Kd3Z3ae1qU0 Gm/yKrrW4RzwQUduJe98Ibr6EclKKNkkwZ8TfnRgUW4z5iHrFwG+BTP2ZYp+8NCQU1cf a//xzjO8Zja4yB83TF54hXOIbEOzYoGnvTvciIoZK866kwN0HCOkq7gvyOKjs93rawyA J3+q2s2qPIPe0dSkRRpB58xcdOrp5jD3S5n4FxxFWN14yrcaI8aD3QeBu5cybCthSsv0 jXlw== 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; bh=r0Kcudw/kG3llxcH4TkxY5WZdKdUckrR0TSUn52scLQ=; b=hHGWaUapel+OzT6FDA/IYALQTncrer5kMM85CIWXvOQxGz2znw/V4qU6GmB+n9RmtK AuM4OA4i6VtiTJfNnGrQ+0e2AyerBxo2UBZ6TWVwYRm6h66+oDNvUaqH6Vh40njUFe3B s96lA3h7VOCf+ZsdY6BDafkyCuC0nrQMma/kxuWQi8mwLVhim+ydXJdon88fDSEr9sez W1Twt15J95JpBWjvwdJtYeDyAKkZGDJSi+3UILa3DX+oJmNQ2L6gsqW8mt6D3B1/KRET 3AaaI9s2UwzP6z6Z6egLSYq3ekqPylxIFZEVXymxqCX20Ab9GGp4te3WoBr+y7qWegCD tIvQ== X-Gm-Message-State: ALyK8tKLKGD9YXzPIDqbRy54qhrW8lqjf3I8e6/24CFV7Pb7Kwo68sr9cL1ixdrZTaLqyyBwxOelVDQHflFHpDVZ X-Received: by 10.107.39.79 with SMTP id n76mr7231658ion.145.1467967002995; Fri, 08 Jul 2016 01:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.105 with HTTP; Fri, 8 Jul 2016 01:36:23 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Fri, 8 Jul 2016 17:36:23 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "v6ops@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:36:47 -0000 >>Section 2.1.2 is far too permissive for my tastes. We need to be able >>to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. > > I changed the end of the section 2.1.2 to reflect this. Albeit, I am > unsure whether there is a clear statement by the IETF about not using ULA > + NPTv6 (and I would LOVE to see such a statement) Then please go ahead and make that statement in your document. I, for one, will help defend it. :-) From nobody Fri Jul 8 01:51:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF42C12D1BD; Fri, 8 Jul 2016 01:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JITxtTKh1tGS; Fri, 8 Jul 2016 01:51:52 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 D0C3012D513; Fri, 8 Jul 2016 01:51:51 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id v6so50695572vkb.2; Fri, 08 Jul 2016 01:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NdREx7YlB6BhODDCDbOmliXaUXyZtPSHPxIiV9AxXrg=; b=WmWJIIoyjijXte6vTgP4BX7FODFtVrd89WDyBrvomekINkhXf1dP8EtUED124INoni MNDJEYjMgkT+N6zdjffyAnCHogeG3L8X1J77R/j5ciiud0VlU2HTTcrTi6B3v42f89Qr 53byZi9HWVHgXKgFts8l5DBDWODfny+EH5pF5psvTSC+PA1SZigBDn6QL4uAKkAaJEIz 2VgsVlxAeG9iHPeu7h0vOQQgVVlcGiSftQIhiSwrmbdhg9FJRWF6HWQQD1w+E2MPrCJ9 TzacyyH+0nqw/jeiNNnMqq3ZbwAW069V1ZnWpvo/dgyA28RXoBHsw5GgArjpYudSiwkx EMHg== 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; bh=NdREx7YlB6BhODDCDbOmliXaUXyZtPSHPxIiV9AxXrg=; b=GyVxCcPKCvMxpIYmh+qYuhAW+1VFsnpGAigPncmKrs57dhRZVQ6sWjQOJli+wpV53E 3tmZ9LMCqhW4dIR/4+UUTIIKPNL4PO+f+FmXo9UtXj8zn2bOnewwmo2EPNGKK/JA05rL HQkEqMHTmnXcV33UI7dSNICRR3WsF1fFoYpPExP5qIqpjLQRf6E0v9uNt+uEQZwYzGuY SidzpStxTa7Eb0LgzYIm5nnQWB5RTERdnW3WohcEFzpxlx38e9uhmxv520KBTkB+uvns Zw93dP8nGzkFKKZMogQSeewG9mCJvb0PhYEIZGwc0YO4sON22S9g9vsapoNsv35+a21T DhAw== X-Gm-Message-State: ALyK8tLrGJpHA5NLz0bjo5R7yDJUgkgXRmadujbhwBhcY60n0sjKLTGoEdAKQOM+oZXCsN/ZniI/deQMcyOJEA== X-Received: by 10.31.163.72 with SMTP id m69mr2182019vke.72.1467967910846; Fri, 08 Jul 2016 01:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Fri, 8 Jul 2016 01:51:21 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Fri, 8 Jul 2016 18:51:21 +1000 Message-ID: To: Erik Kline Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:51:54 -0000 On 8 July 2016 at 18:36, Erik Kline wrote: >>>Section 2.1.2 is far too permissive for my tastes. We need to be able >>>to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I changed the end of the section 2.1.2 to reflect this. Albeit, I am >> unsure whether there is a clear statement by the IETF about not using ULA >> + NPTv6 (and I would LOVE to see such a statement) > > Then please go ahead and make that statement in your document. > > I, for one, will help defend it. :-) > Depending on an experimental RFC for your security sounds like a really bad idea to me! > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 8 02:18:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AFF12D0F7 for ; Fri, 8 Jul 2016 02:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=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 oPpxzmmuU4-R for ; Fri, 8 Jul 2016 02:18:28 -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 3181C12D0B5 for ; Fri, 8 Jul 2016 02:18:25 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CB0D7626FC for ; Fri, 8 Jul 2016 11:18:23 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 75EAE6069F; Fri, 8 Jul 2016 11:18:23 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 63609B36B; Fri, 8 Jul 2016 11:18:23 +0200 (CEST) Date: Fri, 8 Jul 2016 11:18:23 +0200 From: Gert Doering To: Mark Smith Message-ID: <20160708091823.GT79185@Space.Net> References: 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.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:18:29 -0000 Hi, On Fri, Jul 08, 2016 at 06:51:21PM +1000, Mark Smith wrote: > Depending on an experimental RFC for your security sounds like a > really bad idea to me! But NATs are good! I've seen it on youtube, so it must be true! gert (And yes, it *is* Friday) -- 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 Fri Jul 8 02:35:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04C712B044; Fri, 8 Jul 2016 02:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 30HmYpcawSNr; Fri, 8 Jul 2016 02:35:00 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 94ADB127071; Fri, 8 Jul 2016 02:35:00 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id v6so51486131vkb.2; Fri, 08 Jul 2016 02:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N/Ohmy+71NGWRZtERmpSvJByQham7bdYghFIElf6D00=; b=ZZjF2zjw/sXgdKfW4wOYliooz+CzFeHpHLX3F9gVoEGqfxzPU1T20mOICwtXTvmmVE +gnqZ2YEoExmJIw3veD1rcIqiEM2HhuHZFTF6CBNDiu5yFq8g1DgQ2R9I/MWefDhb65u gv3ImKDLbt5/npsPy2aahJTtfUEMd4EOJgeFI82wm1ogqRpVMcCqFJC73U0rNQLL1d4c NDosXrQRm6Kau4K7ASf3cPUbVp7AXizky6/2geMDEeMnYDV8Ow0Prls3E7mesbtiyamO LfYqpdBIM6sF4yjFTyWeZkfJja1HvIHtyD5Q1otso1jSlsysz3j9itD/rszZPpU0IfQX 9j4A== 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; bh=N/Ohmy+71NGWRZtERmpSvJByQham7bdYghFIElf6D00=; b=KuioLKJl/YSy0ycFfB2NVbJb4D9epEahpZFfWtdU8FhsX0cQ8wydTLkI4ZbdOT3Z8Z tkTo2eCnbd1WhL3gninhPOI50fEYtZwhJHMfzleazwVw1Gv1YSFrzafKxM54qcISij5Q NynZ0qAbkx9eaL+5Y8Ar6MwL0oytYX+Nfqhi/7wjxzL4NmuFvvis2QO1TMhcWUamePVy Yy55RIP9TSrmwxNGAN+5wpOddCexaffXGnBYBfqZ2Yu/qBmLi5HXYNjL9RvAvAvDUsFP 5a+q//xMo6HkjRbaZEaMQGplBTJd/3w2yFwYThdLJDwVT5bP8MQREd4FVTJdxUjZDKAj vyGg== X-Gm-Message-State: ALyK8tKRDJXBywj1f/S10DsBf9N7UFwpg5rDFF649Q+skpULFCbUNJuVS9ibv98rmr2CpHBnYie6Ddv+7e0E9Q== X-Received: by 10.31.248.73 with SMTP id w70mr18994vkh.30.1467970499585; Fri, 08 Jul 2016 02:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Fri, 8 Jul 2016 02:34:30 -0700 (PDT) In-Reply-To: <20160708091823.GT79185@Space.Net> References: <20160708091823.GT79185@Space.Net> From: Mark Smith Date: Fri, 8 Jul 2016 19:34:30 +1000 Message-ID: To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:35:03 -0000 On 8 July 2016 at 19:18, Gert Doering wrote: > Hi, > > On Fri, Jul 08, 2016 at 06:51:21PM +1000, Mark Smith wrote: >> Depending on an experimental RFC for your security sounds like a >> really bad idea to me! > > But NATs are good! I've seen it on youtube, so it must be true! > That must be why ISPs are deploying carrier grade ones! Actually, I think people advocating ULA+NPT for security are probably assuming NPT is the IPv6 equivalent of IPv4 (stateful) NAPT. It isn't, it's just stateless prefix swapping at the NPT domain boundary. So no hiding of internal hosts' IIDs, internal hosts are going to be reachable with unsolicited packets from outside because it is stateless, and I think it would be common to deploy it with a 1:1 external to internal /64 prefix mapping, so no internal topology hiding either in that case either. ULA+NPT isn't going to be effective if your objective is to protect hosts from unsolicited incoming connections and to hide their unique parts of their IPv6 addresses. Regards, Mark. > gert > > (And yes, it *is* Friday) > -- > 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 Fri Jul 8 05:36:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C63D12D10B for ; Fri, 8 Jul 2016 05:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 jPrmyjSf6EbG for ; Fri, 8 Jul 2016 05:36:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6795312B062 for ; Fri, 8 Jul 2016 05:36:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68CaTRl025412; Fri, 8 Jul 2016 14:36:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 170F2209065; Fri, 8 Jul 2016 14:36:29 +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 EE49D209060; Fri, 8 Jul 2016 14:36:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68CaS3t020316; Fri, 8 Jul 2016 14:36:28 +0200 To: Mark Andrews , "Heatley, Nick" References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> <5fcbf830-fc25-7394-5c8a-55dc9189b462@gmail.com> <093d3a00-a2cc-c6d9-8939-56114eb4a461@gih.com> <6536E263028723489CCD5B6821D4B2131714501A@UK30S005EXS06.EEAD.EEINT.CO.UK> <20160603021720.15D9E4AA4453@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <4a5750c6-1dd3-9a78-d740-309ce71df45d@gmail.com> Date: Fri, 8 Jul 2016 14:36:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160603021720.15D9E4AA4453@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:36:36 -0000 Le 03/06/2016 04:17, Mark Andrews a crit : > > While reducing power consumtion is a good thing, we will be wasting > peoples time to compare IPv6 vs IPv4 power consumption. Don't we > have better things to do than to waste peoples time on the academic > exercise which will produce nothing useful. Measuring is useful only if it compares against something. We think comparing against IPv4 consumption has a meaning. We advance towards producing something supposedly useful about measuring energy consumption of IPv6 vs IPv4 apps on smartphones on WiFi and 4G. If it proves unuseful we will report that as well. Alex > > Mark > From nobody Fri Jul 8 05:46:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC5812D674 for ; Fri, 8 Jul 2016 05:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 B30Vt81o6a9p for ; Fri, 8 Jul 2016 05:46:05 -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 E05D212D62A for ; Fri, 8 Jul 2016 05:46:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68Ck0T4017091; Fri, 8 Jul 2016 14:46:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22182209070; Fri, 8 Jul 2016 14:46:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 14C3120905F; Fri, 8 Jul 2016 14:46:00 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68CjxKQ001180; Fri, 8 Jul 2016 14:45:59 +0200 To: "Fred Baker (fred)" References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> From: Alexandre Petrescu Message-ID: <5f1127a6-a01f-1395-a04c-0625c55d4176@gmail.com> Date: Fri, 8 Jul 2016 14:45:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in energy consumption X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:46:07 -0000 Fred, Managing power may involve Management Information Base (MIB) which may be expressed as a YANG model. We have just submitted an Internet Draft "YANG model for battery MIB" in the closed eman WG: https://tools.ietf.org/html/draft-petrescu-battery-mib-yang-00 In this model IPv6 does not appear explicitely, but there is a link: YANG modelled MIBs may be queried by SDN tools which in turn may run on IPv6. Our home-brewed SDN tool managing mobile platforms such as smartphones runs fully on IPv6: both data and control planes. We consider JSON but also YANG. Alex Le 01/06/2016 18:13, Fred Baker (fred) a crit : > I personally would find that interesting. As you note, we recently > posted an RFC about managing power by managing activity. Andrew > Yourtchenko has been interested in the chattiness of IPv6 > implementations in WiFi, the issue being that it is a shared medium > (not unlike an Ancient yellow Ethernet cable, and very unlike a > switched network), so every hiccup reverberates throughout the > network. I would expect that the issue affects mobile wireless in > interesting ways. How chatty are we, and what needs to be adjusted? > > Do you have something to share? > >> On Jun 1, 2016, at 5:40 AM, Alexandre Petrescu >> wrote: >> >> Hi v6ops, >> >> I wonder whether there may be interest in evaluating the energy >> consumption of an IPv6 application on smartphones, compared to its >> IPv4 counterpart. >> >> I suspect the difference may be negligible but I am not sure. >> >> It would be good to avoid a situation in which the end user prefers >> IPv4 on the smartphone because IPv6 empties the battery. >> >> Alex >> >> Le 11/02/2016 20:12, rfc-editor@rfc-editor.org a crit : >>> A new Request for Comments is now available in online RFC >>> libraries. >>> >>> BCP 202 RFC 7772 >>> >>> Title: Reducing Energy Consumption of Router Advertisements >>> Author: A. Yourtchenko, L. Colitti Status: Best Current >>> Practice Stream: IETF Date: February 2016 Mailbox: >>> ayourtch@cisco.com, lorenzo@google.com Pages: 6 Characters: >>> 12555 See Also: BCP 202 >>> >>> I-D Tag: >>> draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt >>> >>> URL: https://www.rfc-editor.org/info/rfc7772 >>> >>> DOI: http://dx.doi.org/10.17487/RFC7772 >>> >>> Frequent Router Advertisement messages can severely impact host >>> power consumption. This document recommends operational >>> practices to avoid such impact. >>> >>> 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/retrieve/bulk >>> >>> 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 >>> >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jul 8 06:52:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9188712D695 for ; Fri, 8 Jul 2016 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 UvY4Tjc-UlrM for ; Fri, 8 Jul 2016 06:52:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9963312D6A2 for ; Fri, 8 Jul 2016 06:52:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68DqGBe010592; Fri, 8 Jul 2016 15:52:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 67E2A209054; Fri, 8 Jul 2016 15:52:16 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58852208F58; Fri, 8 Jul 2016 15:52:16 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68DqGF3020503; Fri, 8 Jul 2016 15:52:16 +0200 To: Joe Touch , Owen DeLong References: <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> From: Alexandre Petrescu Message-ID: <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> Date: Fri, 8 Jul 2016 15:52:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <577ED2D0.1030706@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:52:37 -0000 Hi Joe, Le 08/07/2016 à 00:08, Joe Touch a écrit : > > > On 7/7/2016 5:19 AM, Alexandre Petrescu wrote: >> >> >> Le 05/07/2016 à 19:03, Joe Touch a écrit : >>> >>> >>> On 7/4/2016 11:16 AM, Alexandre Petrescu wrote: >>>> >>>> >>>> Le 23/06/2016 à 22:51, Joe Touch a écrit : >>>>> ... IMO, it'd be better to say you're using "all nodes" and >>>>> cite RFC2464 rather than opaquely using the MAC that >>>>> results. >>>> >>>> Well "all nodes" direction sounds better compared to previous >>>> "all cars". But RFC2464 does not define such MAC address, >>>> neither such IP address, so one wouldnt cite RFC2464 >>>> meaningfully. >>>> >>>> The Group ID "all nodes" for an IP address is defined in >>>> RFC4291 and the allocations are managed at >>>> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml >>>> >>>> >>>> >>>> >>>> >>>> But "all nodes" means actually any IP-capable node, not >>>> necessarily those that run 802.11-OCB (aka 802.11p) - i.e. >>>> WiFi, LTE and others. >>> >>> That's because IP multicast addresses are assigned based on >>> protocols that run OVER IP, not those that operate underneath. >> >> Yes, IP multicast addresses are so assigned. >> >> But some IP multicast addresses correspond to some MAC group >> addresses, on a 1-to-1 basis: for the 'all-nodes' link-scoped IP >> multicast address there is a 'all-nodes' MAC group address. >> >> The other way around too: for a 'all-nodes' MAC group address >> there is an IP multicast address called 'all-nodes' with link >> scope. > > That's not really "the other way around"; that happened because the > corresponding IP multicast "all nodes" address within link scope was > defined as such. I suppose it's not a coincidence that IEEE and IETF both call these addresses "all-nodes" but I have no trace of that. >> And, over 802.11p too a MAC multicast address corresponds to an IP >> multicast address. > > AFAICT, IP multicast addresses are explicitly assigned. That's why > the table here includes corresponding IPv6 addresses for only a > subset of Ethernet multiacast addresses: > https://en.wikipedia.org/wiki/Multicast_address#IPv6 Thank you for the wikipedia pointer but I am trying to keep away as much as possible. I am trying to identify the precise IEEE authoritative reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. Worse, if you look at the wikipedia page it says "802.11 wireless networks use the same 01:00:5E:xx:xx:xx and 33:33:xx:xx:xx:xx MAC addresses for multicasting as Ethernet." This is obviously an error for at least two reasons: there should be only _one_ such address for interoperability, and 2nd I never saw this "01:00" address in a IP/wifi capture, it's always "33:33:...". This is an error that wikipedia should correct. Additionally, the IEEE lists multicast addresses there: https://standards.ieee.org/develop/regauth/grpmac/public.html (and there is no "01:00:" address either). So I stay away from wikipedia on these matters. >>>> I could not find a MAC address "all nodes" defined at IEEE. >>> >>> That's usually what all 1's is used for. At the link layer, >>> there isn't much difference between broadcast and multicast "all >>> nodes". >> >> No no, there _is_ a difference. IPv6 does not work with all 1s MAC >> broadcast address, it only works with 33-33-0-0-0-1 MAC multicast >> address. IPv4 only works with all 1s MAC broadcast address. > > I was speaking of "all 1's" as representing "link broadcast", i.e., > as behaving like all 1's in IPv4. Yes, that's not the address used > for IPv6. Ah I see, ok. >>>> At IEEE I found a 48bit "All Multicast Capable End Systems >>>> Address" 01-80-C2-00-00-1B; it is listed there: >>>> https://standards.ieee.org/develop/regauth/grpmac/public.html >>> >>> That's listed as LLDP too - and that makes sense if you want to >>> use a link address over which to find 802.11p-capable nodes. >> >> A-ha, it makes sense. So the question is: which group MAC address >> should IPv6-over-80211p use: >> >> - ff:ff:ff:ff:ff:ff - obviously the answer is no. > > But the correct corresponding "all nodes" might be appropriate: > ff02::1 Yes, this IP "all-nodes" is very appropriate, I agree. >> - 33:33:00:00:00:01 - like IPv6-over-WiFi does > > All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, > but I don't see anywhere where any of these addresses are assigned > (or assignable) to a single protocol. Well, there are multiple things here. The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP addresses). Curiously enough, they are defined in an IETF RFC (RFC 2464 "IPv6-over-Ethernet" lists hexa "3333"). I can not find them defined at IEEE even though there is an IEEE place listing IEEE MAC multicast addresses: https://standards.ieee.org/develop/regauth/grpmac/public.html It is curious because IETF should not define MAC address formats or contents, right? As an additional curiosity, the well-known 'cavebear' registry lists 33-33 as an Ethernet Multicast Address: http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html as an "IPv6 Neighbor Discovery" explanation. It is curious because this "33-33-" MAC address is used below other IPv6 protocols like DHCPv6, not only Neighbor Discovery. To correct all these, the following can be proposed: - IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to mean a 6-byte MAC address, and not an IPv6 address, despite the column use. - IEEE tells where is this "3333" address defined so we can see it publicly. - wikipedia stops writing wrong articles. - RFC2464 gets update to mean it also works on WiFi not only on Ethernet. - cavebear tells "33" to mean all IPv6 not only ND. Unfortunately none of these is my goals here. I am trying to just identify the right MAC multicast address for 802.11p below IPv6 (or IPv6-over-80211p if you wish). >> - 01-80-C2-00-00-1B - like LLDP does - request a new one? >> >>>> Remark (1) I have never seen this 48bit IEEE address in >>>> vehicular network trials and (2) it is not a >>>> "33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6 >>>> vehicular prototypes. >>>> >>>> In this context, I believe it can make sense to think of >>>> requesting IANA (rather than IEEE) for an allocation of a >>>> 112bit Group ID named "All 802.11-OCB interfaces"; >>> >>> There are no other IPv6 multicast addresses that group nodes by >>> link type. This sort of request doesn't make sense to me at all; >>> it's a bit backwards. >> >> I agree there are no other IPv6 multicast addresses that group the >> nodes by link type (you dont have an address called "all Ethernet >> nodes" for example). However, 802.11p is not really a particular >> link type - it is WiFi. > > To IP, WiFi is a link type. Granted, it may have a variety of > physical layers underneath and include various subsets of > extensions, but WiFi is not a network-layer protocol or higher-layer > (e.g., app-layer) service, e.g., as routing or DHCP are. I agree. >> Moreover, we are not concerned here with a request to IEEE. An >> IPv6-over-foo I-D describes _mappings_, i.e. what number gets >> mapped from IETF to IEEE identifier. > > It's exactly because you'd need this assigned by IETF that it makes > no sense. But an IETF stds track document should tell which is the MAC multicast address on which to map some IP address. And it should be only one, and agreed by IEEE. >> As such, it is reasonable to request at IETF a 112bit Group >> Identifier, parts of which may get mapped to some bytes of a group >> multicast address. > > In a general sense, yes, IANA would be the right party to assign a > group ID here, but that assumes that a group ID should be allocated > to a link type. There is no precedent for that. Then we should go with "all-nodes" address (not all-OCB-nodes). But we need to know whether that is "33" MAC prefix or some other prefix. And the fact that RFC2464 says it's "33" prefix it's not sufficient - RFC2464 is for Ethernet (wired) not for WiFi. 802.11OCB (aka 802.11p) is a kind of WiFi not a kind of Ethernet. Unless maybe IEEE tells we should use this "33" MAC prefix. >> The overall goal is that people stop using the MAC broadcast >> address on 802.11p (all 1s) and start using a single MAC group >> address (not various). > > Although I understand your goal, I don't see why a separate *IP* > multicast group is the right way to solve it. In order to get rid of all the above doubts (wikipedia, cavebear, IEEE and RFC2464 seem each contradictory to each other) and start afresh. Just get a new allocation fresh only for vehicular communications, and advertise that in an RFC. Not care about fixing old problems like wired Ethernet and wikipedia. > If you want to reach all nodes, you already can on IPv6 using > ff02::1 YEs. > If you want to reach all 802.11p nodes, you need to define an > IP-visible service that selects for that property, and ask for a > group ID *for that service*, IMO. In a sense yes, but the 'service' layer is much higher than a networking layer which would send a Router Advertisement. It would be a chicken and egg problem: before establishing network connectivity one would need to set up app-layer multicast groups. >>> AFAICT, you either really want to use LLDP at the link layer or >>> the existing SSDP IPv6 multicast address to identify your >>> service. >> >> YEs, later, when we discuss application-level services that is a >> very good direction. For example we need to identify a group of >> all taxis in a cell to send them a call. >> >> But for now we need a group MAC address on 802.11p on which we can >> send network-layer messages like Router Advertisements. > > If you want to send router advertisements, send them to ff02::2 (all > routers). If I do so, what does the dst field in the MAC header contain? "33:33:0:0:0:2"? What is the authoritative reference for that "3333"? > If you want to specify a subset of those routers, you really ought > to do so the same way as everyone else - by the IP-layer *routing > protocol* spoken (e.g., OSPF, RIP, etc.). OSPF also sends HELLOs to "allSPFrouters" ff02::5 IPv6 multicast address. I guess such HELLO gets carried by a MAC header with MAC dst address 33:33:0:0:0:5, even though this 3333 prefix is not specified by IEEE, and even though cavebear says it's for IPv6 ND only (not OSPF). But OSPF is not my problem at this time. Alex > > Joe > From nobody Fri Jul 8 11:20:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2E12D580 for ; Fri, 8 Jul 2016 11:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.527 X-Spam-Level: X-Spam-Status: No, score=-7.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 C1Fc_2mX_sCH for ; Fri, 8 Jul 2016 11:20:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id CB01F12D5F8 for ; Fri, 8 Jul 2016 11:20:00 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u68IIvmo009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2016 11:18:57 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> Date: Fri, 8 Jul 2016 11:18:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.com> References: <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47! @gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 08 Jul 2016 11:18:57 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:20:03 -0000 [SNIP] The IEEE document you referenced is not complete for all 802.x multicast = addresses, but only covers 802.1D and 802.1Q. The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI as = explained in RFC-7042) and has also delegated an OUI block 33-33-00 to 33-33-FF to IANA for IPv6 Multicast. Once those OUIs were delegated to IANA, it is, in fact, up to IANA = (through the IETF process) to register assignments within those OUIs which is exactly what has happened in the RFCs to = which you refer. You can find more information from IANA about this here: = http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#et= hernet-numbers-1 Seems to me that the Wikipedia page is correct and that the Petrescu = understanding is flawed. Owen From nobody Fri Jul 8 11:58:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3912D133 for ; Fri, 8 Jul 2016 11:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 1h-1N6nDGs97 for ; Fri, 8 Jul 2016 11:58:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 56AA912D0AF for ; Fri, 8 Jul 2016 11:58:50 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u68IvI5F028287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jul 2016 11:57:20 -0700 (PDT) To: Owen DeLong , Alexandre Petrescu References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47! @gmail.com> <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.com> From: Joe Touch Message-ID: <577FF78A.2010207@isi.edu> Date: Fri, 8 Jul 2016 11:57:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:58:52 -0000 On 7/8/2016 11:18 AM, Owen DeLong wrote: > [SNIP] > > The IEEE document you referenced is not complete for all 802.x multicast addresses, but only covers 802.1D and 802.1Q. > > The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI as explained in RFC-7042) and has also delegated > an OUI block 33-33-00 to 33-33-FF to IANA for IPv6 Multicast. I saw the former (01-00-5E) at IEEE. Is the latter documented anywhere at IEEE? Joe From nobody Fri Jul 8 12:03:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA2412D0CB for ; Fri, 8 Jul 2016 12:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 qqxe0HNZyUVK for ; Fri, 8 Jul 2016 12:03:13 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F7512D5F8 for ; Fri, 8 Jul 2016 12:03:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68J2wnW021842; Fri, 8 Jul 2016 21:02:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 887BA209779; Fri, 8 Jul 2016 21:02:58 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 798DF2096B6; Fri, 8 Jul 2016 21:02:58 +0200 (CEST) Received: from [132.166.84.31] ([132.166.84.31]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68J2vQ7001624; Fri, 8 Jul 2016 21:02:57 +0200 To: Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47! @gmail.com> <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.com> From: Alexandre Petrescu Message-ID: <76963f45-6da0-743a-fa8d-cb3d596a64ef@gmail.com> Date: Fri, 8 Jul 2016 21:02:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:03:15 -0000 Le 08/07/2016 20:18, Owen DeLong a crit : > [SNIP] > > The IEEE document you referenced is not complete for all 802.x > multicast addresses, but only covers 802.1D and 802.1Q. > > The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI > as explained in RFC-7042) and has also delegated an OUI block > 33-33-00 to 33-33-FF to IANA for IPv6 Multicast. > > Once those OUIs were delegated to IANA, it is, in fact, up to IANA > (through the IETF process) to register assignments within those OUIs > which is exactly what has happened in the RFCs to which you refer. > > You can find more information from IANA about this here: > > http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-1 That URL says: > [...] while multicast addresses under the IANA OUI start with > 01-00-5E. [...] 48-bit MAC addresses in the range > 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF are used for IPv6 multicast. So there is an IETF protocol which is not an IPv6 protocol? (because it uses 01-00-5E at MAC, instead of 33-33-). > Seems to me that the Wikipedia page is correct and that the Petrescu > understanding is flawed. Which of 01-00-5E and 33-33-00 should be used in dst field of multicast IPv6 Router Advertisement packets sent on 802.11-OCB (aka 802.11p)? And most importantly - why? Alex > > Owen > > From nobody Fri Jul 8 12:19:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999A712D592 for ; Fri, 8 Jul 2016 12:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 LTXEcVEZKPfW for ; Fri, 8 Jul 2016 12:19:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 905F612D189 for ; Fri, 8 Jul 2016 12:19:26 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u68JEisQ004256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jul 2016 12:14:46 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> From: Joe Touch Message-ID: <577FFBA2.6030205@isi.edu> Date: Fri, 8 Jul 2016 12:14:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> Content-Type: multipart/alternative; boundary="------------080809070906090907010603" 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:19:29 -0000 This is a multi-part message in MIME format. --------------080809070906090907010603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: > ... > I suppose it's not a coincidence that IEEE and IETF both call these > addresses "all-nodes" but I have no trace of that. Let's get down to the authorities: IANA: http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml IANA does assign addresses starting with 01-00-5E for link multicast. IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for IPv6 multicast. IEEE: http://standards.ieee.org/develop/regauth/grpmac/public.html 01-80-C2-00-00-1B = all multicast-capable endsystems 01-80-C2-00-00-1D = all multicast-capable intermediate systems 01-80-C2-00-00-00..0F = assigned for 802.1Q *** this appears to be where you might request an address for your protocol *** You also argued about "all 1's" not being Ethernet broadcast. It is defined as exactly that on page 32 here: www.ieee802.org/secmail/pdfocSP2xXA6d.pdf However, it's also defined as "never assigned" as NULL or unintialized here: https://standards.*ieee*.org/develop/.../eui48.pdf > I am trying to identify the precise IEEE authoritative reference that > says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. Same here - still looking, but I see only IANA's assertion of ownership based on an RFC. Nothing at the IEEE yet. > >> But the correct corresponding "all nodes" might be appropriate: >> ff02::1 > > Yes, this IP "all-nodes" is very appropriate, I agree. > >>> - 33:33:00:00:00:01 - like IPv6-over-WiFi does >> >> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, >> but I don't see anywhere where any of these addresses are assigned >> (or assignable) to a single protocol. > > Well, there are multiple things here. > > The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP > addresses). Yes - I was intending to say "the 33:33::" addresses are used within IPv6 multicast as per RFC2464... > Curiously enough, they are defined in an IETF RFC (RFC 2464 > "IPv6-over-Ethernet" lists hexa "3333"). I can not find them defined at > IEEE even though there is an IEEE place listing IEEE MAC multicast > addresses: > https://standards.ieee.org/develop/regauth/grpmac/public.html > > It is curious because IETF should not define MAC address formats or > contents, right? Agreed - I think there are a few of us looking, but if anyone knows, please speak up! > As an additional curiosity, the well-known 'cavebear' registry lists > 33-33 as an Ethernet Multicast Address: > http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html > as an "IPv6 Neighbor Discovery" explanation. > > It is curious because this "33-33-" MAC address is used below other IPv6 > protocols like DHCPv6, not only Neighbor Discovery. Yes. > > To correct all these, the following can be proposed: > > - IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to > mean a 6-byte MAC address, and not an IPv6 address, despite the > column use. Agreed. I think you meant "colon" rather than "column", though. > - IEEE tells where is this "3333" address defined so we can see it > publicly. Please! > - wikipedia stops writing wrong articles. Well, it is Wikipedia - if it's incorrect, we can change it... > - RFC2464 gets update to mean it also works on WiFi not only on > Ethernet. I don't understand this at all. I thought WiFi was just a variety wireless media layers over which 802 frames (colloquially known as "ethernet") were sent. > - cavebear tells "33" to mean all IPv6 not only ND. > > Unfortunately none of these is my goals here. I am trying to just > identify the right MAC multicast address for 802.11p below IPv6 (or > IPv6-over-80211p if you wish). > >>> - 01-80-C2-00-00-1B - like LLDP does - request a new one? >>> >>>>> Remark (1) I have never seen this 48bit IEEE address in >>>>> vehicular network trials and (2) it is not a >>>>> "33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6 >>>>> vehicular prototypes. >>>>> >>>>> In this context, I believe it can make sense to think of >>>>> requesting IANA (rather than IEEE) for an allocation of a >>>>> 112bit Group ID named "All 802.11-OCB interfaces"; >>>> >>>> There are no other IPv6 multicast addresses that group nodes by >>>> link type. This sort of request doesn't make sense to me at all; >>>> it's a bit backwards. >>> >>> I agree there are no other IPv6 multicast addresses that group the >>> nodes by link type (you dont have an address called "all Ethernet >>> nodes" for example). However, 802.11p is not really a particular >>> link type - it is WiFi. >> >> To IP, WiFi is a link type. Granted, it may have a variety of >> physical layers underneath and include various subsets of >> extensions, but WiFi is not a network-layer protocol or higher-layer >> (e.g., app-layer) service, e.g., as routing or DHCP are. > > I agree. > >>> Moreover, we are not concerned here with a request to IEEE. An >>> IPv6-over-foo I-D describes _mappings_, i.e. what number gets >>> mapped from IETF to IEEE identifier. >> >> It's exactly because you'd need this assigned by IETF that it makes >> no sense. > > But an IETF stds track document should tell which is the MAC multicast > address on which to map some IP address. And it should be only one, and > agreed by IEEE. I think that's step 2; step 1 is getting the address from the IEEE. > >>> As such, it is reasonable to request at IETF a 112bit Group >>> Identifier, parts of which may get mapped to some bytes of a group >>> multicast address. >> >> In a general sense, yes, IANA would be the right party to assign a >> group ID here, but that assumes that a group ID should be allocated >> to a link type. There is no precedent for that. > > Then we should go with "all-nodes" address (not all-OCB-nodes). But we > need to know whether that is "33" MAC prefix or some other prefix. Agreed. > > And the fact that RFC2464 says it's "33" prefix it's not sufficient - > RFC2464 is for Ethernet (wired) not for WiFi. 802.11OCB (aka 802.11p) > is a kind of WiFi not a kind of Ethernet. > > Unless maybe IEEE tells we should use this "33" MAC prefix. > >>> The overall goal is that people stop using the MAC broadcast >>> address on 802.11p (all 1s) and start using a single MAC group >>> address (not various). >> >> Although I understand your goal, I don't see why a separate *IP* >> multicast group is the right way to solve it. > > In order to get rid of all the above doubts (wikipedia, cavebear, IEEE > and RFC2464 seem each contradictory to each other) and start afresh. > > Just get a new allocation fresh only for vehicular communications, and > advertise that in an RFC. Not care about fixing old problems like wired > Ethernet and wikipedia. Although I agree it isn't useful to solve old problems, "all nodes" IP multicast already exists. If that's what you should be using, then use it. I still see absolutely no reason for "vehicular" assignment; assignments are for protocols, not places where you deploy them. > >> If you want to reach all nodes, you already can on IPv6 using >> ff02::1 > > YEs. > >> If you want to reach all 802.11p nodes, you need to define an >> IP-visible service that selects for that property, and ask for a >> group ID *for that service*, IMO. > > In a sense yes, but the 'service' layer is much higher than a networking > layer which would send a Router Advertisement. You're either sending a link-layer routing protocol message (e.g., like a IS-IS or Ethernet BPDUs) or you're sending an Internet routing protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as "service" layers (i.e., "applications"), i.e., inside UDP or TCP inside IP. Given you want to reach all 802.11p nodes, it seems like you should want an MAC multicast address - but not an IP multicast address. IP multicast is needed only to for IP-layer routing, not for link layer. Joe --------------080809070906090907010603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/8/2016 6:52 AM, Alexandre Petrescu wrote:
...
I suppose it's not a coincidence that IEEE and IETF both call these
addresses "all-nodes" but I have no trace of that.

Let's get down to the authorities:

IANA: http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
    IANA does assign addresses starting with 01-00-5E for link multicast.
    IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for IPv6 multicast.

IEEE:
    http://standards.ieee.org/develop/regauth/grpmac/public.html
        01-80-C2-00-00-1B = all multicast-capable endsystems
        01-80-C2-00-00-1D = all multicast-capable intermediate systems
        01-80-C2-00-00-00..0F = assigned for 802.1Q
            *** this appears to be where you might request an address for your protocol ***

You also argued about "all 1's" not being Ethernet broadcast. It is defined as exactly that on page 32 here:
www.ieee802.org/secmail/pdfocSP2xXA6d.pdf

However, it's also defined as "never assigned" as NULL or unintialized here:
https://standards.ieee.org/develop/.../eui48.pdf
I am trying to identify the precise IEEE authoritative reference that
says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant.

Same here - still looking, but I see only IANA's assertion of ownership based on an RFC. Nothing at the IEEE yet.


But the correct corresponding "all nodes" might be appropriate:
ff02::1

Yes, this IP "all-nodes" is very appropriate, I agree.

- 33:33:00:00:00:01 - like IPv6-over-WiFi does

All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464,
but I don't see anywhere where any of these addresses are assigned
(or assignable) to a single protocol.

Well, there are multiple things here.

The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP addresses).
Yes - I was intending to say "the 33:33::" addresses are used within IPv6 multicast as per RFC2464...

Curiously enough, they are defined in an IETF RFC (RFC 2464
"IPv6-over-Ethernet" lists hexa "3333").  I can not find them defined at
IEEE even though there is an IEEE place listing IEEE MAC multicast
addresses:
https://standards.ieee.org/develop/regauth/grpmac/public.html

It is curious because IETF should not define MAC address formats or
contents, right?

Agreed - I think there are a few of us looking, but if anyone knows, please speak up!

As an additional curiosity, the well-known 'cavebear' registry lists
33-33 as an Ethernet Multicast Address:
http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html
as an "IPv6 Neighbor Discovery" explanation.

It is curious because this "33-33-" MAC address is used below other IPv6
protocols like DHCPv6, not only Neighbor Discovery.
Yes.


To correct all these, the following can be proposed:

- IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to
  mean a 6-byte MAC address, and not an IPv6 address, despite the
  column use.
Agreed. I think you meant "colon" rather than "column", though.

- IEEE tells where is this "3333" address defined so we can see it
  publicly.

Please!

- wikipedia stops writing wrong articles.

Well, it is Wikipedia - if it's incorrect, we can change it...

- RFC2464 gets update to mean it also works on WiFi not only on
  Ethernet.
I don't understand this at all. I thought WiFi was just a variety wireless media layers over which 802 frames (colloquially known as "ethernet") were sent.

- cavebear tells "33" to mean all IPv6 not only ND.

Unfortunately none of these is my goals here.  I am trying to just
identify the right MAC multicast address for 802.11p below IPv6 (or
IPv6-over-80211p if you wish).

- 01-80-C2-00-00-1B - like LLDP does - request a new one?

Remark (1) I have never seen this 48bit IEEE address in
vehicular network trials and (2) it is not a
"33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6
vehicular prototypes.

In this context, I believe it can make sense to think of
requesting IANA (rather than IEEE) for an allocation of a
112bit Group ID named "All 802.11-OCB interfaces";

There are no other IPv6 multicast addresses that group nodes by
link type. This sort of request doesn't make sense to me at all;
it's a bit backwards.

I agree there are no other IPv6 multicast addresses that group the
 nodes by link type (you dont have an address called "all Ethernet
 nodes" for example).  However, 802.11p is not really a particular
link type - it is WiFi.

To IP, WiFi is a link type. Granted, it may have a variety of
physical layers underneath and include various subsets of
extensions, but WiFi is not a network-layer protocol or higher-layer
(e.g., app-layer) service, e.g., as routing or DHCP are.

I agree.

Moreover, we are not concerned here with a request to IEEE.  An
IPv6-over-foo I-D describes _mappings_, i.e. what number gets
mapped from IETF to IEEE identifier.

It's exactly because you'd need this assigned by IETF that it makes
no sense.

But an IETF stds track document should tell which is the MAC multicast
address on which to map some IP address.  And it should be only one, and
agreed by IEEE.
I think that's step 2; step 1 is getting the address from the IEEE.


As such, it is reasonable to request at IETF a 112bit Group
Identifier, parts of which may get mapped to some bytes of a group
 multicast address.

In a general sense, yes, IANA would be the right party to assign a
group ID here, but that assumes that a group ID should be allocated
to a link type. There is no precedent for that.

Then we should go with "all-nodes" address (not all-OCB-nodes).  But we
need to know whether that is "33" MAC prefix or some other prefix.

Agreed.

And the fact that RFC2464 says it's "33" prefix it's not sufficient -
RFC2464 is for Ethernet (wired) not for WiFi.  802.11OCB (aka 802.11p)
is a kind of WiFi not a kind of Ethernet.

Unless maybe IEEE tells we should use this "33" MAC prefix.

The overall goal is that people stop using the MAC broadcast
address on 802.11p (all 1s) and start using a single MAC group
address (not various).

Although I understand your goal, I don't see why a separate *IP*
multicast group is the right way to solve it.

In order to get rid of all the above doubts (wikipedia, cavebear, IEEE
and RFC2464 seem each contradictory to each other) and start afresh.

Just get a new allocation fresh only for vehicular communications, and
advertise that in an RFC.  Not care about fixing old problems like wired
Ethernet and wikipedia.
Although I agree it isn't useful to solve old problems, "all nodes" IP multicast already exists. If that's what you should be using, then use it.

I still see absolutely no reason for "vehicular" assignment; assignments are for protocols, not places where you deploy them.


If you want to reach all nodes, you already can on IPv6 using
ff02::1

YEs.

If you want to reach all 802.11p nodes, you need to define an
IP-visible service that selects for that property, and ask for a
group ID *for that service*, IMO.

In a sense yes, but the 'service' layer is much higher than a networking
layer which would send a Router Advertisement.

You're either sending a link-layer routing protocol message (e.g., like a IS-IS or Ethernet BPDUs) or you're sending an Internet routing protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as "service" layers (i.e., "applications"), i.e., inside UDP or TCP inside IP.

Given you want to reach all 802.11p nodes, it seems like you should want an MAC multicast address - but not an IP multicast address. IP multicast is needed only to for IP-layer routing, not for link layer.

Joe



--------------080809070906090907010603-- From nobody Fri Jul 8 12:38:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D412D16F for ; Fri, 8 Jul 2016 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 SMgVSc4BYHzi for ; Fri, 8 Jul 2016 12:38:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B741212D0D3 for ; Fri, 8 Jul 2016 12:38:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68JcBQj013756 for ; Fri, 8 Jul 2016 21:38:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 97E98209853 for ; Fri, 8 Jul 2016 21:38:11 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8EFAF2095F0 for ; Fri, 8 Jul 2016 21:38:11 +0200 (CEST) Received: from [132.166.84.71] ([132.166.84.71]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68JcAqd008719 for ; Fri, 8 Jul 2016 21:38:11 +0200 References: To: "v6ops@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: Message-ID: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> Date: Fri, 8 Jul 2016 21:38:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:38:15 -0000 Hi, During our discussion of IPv6 and MAC address multicast I laid down a few of comment results of the discussion on this email list, on this Internet Draft referred to below. In my oppinion there is obviously a need to clarify how and what MAC multicast addresses to use below IPv6 in IPv6-over-802.11OCB (Out of the Context of BSSID, aka 802.11p). Alex -------- Message transfr -------- Sujet : [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 21:33:53 +0200 De : Alexandre Petrescu Pour : its@ietf.org Hi, I have just submitted this Internet Draft I co-author with Thierry Ernst. The distinctive aspect is that it tries to suggest the way MAC and IPv6 multicast is used on an IPv6-over-80211-OCB links. Alex -------- Message transfr -------- Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org Rpondre : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IEEE 802.11-OCB Networks Authors : Thierry Ernst Alexandre Petrescu Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : 2016-07-08 Abstract: In this document the mapping of multicast IPv6 addresses to MAC addresses of 802.11-OCB is proposed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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/ _______________________________________________ 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 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Jul 8 12:54:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14712B019 for ; Fri, 8 Jul 2016 12:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sFDpJGhK4UvF for ; Fri, 8 Jul 2016 12:54:16 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 05F0B12D13B for ; Fri, 8 Jul 2016 12:54:16 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id s93so10313940ioi.3 for ; Fri, 08 Jul 2016 12:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfjuIRCMdUB6P6e2ciYgE+lpLbTobkRxaR57aDc+Oeg=; b=eK3Ttp47sFsdXpZsR5HseRirFo6tpATzEX84pcmxRCXIaajMD3Wrw5GSAb6URl4JVL /n9YydmQJUntSB4/upfqhmVB2bXpU8YZRLcgDA5q6JBpv+hEjmhCmtFuWeJZRjD6zXwW ZJnjazRZBOMpnQAQwpTNDapqMEgbQ1+BSVth0gp2YmLIJshCo3ZDVZv58FV5OPR+Skx0 dj5C7l5Nynk3Sck2QQBs5XB4IgxNKUTFk40X14qTHXU5UOK2TKxi5XfARmCdhNa3v8NP GOawuf4ourOQ/4WodkNhwcpSlo5nxhocfRyvoM9kjDNNIhBIK8IvIyhYH2PPYCPjRrQL dgOg== 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; bh=vfjuIRCMdUB6P6e2ciYgE+lpLbTobkRxaR57aDc+Oeg=; b=LKQsRA8x2xxCyGAXH2qp9XjawQKc17LKOfEzN1+y8pXmgRxxXHwZJ0Kt+1S0aN46Ks D0lAOCP3Y12hwfTtpsGOEM9dJP13FLsivlg8eIlZHqQsRQ2qMcxnBNsthhJAPppKap1X LYYP8/ElWeQMR8vXghgKzt0WL3nUDZvPN5wKIQ5tOYtb8ihwPFHeRvlYnyMHbtzXxpzH I+o5blJgujAObcZLTlgtdSwooyhU/ArSvjY9DCH/Tu4DCHwrLjlEshF+re5i2UCAJ64X dp+g7EM6HL4eMwSKRYgRi45cpGhMkh90EA8wGHLsakgm4LUo6as7BbHuGI057XK1FlyQ AJng== X-Gm-Message-State: ALyK8tJBHKW/MFqgvsc8edmU4i2p1dJWb5DZ7Kkuq2f4KNt7pCQvs4a6SZNMvofY2i211pZcamObJ3geDFgTRw== X-Received: by 10.107.170.13 with SMTP id t13mr899716ioe.2.1468007655368; Fri, 08 Jul 2016 12:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Fri, 8 Jul 2016 12:53:55 -0700 (PDT) In-Reply-To: <577FFBA2.6030205@isi.edu> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> From: Jen Linkova Date: Fri, 8 Jul 2016 21:53:55 +0200 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:54:19 -0000 On Fri, Jul 8, 2016 at 9:14 PM, Joe Touch wrote: >> I am trying to identify the precise IEEE authoritative reference that >> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. > > Same here - still looking, but I see only IANA's assertion of ownership > based on an RFC. Nothing at the IEEE yet. > >> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, >> but I don't see anywhere where any of these addresses are assigned >> (or assignable) to a single protocol. >> It is curious because IETF should not define MAC address formats or >> contents, right? > > > Agreed - I think there are a few of us looking, but if anyone knows, please > speak up! We have just discussed it in 6man email thread but in case you missed it: 33-33- has Local bit set. It is *locally assigned* MAC. Not globally assigned by IEEE. >> To correct all these, the following can be proposed: > >> - IEEE tells where is this "3333" address defined so we can see it > publicly. > > > Please! I believe IEEE told us where 3333 is defined by saying that addresses which Local bit set are locally administered ones. IEEE RA is only responsible for assigning identifiers which are globally unique. -- SY, Jen Linkova aka Furry From nobody Fri Jul 8 13:04:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC812D912 for ; Fri, 8 Jul 2016 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 gpxinWBmUItb for ; Fri, 8 Jul 2016 13:04:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5550412D928 for ; Fri, 8 Jul 2016 13:04:46 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u68K3pJ8000087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jul 2016 13:03:53 -0700 (PDT) To: Jen Linkova References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> From: Joe Touch Message-ID: <57800724.70304@isi.edu> Date: Fri, 8 Jul 2016 13:03:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:04:49 -0000 Hi, Jen, Thanks - that helps. So the right thing here would appear to be to use the existing IPv6 multicast for "all nodes" or "all routers", until one of two things happens: - an routing protocol/service is developed that warrants a new IPv6 multicast address assignment (e.g., for a routing protocol that operates *over* IP) - a "link layer"protocol/service is developed that warrants a direct IEEE multicast assignment (e.g., for a routing protocol that operates at the IEEE 802 MAC layer) However, I still have not heard the case for a *protocol* here. I keep hearing about "vehicular networks" as if that were the same thing, but it isn't. Joe On 7/8/2016 12:53 PM, Jen Linkova wrote: > On Fri, Jul 8, 2016 at 9:14 PM, Joe Touch wrote: >>> I am trying to identify the precise IEEE authoritative reference that >>> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. >> Same here - still looking, but I see only IANA's assertion of ownership >> based on an RFC. Nothing at the IEEE yet. >> >>> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, >>> but I don't see anywhere where any of these addresses are assigned >>> (or assignable) to a single protocol. >>> It is curious because IETF should not define MAC address formats or >>> contents, right? >> >> Agreed - I think there are a few of us looking, but if anyone knows, please >> speak up! > We have just discussed it in 6man email thread but in case you missed it: > 33-33- has Local bit set. It is *locally assigned* MAC. Not globally > assigned by IEEE. > >>> To correct all these, the following can be proposed: >>> - IEEE tells where is this "3333" address defined so we can see it >> publicly. >> >> >> Please! > I believe IEEE told us where 3333 is defined by saying that addresses > which Local bit set are locally administered ones. > IEEE RA is only responsible for assigning identifiers which are globally unique. > From nobody Fri Jul 8 14:46:22 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D016F12D611; Fri, 8 Jul 2016 14:46:20 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708214620.32067.7949.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:46:20 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:46: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 of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-01.txt Pages : 8 Date : 2016-07-08 Abstract: In some IPv6 environments the need has arisen for hosts to be able to utilise a unique IPv6 prefix even though the link or media may be shared. Typically hosts (subscribers) on a shared network, like Wi- Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. Benefits of a unique IPv6 prefix compared to a unique IPv6 address from the service provider are going from enhanced subscriber management to improved isolation between subscribers. In most deployments today IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-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 Fri Jul 8 20:13:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EE812B022 for ; Fri, 8 Jul 2016 20:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.527 X-Spam-Level: X-Spam-Status: No, score=-7.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PEdtrBwztqvb for ; Fri, 8 Jul 2016 20:13:08 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 654B112B00C for ; Fri, 8 Jul 2016 20:13:07 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u693C4hX005221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jul 2016 20:12:05 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> Date: Fri, 8 Jul 2016 20:12:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 08 Jul 2016 20:12:05 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 03:13:10 -0000 I fail to see any reason that the mapping would be different in OCB vs. = any other 802 style networking. Owen > On Jul 8, 2016, at 12:38 , Alexandre Petrescu = wrote: >=20 > Hi, >=20 > During our discussion of IPv6 and MAC address multicast I laid down a = few of comment results of the discussion on this email list, on this = Internet Draft referred to below. >=20 > In my oppinion there is obviously a need to clarify how and what MAC = multicast addresses to use below IPv6 in IPv6-over-802.11OCB (Out of the = Context of BSSID, aka 802.11p). >=20 > Alex >=20 > -------- Message transf=E9r=E9 -------- > Sujet : [its] Fwd: I-D Action: = draft-ernst-its-ipv6-over-80211ocb-00.txt > Date : Fri, 8 Jul 2016 21:33:53 +0200 > De : Alexandre Petrescu > Pour : its@ietf.org >=20 > Hi, >=20 > I have just submitted this Internet Draft I co-author with Thierry = Ernst. >=20 > The distinctive aspect is that it tries to suggest the way MAC and = IPv6 multicast is used on an IPv6-over-80211-OCB links. >=20 > Alex >=20 >=20 > -------- Message transf=E9r=E9 -------- > Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt > Date : Fri, 8 Jul 2016 08:55:47 -0700 > De : internet-drafts@ietf.org > R=E9pondre =E0 : internet-drafts@ietf.org > Pour : i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Transmission of IPv6 Packets over IEEE = 802.11-OCB Networks > Authors : Thierry Ernst > Alexandre Petrescu > Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt > Pages : 5 > Date : 2016-07-08 >=20 > Abstract: > In this document the mapping of multicast IPv6 addresses to MAC > addresses of 802.11-OCB is proposed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00 >=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 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jul 9 06:01:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63412D08D for ; Sat, 9 Jul 2016 06:01:51 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xvyD8nynQp5s for ; Sat, 9 Jul 2016 06:01:48 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 BBF5712D0FA for ; Sat, 9 Jul 2016 06:01:47 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n127so41087907wme.1 for ; Sat, 09 Jul 2016 06:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xnLRHyRiYXixq+1nIhy9EEUkP73LiC78euT8YwKAsik=; b=ZfoLM6I9c0nlPq0YUB3fxri698pkc3wDSKusJKBXrgctBfkiwPW7x56L7qQKXas6Py wYM7AfhR8U1Z75gs6ERgc1w/EEr1uwRGsI3os58Mpj/DcmT3kK2bAU96GXFEBHvfeAed KMo5cbOiAgjJKAGROYokBy9NE2w6JJdDWYrl4yLU2ZmYILL/7RuZ7k0tKauSlfZWVM3A JXdrfb0gEo+tDzY61/0e00GqhgvCoJysWZtxTV2G6CHtqGGp3Y97rGUKNNqvpH7YBXjd 9LKrBg8tXLpQLDWYsnHDoonyGa3rdBw45WBZ6F69uv+zZuvNhVeKdbu8+doVDav/Gz4+ oZpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xnLRHyRiYXixq+1nIhy9EEUkP73LiC78euT8YwKAsik=; b=JVm/jPn98OvKWfDjwLAw6JkGFAjtRDgprDZznYBI/7au/23qp9p5ILTRxwtmby5Lne B+mU8BhR80sH8XIVnEiPI/dTOekmf3R4l7EKq73L5TOIgzZyVdDt0EUh/vi5RaEeP4Ma +WnAnSYyLuBGJgZO2oeUOGRHY0MpP20vUxEpx3q+YaYOUAlDnWcjTtfGU5PMgEPDJKQE 2sYU9MtDsMMrFU8JMWKb+dCV9U3QTCIpMNmqdmxfum1mywsNuhQUZBhUJ64x+TWrsB38 VacgGRPSkb5YUaQyVUUH1zV2GyO8CgyI9D/7wSSe3+mKEekO7h4cagLTKwCgfqfOs2Ly S1aw== X-Gm-Message-State: ALyK8tLbfNCVTBUd1mtF15BGaXKnrHFOsHlGOX6ZAK+Sro1czClS1L8JQ66lXk5A2heNaQ== X-Received: by 10.194.87.106 with SMTP id w10mr10572819wjz.151.1468069306028; Sat, 09 Jul 2016 06:01:46 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id p126sm7860376wmp.13.2016.07.09.06.01.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 06:01:45 -0700 (PDT) To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> Date: Sun, 10 Jul 2016 01:01:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Jen Linkova , Chris Bowers Subject: Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 13:01:51 -0000 Dear Bowbakova, This is good stuff. We need SADR on site routers. draft-ietf-6man-multi-homed-host is listed in the references but not cited in the text. Since it is all about effective use of RFC6724 rule 5.5, I would expect it to carefully referenced in section 4.1. In fact, the behaviour specified by draft-ietf-6man-multi-homed-host seems to be essential for your mechanism to succeed. You almost say that in section 4.2.2 but again without citing the draft. Worse, section 4.2.4 says: > At the same time Router Advertisements provide a reliable mechanism > to influence source address selection process via PIO, RIO and > default router preferences. As all those options have been > standardized by IETF and are supported by various operating systems, > no changes are required on hosts. That's not true. The changes described in draft-ietf-6man-multi-homed-host *are* required. Also, routers must be capable of sending PIOs with both L and A bits set to zero. The same error occurs in section 4.6: > 1. no new (non-standard) functionality needs to be implemented on > hosts (except for [RFC4191] support); Section 5.1, shim6. While not disputing your conclusion, I think this is misleading: > We do not consider Shim6 to be a viable solution. It suffers from > the fact that it requires widespread deployment of Shim6 on hosts... It is a two-ended solution and we always knew that it could only be deployed incrementally and opportunistically; that was the plan, not a defect. The real defect is that the Internet is partly opaque to IPv6 extension headers, and therefore even incremental deployment of shim6 is not viable. (The same goes for HIP-based multihoming, which you don't mention.) Finally, it's helpful in site multihoming proposals to indicate whether they meet the goals in RFC 3582. Regards Brian On 07/07/2016 04:33, Fred Baker (fred) wrote: > At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. > >> Begin forwarded message: >> >> From: >> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >> Date: July 5, 2016 at 5:58:25 PM PDT >> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >> >> >> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >> >> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >> Revision: 00 >> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >> Document date: 2016-07-05 >> Group: Individual Submission >> Pages: 44 >> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >> >> >> Abstract: >> Connecting an enterprise site to multiple ISPs using provider- >> assigned addresses is difficult without the use of some form of >> Network Address Translation (NAT). Much has been written on this >> topic over the last 10 to 15 years, but it still remains a problem >> without a clearly defined or widely implemented solution. Any >> multihoming solution without NAT requires hosts at the site to have >> addresses from each ISP and to select the egress ISP by selecting a >> source address for outgoing packets. It also requires routers at the >> site to take into account those source addresses when forwarding >> packets out towards the ISPs. >> >> This document attempts to define a complete solution to this problem. >> It covers the behavior of routers to forward traffic taking into >> account source address, and it covers the behavior of host to select >> appropriate source addresses. It also covers any possible role that >> routers might play in providing information to hosts to help them >> select appropriate source addresses. In the process of exploring >> potential solutions, this documents also makes explicit requirements >> for how the solution would be expected to behave from the perspective >> of an enterprise site network administrator . >> >> >> >> >> 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. >> >> The IETF Secretariat >> > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Jul 9 08:27:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41CD12D5A2; Sat, 9 Jul 2016 08:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vI6S37D3XsYC; Sat, 9 Jul 2016 08:27:18 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43BA12D0DD; Sat, 9 Jul 2016 08:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11592; q=dns/txt; s=iport; t=1468078038; x=1469287638; h=from:to:cc:subject:date:message-id:mime-version; bh=Q6XlfaQE2CMHadw3N24MRU+fOMoqRMzvD+LvsMzwi94=; b=VqfRsHVCB0m87OAERUyuxp7am3MnA8Bawh3NO/LLEZQg8zhFlhvQHHAR Q4PQsAM+tR5z1tIYInLzYUgkvm0/xaJNAEKk1cm0jDY+D4IeXxcEKDvHH f87w3n3USELQbe3e5/BbahXOZm5ypzGs717u6c8hAkr/Wisy9Gjv+L2FS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgCRF4FX/4wNJK1cgnBOVoECtBGFB?= =?us-ascii?q?IF6hhiBJDgUAQEBAQEBAWUcC4RjLT8KAxIBgQAmAQQODYgovgsBAQEBAQEBAQI?= =?us-ascii?q?BAQEBAQEBAQEBARyPH4VxBYgUhip7iV8BjkqPM5AOAR42ggkcgUyJJCobfwEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.28,337,1464652800"; d="scan'208,217";a="295049969" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2016 15:27:17 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u69FRHqV012311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Jul 2016 15:27:17 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 9 Jul 2016 10:27:16 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Sat, 9 Jul 2016 10:27:16 -0500 From: "Bernie Volz (volz)" To: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 Thread-Index: AdHZ9jkImKwO3BL9SIKp8q8qdOfqZQ== Date: Sat, 9 Jul 2016 15:27:16 +0000 Message-ID: <413035d09b9f424a8e6a741234ae1dbf@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: multipart/alternative; boundary="_000_413035d09b9f424a8e6a741234ae1dbfXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: [v6ops] draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 15:27:21 -0000 --_000_413035d09b9f424a8e6a741234ae1dbfXCHALN003ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: Did you perhaps miss some edits late in the document (Section 5): An operational consideration when using IPv6 address assignment using IPv6 SLAAC is that after the onboarding procedure the UE/subscriber will have a prefix with certain preferred and valid lifetimes. The First Hop Provider Router extends these lifetimes by sending an unsolicited RA, the applicable MaxRtrAdvInterval on the WLAN-GW MUST therefore be lower than the preferred lifetime. As a consequence of this process is that the First Hop Router never knows when a UE/ subscriber stops using addresses from a prefix and additional procedures are required to help the First Hop Router to gain this information. When using stateful DHCPv6 IA_NA for IPv6 UE/subscriber address assignment this uncertainty on the First Hop Router is not of impact due to the stateful nature of DHCPv6 IA_NA address assignment. And I'm not really sure how the stateful nature of DHCP helps significantly= with this issue. The RA's preferred/valid lifetime are really no different= than DHCPv6's preferred/valid lifetimes and could easily be made the same.= (While a DHCPv6 client would normally renew at =BD the preferred lifetime,= that is not a hard requirement and therefore a DHCPv6 server must still as= sume that the address is in use until the valid-lifetime has expired.) Sure= , a DHCPv6 client COULD send a Release message to give up its address, but = that is rarely done in practice. And a bit later (RFC4941): When employing stateless IPv6 address assignment a number of widely deployed operating systems will attempt to utilize RFC 4941 RFC4941 [RFC4941] temporary 'private' addresses. This can lead to the And is there much benefit is including: 6. Future work o Informational draft regarding WLAN IPv6 Deployment technology experiences roll-out It would perhaps be useful if you had a draft to reference, but otherwise n= ot so much? - Bernie --_000_413035d09b9f424a8e6a741234ae1dbfXCHALN003ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

Did you perhaps miss some edits late in the document= (Section 5):

 

=    An operational consideration when using IPv6 address assignmen= t using

=    IPv6 SLAAC is that after the onboarding procedure the UE/subsc= riber

=    will have a prefix with certain preferred and valid lifetimes.=   The

=    First Hop Provider Router extends these lifetimes by sending a= n

=    unsolicited RA, the applicable MaxRtrAdvInterval on the WLAN-GW MUST<= o:p>

=    therefore be lower than the preferred lifetime.  As a con= sequence of

=    this process is that the First Hop Router never knows when a U= E/

=    subscriber stops using addresses from a prefix and additional<= o:p>

=    procedures are required to help the First Hop Router to gain t= his

=    information.  When using stateful DHCPv6 IA_NA for IPv6 U= E/subscriber

=    address assignment this uncertainty on the First Hop Router is= not of

=    impact due to the stateful nature of DHCPv6 IA_NA address assi= gnment.

 

And I’m not really sure how the stateful natur= e of DHCP helps significantly with this issue. The RA’s preferred/val= id lifetime are really no different than DHCPv6’s preferred/valid lif= etimes and could easily be made the same. (While a DHCPv6 client would normally renew at =BD the preferred lifetime, that is not a h= ard requirement and therefore a DHCPv6 server must still assume that the ad= dress is in use until the valid-lifetime has expired.) Sure, a DHCPv6 clien= t COULD send a Release message to give up its address, but that is rarely done in practice.

 

And a bit later (RFC4941):

 

=    When employing stateless IPv6 address assignment a number of w= idely

=    deployed operating systems will attempt to utilize RFC 4941 RF= C4941

=    [RFC4941] temporary 'private' addresses.  This can lead t= o the

 

And is there much benefit is including:

 

= 6.  Future work

=  

=    o  Informational draft regarding WLAN IPv6 Deployment tec= hnology

=       experiences roll-out

 

It would perhaps be useful if you had a draft to ref= erence, but otherwise not so much?

 

-     &= nbsp;    Bernie

--_000_413035d09b9f424a8e6a741234ae1dbfXCHALN003ciscocom_-- From nobody Sat Jul 9 12:54:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECA312D187 for ; Sat, 9 Jul 2016 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.443 X-Spam-Level: X-Spam-Status: No, score=-4.443 tagged_above=-999 required=5 tests=[DKIM_ADSP_ALL=1.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, URIBL_SBL=0.644, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=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 bwHCGr9U40yy for ; Sat, 9 Jul 2016 12:54:23 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 71F8D12D0D3 for ; Sat, 9 Jul 2016 12:54:23 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u69JrJpC004916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Jul 2016 12:53:19 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A6AE0E97-D9C5-40AA-B13A-9B0732999F3A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <76963f45-6da0-743a-fa8d-cb3d596a64ef@gmail.com> Date: Sat, 9 Jul 2016 12:53:18 -0700 Message-Id: <113E4799-3AD3-4EE0-8B61-E220607DE38C@delong.com> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47! @gmail.com> <3DA2EBB5-3D27-40B8-A914-642F6AE5A708@delong.com> <76963f45-6da0-743a-fa8d-cb3d596a64! ef@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 09 Jul 2016 12:53:20 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 19:54:25 -0000 --Apple-Mail=_A6AE0E97-D9C5-40AA-B13A-9B0732999F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 8, 2016, at 12:02 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 08/07/2016 =E0 20:18, Owen DeLong a =E9crit : >> [SNIP] >>=20 >> The IEEE document you referenced is not complete for all 802.x >> multicast addresses, but only covers 802.1D and 802.1Q. >>=20 >> The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI >> as explained in RFC-7042) and has also delegated an OUI block >> 33-33-00 to 33-33-FF to IANA for IPv6 Multicast. >>=20 >> Once those OUIs were delegated to IANA, it is, in fact, up to IANA >> (through the IETF process) to register assignments within those OUIs >> which is exactly what has happened in the RFCs to which you refer. >>=20 >> You can find more information from IANA about this here: >>=20 >> = http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#et= hernet-numbers-1 >=20 > That URL says: >> [...] while multicast addresses under the IANA OUI start with >> 01-00-5E. [...] 48-bit MAC addresses in the range >> 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF are used for IPv6 multicast. >=20 > So there is an IETF protocol which is not an IPv6 protocol? (because = it uses 01-00-5E at MAC, instead of 33-33-). IETF defined all of the stuff for IPv4 as well. I am not certain, but I = think IETF also existed for part of the time during NCP prior to IPv4, = but even if it didn=92t, it=92s predecessor did and probably IETF is now = the official repository for that knowledge and its curation. So, yes, of course IETF does more protocols than just IPv6. >=20 >> Seems to me that the Wikipedia page is correct and that the Petrescu >> understanding is flawed. >=20 > Which of 01-00-5E and 33-33-00 should be used in dst field of = multicast > IPv6 Router Advertisement packets sent on 802.11-OCB (aka 802.11p)? = And most importantly - why? Why would it be any different from the MAC address used for IPv6 RA on = 802.11a/b/g/n/ac which I believe is also the same for 802.1, 802.2, = 802.3, =85 According to http://flylib.com/books/en/2.223.1.44/1/ the mapping is = 0x33:33:XX:XX:XX:XX where XX:XX:XX:XX is the last 32 bits of the IPv6 = multicast group number. So, since you would send the IPv6 RA target is most likely =93All nodes = on link=94, ff02::1 this would map to MAC address 0x33:33:0:0:0:1. This is a universal mapping which applies to ALL 802.x (and possibly = other) networks, not merely the ones listed above to the best of my = knowledge. Owen --Apple-Mail=_A6AE0E97-D9C5-40AA-B13A-9B0732999F3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 8, 2016, at 12:02 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 08/07/2016 =E0 20:18, Owen DeLong a = =E9crit :
[SNIP]

The IEEE document you referenced is not = complete for all 802.x
multicast addresses, but only = covers 802.1D and 802.1Q.

The IEEE has = delegated to IANA the management of 01-00-5E (IANA OUI
as = explained in RFC-7042) and has also delegated an OUI block
33-33-00 to 33-33-FF to IANA for IPv6 Multicast.

Once those OUIs were delegated to IANA, it is, = in fact, up to IANA
(through the IETF process) to register = assignments within those OUIs
which is exactly what has = happened in the RFCs to which you refer.

You = can find more information from IANA about this here:

http://www.iana.org/assignments/ethernet-numbers/ethernet-numbe= rs.xhtml#ethernet-numbers-1

That URL says:
[...] while multicast = addresses under the IANA OUI start with
01-00-5E. [...] = 48-bit MAC addresses in the range
33-33-00-00-00-00 to = 33-33-FF-FF-FF-FF are used for IPv6 multicast.

So there is an IETF protocol which is not an = IPv6 protocol? (because it uses 01-00-5E at MAC, instead of = 33-33-).

IETF defined all = of the stuff for IPv4 as well. I am not certain, but I think IETF also = existed for part of the time during NCP prior to IPv4, but even if it = didn=92t, it=92s predecessor did and probably IETF is now the official = repository for that knowledge and its curation.

So, yes, of course IETF does more protocols than = just IPv6.


Seems to me that the Wikipedia page is correct and that the = Petrescu
understanding is flawed.

Which of 01-00-5E and 33-33-00 should be used in = dst field of multicast
IPv6 Router Advertisement packets sent on = 802.11-OCB (aka 802.11p)?  And most importantly - why?

Why would it be any different from the MAC address used = for IPv6 RA on 802.11a/b/g/n/ac which I believe is also the same for = 802.1, 802.2, 802.3, =85

According = to http://flylib.com/books/en/2.223.1.44/1/ the mapping is = 0x33:33:XX:XX:XX:XX where XX:XX:XX:XX is the last 32 bits of the IPv6 = multicast group number.

So, since = you would send the IPv6 RA target is most likely =93All nodes on link=94, = ff02::1 this would map to MAC address 0x33:33:0:0:0:1.

This is a universal mapping which applies to ALL = 802.x (and possibly other) networks, not merely the ones listed above to = the best of my knowledge.


Owen

= --Apple-Mail=_A6AE0E97-D9C5-40AA-B13A-9B0732999F3A-- From nobody Mon Jul 11 02:55:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1378612B00F for ; Mon, 11 Jul 2016 02:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 CudAvAke-FSI for ; Mon, 11 Jul 2016 02:55:28 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6060127071 for ; Mon, 11 Jul 2016 02:55:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6B9tLxv024508; Mon, 11 Jul 2016 11:55:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2092D202EF5; Mon, 11 Jul 2016 11:55: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 12C1120104A; Mon, 11 Jul 2016 11:55:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6B9tKjQ024460; Mon, 11 Jul 2016 11:55:20 +0200 To: Owen DeLong References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> From: Alexandre Petrescu Message-ID: <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> Date: Mon, 11 Jul 2016 11:55:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 09:55:30 -0000 First: which other 802 style networking? 802.3 Ethernet (rfc2464) or 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? Second: OCB mode of 802.11 is different than other 802.11bgn/ac/ad. For example, a link scope in 802.11bgn/ac/ad is clearly bound by the Association operations: whoever associates to a BSSID is within that link scope. Sending one packet to an IP link-scope destination naturally gets mapped into a multicast MAC address (be it prefixed by 33- or 01-). But in Out-of-a-Context-of-a-BSSID mode there are no Association operations; thus it's hard to say who is within link scope, and what would an "all-nodes" multicast address mean when there is no scope and no SSID. Alex Le 09/07/2016 05:12, Owen DeLong a crit : > I fail to see any reason that the mapping would be different in OCB > vs. any other 802 style networking. > > Owen > >> On Jul 8, 2016, at 12:38 , Alexandre Petrescu >> wrote: >> >> Hi, >> >> During our discussion of IPv6 and MAC address multicast I laid down >> a few of comment results of the discussion on this email list, on >> this Internet Draft referred to below. >> >> In my oppinion there is obviously a need to clarify how and what >> MAC multicast addresses to use below IPv6 in IPv6-over-802.11OCB >> (Out of the Context of BSSID, aka 802.11p). >> >> Alex >> >> -------- Message transfr -------- Sujet : [its] Fwd: I-D Action: >> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 >> 21:33:53 +0200 De : Alexandre Petrescu >> Pour : its@ietf.org >> >> Hi, >> >> I have just submitted this Internet Draft I co-author with Thierry >> Ernst. >> >> The distinctive aspect is that it tries to suggest the way MAC and >> IPv6 multicast is used on an IPv6-over-80211-OCB links. >> >> Alex >> >> >> -------- Message transfr -------- Sujet : I-D Action: >> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 >> 08:55:47 -0700 De : internet-drafts@ietf.org Rpondre : >> internet-drafts@ietf.org Pour : i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Transmission of IPv6 Packets over IEEE 802.11-OCB >> Networks Authors : Thierry Ernst Alexandre Petrescu >> Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages >> : 5 Date : 2016-07-08 >> >> Abstract: In this document the mapping of multicast IPv6 addresses >> to MAC addresses of 802.11-OCB is proposed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >> >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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/ >> >> _______________________________________________ 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 >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Mon Jul 11 03:43:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6905B127078 for ; Mon, 11 Jul 2016 03:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 Q_yUenlW84wU for ; Mon, 11 Jul 2016 03:43:34 -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 41EC812B044 for ; Mon, 11 Jul 2016 03:43:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6BAhPs9011812; Mon, 11 Jul 2016 12:43:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9EEB200CFB; Mon, 11 Jul 2016 12:43:25 +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 A9BCF20A08B; Mon, 11 Jul 2016 12:43:25 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6BAhPU7030163; Mon, 11 Jul 2016 12:43:25 +0200 To: Joe Touch , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> From: Alexandre Petrescu Message-ID: Date: Mon, 11 Jul 2016 12:43:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <577FFBA2.6030205@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:43:37 -0000 Le 08/07/2016 à 21:14, Joe Touch a écrit : > > > On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: >> ... >> I suppose it's not a coincidence that IEEE and IETF both call these >> addresses "all-nodes" but I have no trace of that. > > Let's get down to the authorities: > > IANA: > http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml > IANA does assign addresses starting with 01-00-5E for link multicast. > IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for > IPv6 multicast. I wonder what IETF protocol 01-00-5E has been assigned for. It seems IANA has more authority over this address, and it is more likely to be unique. As such maybe it is better to use it for IPv6-over-foo documents, rather than 33-33-. > IEEE: > http://standards.ieee.org/develop/regauth/grpmac/public.html > 01-80-C2-00-00-1B = all multicast-capable endsystems > 01-80-C2-00-00-1D = all multicast-capable intermediate systems > 01-80-C2-00-00-00..0F = assigned for 802.1Q > *** this appears to be where you might request an address > for your protocol *** Right. So this would be a 4th alternative for a multicast address for IPv6-over-80211OCB. Summarizing: - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA global) - 01-80-C2- prefix (IEEE allocation) > You also argued about "all 1's" not being Ethernet broadcast. It is > defined as exactly that on page 32 here: > www.ieee802.org/secmail/pdfocSP2xXA6d.pdf Thanks for the reference. Yes, it's there. > However, it's also defined as "never assigned" as NULL or unintialized here: > https://standards.*ieee*.org/develop/.../eui48.pdf >> I am trying to identify the precise IEEE authoritative reference that >> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. > > Same here - still looking, but I see only IANA's assertion of ownership > based on an RFC. Nothing at the IEEE yet. If IEEE has no text about this 33-33- prefix then I think there can be problems. >>> But the correct corresponding "all nodes" might be appropriate: >>> ff02::1 >> >> Yes, this IP "all-nodes" is very appropriate, I agree. >> >>>> - 33:33:00:00:00:01 - like IPv6-over-WiFi does >>> >>> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, >>> but I don't see anywhere where any of these addresses are assigned >>> (or assignable) to a single protocol. >> >> Well, there are multiple things here. >> >> The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP >> addresses). > Yes - I was intending to say "the 33:33::" addresses are used within > IPv6 multicast as per RFC2464... > >> Curiously enough, they are defined in an IETF RFC (RFC 2464 >> "IPv6-over-Ethernet" lists hexa "3333"). I can not find them defined at >> IEEE even though there is an IEEE place listing IEEE MAC multicast >> addresses: >> https://standards.ieee.org/develop/regauth/grpmac/public.html >> >> It is curious because IETF should not define MAC address formats or >> contents, right? > > Agreed - I think there are a few of us looking, but if anyone knows, > please speak up! > >> As an additional curiosity, the well-known 'cavebear' registry lists >> 33-33 as an Ethernet Multicast Address: >> http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html >> as an "IPv6 Neighbor Discovery" explanation. >> >> It is curious because this "33-33-" MAC address is used below other IPv6 >> protocols like DHCPv6, not only Neighbor Discovery. > Yes. > >> >> To correct all these, the following can be proposed: >> >> - IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to >> mean a 6-byte MAC address, and not an IPv6 address, despite the >> column use. > > Agreed. I think you meant "colon" rather than "column", though. YEs. This makes think writing an I-D title "IETF notation of MAC addresses" could make sense to avoid confusion. Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely used packet analyzer says "33:33:00:00:00:01". Common dialogue with the IPv6-versed tends to say "33:33::1". This may lead to confusion. >> - IEEE tells where is this "3333" address defined so we can see it >> publicly. > > Please! > >> - wikipedia stops writing wrong articles. > > Well, it is Wikipedia - if it's incorrect, we can change it... > >> - RFC2464 gets update to mean it also works on WiFi not only on >> Ethernet. > > I don't understand this at all. I thought WiFi was just a variety > wireless media layers over which 802 frames (colloquially known as > "ethernet") were sent. In principle it is that way. For introduction I believe there may be some detail that RFC2464 overlooks. I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, ethertype] - does not get sent over the 802.11 media. I suspect there is a local adaptation layer in each WiFi computer which converts bidirectionaly between an Ethernet II header [dst, src, ethertype] and 802.11 frames: for each Ethernet II header there is a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an LLC header. And it's this tuple that gets sent over the 802.11 media, not the Ethernet II header. The difference can be seen between captures in normal and monitor mode. RFC2464 is concerned only of that Ethernet II header captured in normal mode, even though it does not get sent over the air. However, there can be some detail lost when considering only the Ethernet II header. For example, if the 802.11 QoS Data Header is employed then some of its fields are invisible by the RFC2464 mapping process. However, these fields could be useful for the Traffic Class or Flow Label fields of the IPv6 header. In some vehicular network trials the 802.11 QoS Data Header is used below a WSMP protocol (a network layer-free app-layer protocol). In these trials, if one considers the use of IPv6 below WSMP, then one has to consider the need of distinctive flows of IP datagrams (e.g. emergency). It is also worth mentioning that the discrepancy between what the Ethernet II header has to offer and what many media need, can be seen not only on this 802.11-OCB mode for vehicles, but also by IoT documents at IETF describing adaptation layers for media like 802.15.4, lowpan, and more. For these reasons I think 802.11 too deserves its own IPv6-over-80211 document at IETF. >> - cavebear tells "33" to mean all IPv6 not only ND. >> >> Unfortunately none of these is my goals here. I am trying to just >> identify the right MAC multicast address for 802.11p below IPv6 (or >> IPv6-over-80211p if you wish). >> >>>> - 01-80-C2-00-00-1B - like LLDP does - request a new one? >>>> >>>>>> Remark (1) I have never seen this 48bit IEEE address in >>>>>> vehicular network trials and (2) it is not a >>>>>> "33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6 >>>>>> vehicular prototypes. >>>>>> >>>>>> In this context, I believe it can make sense to think of >>>>>> requesting IANA (rather than IEEE) for an allocation of a >>>>>> 112bit Group ID named "All 802.11-OCB interfaces"; >>>>> >>>>> There are no other IPv6 multicast addresses that group nodes by >>>>> link type. This sort of request doesn't make sense to me at all; >>>>> it's a bit backwards. >>>> >>>> I agree there are no other IPv6 multicast addresses that group the >>>> nodes by link type (you dont have an address called "all Ethernet >>>> nodes" for example). However, 802.11p is not really a particular >>>> link type - it is WiFi. >>> >>> To IP, WiFi is a link type. Granted, it may have a variety of >>> physical layers underneath and include various subsets of >>> extensions, but WiFi is not a network-layer protocol or higher-layer >>> (e.g., app-layer) service, e.g., as routing or DHCP are. >> >> I agree. >> >>>> Moreover, we are not concerned here with a request to IEEE. An >>>> IPv6-over-foo I-D describes _mappings_, i.e. what number gets >>>> mapped from IETF to IEEE identifier. >>> >>> It's exactly because you'd need this assigned by IETF that it makes >>> no sense. >> >> But an IETF stds track document should tell which is the MAC multicast >> address on which to map some IP address. And it should be only one, and >> agreed by IEEE. > I think that's step 2; step 1 is getting the address from the IEEE. > >> >>>> As such, it is reasonable to request at IETF a 112bit Group >>>> Identifier, parts of which may get mapped to some bytes of a group >>>> multicast address. >>> >>> In a general sense, yes, IANA would be the right party to assign a >>> group ID here, but that assumes that a group ID should be allocated >>> to a link type. There is no precedent for that. >> >> Then we should go with "all-nodes" address (not all-OCB-nodes). But we >> need to know whether that is "33" MAC prefix or some other prefix. > > Agreed. >> >> And the fact that RFC2464 says it's "33" prefix it's not sufficient - >> RFC2464 is for Ethernet (wired) not for WiFi. 802.11OCB (aka 802.11p) >> is a kind of WiFi not a kind of Ethernet. >> >> Unless maybe IEEE tells we should use this "33" MAC prefix. >> >>>> The overall goal is that people stop using the MAC broadcast >>>> address on 802.11p (all 1s) and start using a single MAC group >>>> address (not various). >>> >>> Although I understand your goal, I don't see why a separate *IP* >>> multicast group is the right way to solve it. >> >> In order to get rid of all the above doubts (wikipedia, cavebear, IEEE >> and RFC2464 seem each contradictory to each other) and start afresh. >> >> Just get a new allocation fresh only for vehicular communications, and >> advertise that in an RFC. Not care about fixing old problems like wired >> Ethernet and wikipedia. > Although I agree it isn't useful to solve old problems, "all nodes" IP > multicast already exists. If that's what you should be using, then use it. > > I still see absolutely no reason for "vehicular" assignment; assignments > are for protocols, not places where you deploy them. I note that. >>> If you want to reach all nodes, you already can on IPv6 using >>> ff02::1 >> >> YEs. >> >>> If you want to reach all 802.11p nodes, you need to define an >>> IP-visible service that selects for that property, and ask for a >>> group ID *for that service*, IMO. >> >> In a sense yes, but the 'service' layer is much higher than a networking >> layer which would send a Router Advertisement. > > You're either sending a link-layer routing protocol message (e.g., like > a IS-IS or Ethernet BPDUs) or you're sending an Internet routing > protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as > "service" layers (i.e., "applications"), i.e., inside UDP or TCP inside IP. > > Given you want to reach all 802.11p nodes, it seems like you should want > an MAC multicast address - but not an IP multicast address. IP multicast > is needed only to for IP-layer routing, not for link layer. YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: re-use an existing one? If yes which one? Allocate a new one? If yes where to ask? For IP multicast address, let's see a bit later. Alex > > Joe > > > From nobody Mon Jul 11 03:48:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520F112D0A7 for ; Mon, 11 Jul 2016 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 YU-yzQtf2Me5 for ; Mon, 11 Jul 2016 03:48:03 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 2D05412B044 for ; Mon, 11 Jul 2016 03:48:03 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q83so32939775iod.1 for ; Mon, 11 Jul 2016 03:48:03 -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; bh=orkLjL2SfdxFM8xs7401NtfDdmTURM9GVy7Habo7ib4=; b=LHQnzcaCe85jbd0798Stn3UOzQeukDYS0IcZYGHhZSiB5u1US8Vg/7E0Iz9fMFRHt2 x8jHPkQBo1t9aa/+d7HU8fxnGmIQSefhdh3UNRn/pCqaTdGkud81I5dX2jlofITLL1C/ iPHTHMY011fUwLernndAH3Aieg0BAgfTq+m8df6d51GUK8C0Hvsgk1evWHNz/Mua7mzB PI5Jix8mCOKluHGIGgqaeUcs3zhsM3U2cD9OvW801TvEzW5qlI26TTCaDMm46Sk6/5qf 6V5BxNighmmn26bsazoaTtX70V7XjHKOzxpFrF21CrTH2YHSdjFit/6IqcOqgFo7vKIa kfdA== 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; bh=orkLjL2SfdxFM8xs7401NtfDdmTURM9GVy7Habo7ib4=; b=NErDhNiK5K/h9ggVqaId90p9P1rah/AiwRU2WiWpoYWwquPsp6jYttR4MFInvYJOnp LmR5sAr5QLkW1Z4bHZFJAfsSQlHR4iwGCzX1cMwg7Gp5ETXEZ99yegBwwHOPvHNqb/Ms Rcu8ba9R2W4l/TmoCFTiRTrtKd61LBXFvoxsIjLIuqa6FOODArmX+209IFjiXKTwZdU1 pvo03hIf5wCZQ3HHTQR9iRbaQ1jUcNXHfg+zMVnNeGWsR+mGWeZpNIh2HvhjZATcN8Rd AuTokEiHS+7jaE4DbOSUe454g0sQl5z3Pc/BjGxssjOZ48FHSwXSjUyqsfycR7vLz0FZ qk3A== X-Gm-Message-State: ALyK8tLE/GHAgEJYLQqJ28HQV34TBJBG1MwZAoS353QSKvsfG831Y/38IkNElpkl2CPr/WrsgIaes77WL+3hcqsh X-Received: by 10.107.39.79 with SMTP id n76mr19481818ion.145.1468234082452; Mon, 11 Jul 2016 03:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.105 with HTTP; Mon, 11 Jul 2016 03:47:42 -0700 (PDT) In-Reply-To: <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> From: Erik Kline Date: Mon, 11 Jul 2016 19:47:42 +0900 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:48:04 -0000 > But in Out-of-a-Context-of-a-BSSID mode there are no Association > operations; thus it's hard to say who is within link scope, and what > would an "all-nodes" multicast address mean when there is no scope and > no SSID. Can "all nodes" be anything other than "best effort" in these networks? Akin to "everyone within the sound of my voice and this particular moment"? From nobody Mon Jul 11 04:49:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6B812D113 for ; Mon, 11 Jul 2016 04:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 p_G-YZvDDmtg for ; Mon, 11 Jul 2016 04:49:52 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27E912D0DD for ; Mon, 11 Jul 2016 04:49:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6BBnh4w012257; Mon, 11 Jul 2016 13:49:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6ED3920A088; Mon, 11 Jul 2016 13:49:43 +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 5553A209E03; Mon, 11 Jul 2016 13:49:43 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6BBnht9008219; Mon, 11 Jul 2016 13:49:43 +0200 To: Erik Kline References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> From: Alexandre Petrescu Message-ID: <62bf60fa-05e8-0c78-2e36-52c722b6e66b@gmail.com> Date: Mon, 11 Jul 2016 13:49:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 11:49:53 -0000 Le 11/07/2016 à 12:47, Erik Kline a écrit : >> But in Out-of-a-Context-of-a-BSSID mode there are no Association >> operations; thus it's hard to say who is within link scope, and >> what would an "all-nodes" multicast address mean when there is no >> scope and no SSID. > > Can "all nodes" be anything other than "best effort" in these > networks? Akin to "everyone within the sound of my voice and this > particular moment"? I think there could be a scope within an approximate radio range around an emitter, during a precise time. But such scope would not be named like the current "link" scope valid in a precise ESSID association, during an approximate time length between association and disassociation. Then the existing "all-nodes" id could live within this yet-unnamed scope as it lives within link-scope, or site-scope, or global-scope. Alex > From nobody Mon Jul 11 08:06:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB712D1AF for ; Mon, 11 Jul 2016 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4AEWmnDov9Et for ; Mon, 11 Jul 2016 08:06:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C9F12D08E for ; Mon, 11 Jul 2016 08:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4332; q=dns/txt; s=iport; t=1468249598; x=1469459198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oL4lfsxgTEaorj/mC5AkmC+AlY3tbWXJO31NgoKp26E=; b=TisGh1ApUgPiCOAVzraOBZm2PTRFbCh0+djUKgCScG/7W6qSvZqrjqeG s51EkrmbMljMQwdRi04wczFJnI06q6a8NJOtnbwBxX5Ak82TAmLdPZaXq ucUkAl9uC6mDAerq3J13fcaKIY3MA5Lku78ExEinf3NwMLu2qk+MpEn+A o=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAgC2tYNX/4UNJK1cgz5WfAasdowWg?= =?us-ascii?q?XoihXYCgSo4FAEBAQEBAQFlJ4RcAQEEAQEBCmILBQsCAQgYLiEGCyUCBA4FCQW?= =?us-ascii?q?ICAMPCA67EQ2EFAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OiB+CVYJDgVARAU4Mg?= =?us-ascii?q?m6CLwWYZDQBgzKBbG6GL4IWgWpOhAqIaogbF4dcAR42ggkcgUxuAYgJNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,347,1464652800"; d="asc'?scan'208";a="124812799" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 15:06:22 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6BF6MG2009623 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 15:06:22 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 10:06:21 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 10:06:21 -0500 From: "Fred Baker (fred)" To: Alexandre Petrescu Thread-Topic: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Thread-Index: AQHR24XIYHZfzI+xwkSR8v9zY62S+Q== Date: Mon, 11 Jul 2016 15:06:21 +0000 Message-ID: <28BAEA6E-D837-4CDE-A54E-8775CBD2C23C@cisco.com> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> In-Reply-To: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_36431256-CDAB-4C34-A6E9-B5A685150D7C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:06:40 -0000 --Apple-Mail=_36431256-CDAB-4C34-A6E9-B5A685150D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK, the chairs are looking for interest from the operators. Speak up, = folks! > On Jul 8, 2016, at 12:38 PM, Alexandre Petrescu = wrote: >=20 > Hi, >=20 > During our discussion of IPv6 and MAC address multicast I laid down a = few of comment results of the discussion on this email list, on this = Internet Draft referred to below. >=20 > In my oppinion there is obviously a need to clarify how and what MAC = multicast addresses to use below IPv6 in IPv6-over-802.11OCB (Out of the = Context of BSSID, aka 802.11p). >=20 > Alex >=20 > -------- Message transf=E9r=E9 -------- > Sujet : [its] Fwd: I-D Action: = draft-ernst-its-ipv6-over-80211ocb-00.txt > Date : Fri, 8 Jul 2016 21:33:53 +0200 > De : Alexandre Petrescu > Pour : its@ietf.org >=20 > Hi, >=20 > I have just submitted this Internet Draft I co-author with Thierry = Ernst. >=20 > The distinctive aspect is that it tries to suggest the way MAC and = IPv6 multicast is used on an IPv6-over-80211-OCB links. >=20 > Alex >=20 >=20 > -------- Message transf=E9r=E9 -------- > Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt > Date : Fri, 8 Jul 2016 08:55:47 -0700 > De : internet-drafts@ietf.org > R=E9pondre =E0 : internet-drafts@ietf.org > Pour : i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Transmission of IPv6 Packets over IEEE = 802.11-OCB Networks > Authors : Thierry Ernst > Alexandre Petrescu > Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt > Pages : 5 > Date : 2016-07-08 >=20 > Abstract: > In this document the mapping of multicast IPv6 addresses to MAC > addresses of 802.11-OCB is proposed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00 >=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 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_36431256-CDAB-4C34-A6E9-B5A685150D7C 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 iQIVAwUBV4O160ayAOS/EQ8MAQLhog//Zz/Xoe/+Lu7vh+yg2HSSXTCVfLhb+jyJ NVX+uZYH3N1gSzto3m8SK0UpuOG8Bt1sW7xCGShuDk5W2en5i0khk2pupDd2aUdy DzwcqKi85EgrjXOM63THibVC2zO/6vFniudIIVpcTVK4G88EgU90fTZ9Ke/7sWk9 mdf8ua6oWcF2lfknvC7B9A4UItiNcepWTs8p7D0TXTur1Ja59W9vuR6nI+T43Ezt Y8sbs48YHVS2xi6/5dHi47I6mmUMOuqmEzQ1sBJvnLrOX72QgTQqemEmPFx66UHC /hkLF5vXFYPegXj66ofkbV6yc1d2k0BW8kdpxilUyYsHpGtYRacqf72TcfYfHxMU DRVtVN07CLHV4sOuy8TBzWeM1JCQkxrz3/CD+IVvHArLVTYTMjE/eRCEUorog2rc BBDBIS4DjkQOz1UFf7RfolD+1jFnFh2/0cm8fO4rLeRGEgvq+kE66HVvkWnC/zCJ OHew2GuA6T9KO+3U4ptE33ZC6QqdxhgrFqRrWBA4txIEGbpfphBUOevY9blK9bnO Cr3EoPH/9ZQ7JwVF2eiwx+7FT9JavyNaN+p7V7Ne6lc0XSOhXHs/yYFo6KQcDg5Z ouX/b3R5BMaJvr2znwvOotDSOrAHcOkAfkMzb9sXXd8vTSs3rze+/aPGEDkXi8Uz Obf2bjMdaXI= =Z7WB -----END PGP SIGNATURE----- --Apple-Mail=_36431256-CDAB-4C34-A6E9-B5A685150D7C-- From nobody Mon Jul 11 08:15:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFA212D51D for ; Mon, 11 Jul 2016 08:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 s57vCa4IwoAA for ; Mon, 11 Jul 2016 08:15:08 -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 E5F5412D1C1 for ; Mon, 11 Jul 2016 08:15:07 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E5797626E1 for ; Mon, 11 Jul 2016 17:15:05 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A162C61B3A; Mon, 11 Jul 2016 17:15:05 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8D40310B9F; Mon, 11 Jul 2016 17:15:05 +0200 (CEST) Date: Mon, 11 Jul 2016 17:15:05 +0200 From: Gert Doering To: "Fred Baker (fred)" Message-ID: <20160711151505.GQ79185@Space.Net> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <28BAEA6E-D837-4CDE-A54E-8775CBD2C23C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9sEofKxuIdkrjmav" Content-Disposition: inline In-Reply-To: <28BAEA6E-D837-4CDE-A54E-8775CBD2C23C@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:15:10 -0000 --9sEofKxuIdkrjmav Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 11, 2016 at 03:06:21PM +0000, Fred Baker (fred) wrote: > OK, the chairs are looking for interest from the operators. Speak up, fol= ks! As far as I can see, IPv6-to-MAC mapping is defined well enough. Reading the discussion (not having looked into the draft yet, the discussion was weird enough), I see severe disconnection between reality and this=20 discussion. A document that clarifies the relationship between IEEE and IANA/IETF regarding MAC address assignment, having pointers to the relevant documents might be a better use of our time. 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 --9sEofKxuIdkrjmav Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXg7f2AAoJEN9WwGXkzn/FAcYP/RaTEumqbOY/+swcGDLWXgup QCoIm0XKj/XNbS1EdDE1F3Bq/ajsFXnOYZWyRj80xFILYNBhMESQ502IkfdqLDSC n6ol2yEdfYoMieWF4Ck5yun0hkuR6BIbnWFmxyOWzEZf9N6sQbdX747JjwH63H2P Jvgc68ozNJSXeERlga5tf63gRFhEF61Jr34Gxfb7tuXeYzYVrqXH+wr3BcmZ2Iq3 vkpa/t8vFixEc6Oc+hdSnxM24a91Twhvq8nr4mfV+x1fYhSt8xEiU3nb4pxumlSp GjP2XoDbWu9f0hSwf8zg8biE0nVgS4pQuAeJS5rawOcjDnSJzSyersGBOMW0dOYv dagJaEXp4E6yjgJaxo0Sng9d/Xka32F2vPpRUqwi0+b7xCxd9hbpZwA0CR7DryU2 JtGJ8Q00u/cMxIj2hp0zKxjU9iSwRR+5YnokbVgtt1rnMGnm+BitmvQcv0MtOaPl mHBgSXFsqqIeF41j/Xg2UqX/a3SVeds9PwZ1pIAKM+SExVbAFctrdSx7NMrmQbPV Tqyoc37McvrXrctglEIVLxdmnmP52wEZhuHhTkprXs272iodqa1FP4BoHhQZN6ma RqXYqNV5aTU87Kv/qKDYSpOUB0U+gaXMkA10S0elN/995W8e6or/lI1YfnAbd808 uhpIdctjiog4iXc4D1kn =rK9l -----END PGP SIGNATURE----- --9sEofKxuIdkrjmav-- From nobody Mon Jul 11 08:21:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225A612D581 for ; Mon, 11 Jul 2016 08:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5Zu2xTYHGNHh for ; Mon, 11 Jul 2016 08:21:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DAB12D580 for ; Mon, 11 Jul 2016 08:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1488; q=dns/txt; s=iport; t=1468250489; x=1469460089; h=from:to:subject:date:message-id:mime-version; bh=k9j/iAgopeE0od6bKROE343tgL6XBIcOzPtIhVoJd/4=; b=m+OCiU7UgG3E14Yx8grhHGQCpW94ed+dbeklaOUfWW3QlMGrMLP5LuOA ni2TTvojatdKk0fQXWbayx4CHEZ0okE+n9UVpxkfPMes59w695sAyD2AB plxBzceNbZWORZ+AUX0qdnwXkiqWsWE/R2FLYCMELAbyE2U3TfSyDx7dr 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSBgD3uINX/40NJK1cgz5WgQK2aIQJI?= =?us-ascii?q?ociOxEBAQEBAQEBZRwLhGOBCwGBACcEIYgiDqBknjIBAQEBBgEBAQEBAQEBEQk?= =?us-ascii?q?FiB8IijqCLwWZGAGDMoFsiTOBVAEVhFiIapAOATQgg3GJLn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,347,1464652800"; d="asc'?scan'208";a="294903241" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 15:21:29 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6BFLTdh000485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jul 2016 15:21:29 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 10:21:28 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 10:21:28 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: IETF 96 Agenda Thread-Index: AQHR24fl8I49WMQbqk6QJEaOxkoDng== Date: Mon, 11 Jul 2016 15:21:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_4FFB77F4-8848-4665-9440-D4EE9F29E45C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] IETF 96 Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:21:31 -0000 --Apple-Mail=_4FFB77F4-8848-4665-9440-D4EE9F29E45C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have posted a preliminary agenda at = https://www.ietf.org/proceedings/96/agenda/agenda-96-v6ops, assuming = interest in Alexandre's draft. Comments please? --Apple-Mail=_4FFB77F4-8848-4665-9440-D4EE9F29E45C 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 iQIVAwUBV4O5d0ayAOS/EQ8MAQLHwg/9FmNCpdp6DRTugGY4qNUNzwrV7VFc2ZOS Sp9QaZZ7lfnwVWeIRsEkNJ76QH0HSqsYVVF9lKyzotDtMmI43zadIvXD4RY63UAK a3NQSQjRLUuydN0mb1W4sGZSkOaPvkVK8DB1kCLIAzUioQ7iJ+zZs6q1E4RajM8/ v8UJ/oHvC7riUllU+r+PDfEJj1ReeE9D3ez4AD5DOMdejcZh8oNvEApACRjHVLxU d87ofVHIxkzbYAMLlwEQtYV/9TqQi88VLc2UPsZYd8wx6Bl8pMhcER/3SaIoKUsQ v7R0JFQwg0N0iViZAIAJ1/O+OPN76kE/fYWjb/4yZ6e8zWDXqB2TB9B9DaGwZkU6 QvV71ioeLvoSbImuw542gstVIKhbgKYxMYw78vZ5fNgupxKLexeMJHPjINvY0nMV 92YlUA2TJoCpaobpvSwe5Dmis4DQZhgNUT3FokKKbHwTVCd9LvVFU4Z9DDOgCxS+ 5j5ODP2tsWwKCFO9oYIeJb1FqZu9M/IcfqXqG5Z/M/KcEDLDuhuMOTSNOw8eRuKj CZUIUMowhitSWJ5/tKeZN/QmXlv3o2yUWkt+SIaLsaLuon3QjHaQgXx4GlvJGMG2 x7SAW2eH96Agw78WqqNh0bCg711H0SSGve71HMxr/gwbkw9XrKTrv3ZH1V5mP4wr A0U3tDNoK8Y= =exF6 -----END PGP SIGNATURE----- --Apple-Mail=_4FFB77F4-8848-4665-9440-D4EE9F29E45C-- From nobody Mon Jul 11 10:34:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4D12D1E6 for ; Mon, 11 Jul 2016 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vUZ-O8B0_MKK for ; Mon, 11 Jul 2016 10:34:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id F16F412D0F6 for ; Mon, 11 Jul 2016 10:34:17 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6BHXEdW008286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jul 2016 10:33:14 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_4BB75D9B-5A89-45D6-8F57-2C706905C220" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Mon, 11 Jul 2016 10:33:13 -0700 Message-Id: <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 11 Jul 2016 10:33:14 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:34:21 -0000 --Apple-Mail=_4BB75D9B-5A89-45D6-8F57-2C706905C220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 11, 2016, at 03:43 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 08/07/2016 =C3=A0 21:14, Joe Touch a =C3=A9crit : >>=20 >>=20 >> On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: >>> ... >>> I suppose it's not a coincidence that IEEE and IETF both call these >>> addresses "all-nodes" but I have no trace of that. >>=20 >> Let's get down to the authorities: >>=20 >> IANA: >> = http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml >> IANA does assign addresses starting with 01-00-5E for link = multicast. >> IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF = for >> IPv6 multicast. >=20 > I wonder what IETF protocol 01-00-5E has been assigned for. >=20 > It seems IANA has more authority over this address, and it is more = likely to be unique. As such maybe it is better to use it for = IPv6-over-foo documents, rather than 33-33-. 33-33 is a locally administered address. It is reasonable to presume = that any local admin who wants IPv6 to work on their network will not = conflict with 33-33 at this point. Remember, MAC addresses are replaced at each routing hop, so they are = only relevant on the local link. The full IANA MAC registry is here: http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml Note that there are IANA assignments under 00-00-5E for non-multicast = purposes as well. The procedure for updating that registry is here: https://tools.ietf.org/html/rfc7042 >=20 >> IEEE: >> http://standards.ieee.org/develop/regauth/grpmac/public.html = >> 01-80-C2-00-00-1B =3D all multicast-capable endsystems >> 01-80-C2-00-00-1D =3D all multicast-capable intermediate = systems >> 01-80-C2-00-00-00..0F =3D assigned for 802.1Q >> *** this appears to be where you might request an address >> for your protocol *** >=20 > Right. I think using this range would be ill advised for this purpose. >=20 > So this would be a 4th alternative for a multicast address for = IPv6-over-80211OCB. Summarizing: >=20 > - all 1s > - 33-33- prefix (IANA local) Locally administered means that it is up to the owner of each link to = decide if they want to use this or not. IANA has suggested and there=E2=80=99s lots of code deployed that uses = 33-33 for IPv6 multicast. As such, any local administrator that wants = IPv6 to work on their network should probably respect this or expect a = fair amount of pain. I=E2=80=99d say that makes 33-33 fairly safe to use for any IPv6 = multicast need. > - 01-00-5E- prefix (IANA global) It appears that IANA is unlikely to use this for IPv6 and I suspect that = you will have a hard time getting agreement to allocate anything special = here for your intent. > - 01-80-C2- prefix (IEEE allocation) Since your protocol is an application sitting on top of TCP or UDP or = something else on top of IPv6, I think you are unlikely to get much = traction here as well. Even if you do, I think it=E2=80=99s an abuse of = the addresses. >> However, it's also defined as "never assigned" as NULL or = unintialized here: >> https://standards.*ieee*.org/develop/.../eui48.pdf = >>> I am trying to identify the precise IEEE authoritative reference = that >>> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. >>=20 >> Same here - still looking, but I see only IANA's assertion of = ownership >> based on an RFC. Nothing at the IEEE yet. >=20 > If IEEE has no text about this 33-33- prefix then I think there can be = problems. Nope=E2=80=A6 It=E2=80=99s locally administered meaning each segment = owner can do what they like. If they like IPv6, they=E2=80=99ll leave = 33-33 alone for IPv6 multicast. The worst that can happen is you end up with some stations receiving = packets they don=E2=80=99t want. > I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, = ethertype] - does not get sent over the 802.11 media. I suspect there = is a local adaptation layer in each WiFi computer which converts = bidirectionaly between an Ethernet II header [dst, src, ethertype] and = 802.11 frames: for each Ethernet II header there is a corresponding = tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an = LLC header. And it's this tuple that gets sent over the 802.11 media, = not the Ethernet II header. My understanding is that all happens in the hardware, so as far as all = of the system software is concerned, it=E2=80=99s sending and receiving = 802.3 frames to/from the interface. > The difference can be seen between captures in normal and monitor = mode. >=20 > RFC2464 is concerned only of that Ethernet II header captured in = normal mode, even though it does not get sent over the air. >=20 > However, there can be some detail lost when considering only the = Ethernet II header. For example, if the 802.11 QoS Data Header is = employed then some of its fields are invisible by the RFC2464 mapping = process. However, these fields could be useful for the Traffic Class or = Flow Label fields of the IPv6 header. In general that would be a layering violation anyway. > In some vehicular network trials the 802.11 QoS Data Header is used = below a WSMP protocol (a network layer-free app-layer protocol). In = these trials, if one considers the use of IPv6 below WSMP, then one has = to consider the need of distinctive flows of IP datagrams (e.g. = emergency). It=E2=80=99s unclear what you mean by =E2=80=9Cdistinctive flows of IP = datagrams=E2=80=9D. > It is also worth mentioning that the discrepancy between what the = Ethernet II header has to offer and what many media need, can be seen = not only on this 802.11-OCB mode for vehicles, but also by IoT documents = at IETF describing adaptation layers for media like 802.15.4, lowpan, = and more. Not everything is an 802.3 network. Non-802.3 networks require different = adaptation layers. > For these reasons I think 802.11 too deserves its own IPv6-over-80211 = document at IETF. I=E2=80=99m not completely convinced of this as so far, you seem to be = insisting on an approach of adapting IPv6 and 802.3 multicast to your = idea of how things should work rather than adapting your application to = the idea of how things actually work. I haven=E2=80=99t seen anything in any of your posts that leads me to = believe that the latter would not be the better approach. >=20 >>> - cavebear tells "33" to mean all IPv6 not only ND. >>>=20 >>> Unfortunately none of these is my goals here. I am trying to just >>> identify the right MAC multicast address for 802.11p below IPv6 (or >>> IPv6-over-80211p if you wish). The right solution is: 1. Use the correct IPv6 multicast group ID. If you want all nodes on link, then that would be = ff02::1. 2. Map that multicast group ID onto the IPv6 multicast MAC = range. Assuming ff02::1 as above, then this would be = 33-33-0-0-0-1 >>>=20 >>> But an IETF stds track document should tell which is the MAC = multicast >>> address on which to map some IP address. And it should be only one, = and >>> agreed by IEEE. >> I think that's step 2; step 1 is getting the address from the IEEE. Since IPv6 multicast uses a well defined set of =E2=80=9Clocally = administered=E2=80=9D MAC addresses, there=E2=80=99s no need to involve IEEE. You can debate the validity of using 33-33 instead of getting an OUI = block as much as you want, but there=E2=80=99s a lot of running code out there = that is already using 33-33 without any issues. As such, I think that=E2=80=99s = a decision we just have to live with at this point. I certainly think that picking alternatives piecemeal protocol by = protocol or worse application by application is not a good approach. >>> Then we should go with "all-nodes" address (not all-OCB-nodes). But = we >>> need to know whether that is "33" MAC prefix or some other prefix. >>=20 >> Agreed. If it is an IPv6 datagram, then it should be 33-33. If it is an IPv4 = datagram, then it should probably be ff-ff-ff-ff-ff-ff. If it=E2=80=99s something = else, then the IETF doesn=E2=80=99t really care and isn=E2=80=99t involved. >> Given you want to reach all 802.11p nodes, it seems like you should = want >> an MAC multicast address - but not an IP multicast address. IP = multicast >> is needed only to for IP-layer routing, not for link layer. That=E2=80=99s not entirely true. All nodes on link (for example, = ff02::1) is definitely a link-layer communication for IPv6 that should not be routed at the IP layer. There are reasons for interface and link scoped IPv6 multicast = addresses. Of course, if you want your packets routed, then you can use the same = group IDs with different scopes. > YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: = re-use an existing one? If yes which one? Allocate a new one? If yes = where to ask? >=20 > For IP multicast address, let's see a bit later. All of this is asked and answered. If your target is described already by a well known IPv6 multicast = address (it is, All-nodes on link, ff02::1) then use the appropriate group ID (::1 in this case) and the appropriate scope = (Link =3D 2). The flags are 0 because (Reserved bit always 0, RP not = embedded =3D 0, Group not based on prefix =3D 0, Group not transiet =3D = 0). So: Multicast (ff), Flags (0) Scope (2) and Group ID (1) come = together to form Address (ff02::1). Once you have the IPv6 multicast address, then you simply map the low = order 32-bits onto the MAC prefix (33-33) and you get (33-33-0-0-0-1). So for your stated purpose, it seems to me the best alternative is = destination: ff02::1 @ 33-33-0-0-0-1. There is nothing special here. Owen --Apple-Mail=_4BB75D9B-5A89-45D6-8F57-2C706905C220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 11, 2016, at 03:43 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 08/07/2016 =C3=A0 21:14, Joe Touch a = =C3=A9crit :


On 7/8/2016 6:52 AM, Alexandre Petrescu = wrote:
...
I suppose it's not a coincidence that IEEE and IETF both call = these
addresses "all-nodes" but I have no trace of = that.

Let's get down to the = authorities:

IANA:
http://www.iana.org/assignments/ethernet-numbers/ethernet-numbe= rs.xhtml
   IANA does assign addresses = starting with 01-00-5E for link multicast.
   IANA recognizes the use of 3-33-00-00-00-00 = to 33-33-FF-FF-FF-FF for
IPv6 multicast.

I wonder what IETF protocol 01-00-5E has been = assigned for.

It seems IANA has more = authority over this address, and it is more likely to be unique. =  As such maybe it is better to use it for IPv6-over-foo documents, = rather than 33-33-.

33-33 is a = locally administered address. It is reasonable to presume that any local = admin who wants IPv6 to work on their network will not conflict with = 33-33 at this point.

Remember, MAC = addresses are replaced at each routing hop, so they are only relevant on = the local link.

The full IANA MAC = registry is here:


Note that there are = IANA assignments under 00-00-5E for non-multicast purposes as = well.


The = procedure for updating that registry is here:






Since your = protocol is an application sitting on top of TCP or UDP or something = else on top of IPv6, I think you are unlikely to get much traction here = as well. Even if you do, I think it=E2=80=99s an abuse of the = addresses.

However, it's also defined as "never assigned" as NULL or = unintialized here:
https://standards.*ieee*.org/develop/.../eui48.pdf
I am trying to identify = the precise IEEE authoritative reference that
says = "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant.

Same here - still looking, but I = see only IANA's assertion of ownership
based on an RFC. = Nothing at the IEEE yet.

If IEEE has no text about = this 33-33- prefix then I think there can be problems.

Nope=E2=80=A6 It=E2=80=99s locally administered meaning = each segment owner can do what they like. If they like IPv6, they=E2=80=99= ll leave 33-33 alone for IPv6 multicast.

The worst that can happen is you end up with some = stations receiving packets they don=E2=80=99t want.

I suspect the 802.3 frame - e.g. an Ethernet II = Header [dst, src, ethertype] - does not get sent over the 802.11 media. =  I suspect there is a local adaptation layer in each WiFi computer = which converts bidirectionaly between an Ethernet II header [dst, src, = ethertype] and 802.11 frames: for each Ethernet II header there is a = corresponding tuple made of a 802.11 Data Header (or 802.11 QoS Data = Header) plus an LLC header.  And it's this tuple that gets sent = over the 802.11 media, not the Ethernet II header.

My understanding is that all happens in the hardware, = so as far as all of the system software is concerned, it=E2=80=99s = sending and receiving 802.3 frames to/from the interface.

The difference can be seen between captures in = normal and monitor mode.

RFC2464 is concerned only of that Ethernet II = header captured in normal mode, even though it does not get sent over = the air.

However, there can be some = detail lost when considering only the Ethernet II header.  For = example, if the 802.11 QoS Data Header is employed then some of its = fields are invisible by the RFC2464 mapping process.  However, = these fields could be useful for the Traffic Class or Flow Label fields = of the IPv6 header.

In general that = would be a layering violation anyway.

In some vehicular network = trials the 802.11 QoS Data Header is used below a WSMP protocol (a = network layer-free app-layer protocol).  In these trials, if one = considers the use of IPv6 below WSMP, then one has to consider the need = of distinctive flows of IP datagrams (e.g. emergency).

It=E2=80=99s unclear what you mean by =E2=80=9Cdistinctiv= e flows of IP datagrams=E2=80=9D.

It is also worth = mentioning that the discrepancy between what the Ethernet II header has = to offer and what many media need, can be seen not only on this = 802.11-OCB mode for vehicles, but also by IoT documents at IETF = describing adaptation layers for media like 802.15.4, lowpan, and = more.

Not everything = is an 802.3 network. Non-802.3 networks require different adaptation = layers.

For these reasons I think 802.11 too = deserves its own IPv6-over-80211 document at IETF.

I=E2=80=99m not completely convinced of this as so far, = you seem to be insisting on an approach of adapting IPv6 and 802.3 = multicast to your idea of how things should work rather than adapting = your application to the idea of how things actually work.

I haven=E2=80=99t seen anything in any of your = posts that leads me to believe that the latter would not be the better = approach.


- cavebear tells "33" to = mean all IPv6 not only ND.

Unfortunately = none of these is my goals here.  I am trying to just
identify the right MAC multicast address for 802.11p below = IPv6 (or
IPv6-over-80211p if you wish).


The right solution = is:

1. Use the correct IPv6 multicast = group ID.
If you want all nodes on = link, then that would be ff02::1.

2. Map that multicast group ID onto = the IPv6 multicast MAC range.
Assuming ff02::1 as = above, then this would be 33-33-0-0-0-1


But an = IETF stds track document should tell which is the MAC multicast
address on which to map some IP address.  And it should = be only one, and
agreed by IEEE.
I think that's step 2; step 1 is getting the = address from the IEEE.

Since= IPv6 multicast uses a well defined set of =E2=80=9Clocally = administered=E2=80=9D
MAC addresses, there=E2=80=99s no need = to involve IEEE.

You can debate the = validity of using 33-33 instead of getting an OUI block
as = much as you want, but there=E2=80=99s a lot of running code out there = that is
already using 33-33 without any issues. As such, I = think that=E2=80=99s a decision
we just have to live with at = this point.

I certainly think that = picking alternatives piecemeal protocol by protocol
or worse = application by application is not a good approach.

Then we should go with = "all-nodes" address (not all-OCB-nodes).  But we
need = to know whether that is "33" MAC prefix or some other prefix.

Agreed.

If = it is an IPv6 datagram, then it should be 33-33. If it is an IPv4 = datagram,
then it should probably be ff-ff-ff-ff-ff-ff. If = it=E2=80=99s something else,
then the IETF doesn=E2=80=99t = really care and isn=E2=80=99t involved.

Given you want to reach all 802.11p nodes, it seems like you = should want
an MAC multicast address - but not an IP = multicast address. IP multicast
is needed only to for = IP-layer routing, not for link layer.

That=E2=80=99s not entirely true. All nodes on link = (for example, ff02::1) is definitely a link-layer = communication
for IPv6 that should not be routed at the IP = layer.

There are reasons for = interface and link scoped IPv6 multicast addresses.

Of course, if you want your packets routed, then = you can use the same group IDs with different scopes.

YEs, I need to have this MAC multicast address = for IPv6-over-80211OCB: re-use an existing one?  If yes which one? =  Allocate a new one?  If yes where to ask?

For IP multicast address, let's see a bit = later.

All of this is = asked and answered.

If your target = is described already by a well known IPv6 multicast address (it is, = All-nodes on link, ff02::1) then use
the appropriate group ID = (::1 in this case) and the appropriate scope (Link =3D 2). The flags are = 0 because (Reserved bit always 0, RP not embedded =3D 0, Group not based = on prefix =3D 0, Group not transiet =3D 0). So: Multicast (ff), Flags = (0) Scope (2) and Group ID (1) come together to form Address = (ff02::1).

Once you have the IPv6 = multicast address, then you simply map the low order 32-bits onto the = MAC prefix (33-33) and you get (33-33-0-0-0-1).

So for your stated purpose, it seems to me the = best alternative is destination: ff02::1 @ 33-33-0-0-0-1.

There is nothing special here.

Owen


= --Apple-Mail=_4BB75D9B-5A89-45D6-8F57-2C706905C220-- From nobody Mon Jul 11 13:03:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A3C12D1A1 for ; Mon, 11 Jul 2016 13:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 D2ifD-3pms3Q for ; Mon, 11 Jul 2016 13:03:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E683412D598 for ; Mon, 11 Jul 2016 13:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1621; q=dns/txt; s=iport; t=1468267407; x=1469477007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=quFjnpQXSGmGxJEs2N9oGagcmvDhE1OqCseGvmPFI3c=; b=W/xYi5hrdnuk5Yb6jaXqOjU6gdt+QokCtVuJY1E+ON7CArjO4ELGQ40j isuHyYluxp6kz844LrpowtS+v2nNedeiBwwAYw6l0FiMM2av2GAaQoHCa xwz6HiUm14rtN2uRdpTOfMsFiVgWO+cQBa6MV+pheJuEPL1ClW1BZnsfX A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgAr+oNX/4QNJK1cgz5WfAasaYwWg?= =?us-ascii?q?XoihXYCgSo4FAEBAQEBAQFlJ4RcAQEEAXkFCwIBCBguIRElAgQOBQ6ICAMPCA6?= =?us-ascii?q?7Bg2DfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgfCIJNgkOFKoIvBZhkNAGDM?= =?us-ascii?q?oFsboYvghaBVAGNV4gbh3MBHjaDcW6IQH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,348,1464652800"; d="asc'?scan'208";a="127606707" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 20:03:27 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6BK3R1R027903 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jul 2016 20:03:27 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 15:03:26 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 15:03:26 -0500 From: "Fred Baker (fred)" To: Alexandre Petrescu Thread-Topic: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Thread-Index: AQHR269J9btVJxWtY0+ZFdE6y96lEg== Date: Mon, 11 Jul 2016 20:03:26 +0000 Message-ID: References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> In-Reply-To: <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_7045514F-8069-420A-A6F5-2C9FBB866678"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 20:03:29 -0000 --Apple-Mail=_7045514F-8069-420A-A6F5-2C9FBB866678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 11, 2016, at 2:55 AM, Alexandre Petrescu = wrote: >=20 > First: which other 802 style networking? 802.3 Ethernet (rfc2464) or > 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11? --Apple-Mail=_7045514F-8069-420A-A6F5-2C9FBB866678 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 iQIVAwUBV4P7jUayAOS/EQ8MAQLcqg/6A8WaZk8XPjcD5kLGgjDV6eLLWqJRjG9H 1cN5pPK7QVx/aRy4bDbZHCFyby8Gjv1zdCF0H87Sxxr6NLKHWqddlEegD+NqD2J9 Vu18L6j3Zz3CLM1zIbHhNVeawdxrOM9B9cUTLsHDyEppcaaA4LZSreQTpwsOCKJh mmGpbhzi9EJD92De8QQiQErnFNCApNWOsP203kY74w3chx8f83MDiyMUFfpqGNtF fLTkZQBv4lQ/QC/f65mfjvK7EbYKbPo2MrjT2SbGMnq07nVcgywHf96ZHudLofwj 2Q0zArLhFZPYtbyDnqmC3DK8iTgc3biw2G+eskgsxxde7rg3INCpas4DSAiz2/nw WfNwo8pZeueSGVBWbeJZqkUcN1z9Ojmuy7Wt2a50wJsYYn1Lfprfr+bdNklz2AWf d4BrkDFsIoOkBYR/jDWdbOsba4nH78Njn0aNNmkBrSPFYIrkliRAH8mFiTsVJlrD 22bdCb84vyTMo7jFnLNnnqox1Sa/Y39jaBFtp7j+LN6c4Obn82HgpniA4nmB419Y wTOwkp/XwPAu1+K9+dJihrEIXWGDX5GDK5JmBy+GK32Js/W6RTgTWSsW7rFtIjEp GI4CxzoM0TDrdl+FkZfLJ0MW7sjixX0erR1sDRwS5qNEFQTkQAIkRSHWXd8Y0/Xq wrRRT2xOMGo= =jton -----END PGP SIGNATURE----- --Apple-Mail=_7045514F-8069-420A-A6F5-2C9FBB866678-- From nobody Mon Jul 11 14:26:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32312D0E1 for ; Mon, 11 Jul 2016 14:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 vVovM0-teKV3 for ; Mon, 11 Jul 2016 14:26:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 E995112D0C3 for ; Mon, 11 Jul 2016 14:26:41 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.158]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6BLQ79V007018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 14:26:17 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> From: Joe Touch Message-ID: <57840EEC.4070200@isi.edu> Date: Mon, 11 Jul 2016 14:26:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010701020902040604070309" 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:26:44 -0000 This is a multi-part message in MIME format. --------------010701020902040604070309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/11/2016 3:43 AM, Alexandre Petrescu wrote: > > > Le 08/07/2016 à 21:14, Joe Touch a écrit : >> >> >> On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: >>> ... >>> I suppose it's not a coincidence that IEEE and IETF both call these >>> addresses "all-nodes" but I have no trace of that. >> >> Let's get down to the authorities: >> >> IANA: >> http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml >> IANA does assign addresses starting with 01-00-5E for link >> multicast. >> IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for >> IPv6 multicast. > > I wonder what IETF protocol 01-00-5E has been assigned for. You don't need to wonder. Look further down that link: IANA Multicast 48-bit MAC Addresses Note These values are prefixed with 01-00-5E. 00-00-00 to 7F-FF-FF IPv4 Multicast [RFC1112 ] 80-00-00 to 8F-FF-FF MPLS Multicast [RFC5332 ] 90-00-00 MPLS-TP p2p [RFC7213 ] 90-00-01 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130 ] 90-00-02 AllL1MI-ISs [RFC6822 ] 90-00-03 AllL2MI-ISs [RFC6822 ] 90-00-04 to 90-00-FF Unassigned (small allocations) 90-01-00 TRILL OAM [RFC7455 ] 90-01-01 to 90-01-FF Unassigned (small allocations requiring both unicast and multicast) 90-02-00 to 90-0F-FF Unassigned 90-10-00 to 90-10-FF Documentation [RFC7042 ] 90-11-00 to FF-FF-FF Unassigned Note that the only assignments in this block are for IETF-generated L2 protocols. > > It seems IANA has more authority over this address, and it is more > likely to be unique. As such maybe it is better to use it for > IPv6-over-foo documents, rather than 33-33-. It may be, but it is still inappropriate for the use you're seeking, IMO. > >> IEEE: >> http://standards.ieee.org/develop/regauth/grpmac/public.html >> 01-80-C2-00-00-1B = all multicast-capable endsystems >> 01-80-C2-00-00-1D = all multicast-capable intermediate systems >> 01-80-C2-00-00-00..0F = assigned for 802.1Q >> *** this appears to be where you might request an address >> for your protocol *** > > Right. > > So this would be a 4th alternative for a multicast address for > IPv6-over-80211OCB. Summarizing: There should never be a multicast address for IPv6 over FOO for any FOO that isn't a *protocol*. Link layers are not protocols. > > - all 1s > - 33-33- prefix (IANA local) > - 01-00-5E- prefix (IANA global) > - 01-80-C2- prefix (IEEE allocation) > >> You also argued about "all 1's" not being Ethernet broadcast. It is >> defined as exactly that on page 32 here: >> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf > > Thanks for the reference. Yes, it's there. > >> However, it's also defined as "never assigned" as NULL or >> unintialized here: >> https://standards.*ieee*.org/develop/.../eui48.pdf >>> I am trying to identify the precise IEEE authoritative reference that >>> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant. >> >> Same here - still looking, but I see only IANA's assertion of ownership >> based on an RFC. Nothing at the IEEE yet. > > If IEEE has no text about this 33-33- prefix then I think there can be > problems. As others have noted, the link local bit is set, which means it is covered by IEEE specs as being locally managed. > >>>> But the correct corresponding "all nodes" might be appropriate: >>>> ff02::1 >>> >>> Yes, this IP "all-nodes" is very appropriate, I agree. >>> >>>>> - 33:33:00:00:00:01 - like IPv6-over-WiFi does >>>> >>>> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464, >>>> but I don't see anywhere where any of these addresses are assigned >>>> (or assignable) to a single protocol. >>> >>> Well, there are multiple things here. >>> >>> The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP >>> addresses). >> Yes - I was intending to say "the 33:33::" addresses are used within >> IPv6 multicast as per RFC2464... >> >>> Curiously enough, they are defined in an IETF RFC (RFC 2464 >>> "IPv6-over-Ethernet" lists hexa "3333"). I can not find them >>> defined at >>> IEEE even though there is an IEEE place listing IEEE MAC multicast >>> addresses: >>> https://standards.ieee.org/develop/regauth/grpmac/public.html >>> >>> It is curious because IETF should not define MAC address formats or >>> contents, right? >> >> Agreed - I think there are a few of us looking, but if anyone knows, >> please speak up! >> >>> As an additional curiosity, the well-known 'cavebear' registry lists >>> 33-33 as an Ethernet Multicast Address: >>> http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html >>> as an "IPv6 Neighbor Discovery" explanation. >>> >>> It is curious because this "33-33-" MAC address is used below other >>> IPv6 >>> protocols like DHCPv6, not only Neighbor Discovery. >> Yes. >> >>> >>> To correct all these, the following can be proposed: >>> >>> - IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to >>> mean a 6-byte MAC address, and not an IPv6 address, despite the >>> column use. > > >> Agreed. I think you meant "colon" rather than "column", though. > > YEs. This makes think writing an I-D title "IETF notation of MAC > addresses" could make sense to avoid confusion. > > Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely used > packet analyzer says "33:33:00:00:00:01". Common dialogue with the > IPv6-versed tends to say "33:33::1". This may lead to confusion. > >>> - IEEE tells where is this "3333" address defined so we can see it >>> publicly. >> >> Please! >> >>> - wikipedia stops writing wrong articles. >> >> Well, it is Wikipedia - if it's incorrect, we can change it... >> >>> - RFC2464 gets update to mean it also works on WiFi not only on >>> Ethernet. > > >> I don't understand this at all. I thought WiFi was just a variety >> wireless media layers over which 802 frames (colloquially known as >> "ethernet") were sent. > > In principle it is that way. > > For introduction I believe there may be some detail that RFC2464 > overlooks. > > I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, > ethertype] - does not get sent over the 802.11 media. I suspect there > is a local adaptation layer in each WiFi computer which converts > bidirectionaly between an Ethernet II header [dst, src, ethertype] and > 802.11 frames: for each Ethernet II header there is a corresponding > tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an > LLC header. And it's this tuple that gets sent over the 802.11 media, > not the Ethernet II header. IP is a payload to 802. What that layer ends up sending out over the physical media doesn't matter to IP. > > The difference can be seen between captures in normal and monitor mode. > > RFC2464 is concerned only of that Ethernet II header captured in > normal mode, even though it does not get sent over the air. See above; that's normal layer separation. > > However, there can be some detail lost when considering only the > Ethernet II header. For example, if the 802.11 QoS Data Header is > employed then some of its fields are invisible by the RFC2464 mapping > process. However, these fields could be useful for the Traffic Class > or Flow Label fields of the IPv6 header. See draft-szigeti-tsvwg-ieee-802-11e > > In some vehicular network trials the 802.11 QoS Data Header is used > below a WSMP protocol (a network layer-free app-layer protocol). In > these trials, if one considers the use of IPv6 below WSMP, then one > has to consider the need of distinctive flows of IP datagrams (e.g. > emergency). > > It is also worth mentioning that the discrepancy between what the > Ethernet II header has to offer and what many media need, can be seen > not only on this 802.11-OCB mode for vehicles, but also by IoT > documents at IETF describing adaptation layers for media like > 802.15.4, lowpan, and more. > > For these reasons I think 802.11 too deserves its own IPv6-over-80211 > document at IETF. It might, as per the 802-11e doc above. But that's a long way from necessarily needing a multicast MAC address assignment, either from the IETF's managed block or directly from the IEEE. ... >> You're either sending a link-layer routing protocol message (e.g., like >> a IS-IS or Ethernet BPDUs) or you're sending an Internet routing >> protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as >> "service" layers (i.e., "applications"), i.e., inside UDP or TCP >> inside IP. >> >> Given you want to reach all 802.11p nodes, it seems like you should want >> an MAC multicast address - but not an IP multicast address. IP multicast >> is needed only to for IP-layer routing, not for link layer. > > YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: > re-use an existing one? If yes which one? Allocate a new one? If > yes where to ask? You might start by having that discussion with the IEEE. > > For IP multicast address, let's see a bit later. Sure - once you explain how what you need runs OVER IP. Joe --------------010701020902040604070309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/11/2016 3:43 AM, Alexandre Petrescu wrote:


Le 08/07/2016 à 21:14, Joe Touch a écrit :


On 7/8/2016 6:52 AM, Alexandre Petrescu wrote:
...
I suppose it's not a coincidence that IEEE and IETF both call these
addresses "all-nodes" but I have no trace of that.

Let's get down to the authorities:

IANA:
http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
    IANA does assign addresses starting with 01-00-5E for link multicast.
    IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for
IPv6 multicast.

I wonder what IETF protocol 01-00-5E has been assigned for.

You don't need to wonder. Look further down that link:

IANA Multicast 48-bit MAC Addresses

Note
These values are prefixed with 01-00-5E.
00-00-00 to 7F-FF-FF IPv4 Multicast [RFC1112]
80-00-00 to 8F-FF-FF MPLS Multicast [RFC5332]
90-00-00 MPLS-TP p2p [RFC7213]
90-00-01 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130]
90-00-02 AllL1MI-ISs [RFC6822]
90-00-03 AllL2MI-ISs [RFC6822]
90-00-04 to 90-00-FF Unassigned (small allocations)
90-01-00 TRILL OAM [RFC7455]
90-01-01 to 90-01-FF Unassigned (small allocations requiring both unicast and multicast)
90-02-00 to 90-0F-FF Unassigned
90-10-00 to 90-10-FF Documentation [RFC7042]
90-11-00 to FF-FF-FF Unassigned
Note that the only assignments in this block are for IETF-generated L2 protocols.


It seems IANA has more authority over this address, and it is more likely to be unique.  As such maybe it is better to use it for IPv6-over-foo documents, rather than 33-33-.
It may be, but it is still inappropriate for the use you're seeking, IMO.


IEEE:
    http://standards.ieee.org/develop/regauth/grpmac/public.html
        01-80-C2-00-00-1B = all multicast-capable endsystems
        01-80-C2-00-00-1D = all multicast-capable intermediate systems
        01-80-C2-00-00-00..0F = assigned for 802.1Q
            *** this appears to be where you might request an address
for your protocol ***

Right.

So this would be a 4th alternative for a multicast address for IPv6-over-80211OCB.  Summarizing:

There should never be a multicast address for IPv6 over FOO for any FOO that isn't a *protocol*.

Link layers are not protocols.


- all 1s
- 33-33- prefix (IANA local)
- 01-00-5E- prefix (IANA global)
- 01-80-C2- prefix (IEEE allocation)

You also argued about "all 1's" not being Ethernet broadcast. It is
defined as exactly that on page 32 here:
www.ieee802.org/secmail/pdfocSP2xXA6d.pdf

Thanks for the reference.  Yes, it's there.

However, it's also defined as "never assigned" as NULL or unintialized here:
https://standards.*ieee*.org/develop/.../eui48.pdf
I am trying to identify the precise IEEE authoritative reference that
says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant.

Same here - still looking, but I see only IANA's assertion of ownership
based on an RFC. Nothing at the IEEE yet.

If IEEE has no text about this 33-33- prefix then I think there can be problems.

As others have noted, the link local bit is set, which means it is covered by IEEE specs as being locally managed.


But the correct corresponding "all nodes" might be appropriate:
ff02::1

Yes, this IP "all-nodes" is very appropriate, I agree.

- 33:33:00:00:00:01 - like IPv6-over-WiFi does

All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464,
but I don't see anywhere where any of these addresses are assigned
(or assignable) to a single protocol.

Well, there are multiple things here.

The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP
addresses).
Yes - I was intending to say "the 33:33::" addresses are used within
IPv6 multicast as per RFC2464...

Curiously enough, they are defined in an IETF RFC (RFC 2464
"IPv6-over-Ethernet" lists hexa "3333").  I can not find them defined at
IEEE even though there is an IEEE place listing IEEE MAC multicast
addresses:
https://standards.ieee.org/develop/regauth/grpmac/public.html

It is curious because IETF should not define MAC address formats or
contents, right?

Agreed - I think there are a few of us looking, but if anyone knows,
please speak up!

As an additional curiosity, the well-known 'cavebear' registry lists
33-33 as an Ethernet Multicast Address:
http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html
as an "IPv6 Neighbor Discovery" explanation.

It is curious because this "33-33-" MAC address is used below other IPv6
protocols like DHCPv6, not only Neighbor Discovery.
Yes.


To correct all these, the following can be proposed:

- IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to
  mean a 6-byte MAC address, and not an IPv6 address, despite the
  column use.
>
Agreed. I think you meant "colon" rather than "column", though.

YEs.  This makes think writing an I-D title "IETF notation of MAC addresses" could make sense to avoid confusion.

Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely used packet analyzer says "33:33:00:00:00:01".  Common dialogue with the IPv6-versed tends to say "33:33::1".  This may lead to confusion.

- IEEE tells where is this "3333" address defined so we can see it
  publicly.

Please!

- wikipedia stops writing wrong articles.

Well, it is Wikipedia - if it's incorrect, we can change it...

- RFC2464 gets update to mean it also works on WiFi not only on
  Ethernet.
>
I don't understand this at all. I thought WiFi was just a variety
wireless media layers over which 802 frames (colloquially known as
"ethernet") were sent.

In principle it is that way.

For introduction I believe there may be some detail that RFC2464 overlooks.

I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, ethertype] - does not get sent over the 802.11 media.  I suspect there is a local adaptation layer in each WiFi computer which converts bidirectionaly between an Ethernet II header [dst, src, ethertype] and 802.11 frames: for each Ethernet II header there is a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an LLC header.  And it's this tuple that gets sent over the 802.11 media, not the Ethernet II header.

IP is a payload to 802. What that layer ends up sending out over the physical media doesn't matter to IP.


The difference can be seen between captures in normal and monitor mode.

RFC2464 is concerned only of that Ethernet II header captured in normal mode, even though it does not get sent over the air.
See above; that's normal layer separation.


However, there can be some detail lost when considering only the Ethernet II header.  For example, if the 802.11 QoS Data Header is employed then some of its fields are invisible by the RFC2464 mapping process.  However, these fields could be useful for the Traffic Class or Flow Label fields of the IPv6 header.
See draft-szigeti-tsvwg-ieee-802-11e


In some vehicular network trials the 802.11 QoS Data Header is used below a WSMP protocol (a network layer-free app-layer protocol).  In these trials, if one considers the use of IPv6 below WSMP, then one has to consider the need of distinctive flows of IP datagrams (e.g. emergency).

It is also worth mentioning that the discrepancy between what the Ethernet II header has to offer and what many media need, can be seen not only on this 802.11-OCB mode for vehicles, but also by IoT documents at IETF describing adaptation layers for media like 802.15.4, lowpan, and more.

For these reasons I think 802.11 too deserves its own IPv6-over-80211 document at IETF.

It might, as per the 802-11e doc above. But that's a long way from necessarily needing a multicast MAC address assignment, either from the IETF's managed block or directly from the IEEE.
...
You're either sending a link-layer routing protocol message (e.g., like
a IS-IS or Ethernet BPDUs) or you're sending an Internet routing
protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as
"service" layers (i.e., "applications"), i.e., inside UDP or TCP inside IP.

Given you want to reach all 802.11p nodes, it seems like you should want
an MAC multicast address - but not an IP multicast address. IP multicast
is needed only to for IP-layer routing, not for link layer.

YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: re-use an existing one?  If yes which one?  Allocate a new one?  If yes where to ask?
You might start by having that discussion with the IEEE.


For IP multicast address, let's see a bit later.

Sure - once you explain how what you need runs OVER IP.

Joe
--------------010701020902040604070309-- From nobody Mon Jul 11 15:10:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C9212D541 for ; Mon, 11 Jul 2016 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vNPl4CJuz97X for ; Mon, 11 Jul 2016 15:10:39 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 3A78D12D10C for ; Mon, 11 Jul 2016 15:10:39 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id u186so72530575ita.0 for ; Mon, 11 Jul 2016 15:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Otg+u0gTP7i4+ogG1EKXbrWvhdbUY9kNXhFUvP5pfkw=; b=SGulMoGK1IJfsV+NgIFEX94LOTPPlmmyD76oGJNfSpJ/OFBZAnXgRoFTxIskp4LcXf 5ST7FqgXlPnf5t4D8sHwPc/pp+r7pwTnhevWFSF2QksZVIKErBsLoR0q4pABDJYzRNXm m3F4rCSSffnTSAoxXmmMmgzZ8M1ePqblzh3wU17UobC9Qk82oFZlRBqY8VudSQOX1vsy 3KYiBWQ04IyMK3Rn3etXHMZ2vFsGMKxysl2vIg0GHoc2MnLe7xJsQGdzyTMrqCU2ARa2 q74gRCgb7vcZlDvgY4dLdj7TbLLbRwkM19JqnVTla+FINcvQ5yYdITgHvUng9u/SjzRh 2eLA== 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; bh=Otg+u0gTP7i4+ogG1EKXbrWvhdbUY9kNXhFUvP5pfkw=; b=HLfUIUCk/4VSVHpZrSuFe6gvfHnuI9K7lVMoGcLMiLTttUqtxezqxoUdFqwXzHr1c6 +oJTOMCjdPUSikwEmo9f/OBQ0aAg1l2Gf+tQ6/xqnumUjyng1uxw2DiMVFPSdEHO6Yof uKnGXVeHGFsfDkmhAjCoxVmEOv3Z2cJK5hzLAh2L0dcZIcvVMZnIaG4XCceajUg0YuW9 4wri59/cEnV3wrscDchx8JF2TiXGxCGbX6BsPEaXvZUbZvjq8jKMZFtjFPnxGdONdGha qACrDShL+qIc+nVZhUfYjg5k3dJFholzF/FWKaYMDwufAMx27otPqKqqOo7Iu2Hjv6A6 JV2A== X-Gm-Message-State: ALyK8tL60Inhr8i+eOk+MUGgDOqhyRM5ARx4PpQR9b8C/PIqCuxNHF+A3UwdVWs9y5h/WciYTrwYCKp3FrJBtg== X-Received: by 10.36.200.131 with SMTP id w125mr16256256itf.80.1468275038476; Mon, 11 Jul 2016 15:10:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Mon, 11 Jul 2016 15:10:19 -0700 (PDT) In-Reply-To: <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> From: Jen Linkova Date: Tue, 12 Jul 2016 00:10:19 +0200 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , Chris Bowers Subject: Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:10:41 -0000 Brian, First of all - thanks for reviewing the draft and providing your feedback! On Sat, Jul 9, 2016 at 3:01 PM, Brian E Carpenter wrote: > draft-ietf-6man-multi-homed-host is listed in the references but not cited > in the text. Since it is all about effective use of RFC6724 rule 5.5, I would > expect it to carefully referenced in section 4.1. Ah, good catch, thanks - I'll add the reference. >In fact, the behaviour > specified by draft-ietf-6man-multi-homed-host seems to be essential for > your mechanism to succeed. You are right, most of them are required, I'll update the text, thanks for pointing this out. Looks like we've completely missed the scenario when hosts have addresses assigned by DHCPv6 (or manually) and receive RAs... However I'm not sure about Section 3.2... draft-ietf-6man-multi-homed-host says: "Default Router Selection is modified as follows: A host SHOULD select default routers for each prefix it is assigned an address in.". I'm not sure it is actually required if routers implement the feature described in our draft and send one RA (with PIOs) per scoped table (as the whole idea of a SADR-capable router pretending to be two or more routers - one router per scoped table is to trick the host). The host SHOULD add a router into its Default Router list upon receiving a valid RA with non-zero Router Lifetime, yes (as per RFC4191). Let's look at the situation when R3 (see Figure 3 at the page 11 of draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) sends two RAs: one from LLA_A for its forwarding table scoped to 2001:db8:0:a000::/56 and another one from LLA_B for its forwarding table scoped to 2001:db8:0:b000::/56. Even if the first RA has two PIOs (e.g. 2001:db8:0:a020::/64 and 2001:db8:0:a021::/64), the host does not need to select two default routers for 2001:db8:0:a020::/64 and 2001:db8:0:a021::/64 as it would not add any functionality (both prefixes will match the same scoped table on SADR-capable routers). Basically, if packets with source addresses from two prefixes are going to be routed differently, then those two prefixes belong to two different scoped tables on the network side and therefore two RAs will be sent for them. Am I missing smth? >You almost say that in section 4.2.2 but again > without citing the draft. > > Worse, section 4.2.4 says: > >> At the same time Router Advertisements provide a reliable mechanism >> to influence source address selection process via PIO, RIO and >> default router preferences. As all those options have been >> standardized by IETF and are supported by various operating systems, >> no changes are required on hosts. > > That's not true. The changes described in draft-ietf-6man-multi-homed-host > *are* required. To be honest I'm a bit confused with the changes described in the Section 3.1 of draft-ietf-6man-multi-homed-host... Let's assume that 1) first-hop routers behave as described in draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 (SADR-capable routers which stop advertizing themselves as default routers and/or withdraw the prefixes if source address from that prefix should not be used) 2) the host uses the rule 5.5 of the source address selection algorithm. In that case would not any host which follows RFC6724 and RFC4191 behave exactly as described in the Section 3.1 anyway? (sorry for the stupid question, I feel like I'm missing smth here..). The Section 3.2 (Default Router Selection) - see my comment above. I'll add the reference to the section 3.4 of draft-ietf-6man-multi-homed-host to the sections of our draft which discuss ICMPv6 error messages as a mechanism to influence the address selection on hosts. > Also, routers must be capable of sending PIOs with both > L and A bits set to zero. Oh, I was not consider that as a special feature, assuming any router should be capable of doing that. Probably you are right and it should be explicitly mentioned, just in case... > The same error occurs in section 4.6: > >> 1. no new (non-standard) functionality needs to be implemented on >> hosts (except for [RFC4191] support); > > Section 5.1, shim6. While not disputing your conclusion, I think this is > misleading: > >> We do not consider Shim6 to be a viable solution. It suffers from >> the fact that it requires widespread deployment of Shim6 on hosts... > > It is a two-ended solution and we always knew that it could only be deployed > incrementally and opportunistically; that was the plan, not a defect. The real > defect is that the Internet is partly opaque to IPv6 extension headers, and > therefore even incremental deployment of shim6 is not viable. (The same goes > for HIP-based multihoming, which you don't mention.) Good point, I'll update the text with extension header issues. > > Finally, it's helpful in site multihoming proposals to indicate whether > they meet the goals in RFC 3582. Oh, thanks - we do list RFC3582 in the Normative References section but there is no reference to it in the text. Will be fixed! > On 07/07/2016 04:33, Fred Baker (fred) wrote: >> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. >> >>> Begin forwarded message: >>> >>> From: >>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Date: July 5, 2016 at 5:58:25 PM PDT >>> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >>> >>> >>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> has been successfully submitted by Fred Baker and posted to the >>> IETF repository. >>> >>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>> Revision: 00 >>> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >>> Document date: 2016-07-05 >>> Group: Individual Submission >>> Pages: 44 >>> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>> >>> >>> Abstract: >>> Connecting an enterprise site to multiple ISPs using provider- >>> assigned addresses is difficult without the use of some form of >>> Network Address Translation (NAT). Much has been written on this >>> topic over the last 10 to 15 years, but it still remains a problem >>> without a clearly defined or widely implemented solution. Any >>> multihoming solution without NAT requires hosts at the site to have >>> addresses from each ISP and to select the egress ISP by selecting a >>> source address for outgoing packets. It also requires routers at the >>> site to take into account those source addresses when forwarding >>> packets out towards the ISPs. >>> >>> This document attempts to define a complete solution to this problem. >>> It covers the behavior of routers to forward traffic taking into >>> account source address, and it covers the behavior of host to select >>> appropriate source addresses. It also covers any possible role that >>> routers might play in providing information to hosts to help them >>> select appropriate source addresses. In the process of exploring >>> potential solutions, this documents also makes explicit requirements >>> for how the solution would be expected to behave from the perspective >>> of an enterprise site network administrator . >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >> >> >> >> _______________________________________________ >> 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 -- SY, Jen Linkova aka Furry From nobody Tue Jul 12 00:01:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BF12D5C8 for ; Tue, 12 Jul 2016 00:01:31 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nAKG0ADdtmCK for ; Tue, 12 Jul 2016 00:01:29 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 7EEBF12B075 for ; Tue, 12 Jul 2016 00:01:28 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i5so11790039wmg.0 for ; Tue, 12 Jul 2016 00:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qkB2sT8eJEyOAe/JWL4vsgzdw1F/7s42JukRLj90PxI=; b=ff3QCv/KiS1DNW/uDHAo/6WJnotYv/tVJRqzdSSrRFO7ZzMEptKNO63tDIM0QCtGwS dGiA1ujsNStqoKA77hZ/QPwlxf9/P31YRh5ar76yi8HfgJWzQ7M4ooGNCik9+lP6gW/e F2LcUoR8Y0wapxBKZkKfjp6L4Wdb16oCurptjWSO/IM5t9Z/7NJRcPCAl7YnD4kCw1so bjtmTE7kWTP9/GyYU5hGRL8KIF7w7UBVrB+ebIPvCgLHADHg8+nRflN5xA9E7se49pkQ 0ykDJw5v+BhJbVDkpmqJqnJXtJYx9A/dlXklgX3WnavfW9VM982V8VUa5rYpC06GwP4p 6i7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qkB2sT8eJEyOAe/JWL4vsgzdw1F/7s42JukRLj90PxI=; b=Pp5ko46MdOim5T9FB/0AI0CAGjwHiP3feFn3rljdpdEmHvpmj4RrxaEF4dUuqT2sWs EXWWBDZsfDThdbcw6ocONTmj448eyK8b/4GmpyNkIZgYiLYtMXW2FruuJd/A7MxikAR7 uaZgkRC62MGDmkn8W1UduS10Z+F0C5gw5/N+kDXcqjKYwk2vNEtqjXlCWRQpEGIFLEik mk9NPOuAU35a5AL6IvxkT/B1GpPRItftQ4Qnhiubq0LiodL+BIfS1J60IRKh7t0mAWBE MHY/sZ9A032+wDxu7OwFZiygd7HjJkvkbpyLOVRGjSALjB9/vfomDirG1Ev6I6Hb3zXf j86g== X-Gm-Message-State: ALyK8tIN2xCsKLbymeO01V0nLvsmuN6JgkXJVwCS1uRlkYbWa1pwOerUwcNxJXbPC56kDw== X-Received: by 10.28.52.142 with SMTP id b136mr1087968wma.35.1468306886865; Tue, 12 Jul 2016 00:01:26 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id k2sm3477007wjl.6.2016.07.12.00.01.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 00:01:26 -0700 (PDT) To: Jen Linkova References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 12 Jul 2016 19:01:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , Chris Bowers Subject: Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 07:01:31 -0000 Hi, On 12/07/2016 10:10, Jen Linkova wrote: > Brian, > > First of all - thanks for reviewing the draft and providing your feedback! > > On Sat, Jul 9, 2016 at 3:01 PM, Brian E Carpenter > wrote: >> draft-ietf-6man-multi-homed-host is listed in the references but not cited >> in the text. Since it is all about effective use of RFC6724 rule 5.5, I would >> expect it to carefully referenced in section 4.1. > > Ah, good catch, thanks - I'll add the reference. > >> In fact, the behaviour >> specified by draft-ietf-6man-multi-homed-host seems to be essential for >> your mechanism to succeed. > > You are right, most of them are required, I'll update the text, thanks > for pointing this out. Looks like we've completely > missed the scenario when hosts have addresses assigned by DHCPv6 (or > manually) and receive RAs... > > However I'm not sure about Section 3.2... > draft-ietf-6man-multi-homed-host says: > "Default Router Selection is modified as follows: A host SHOULD select > default routers for each prefix it is assigned an address in.". > > I'm not sure it is actually required if routers implement the feature > described in our draft and send one RA (with PIOs) per > scoped table (as the whole idea of a SADR-capable router pretending to > be two or more routers - one router per scoped table is > to trick the host). That may be. Fred should comment, but in the 6man draft we were trying to cover as many cases as possible, while *hoping* that SADR would become widespread. > The host SHOULD add a router into its Default Router list upon > receiving a valid RA with non-zero Router Lifetime, yes (as per > RFC4191). > Let's look at the situation when R3 (see Figure 3 at the page 11 of > draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) sends two RAs: one > from LLA_A for its forwarding table scoped to 2001:db8:0:a000::/56 and > another one from LLA_B for its forwarding table scoped to > 2001:db8:0:b000::/56. > Even if the first RA has two PIOs (e.g. 2001:db8:0:a020::/64 and > 2001:db8:0:a021::/64), the host does not need to select two default > routers for 2001:db8:0:a020::/64 and 2001:db8:0:a021::/64 as it would > not add any functionality (both prefixes will match the same scoped > table on SADR-capable routers). Basically, if packets with source > addresses from two prefixes are going to be routed differently, then > those two prefixes belong to two different scoped tables on the > network side and therefore two RAs will be sent for them. > Am I missing smth? I don't think you are. But today, that doesn't happen, and I think we were trying to have the host do the best it can anyway. > >> You almost say that in section 4.2.2 but again >> without citing the draft. >> >> Worse, section 4.2.4 says: >> >>> At the same time Router Advertisements provide a reliable mechanism >>> to influence source address selection process via PIO, RIO and >>> default router preferences. As all those options have been >>> standardized by IETF and are supported by various operating systems, >>> no changes are required on hosts. >> >> That's not true. The changes described in draft-ietf-6man-multi-homed-host >> *are* required. > > To be honest I'm a bit confused with the changes described in the Section 3.1 of > draft-ietf-6man-multi-homed-host... > Let's assume that > 1) first-hop routers behave as described in > draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 > (SADR-capable routers which stop advertizing > themselves as default routers and/or withdraw the prefixes if source > address from that prefix should not be used) > 2) the host uses the rule 5.5 of the source address selection algorithm. > In that case would not any host which follows RFC6724 and RFC4191 > behave exactly as described in the Section 3.1 anyway? > (sorry for the stupid question, I feel like I'm missing smth here..). No, I think that's right, but today many hosts don't use rule 5.5 and many routers don't do SADR. We were trying to make the best of it. > > The Section 3.2 (Default Router Selection) - see my comment above. > > I'll add the reference to the section 3.4 of > draft-ietf-6man-multi-homed-host to the sections of our draft > which discuss ICMPv6 error messages as a mechanism to influence the > address selection on hosts. > >> Also, routers must be capable of sending PIOs with both >> L and A bits set to zero. > > Oh, I was not consider that as a special feature, assuming any router > should be capable of doing that. > Probably you are right and it should be explicitly mentioned, just in case... People have alleged that current routers won't do that. Thanks! Brian > >> The same error occurs in section 4.6: >> >>> 1. no new (non-standard) functionality needs to be implemented on >>> hosts (except for [RFC4191] support); >> >> Section 5.1, shim6. While not disputing your conclusion, I think this is >> misleading: >> >>> We do not consider Shim6 to be a viable solution. It suffers from >>> the fact that it requires widespread deployment of Shim6 on hosts... >> >> It is a two-ended solution and we always knew that it could only be deployed >> incrementally and opportunistically; that was the plan, not a defect. The real >> defect is that the Internet is partly opaque to IPv6 extension headers, and >> therefore even incremental deployment of shim6 is not viable. (The same goes >> for HIP-based multihoming, which you don't mention.) > > Good point, I'll update the text with extension header issues. > >> >> Finally, it's helpful in site multihoming proposals to indicate whether >> they meet the goals in RFC 3582. > > Oh, thanks - we do list RFC3582 in the Normative References section > but there is no reference to it > in the text. Will be fixed! > > >> On 07/07/2016 04:33, Fred Baker (fred) wrote: >>> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. >>> >>>> Begin forwarded message: >>>> >>>> From: >>>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>> Date: July 5, 2016 at 5:58:25 PM PDT >>>> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >>>> >>>> >>>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>> has been successfully submitted by Fred Baker and posted to the >>>> IETF repository. >>>> >>>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>>> Revision: 00 >>>> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >>>> Document date: 2016-07-05 >>>> Group: Individual Submission >>>> Pages: 44 >>>> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>>> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>>> >>>> >>>> Abstract: >>>> Connecting an enterprise site to multiple ISPs using provider- >>>> assigned addresses is difficult without the use of some form of >>>> Network Address Translation (NAT). Much has been written on this >>>> topic over the last 10 to 15 years, but it still remains a problem >>>> without a clearly defined or widely implemented solution. Any >>>> multihoming solution without NAT requires hosts at the site to have >>>> addresses from each ISP and to select the egress ISP by selecting a >>>> source address for outgoing packets. It also requires routers at the >>>> site to take into account those source addresses when forwarding >>>> packets out towards the ISPs. >>>> >>>> This document attempts to define a complete solution to this problem. >>>> It covers the behavior of routers to forward traffic taking into >>>> account source address, and it covers the behavior of host to select >>>> appropriate source addresses. It also covers any possible role that >>>> routers might play in providing information to hosts to help them >>>> select appropriate source addresses. In the process of exploring >>>> potential solutions, this documents also makes explicit requirements >>>> for how the solution would be expected to behave from the perspective >>>> of an enterprise site network administrator . >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>>> >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 12 01:44:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8498712D752 for ; Tue, 12 Jul 2016 01:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SGL-8CwFPM2n for ; Tue, 12 Jul 2016 01:44:36 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 3269812D0C2 for ; Tue, 12 Jul 2016 01:44:36 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f6so74494892ith.1 for ; Tue, 12 Jul 2016 01:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BLKob7TCwN5MnmVCYhlls1Rqb13uxRrMswB3fHxg8mE=; b=NTXYQGMEzYtUpadgbBYR55FTSrYwmYVNTiwdaGRNyXIw0bnFQdiyaiFhR8pZ0Ez2aS TOPXoVFP4umzuOXvELl/dI1Iup4pDPmxbNnt1yTqmgos7gGF+u6/bkEBkqm8YNRa2k6z YzsvkT7D/YJli3uBVEcBlSA+e/bOArhqH8REAYeKlmuISz4Buz4PICLnNu2U5nNJRqIv 84fg0He8MO4Zs+RA6Ibs8cvRJ/9ZbB781zzts8tkdVoI2nCeHtmW1BVbUvf3d0GuPkzv Mnf13wFunwURt7a4NtiqHyqJZ0zUCEROvhI0EV+fwPh9OG32jAu1ByR4QZqe3LmqIUIF xuJQ== 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; bh=BLKob7TCwN5MnmVCYhlls1Rqb13uxRrMswB3fHxg8mE=; b=jWO2pPEKFutwbKrWVd75tlHFoowefTcrfClN8V2ILfQTSVzIor42Bh7m+qQ4n3XDrl /UCGU+YisIV0yVMfptelP2KWNy1gVVWXZ9FJVpX0DZZuAO7EyHZGEuGwWX3bvAZKYHfr KQ/xn+4z+NS9aLvhfiseb++VgSxtFHttAFhrd99o6xAvhnmCie5Jhvfdsd4uSeOFcskY 4bhAePua+k+bMa5GlvKLVB2oIwfwRi3bQnEYosK6TCx0/Pf3zZ39+R30Evnw4RGP+kBw b5GH81sZ5pFNbSezzzyS2HdE8UlgUMgZdohCUn0kEcHIrf/1xNPT1vwYocwvMmmJ4F5G pdbw== X-Gm-Message-State: ALyK8tINx4HCQeqQbFdVjPZRl5OyRY7vWnmoqx+hLl/ZRgv8p4d3+6YYJkwhr7GguOy3UCow75UDyTtNfHgEeA== X-Received: by 10.36.14.76 with SMTP id 73mr1486987ite.70.1468313075249; Tue, 12 Jul 2016 01:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Tue, 12 Jul 2016 01:44:15 -0700 (PDT) In-Reply-To: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> From: Jen Linkova Date: Tue, 12 Jul 2016 10:44:15 +0200 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , Chris Bowers Subject: Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:44:38 -0000 On Tue, Jul 12, 2016 at 9:01 AM, Brian E Carpenter wrote: >>> Worse, section 4.2.4 says: >>> >>>> At the same time Router Advertisements provide a reliable mechanism >>>> to influence source address selection process via PIO, RIO and >>>> default router preferences. As all those options have been >>>> standardized by IETF and are supported by various operating systems, >>>> no changes are required on hosts. >>> >>> That's not true. The changes described in draft-ietf-6man-multi-homed-host >>> *are* required. >> >> To be honest I'm a bit confused with the changes described in the Section 3.1 of >> draft-ietf-6man-multi-homed-host... >> Let's assume that >> 1) first-hop routers behave as described in >> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >> (SADR-capable routers which stop advertizing >> themselves as default routers and/or withdraw the prefixes if source >> address from that prefix should not be used) >> 2) the host uses the rule 5.5 of the source address selection algorithm. >> In that case would not any host which follows RFC6724 and RFC4191 >> behave exactly as described in the Section 3.1 anyway? >> (sorry for the stupid question, I feel like I'm missing smth here..). > > No, I think that's right, but today many hosts don't use rule 5.5 > and many routers don't do SADR. We were trying to make the best of it. Ah, I see, it's more clear now, thanks for the explanation. So basically the changes described in draft-ietf-6man-multi-homed-host are required unless the network (and the first-hop routers in particular) support SADR and the features described in draft-bowbakova-rtgwg-enterprise-pa-multihoming. What if the Section 4.2.4 is re-phrased in the following way: === old text=== At the same time Router Advertisements provide a reliable mechanism to influence source address selection process via PIO, RIO and default router preferences. As all those options have been standardized by IETF and are supported by various operating systems, no changes are required on hosts. First-hop routers in the enterprise network need to be able of sending different RAs for different SLAAC prefixes (either based on scoped forwarding tables or based on pre-configured policies). ===== new text ===== At the same time Router Advertisements provide a reliable mechanism to influence source address selection process via PIO, RIO and default router preferences (all those options have been standardized by IETF). In SADR-capable network where first-hop routers are capable of sending different RAs for different SLAAC prefixes (either based on scoped forwarding tables or based on pre-configured policies), no changes in hosts behavior are required. However to fully benefit of RA-based solution, hosts are required to support RFC4191 and use the Rule 5.5 of source address selection algorithm as specified in RFC6724. If first-hop routers do not support SADR and scoped RAs as described in the Section 4 of this document, hosts behavior needs to be changed as described in draft-ietf-6man-multi-homed-host ====== (Section 4.6 will be updated accordingly). What do you think? >From deployment perspective requesting a new feature from my router vendor(s) and upgrading X (where X < 100 usually) routers is much simpler than requesting a behavior change of thousands of end devices (well, some of them might not support Rule 5.5 and RFC4191 but at least some of them do...), especially in 'Bring Your Own Device' model. IMHO it would be nice to make it clear in the document that SADR helps deploying multihoming with minimal changes on hosts side (comparing to changes required if the network is not SADR-capable). >>> Also, routers must be capable of sending PIOs with both >>> L and A bits set to zero. >> >> Oh, I was not consider that as a special feature, assuming any router >> should be capable of doing that. >> Probably you are right and it should be explicitly mentioned, just in case... > > People have alleged that current routers won't do that. I'll update the text with the requirement, thanks! >> >>> The same error occurs in section 4.6: >>> >>>> 1. no new (non-standard) functionality needs to be implemented on >>>> hosts (except for [RFC4191] support); >>> >>> Section 5.1, shim6. While not disputing your conclusion, I think this is >>> misleading: >>> >>>> We do not consider Shim6 to be a viable solution. It suffers from >>>> the fact that it requires widespread deployment of Shim6 on hosts... >>> >>> It is a two-ended solution and we always knew that it could only be deployed >>> incrementally and opportunistically; that was the plan, not a defect. The real >>> defect is that the Internet is partly opaque to IPv6 extension headers, and >>> therefore even incremental deployment of shim6 is not viable. (The same goes >>> for HIP-based multihoming, which you don't mention.) >> >> Good point, I'll update the text with extension header issues. >> >>> >>> Finally, it's helpful in site multihoming proposals to indicate whether >>> they meet the goals in RFC 3582. >> >> Oh, thanks - we do list RFC3582 in the Normative References section >> but there is no reference to it >> in the text. Will be fixed! >> >> >>> On 07/07/2016 04:33, Fred Baker (fred) wrote: >>>> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. >>>> >>>>> Begin forwarded message: >>>>> >>>>> From: >>>>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>> Date: July 5, 2016 at 5:58:25 PM PDT >>>>> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >>>>> >>>>> >>>>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>> has been successfully submitted by Fred Baker and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>>>> Revision: 00 >>>>> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >>>>> Document date: 2016-07-05 >>>>> Group: Individual Submission >>>>> Pages: 44 >>>>> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>>>> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>>>> >>>>> >>>>> Abstract: >>>>> Connecting an enterprise site to multiple ISPs using provider- >>>>> assigned addresses is difficult without the use of some form of >>>>> Network Address Translation (NAT). Much has been written on this >>>>> topic over the last 10 to 15 years, but it still remains a problem >>>>> without a clearly defined or widely implemented solution. Any >>>>> multihoming solution without NAT requires hosts at the site to have >>>>> addresses from each ISP and to select the egress ISP by selecting a >>>>> source address for outgoing packets. It also requires routers at the >>>>> site to take into account those source addresses when forwarding >>>>> packets out towards the ISPs. >>>>> >>>>> This document attempts to define a complete solution to this problem. >>>>> It covers the behavior of routers to forward traffic taking into >>>>> account source address, and it covers the behavior of host to select >>>>> appropriate source addresses. It also covers any possible role that >>>>> routers might play in providing information to hosts to help them >>>>> select appropriate source addresses. In the process of exploring >>>>> potential solutions, this documents also makes explicit requirements >>>>> for how the solution would be expected to behave from the perspective >>>>> of an enterprise site network administrator . >>>>> >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> -- SY, Jen Linkova aka Furry From nobody Tue Jul 12 02:32:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF85C12B026 for ; Tue, 12 Jul 2016 02:32:46 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LBTsI2qAd41Z for ; Tue, 12 Jul 2016 02:32:43 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 27819128874 for ; Tue, 12 Jul 2016 02:32:43 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f65so93807462wmi.0 for ; Tue, 12 Jul 2016 02:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qRoRsMNag+5iobyhy/Y7pHg72H9hYZY1qPtepKxxgss=; b=rW3esF3BQYY1azFupRkyt5riYnMiVXilq7aMFzyCPfHQ123A5foUc9zRZ52h6SR8fe ZPQAr/Mj78kgduANmPy3NwqNrvzuhZoQKhmudAZG5IjOFejYeqxwF91BbClwYqqmRsMi +asvmrZsxa9os4TW0DF7j9DKcpAlelGM7ApHQin5Hh8vQ79pSTOYKundguoHTfZUXMFM zPsCMFhE8nezSr04dkbguJ/ylVinQLym+ZyXoL7r5aiQKbOgKasGs5Da1SgTf6xQjP9o 57vVfdCrxfO9gp4Dw5u8UIJhhZsidWNjg4jE6pZ4fRgyyGXTPkWCStsUZT/GXUbbpxhc lYDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qRoRsMNag+5iobyhy/Y7pHg72H9hYZY1qPtepKxxgss=; b=jU+FCMib0o29MFB58sVH8LZ1W3olqGAAivDd+E50koj9FhJ5HySXTNKKgKM86TB4Sv DbTQqDLWPx+gRBK0cPC/HjgZoPxu/90q2M3HNOGRo7kU74k0agSJ/J2XIqlaHRGyWlPR AmkC0yzHMG8sj6I0H+aNc2UbUs8PNdGydL2PLsD3Z4aI5xXb0bk+pjU21T9xRowPFcQk QCF8LNBnLlZru3h1BNoZIJylCEgBMKY/nfhuONGku6QSwlfPmsgb7VXFs6v8nX30bckS mfffK4gBzuy3KHNMg9BkIt8ag8iIFs6CYWN/AlhyMVHvfSzqs/M42vharKCgrcZOujoz S+cg== X-Gm-Message-State: ALyK8tLKGOK8tL6CrjN0zfaX9eqjBNWK6AbrnDAHLRKgE398kq4r5AI1hMz4817bCLSusQ== X-Received: by 10.28.182.136 with SMTP id g130mr1826240wmf.21.1468315961457; Tue, 12 Jul 2016 02:32:41 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id b200sm2323731wmb.9.2016.07.12.02.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 02:32:40 -0700 (PDT) To: Jen Linkova References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <5130903e-f191-09fa-1d17-3f7ac908c38a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 12 Jul 2016 21:32:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , Chris Bowers Subject: Re: [v6ops] Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 09:32:47 -0000 in line... On 12/07/2016 20:44, Jen Linkova wrote: > On Tue, Jul 12, 2016 at 9:01 AM, Brian E Carpenter > wrote: >>>> Worse, section 4.2.4 says: >>>> >>>>> At the same time Router Advertisements provide a reliable mechanism >>>>> to influence source address selection process via PIO, RIO and >>>>> default router preferences. As all those options have been >>>>> standardized by IETF and are supported by various operating systems, >>>>> no changes are required on hosts. >>>> >>>> That's not true. The changes described in draft-ietf-6man-multi-homed-host >>>> *are* required. >>> >>> To be honest I'm a bit confused with the changes described in the Section 3.1 of >>> draft-ietf-6man-multi-homed-host... >>> Let's assume that >>> 1) first-hop routers behave as described in >>> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>> (SADR-capable routers which stop advertizing >>> themselves as default routers and/or withdraw the prefixes if source >>> address from that prefix should not be used) >>> 2) the host uses the rule 5.5 of the source address selection algorithm. >>> In that case would not any host which follows RFC6724 and RFC4191 >>> behave exactly as described in the Section 3.1 anyway? >>> (sorry for the stupid question, I feel like I'm missing smth here..). >> >> No, I think that's right, but today many hosts don't use rule 5.5 >> and many routers don't do SADR. We were trying to make the best of it. > > Ah, I see, it's more clear now, thanks for the explanation. > So basically the changes described in draft-ietf-6man-multi-homed-host > are required unless the network (and the first-hop routers in particular) > support SADR and the features described in > draft-bowbakova-rtgwg-enterprise-pa-multihoming. > > What if the Section 4.2.4 is re-phrased in the following way: > === old text=== > > At the same time Router Advertisements provide a reliable mechanism > to influence source address selection process via PIO, RIO and > default router preferences. As all those options have been > standardized by IETF and are supported by various operating systems, > no changes are required on hosts. First-hop routers in the > enterprise network need to be able of sending different RAs for > different SLAAC prefixes (either based on scoped forwarding tables or > based on pre-configured policies). > ===== new text ===== > At the same time Router Advertisements provide a reliable mechanism > to influence source address selection process via PIO, RIO and > default router preferences (all those options have been > standardized by IETF). In SADR-capable network where first-hop routers > are capable of sending different RAs for different SLAAC prefixes > (either based on scoped forwarding tables or > based on pre-configured policies), no changes in hosts behavior are > required. However to fully benefit of RA-based solution, > hosts are required to support RFC4191 and use the Rule 5.5 of source > address selection algorithm as specified in RFC6724. > If first-hop routers do not support SADR and scoped RAs as described > in the Section 4 of this document, hosts behavior needs to > be changed as described in draft-ietf-6man-multi-homed-host > ====== > > (Section 4.6 will be updated accordingly). > > What do you think? That looks good to me, assuming Fred agrees. Rgds Brian > >>From deployment perspective requesting a new feature from my router > vendor(s) and upgrading X (where X < 100 usually) routers is much > simpler than requesting a behavior change of thousands of end devices > (well, some of them might not support Rule 5.5 and RFC4191 but at > least some of them do...), especially in 'Bring Your Own Device' > model. IMHO it would be nice to make it clear in the document that > SADR helps deploying multihoming with minimal changes on hosts side > (comparing to changes required if the network is not SADR-capable). > >>>> Also, routers must be capable of sending PIOs with both >>>> L and A bits set to zero. >>> >>> Oh, I was not consider that as a special feature, assuming any router >>> should be capable of doing that. >>> Probably you are right and it should be explicitly mentioned, just in case... >> >> People have alleged that current routers won't do that. > > I'll update the text with the requirement, thanks! > >>> >>>> The same error occurs in section 4.6: >>>> >>>>> 1. no new (non-standard) functionality needs to be implemented on >>>>> hosts (except for [RFC4191] support); >>>> >>>> Section 5.1, shim6. While not disputing your conclusion, I think this is >>>> misleading: >>>> >>>>> We do not consider Shim6 to be a viable solution. It suffers from >>>>> the fact that it requires widespread deployment of Shim6 on hosts... >>>> >>>> It is a two-ended solution and we always knew that it could only be deployed >>>> incrementally and opportunistically; that was the plan, not a defect. The real >>>> defect is that the Internet is partly opaque to IPv6 extension headers, and >>>> therefore even incremental deployment of shim6 is not viable. (The same goes >>>> for HIP-based multihoming, which you don't mention.) >>> >>> Good point, I'll update the text with extension header issues. >>> >>>> >>>> Finally, it's helpful in site multihoming proposals to indicate whether >>>> they meet the goals in RFC 3582. >>> >>> Oh, thanks - we do list RFC3582 in the Normative References section >>> but there is no reference to it >>> in the text. Will be fixed! >>> >>> >>>> On 07/07/2016 04:33, Fred Baker (fred) wrote: >>>>> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. >>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> From: >>>>>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>>> Date: July 5, 2016 at 5:58:25 PM PDT >>>>>> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >>>>>> >>>>>> >>>>>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>>> has been successfully submitted by Fred Baker and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>>>>> Revision: 00 >>>>>> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >>>>>> Document date: 2016-07-05 >>>>>> Group: Individual Submission >>>>>> Pages: 44 >>>>>> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>>>>> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>>>>> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> Connecting an enterprise site to multiple ISPs using provider- >>>>>> assigned addresses is difficult without the use of some form of >>>>>> Network Address Translation (NAT). Much has been written on this >>>>>> topic over the last 10 to 15 years, but it still remains a problem >>>>>> without a clearly defined or widely implemented solution. Any >>>>>> multihoming solution without NAT requires hosts at the site to have >>>>>> addresses from each ISP and to select the egress ISP by selecting a >>>>>> source address for outgoing packets. It also requires routers at the >>>>>> site to take into account those source addresses when forwarding >>>>>> packets out towards the ISPs. >>>>>> >>>>>> This document attempts to define a complete solution to this problem. >>>>>> It covers the behavior of routers to forward traffic taking into >>>>>> account source address, and it covers the behavior of host to select >>>>>> appropriate source addresses. It also covers any possible role that >>>>>> routers might play in providing information to hosts to help them >>>>>> select appropriate source addresses. In the process of exploring >>>>>> potential solutions, this documents also makes explicit requirements >>>>>> for how the solution would be expected to behave from the perspective >>>>>> of an enterprise site network administrator . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Jul 12 04:10:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1091612D091 for ; Tue, 12 Jul 2016 04:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 YHbhBCAuVLi9 for ; Tue, 12 Jul 2016 04:09:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735D612D7BA for ; Tue, 12 Jul 2016 04:09:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6CB9StI008564; Tue, 12 Jul 2016 13:09:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 12A652046E5; Tue, 12 Jul 2016 13:09:28 +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 02DE42039C6; Tue, 12 Jul 2016 13:09:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6CB9RLx008935; Tue, 12 Jul 2016 13:09:27 +0200 From: Alexandre Petrescu To: Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> Message-ID: Date: Tue, 12 Jul 2016 13:09:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 11:09:50 -0000 Le 11/07/2016 à 19:33, Owen DeLong a écrit : > >> On Jul 11, 2016, at 03:43 , Alexandre Petrescu >> > > wrote: >> >> >> >> Le 08/07/2016 à 21:14, Joe Touch a écrit : >>> >>> >>> On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: >>>> ... I suppose it's not a coincidence that IEEE and IETF both >>>> call these addresses "all-nodes" but I have no trace of that. >>> >>> Let's get down to the authorities: >>> >>> IANA: >>> http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml >>> >>> >>> >>> IANA does assign addresses starting with 01-00-5E for link >>> multicast. IANA recognizes the use of 3-33-00-00-00-00 to >>> 33-33-FF-FF-FF-FF for IPv6 multicast. >> >> I wonder what IETF protocol 01-00-5E has been assigned for. >> >> It seems IANA has more authority over this address, and it is more >> likely to be unique. As such maybe it is better to use it for >> IPv6-over-foo documents, rather than 33-33-. > > 33-33 is a locally administered address. It is reasonable to presume > that any local admin who wants IPv6 to work on their network will not > conflict with 33-33 at this point. > > Remember, MAC addresses are replaced at each routing hop, so they > are only relevant on the local link. > > The full IANA MAC registry is here: > > http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml > > > > > Note that there are IANA assignments under 00-00-5E for non-multicast > purposes as well. > > > The procedure for updating that registry is here: > > https://tools.ietf.org/html/rfc7042 > > >> >>> IEEE: >>> http://standards.ieee.org/develop/regauth/grpmac/public.html >>> 01-80-C2-00-00-1B = all multicast-capable endsystems >>> 01-80-C2-00-00-1D = all multicast-capable intermediate systems >>> 01-80-C2-00-00-00..0F = assigned for 802.1Q *** this appears to >>> be where you might request an address for your protocol *** >> >> Right. > > I think using this range would be ill advised for this purpose. > > >> >> So this would be a 4th alternative for a multicast address for >> IPv6-over-80211OCB. Summarizing: >> >> - all 1s - 33-33- prefix (IANA local) > > Locally administered means that it is up to the owner of each link > to decide if they want to use this or not. > > IANA has suggested and there’s lots of code deployed that uses 33-33 > for IPv6 multicast. As such, any local administrator that wants IPv6 > to work on their network should probably respect this or expect a > fair amount of pain. > > I’d say that makes 33-33 fairly safe to use for any IPv6 multicast > need. > >> - 01-00-5E- prefix (IANA global) > > It appears that IANA is unlikely to use this for IPv6 and I suspect > that you will have a hard time getting agreement to allocate anything > special here for your intent. > >> - 01-80-C2- prefix (IEEE allocation) > > Since your protocol is an application sitting on top of TCP or UDP > or something else on top of IPv6, I think you are unlikely to get > much traction here as well. Even if you do, I think it’s an abuse of > the addresses. > >>> However, it's also defined as "never assigned" as NULL or >>> unintialized here: >>> https://standards.*ieee*.org/develop/.../eui48.pdf >>>> I am trying to identify the precise IEEE authoritative >>>> reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' >>>> address but I cant. >>> >>> Same here - still looking, but I see only IANA's assertion of >>> ownership based on an RFC. Nothing at the IEEE yet. >> >> If IEEE has no text about this 33-33- prefix then I think there can >> be problems. > > Nope… It’s locally administered meaning each segment owner can do > what they like. If they like IPv6, they’ll leave 33-33 alone for IPv6 > multicast. > > The worst that can happen is you end up with some stations receiving > packets they don’t want. > >> I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, >> ethertype] - does not get sent over the 802.11 media. I suspect >> there is a local adaptation layer in each WiFi computer which >> converts bidirectionaly between an Ethernet II header [dst, src, >> ethertype] and 802.11 frames: for each Ethernet II header there is >> a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS >> Data Header) plus an LLC header. And it's this tuple that gets >> sent over the 802.11 media, not the Ethernet II header. > > My understanding is that all happens in the hardware, so as far as > all of the system software is concerned, it’s sending and receiving > 802.3 frames to/from the interface. > >> The difference can be seen between captures in normal and monitor >> mode. >> >> RFC2464 is concerned only of that Ethernet II header captured in >> normal mode, even though it does not get sent over the air. >> >> However, there can be some detail lost when considering only the >> Ethernet II header. For example, if the 802.11 QoS Data Header is >> employed then some of its fields are invisible by the RFC2464 >> mapping process. However, these fields could be useful for the >> Traffic Class or Flow Label fields of the IPv6 header. > > In general that would be a layering violation anyway. > >> In some vehicular network trials the 802.11 QoS Data Header is >> used below a WSMP protocol (a network layer-free app-layer >> protocol). In these trials, if one considers the use of IPv6 below >> WSMP, then one has to consider the need of distinctive flows of IP >> datagrams (e.g. emergency). > > It’s unclear what you mean by “distinctive flows of IP datagrams”. For example an UDP/IP datagram carrying a warning approach would need to be transmitted distinctively from an UDP/IP datagram carrying an entertainment video frame. This could be achieved by a special value in an IPv6 Traffic Class field and in the QoS control fields of the IEEE 802.11 QoS Data header. >> It is also worth mentioning that the discrepancy between what the >> Ethernet II header has to offer and what many media need, can be >> seen not only on this 802.11-OCB mode for vehicles, but also by >> IoT documents at IETF describing adaptation layers for media like >> 802.15.4, lowpan, and more. > > Not everything is an 802.3 network. Non-802.3 networks require > different adaptation layers. > >> For these reasons I think 802.11 too deserves its own >> IPv6-over-80211 document at IETF. > > I’m not completely convinced of this as so far, I just learned a new argument for an IPv6-over-80211 document: 802.3 Ethernet uses an MTU 1500bytes. But 802.11 allows for larger MTUs. So why should IPv6-over-80211 restrain to only 1500bytes? (1500bytes is what RFC2464 requires). > you seem to be insisting on an approach of adapting IPv6 and 802.3 > multicast to your idea of how things should work rather than adapting > your application to the idea of how things actually work. For clarification: I do not propose an application. This is networking I am talking about. Adapting vehicular networking to the existing IPv6 networking has some problems. The problems we raise in this thread are really small. Think that other problems of this seem so huge to other people that they say IPv6 is not meaningful at all in vehicular networks - so WSMP/CAM/DENM/GN came to life. These protocols are application-glued-to-link protocols - i.e. no network-layer protocol at all. > I haven’t seen anything in any of your posts that leads me to > believe that the latter would not be the better approach. Well, it is not an application I am considering but networks - vehicular networks. There is a need to make run IPv6 between vehicles. >>>> - cavebear tells "33" to mean all IPv6 not only ND. >>>> >>>> Unfortunately none of these is my goals here. I am trying to >>>> just identify the right MAC multicast address for 802.11p below >>>> IPv6 (or IPv6-over-80211p if you wish). > > > The right solution is: > > 1.Use the correct IPv6 multicast group ID. If you want all nodes on > link, then that would be ff02::1. > > 2.Map that multicast group ID onto the IPv6 multicast MAC range. > Assuming ff02::1 as above, then this would be 33-33-0-0-0-1 Except that ff02 link scope has no meaning in 802.11-OCB networks - there is no ESSID, no Association operations, no link. >>>> But an IETF stds track document should tell which is the MAC >>>> multicast address on which to map some IP address. And it >>>> should be only one, and agreed by IEEE. >>> I think that's step 2; step 1 is getting the address from the >>> IEEE. > > Since IPv6 multicast uses a well defined set of “locally > administered” MAC addresses, there’s no need to involve IEEE. > > You can debate the validity of using 33-33 instead of getting an OUI > block as much as you want, but there’s a lot of running code out > there that is already using 33-33 without any issues. As such, I > think that’s a decision we just have to live with at this point. > > I certainly think that picking alternatives piecemeal protocol by > protocol or worse application by application is not a good approach. > >>>> Then we should go with "all-nodes" address (not all-OCB-nodes). >>>> But we need to know whether that is "33" MAC prefix or some >>>> other prefix. >>> >>> Agreed. > > If it is an IPv6 datagram, then it should be 33-33. If it is an IPv4 > datagram, then it should probably be ff-ff-ff-ff-ff-ff. If it’s > something else, then the IETF doesn’t really care and isn’t > involved. > > >>> Given you want to reach all 802.11p nodes, it seems like you >>> should want an MAC multicast address - but not an IP multicast >>> address. IP multicast is needed only to for IP-layer routing, not >>> for link layer. > > That’s not entirely true. All nodes on link (for example, ff02::1) > is definitely a link-layer communication for IPv6 that should not be > routed at the IP layer. > > There are reasons for interface and link scoped IPv6 multicast > addresses. > > Of course, if you want your packets routed, then you can use the > same group IDs with different scopes. > >> YEs, I need to have this MAC multicast address for >> IPv6-over-80211OCB: re-use an existing one? If yes which one? >> Allocate a new one? If yes where to ask? >> >> For IP multicast address, let's see a bit later. > > All of this is asked and answered. > > If your target is described already by a well known IPv6 multicast > address (it is, All-nodes on link, ff02::1) then use the appropriate > group ID (::1 in this case) and the appropriate scope (Link = 2). > The flags are 0 because (Reserved bit always 0, RP not embedded = 0, > Group not based on prefix = 0, Group not transiet = 0). So: > Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together > to form Address (ff02::1). Allow me repeat myself: the scopes 'link' and 'site' make little if any sense at all in networks of vehicles. > Once you have the IPv6 multicast address, then you simply map the > low order 32-bits onto the MAC prefix (33-33) and you get > (33-33-0-0-0-1). > > So for your stated purpose, it seems to me the best alternative is > destination: ff02::1 @ 33-33-0-0-0-1. > > There is nothing special here. > > Owen > > Noted. Alex From nobody Tue Jul 12 04:20:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5C412D095 for ; Tue, 12 Jul 2016 04:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 PRhfU6J4P39B for ; Tue, 12 Jul 2016 04:20:19 -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 51A35127071 for ; Tue, 12 Jul 2016 04:20:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6CBKAdp007623; Tue, 12 Jul 2016 13:20:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD5782056F8; Tue, 12 Jul 2016 13:20:10 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B4987204FFA; Tue, 12 Jul 2016 13:20:10 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6CBKAFj005890; Tue, 12 Jul 2016 13:20:10 +0200 To: "Fred Baker (fred)" References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> From: Alexandre Petrescu Message-ID: <6d4fe183-f47d-a1ad-1ca9-027ffa4c317a@gmail.com> Date: Tue, 12 Jul 2016 13:20:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 11:20:21 -0000 Le 11/07/2016 22:03, Fred Baker (fred) a crit : > >> On Jul 11, 2016, at 2:55 AM, Alexandre Petrescu >> wrote: >> >> First: which other 802 style networking? 802.3 Ethernet (rfc2464) >> or 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? > > https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11? Fred, After quickly skimming through it, the idea of mapping IP fields in 802.11 QoS fields as proposed in the above draft seem attractive to an IPv6-over-80211-OCB setting too. Use-cases in vehicular networks do pertain to such differentiation. For example an ambulance sending priority presence messages to all vehicles to make place. Some trials of vehicular networks in US make use of IEEE 802.11 QoS Headers (shown in a public website), although they dont yet employ IPv6 networking protocols. Alex From nobody Tue Jul 12 04:36:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A69912D7B9 for ; Tue, 12 Jul 2016 04:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 3h-d6I3RjODl for ; Tue, 12 Jul 2016 04:35:57 -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 1A83812D095 for ; Tue, 12 Jul 2016 04:35:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6CBZpRL015846; Tue, 12 Jul 2016 13:35:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 73EFA2056F8; Tue, 12 Jul 2016 13:35:51 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 63F00202786; Tue, 12 Jul 2016 13:35:51 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6CBZpVK014753; Tue, 12 Jul 2016 13:35:51 +0200 To: Joe Touch , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> From: Alexandre Petrescu Message-ID: <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> Date: Tue, 12 Jul 2016 13:35:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57840EEC.4070200@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 11:36:00 -0000 Le 11/07/2016 à 23:26, Joe Touch a écrit : > > > On 7/11/2016 3:43 AM, Alexandre Petrescu wrote: >> >> >> Le 08/07/2016 à 21:14, Joe Touch a écrit : >>> >>> >>> On 7/8/2016 6:52 AM, Alexandre Petrescu wrote: >>>> ... I suppose it's not a coincidence that IEEE and IETF both >>>> call these addresses "all-nodes" but I have no trace of that. >>> >>> Let's get down to the authorities: >>> >>> IANA: >>> http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml >>> >>> IANA does assign addresses starting with 01-00-5E for link >>> multicast. IANA recognizes the use of 3-33-00-00-00-00 to >>> 33-33-FF-FF-FF-FF for IPv6 multicast. >> >> I wonder what IETF protocol 01-00-5E has been assigned for. > > You don't need to wonder. Look further down that link: > > > IANA Multicast 48-bit MAC Addresses > > Note > > These values are prefixed with 01-00-5E. > > 00-00-00 to 7F-FF-FF IPv4 Multicast [RFC1112 > ] 80-00-00 to 8F-FF-FF MPLS > Multicast [RFC5332 ] 90-00-00 > MPLS-TP p2p [RFC7213 ] 90-00-01 > Bidirectional Forwarding Detection (BFD) on Link Aggregation Group > (LAG) Interfaces [RFC7130 ] 90-00-02 > AllL1MI-ISs [RFC6822 ] 90-00-03 > AllL2MI-ISs [RFC6822 ] 90-00-04 to > 90-00-FF Unassigned (small allocations) 90-01-00 TRILL OAM > [RFC7455 ] 90-01-01 to 90-01-FF > Unassigned (small allocations requiring both unicast and multicast) > 90-02-00 to 90-0F-FF Unassigned 90-10-00 to 90-10-FF Documentation > [RFC7042 ] 90-11-00 to FF-FF-FF > Unassigned > > Note that the only assignments in this block are for IETF-generated > L2 protocols. > >> >> It seems IANA has more authority over this address, and it is more >> likely to be unique. As such maybe it is better to use it for >> IPv6-over-foo documents, rather than 33-33-. > It may be, but it is still inappropriate for the use you're seeking, > IMO. > >> >>> IEEE: >>> http://standards.ieee.org/develop/regauth/grpmac/public.html >>> 01-80-C2-00-00-1B = all multicast-capable endsystems >>> 01-80-C2-00-00-1D = all multicast-capable intermediate systems >>> 01-80-C2-00-00-00..0F = assigned for 802.1Q *** this appears to >>> be where you might request an address for your protocol *** >> >> Right. >> >> So this would be a 4th alternative for a multicast address for >> IPv6-over-80211OCB. Summarizing: > > There should never be a multicast address for IPv6 over FOO for any > FOO that isn't a *protocol*. Sounds as a good principle. But what to do about the existing 33-33- prefix for Ethernet multicast groups for which there is no MAC multicast protocol (there is no MAC 'join' message like there is an IPv6 'join' REPORT MLD protocol). > Link layers are not protocols. But what to think about the title of all IPv6-over-foo RFCs saying "Transmission of IPv6 packets over XXX _Networks_". They are not link layers, nor protocols. >> - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA >> global) - 01-80-C2- prefix (IEEE allocation) >> >>> You also argued about "all 1's" not being Ethernet broadcast. It >>> is defined as exactly that on page 32 here: >>> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf >> >> Thanks for the reference. Yes, it's there. >> >>> However, it's also defined as "never assigned" as NULL or >>> unintialized here: >>> https://standards.*ieee*.org/develop/.../eui48.pdf >>>> I am trying to identify the precise IEEE authoritative >>>> reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' >>>> address but I cant. >>> >>> Same here - still looking, but I see only IANA's assertion of >>> ownership based on an RFC. Nothing at the IEEE yet. >> >> If IEEE has no text about this 33-33- prefix then I think there can >> be problems. > > As others have noted, the link local bit is set, which means it is > covered by IEEE specs as being locally managed. Yes, but this does not stop somebody from sending non-IP messages to 33-33- prefixed MAC dst addresses. Especially in settings where people dont want IPv6 because of presumably too much overhead. Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no conflict with non-IP protocols. (though it would be funny for IEEE to consider IPv6 as local opposed to global, while IPv6 too considers IEEE links as link scope as opposed to global Internet). >>>>> But the correct corresponding "all nodes" might be >>>>> appropriate: ff02::1 >>>> >>>> Yes, this IP "all-nodes" is very appropriate, I agree. >>>> >>>>>> - 33:33:00:00:00:01 - like IPv6-over-WiFi does >>>>> >>>>> All of the 33:33:: addresses are IPv6 multicast, as per RFC >>>>> 2464, but I don't see anywhere where any of these addresses >>>>> are assigned (or assignable) to a single protocol. >>>> >>>> Well, there are multiple things here. >>>> >>>> The 6-byte "33:33::" addresses are MAC addresses (not 16-byte >>>> IP addresses). >>> Yes - I was intending to say "the 33:33::" addresses are used >>> within IPv6 multicast as per RFC2464... >>> >>>> Curiously enough, they are defined in an IETF RFC (RFC 2464 >>>> "IPv6-over-Ethernet" lists hexa "3333"). I can not find them >>>> defined at IEEE even though there is an IEEE place listing IEEE >>>> MAC multicast addresses: >>>> https://standards.ieee.org/develop/regauth/grpmac/public.html >>>> >>>> It is curious because IETF should not define MAC address >>>> formats or contents, right? >>> >>> Agreed - I think there are a few of us looking, but if anyone >>> knows, please speak up! >>> >>>> As an additional curiosity, the well-known 'cavebear' registry >>>> lists 33-33 as an Ethernet Multicast Address: >>>> http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html >>>> >>>> >>>> as an "IPv6 Neighbor Discovery" explanation. >>>> >>>> It is curious because this "33-33-" MAC address is used below >>>> other IPv6 protocols like DHCPv6, not only Neighbor Discovery. >>> Yes. >>> >>>> >>>> To correct all these, the following can be proposed: >>>> >>>> - IETF define notation "33:33:0:0:0:0:1" (and not >>>> "33-33-0-0-0-0-1") to mean a 6-byte MAC address, and not an >>>> IPv6 address, despite the column use. >>> >>> Agreed. I think you meant "colon" rather than "column", though. >> >> YEs. This makes think writing an I-D title "IETF notation of MAC >> addresses" could make sense to avoid confusion. >> >> Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely >> used packet analyzer says "33:33:00:00:00:01". Common dialogue >> with the IPv6-versed tends to say "33:33::1". This may lead to >> confusion. >> >>>> - IEEE tells where is this "3333" address defined so we can see >>>> it publicly. >>> >>> Please! >>> >>>> - wikipedia stops writing wrong articles. >>> >>> Well, it is Wikipedia - if it's incorrect, we can change it... >>> >>>> - RFC2464 gets update to mean it also works on WiFi not only >>>> on Ethernet. >>> >>> I don't understand this at all. I thought WiFi was just a >>> variety wireless media layers over which 802 frames (colloquially >>> known as "ethernet") were sent. >> >> In principle it is that way. >> >> For introduction I believe there may be some detail that RFC2464 >> overlooks. >> >> I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, >> ethertype] - does not get sent over the 802.11 media. I suspect >> there is a local adaptation layer in each WiFi computer which >> converts bidirectionaly between an Ethernet II header [dst, src, >> ethertype] and 802.11 frames: for each Ethernet II header there is >> a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS >> Data Header) plus an LLC header. And it's this tuple that gets >> sent over the 802.11 media, not the Ethernet II header. > > IP is a payload to 802. What that layer ends up sending out over the > physical media doesn't matter to IP. Well but there are huge differences between 802.X variants when it comes to parameters relevant to IP like MTU, access control... >> The difference can be seen between captures in normal and monitor >> mode. >> >> RFC2464 is concerned only of that Ethernet II header captured in >> normal mode, even though it does not get sent over the air. > See above; that's normal layer separation. > >> >> However, there can be some detail lost when considering only the >> Ethernet II header. For example, if the 802.11 QoS Data Header is >> employed then some of its fields are invisible by the RFC2464 >> mapping process. However, these fields could be useful for the >> Traffic Class or Flow Label fields of the IPv6 header. > > See draft-szigeti-tsvwg-ieee-802-11e Noted. >> In some vehicular network trials the 802.11 QoS Data Header is >> used below a WSMP protocol (a network layer-free app-layer >> protocol). In these trials, if one considers the use of IPv6 below >> WSMP, then one has to consider the need of distinctive flows of IP >> datagrams (e.g. emergency). >> >> It is also worth mentioning that the discrepancy between what the >> Ethernet II header has to offer and what many media need, can be >> seen not only on this 802.11-OCB mode for vehicles, but also by >> IoT documents at IETF describing adaptation layers for media like >> 802.15.4, lowpan, and more. >> >> For these reasons I think 802.11 too deserves its own >> IPv6-over-80211 document at IETF. > > It might, as per the 802-11e doc above. But that's a long way from > necessarily needing a multicast MAC address assignment, either from > the IETF's managed block or directly from the IEEE. ... _If_ there is a new IPv6-over-80211 document then there is new discussion about it, with more parameters. Sure it's a long way. When that is settled then maybe IPv6-over-80211-OCB is much more straightforward. Or maybe just write an IPv6-over-80211-OCB like all other IPv6-over-foo which have inherited from RFC2464 and get it done. >>> You're either sending a link-layer routing protocol message >>> (e.g., like a IS-IS or Ethernet BPDUs) or you're sending an >>> Internet routing protocol (e.g., OSPF, RIP). Most Internet >>> routing protocols operate as "service" layers (i.e., >>> "applications"), i.e., inside UDP or TCP inside IP. >>> >>> Given you want to reach all 802.11p nodes, it seems like you >>> should want an MAC multicast address - but not an IP multicast >>> address. IP multicast is needed only to for IP-layer routing, not >>> for link layer. >> >> YEs, I need to have this MAC multicast address for >> IPv6-over-80211OCB: re-use an existing one? If yes which one? >> Allocate a new one? If yes where to ask? > You might start by having that discussion with the IEEE. > >> >> For IP multicast address, let's see a bit later. > > Sure - once you explain how what you need runs OVER IP. Sure. Alex > > Joe From nobody Tue Jul 12 08:01:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C55B12DB01 for ; Tue, 12 Jul 2016 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 PUm8ya_k-3au for ; Tue, 12 Jul 2016 08:01:20 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 8ED6F12DB03 for ; Tue, 12 Jul 2016 07:30:25 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6CEU8Sk018600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2016 07:30:09 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> From: Joe Touch Message-ID: <5784FEED.2040801@isi.edu> Date: Tue, 12 Jul 2016 07:30:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: u6CEU8Sk018600 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:01:23 -0000 On 7/12/2016 4:09 AM, Alexandre Petrescu wrote: >> It’s unclear what you mean by “distinctive flows of IP datagrams”. > > For example an UDP/IP datagram carrying a warning approach would need to > be transmitted distinctively from an UDP/IP datagram carrying an > entertainment video frame. This could be achieved by a special value in > an IPv6 Traffic Class field and in the QoS control fields of the IEEE > 802.11 QoS Data header. Agreed. It would be useful to understand whetehr the current 802.11 QoS mapping draft is sufficient for your needs. > >>> It is also worth mentioning that the discrepancy between what the >>> Ethernet II header has to offer and what many media need, can be >>> seen not only on this 802.11-OCB mode for vehicles, but also by >>> IoT documents at IETF describing adaptation layers for media like >>> 802.15.4, lowpan, and more. >> >> Not everything is an 802.3 network. Non-802.3 networks require >> different adaptation layers. >> >>> For these reasons I think 802.11 too deserves its own >>> IPv6-over-80211 document at IETF. >> >> I’m not completely convinced of this as so far, > > I just learned a new argument for an IPv6-over-80211 document: 802.3 > Ethernet uses an MTU 1500bytes. But 802.11 allows for larger MTUs. So > why should IPv6-over-80211 restrain to only 1500bytes? (1500bytes is > what RFC2464 requires). There appear to be several RFCs that set this limit for nearly every Ethernet based technology because IP deals with 802.2 (which is what I had intended to cite above) rather than the specific link technology except for QoS markings and configuration. >> you seem to be insisting on an approach of adapting IPv6 and 802.3 >> multicast to your idea of how things should work rather than adapting >> your application to the idea of how things actually work. > > For clarification: I do not propose an application. This is networking > I am talking about. In the above sentence, "application" is "the way you're using a network". You're not talking about just networking - you're talking about networking *used for intervehicular communications*. > > Adapting vehicular networking to the existing IPv6 networking has some > problems. Vehicular networking isn't a protocol, it's a use of protocols and networking for a purpose. > The problems we raise in this thread are really small. Think > that other problems of this seem so huge to other people that they say > IPv6 is not meaningful at all in vehicular networks - so > WSMP/CAM/DENM/GN came to life. These protocols are > application-glued-to-link protocols - i.e. no network-layer protocol > at all. > >> I haven’t seen anything in any of your posts that leads me to >> believe that the latter would not be the better approach. > > Well, it is not an application I am considering but networks - vehicular > networks. There is a need to make run IPv6 between vehicles. You need to find a way to describe your system in terms of protocols, not locations. We don't have different versions of IPv6 to run between 2-story and 3-story houses. > >>>>> - cavebear tells "33" to mean all IPv6 not only ND. >>>>> >>>>> Unfortunately none of these is my goals here. I am trying to >>>>> just identify the right MAC multicast address for 802.11p below >>>>> IPv6 (or IPv6-over-80211p if you wish). >> >> >> The right solution is: >> >> 1.Use the correct IPv6 multicast group ID. If you want all nodes on >> link, then that would be ff02::1. >> >> 2.Map that multicast group ID onto the IPv6 multicast MAC range. >> Assuming ff02::1 as above, then this would be 33-33-0-0-0-1 > > Except that ff02 link scope has no meaning in 802.11-OCB networks - > there is no ESSID, no Association operations, no link. If there's no link, then what do you mean above when you say this? > so > WSMP/CAM/DENM/GN came to life. These protocols are > application-glued-to-link protocols - i.e. no network-layer protocol > at all. If there is no link, there is no communication. Joe From nobody Tue Jul 12 08:07:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E5C12DB7C for ; Tue, 12 Jul 2016 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XPsbcpfBIHmA for ; Tue, 12 Jul 2016 08:07:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F612DBAC for ; Tue, 12 Jul 2016 07:37:38 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6CEaaHb030438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2016 07:36:36 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_C762489B-BB73-49F7-A1A0-860AF1EFA2F5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Tue, 12 Jul 2016 07:36:36 -0700 Message-Id: References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 12 Jul 2016 07:36:37 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:07:26 -0000 --Apple-Mail=_C762489B-BB73-49F7-A1A0-860AF1EFA2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> The right solution is: >>=20 >> 1.Use the correct IPv6 multicast group ID. If you want all nodes on >> link, then that would be ff02::1. >>=20 >> 2.Map that multicast group ID onto the IPv6 multicast MAC range. >> Assuming ff02::1 as above, then this would be 33-33-0-0-0-1 >=20 > Except that ff02 link scope has no meaning in 802.11-OCB networks - > there is no ESSID, no Association operations, no link. Sigh=E2=80=A6 We=E2=80=99ve been over this before, and it appears you = either are resistant to accepting reality or you just aren=E2=80=99t getting it. It=E2=80=99s = unclear which is the case. Link Scope means everything you can reach without crossing a router. So there is, in fact, a link anywhere there is an interface. It may be extremely variable what set of other vehicles are = participating in the same link at any given time due to differences in relative = position, propagation, interference, and other factors. There may not be = meaningful notification of host arrival on or departure from said link. = Nonetheless, there is, in fact, a link. I agree that the amorphous nature of who is =E2=80=9Con link=E2=80=9D = can present a variety of unique challenges to applications making use of such links, but it = doesn=E2=80=99t change the fact that there is a link. If you don=E2=80=99t like the Link scope and want to use a different = scope for your destination, that=E2=80=99s quite readily available as well. If you = don=E2=80=99t like any of the existing scopes, there are lots of undefined numbers for scopes = so perhaps you need to write up your new scope definitions in an I-D and = try to get numbers allocated to them. >> If your target is described already by a well known IPv6 multicast >> address (it is, All-nodes on link, ff02::1) then use the appropriate >> group ID (::1 in this case) and the appropriate scope (Link =3D 2). >> The flags are 0 because (Reserved bit always 0, RP not embedded =3D = 0, >> Group not based on prefix =3D 0, Group not transiet =3D 0). So: >> Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together >> to form Address (ff02::1). >=20 > Allow me repeat myself: the scopes 'link' and 'site' make little if = any > sense at all in networks of vehicles. Repeating the same incorrect assertion over and over doesn=E2=80=99t = make it any less incorrect. See above for =E2=80=98link=E2=80=99. Site is by definition an =E2=80=9Cadministratively defined=E2=80=9D = boundary determined by the configuration of routers participating within (and at the borders of) = the site, so while =E2=80=9CSite=E2=80=9D might not seem like a meaningful term in = your context, the ability to define a =E2=80=9Csite=E2=80=9D pretty much any way you choose makes = it a viable concept even if the term doesn=E2=80=99t fit comfortably. As I=E2=80=99ve said, if you have unique scope requirements, then = there=E2=80=99s a process by which you can attempt to get the IETF to allocate you a scope number = for those particular requirements. Nonetheless, it doesn=E2=80=99t change the relationship between the IPv6 = multicast address and the MAC address you should be using. The scope is not part of the last 32 bits of the group ID, so it won=E2=80= =99t change the MAC address. If you want All Nodes in (any possible scope), it=E2=80=99s still ff0x::1 and the MAC address is still 33-33-0-0-0-1. Owen --Apple-Mail=_C762489B-BB73-49F7-A1A0-860AF1EFA2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The right solution is:

1.Use the = correct IPv6 multicast group ID. If you want all nodes on
link, then that would be ff02::1.

2.Map that multicast group ID onto the IPv6 multicast MAC = range.
Assuming ff02::1 as above, then this would be = 33-33-0-0-0-1

Except that ff02 link scope has no = meaning in 802.11-OCB networks -
there is no ESSID, no Association = operations, no link.

Sigh=E2=80=A6 = We=E2=80=99ve been over this before, and it appears you either are = resistant
to accepting reality or you just aren=E2=80=99t = getting it. It=E2=80=99s unclear which is
the = case.

Link Scope means everything = you can reach without crossing a router.

So there is, in fact, a link anywhere there is an = interface.

It may be extremely = variable what set of other vehicles are participating
in the = same link at any given time due to differences in relative = position,
propagation, interference, and other factors. There = may not be meaningful
notification of host arrival on or = departure from said link. Nonetheless,
there is, in fact, a = link.

I agree that the amorphous = nature of who is =E2=80=9Con link=E2=80=9D can present a = variety
of unique challenges to applications making use of = such links, but it doesn=E2=80=99t
change the fact that there = is a link.

If you don=E2=80=99t like = the Link scope and want to use a different scope for = your
destination, that=E2=80=99s quite readily available as = well. If you don=E2=80=99t like any
of the existing scopes, = there are lots of undefined numbers for scopes so
perhaps you = need to write up your new scope definitions in an I-D and = try
to get numbers allocated to them.

If your target is described already by a well known IPv6 = multicast
address (it is, All-nodes on link, ff02::1) then = use the appropriate
group ID (::1 in this case) and the = appropriate scope (Link =3D 2).
The flags are 0 because = (Reserved bit always 0, RP not embedded =3D 0,
Group not = based on prefix =3D 0, Group not transiet =3D 0). So:
Multicast (ff), Flags (0) Scope (2) and Group ID (1) come = together
to form Address (ff02::1).

Allow me repeat myself: the scopes 'link' and = 'site' make little if any
sense at all in networks of = vehicles.

Repeating the = same incorrect assertion over and over doesn=E2=80=99t make it any = less
incorrect.

See above = for =E2=80=98link=E2=80=99.

Site is = by definition an =E2=80=9Cadministratively defined=E2=80=9D boundary = determined by the
configuration of routers participating = within (and at the borders of) the site,
so while =E2=80=9CSite=E2= =80=9D might not seem like a meaningful term in your context, the = ability
to define a =E2=80=9Csite=E2=80=9D pretty much any way = you choose makes it a viable concept
even if the term = doesn=E2=80=99t fit comfortably.

As = I=E2=80=99ve said, if you have unique scope requirements, then there=E2=80= =99s a process
by which you can attempt to get the IETF to = allocate you a scope number for
those particular = requirements.

Nonetheless, it = doesn=E2=80=99t change the relationship between the IPv6 = multicast
address and the MAC address you should be = using.

The scope is not part of the = last 32 bits of the group ID, so it won=E2=80=99t
change the = MAC address. If you want All Nodes in (any possible = scope),
it=E2=80=99s still ff0x::1 and the MAC address is = still 33-33-0-0-0-1.

Owen


= --Apple-Mail=_C762489B-BB73-49F7-A1A0-860AF1EFA2F5-- From nobody Tue Jul 12 08:10:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7903F12D9A9 for ; Tue, 12 Jul 2016 08:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 Qp7y_Eni-tLA for ; Tue, 12 Jul 2016 08:10:40 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 D195312D9B5 for ; Tue, 12 Jul 2016 07:41:24 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6CEenaM020189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2016 07:40:50 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> From: Joe Touch Message-ID: <5785016F.6010106@isi.edu> Date: Tue, 12 Jul 2016 07:40:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> Content-Type: multipart/alternative; boundary="------------080300010705020206010400" X-MailScanner-ID: u6CEenaM020189 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:10:41 -0000 This is a multi-part message in MIME format. --------------080300010705020206010400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/12/2016 4:35 AM, Alexandre Petrescu wrote: >> There should never be a multicast address for IPv6 over FOO for any >> FOO that isn't a *protocol*. > > Sounds as a good principle. But what to do about the existing 33-33- > prefix for Ethernet multicast groups for which there is no MAC multicast > protocol (there is no MAC 'join' message like there is an IPv6 'join' > REPORT MLD protocol). Then there is a link layer problem within the specification of that variant of ethernet. > >> Link layers are not protocols. > > But what to think about the title of all IPv6-over-foo RFCs saying > "Transmission of IPv6 packets over XXX _Networks_". They are not link > layers, nor protocols. These fall into a two groups: 1) link layers (ethernet, FDDI, token ring) 2) groups of link layers defined by a property of the link behavior that affects IPv6 (NBMA, IPv4 Domains without Explicit Tunnels) > ... >>> If IEEE has no text about this 33-33- prefix then I think there can >>> be problems. >> >> As others have noted, the link local bit is set, which means it is >> covered by IEEE specs as being locally managed. > > Yes, but this does not stop somebody from sending non-IP messages to > 33-33- prefixed MAC dst addresses. Especially in settings where people > dont want IPv6 because of presumably too much overhead. > > Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no conflict > with non-IP protocols. > > (though it would be funny for IEEE to consider IPv6 as local opposed to > global, while IPv6 too considers IEEE links as link scope as opposed to > global Internet). IPv6 operates over link local addressed links. ... >> IP is a payload to 802. What that layer ends up sending out over the >> physical media doesn't matter to IP. > > Well but there are huge differences between 802.X variants when it > comes to parameters relevant to IP like MTU, access control... As you already noted, IP interacts with the 802.2 LLC layer when it comes to MTU. If you want that fixed so IP can use different MTUs over different physical layers below 802.2, then you should take up that issue with the IEEE. The ways in which other 802.X variants are defined as interacting with IP in the IETF have typically been limited to configuration of the 802.X layer, e.g., setting 802.X QOS parameters or CAPWAP .... >>> For these reasons I think 802.11 too deserves its own >>> IPv6-over-80211 document at IETF. >> >> It might, as per the 802-11e doc above. But that's a long way from >> necessarily needing a multicast MAC address assignment, either from >> the IETF's managed block or directly from the IEEE. ... > > _If_ there is a new IPv6-over-80211 document then there is new > discussion about it, with more parameters. Sure it's a long way. > > When that is settled then maybe IPv6-over-80211-OCB is much more > straightforward. > > Or maybe just write an IPv6-over-80211-OCB like all other > IPv6-over-foo which have inherited from RFC2464 and get it done. You can, but you should look at 2464 to at least see the types of interactions that are specified. Joe --------------080300010705020206010400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/12/2016 4:35 AM, Alexandre Petrescu wrote:
There should never be a multicast address for IPv6 over FOO for any
FOO that isn't a *protocol*.

Sounds as a good principle.  But what to do about the existing 33-33-
prefix for Ethernet multicast groups for which there is no MAC multicast
protocol (there is no MAC 'join' message like there is an IPv6 'join'
REPORT MLD protocol).

Then there is a link layer problem within the specification of that variant of ethernet.


Link layers are not protocols.

But what to think about the title of all IPv6-over-foo RFCs saying
"Transmission of IPv6 packets over XXX _Networks_".  They are not link
layers, nor protocols.

These fall into a two groups:

1) link layers (ethernet, FDDI, token ring)

2) groups of link layers defined by a property of the link behavior that affects IPv6 (NBMA, IPv4 Domains without Explicit Tunnels)

...
If IEEE has no text about this 33-33- prefix then I think there can
be problems.

As others have noted, the link local bit is set, which means it is
covered by IEEE specs as being locally managed.

Yes, but this does not stop somebody from sending non-IP messages to
33-33- prefixed MAC dst addresses.  Especially in settings where people
dont want IPv6 because of presumably too much overhead.

Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no conflict
with non-IP protocols.

(though it would be funny for IEEE to consider IPv6 as local opposed to
global, while IPv6 too considers IEEE links as link scope as opposed to
global Internet).

IPv6 operates over link local addressed links.
...
IP is a payload to 802. What that layer ends up sending out over the
physical media doesn't matter to IP.

Well but there are huge differences between 802.X variants when it comes to parameters relevant to IP like MTU, access control...

As you already noted, IP interacts with the 802.2 LLC layer when it comes to MTU. If you want that fixed so IP can use different MTUs over different physical layers below 802.2, then you should take up that issue with the IEEE.

The ways in which other 802.X variants are defined as interacting with IP in the IETF have typically been limited to configuration of the 802.X layer, e.g., setting 802.X QOS parameters or CAPWAP
....
For these reasons I think 802.11 too deserves its own
IPv6-over-80211 document at IETF.

It might, as per the 802-11e doc above. But that's a long way from
necessarily needing a multicast MAC address assignment, either from
the IETF's managed block or directly from the IEEE. ...

_If_ there is a new IPv6-over-80211 document then there is new discussion about it, with more parameters.  Sure it's a long way.

When that is settled then maybe IPv6-over-80211-OCB is much more straightforward.

Or maybe just write an IPv6-over-80211-OCB like all other IPv6-over-foo which have inherited from RFC2464 and get it done.

You can, but you should look at 2464 to at least see the types of interactions that are specified.

Joe
--------------080300010705020206010400-- From nobody Tue Jul 12 08:23:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5812DAA0 for ; Tue, 12 Jul 2016 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8z4XmFv5aFsK for ; Tue, 12 Jul 2016 08:23:38 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 727F712DDD0 for ; Tue, 12 Jul 2016 07:57:15 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6CEuCKf000362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2016 07:56:13 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F944AD9A-79CE-4184-B91B-7E8DEA6DB1DB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> Date: Tue, 12 Jul 2016 07:56:12 -0700 Message-Id: <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 12 Jul 2016 07:56:13 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:23:51 -0000 --Apple-Mail=_F944AD9A-79CE-4184-B91B-7E8DEA6DB1DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>=20 >> There should never be a multicast address for IPv6 over FOO for any >> FOO that isn't a *protocol*. >=20 > Sounds as a good principle. But what to do about the existing 33-33- > prefix for Ethernet multicast groups for which there is no MAC = multicast > protocol (there is no MAC 'join' message like there is an IPv6 'join' > REPORT MLD protocol). Not relevant. The multicast bit being set in the ethernet address means that switches will flood it accordingly. IIRC, there is no effective difference between multicast and broadcast on the vast majority (all) = 802 media. In cases where there is some difference, it=E2=80=99s up to the = applicable hardware to do the right thing. This applies equally in all cases of multicast regardless of which multicast MAC range is used. >> Link layers are not protocols. >=20 > But what to think about the title of all IPv6-over-foo RFCs saying > "Transmission of IPv6 packets over XXX _Networks_". They are not link > layers, nor protocols. Nor do they define new MAC addresses. You are conflating different = things here. RFCs for link type adaptation are relatively common. That=E2=80=99s got = nothing to do with the mapping of MAC addresses. >>> - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA >>> global) - 01-80-C2- prefix (IEEE allocation) >>>=20 >>>> You also argued about "all 1's" not being Ethernet broadcast. It >>>> is defined as exactly that on page 32 here: >>>> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf >>>=20 >>> Thanks for the reference. Yes, it's there. >>>=20 >>>> However, it's also defined as "never assigned" as NULL or >>>> unintialized here: >>>> https://standards.*ieee*.org/develop/.../eui48.pdf >>>>> I am trying to identify the precise IEEE authoritative >>>>> reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' >>>>> address but I cant. >>>>=20 >>>> Same here - still looking, but I see only IANA's assertion of >>>> ownership based on an RFC. Nothing at the IEEE yet. >>>=20 >>> If IEEE has no text about this 33-33- prefix then I think there can >>> be problems. >>=20 >> As others have noted, the link local bit is set, which means it is >> covered by IEEE specs as being locally managed. >=20 > Yes, but this does not stop somebody from sending non-IP messages to > 33-33- prefixed MAC dst addresses. Especially in settings where = people > dont want IPv6 because of presumably too much overhead. So what? Your IPv6 stack should never see a non-IPv6 datagram. This is = no different than the days when we commonly ran Appletalk, NetBEUI, IPX, = and IP all at the same time on the same networks. It=E2=80=99s not like = every host had a separate MAC address for each protocol. The ethernet driver would pass the packet to the correct stack based on = the ethernet EtherType field if said stack was available on the machine. = If the machine didn=E2=80=99t have the applicable stack, the packet was = silently ignored. > Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no = conflict > with non-IP protocols. There=E2=80=99s no conflict anyway. The EtherType field of the ethernet = header insures this. The IEEE has allocated that number for IPv6 and = IIRC, it is 0x0800 for IPv4 and 0x86dd for IPv6. > (though it would be funny for IEEE to consider IPv6 as local opposed = to > global, while IPv6 too considers IEEE links as link scope as opposed = to > global Internet). IEEE links are by definition link scope. IEEE does not have any = definitions above layer 2. There=E2=80=99s no need for IEEE to consider IPv6 as anything other than = an EtherType. You seem quite lost in your fundamental understandings here. Perhaps it = is time to go back and read the Comer books. >> IP is a payload to 802. What that layer ends up sending out over the >> physical media doesn't matter to IP. >=20 > Well but there are huge differences between 802.X variants when it = comes to parameters relevant to IP like MTU, access control=E2=80=A6 MTU is not a huge variant and as long as it=E2=80=99s at least 1280, = IPv6 doesn=E2=80=99t really care. The MTU is just a parameter passed up = the stack which IPv6 adapts to whether the underlying link is 802.X or = some other medium. If the MTU is <1280, then the link adaptation layer must provide for = segmentation and reassembly. I=E2=80=99m not sure what you mean by =E2=80=9Caccess control=E2=80=9D = in an IP context, so you=E2=80=99ll have to explain. If you=E2=80=99re = talking about things like WPA for 802.11, then that is utterly and = completely irrelevant to IP and is strictly handled by the link = configuration before the IP stack is ever even started on the interface. Sure, there are a few link level parameters that have to be passed back = up to the IP stack to allow it to adapt to the underlying link. These are generally interface configuration parameters that are passed = to the IP stack when it is started on the interface. But that doesn=E2=80=99t require a different specification for IP to = adapt to each 802.x style link. >> It might, as per the 802-11e doc above. But that's a long way from >> necessarily needing a multicast MAC address assignment, either from >> the IETF's managed block or directly from the IEEE. ... >=20 > _If_ there is a new IPv6-over-80211 document then there is new = discussion about it, with more parameters. Sure it's a long way. >=20 > When that is settled then maybe IPv6-over-80211-OCB is much more = straightforward. You still haven=E2=80=99t provided any sort of coherent explanation why = IPv6 over 802.11OCB needs to be meaningfully different than IPv6 over = any other 802.x link. > Or maybe just write an IPv6-over-80211-OCB like all other = IPv6-over-foo which have inherited from RFC2464 and get it done. If you even need a separate document. So far, nothing you=E2=80=99ve = explained leads me to believe this is even necessary. Owen --Apple-Mail=_F944AD9A-79CE-4184-B91B-7E8DEA6DB1DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

There should never be a multicast address for = IPv6 over FOO for any
FOO that isn't a *protocol*.

Sounds as a good principle.  But what to do = about the existing 33-33-
prefix for Ethernet multicast groups for = which there is no MAC multicast
protocol (there is no MAC 'join' message = like there is an IPv6 'join'
REPORT MLD protocol).

Not relevant. The multicast bit being set in the = ethernet address means
that switches will flood it = accordingly. IIRC, there is no effective
difference between = multicast and broadcast on the vast majority (all) = 802
media.

In cases where = there is some difference, it=E2=80=99s up to the applicable = hardware
to do the right thing. This applies equally in all = cases of multicast
regardless of which multicast MAC range is = used.

Link layers are not protocols.

But what to think about = the title of all IPv6-over-foo RFCs saying
"Transmission of IPv6 packets over XXX = _Networks_".  They are not link
layers, nor protocols.

Nor do they define new MAC addresses. You are = conflating different things here.

RFCs= for link type adaptation are relatively common. That=E2=80=99s got = nothing to do
with the mapping of MAC addresses.

- all 1s - 33-33- prefix = (IANA local) - 01-00-5E- prefix (IANA
global) - 01-80-C2- = prefix (IEEE allocation)

You also argued about "all 1's" not being = Ethernet broadcast. It
is defined as exactly that on page = 32 here:
www.ieee802.org/secmail/pdfocSP2xXA6d.pdf

Thanks for the reference. =  Yes, it's there.

However, it's also defined as "never assigned" = as NULL or
unintialized here:
https://standards.*ieee*.org/develop/.../eui48.pdf
I am trying to identify = the precise IEEE authoritative
reference that says = "33-33-0-0-0-1" is the MAC 'all-nodes'
address but I = cant.

Same here - still = looking, but I see only IANA's assertion of
ownership = based on an RFC. Nothing at the IEEE yet.

If IEEE has no text about this 33-33- prefix then I think = there can
be problems.

As others have noted, the link local bit is set, which means = it is
covered by IEEE specs as being locally managed.

Yes, but this does not stop somebody from = sending non-IP messages to
33-33- prefixed MAC dst addresses. =  Especially in settings where people
dont want IPv6 because of presumably too = much overhead.

So what? Your = IPv6 stack should never see a non-IPv6 datagram. This is no different = than the days when we commonly ran Appletalk, NetBEUI, IPX, and IP all = at the same time on the same networks. It=E2=80=99s not like every host = had a separate MAC address for each protocol.

The ethernet driver would pass the packet to the = correct stack based on the ethernet EtherType field if said stack was = available on the machine. If the machine didn=E2=80=99t have the = applicable stack, the packet was silently ignored.

Were IEEE to state "33-33-" is for IPv6 then = we'd be sure of no conflict
with non-IP protocols.

There=E2=80=99s no conflict anyway. The EtherType field = of the ethernet header insures this. The IEEE has allocated that number = for IPv6 and IIRC, it is 0x0800 for IPv4 and 0x86dd for = IPv6.

(though it would be funny for IEEE to = consider IPv6 as local opposed to
global, while IPv6 too considers IEEE = links as link scope as opposed to
global Internet).

IEEE links are by definition link scope. IEEE does not = have any definitions above layer 2.

There=E2=80=99s no need for IEEE to consider IPv6 = as anything other than an EtherType.

You seem quite lost in your fundamental = understandings here. Perhaps it is time to go back and read the Comer = books.

IP is a payload to 802. What that layer ends up sending out = over the
physical media doesn't matter to IP.

Well but there are huge differences between = 802.X variants when it comes to parameters relevant to IP like MTU, = access control=E2=80=A6

MTU is not a huge variant and as long as it=E2=80=99s = at least 1280, IPv6 doesn=E2=80=99t really care. The MTU is just a = parameter passed up the stack which IPv6 adapts to whether the = underlying link is 802.X or some other medium.

If the MTU is <1280, then the link adaptation = layer must provide for segmentation and reassembly.

I=E2=80=99m not sure what you mean by =E2=80=9Cacces= s control=E2=80=9D in an IP context, so you=E2=80=99ll have to explain. = If you=E2=80=99re talking about things like WPA for 802.11, then that is = utterly and completely irrelevant to IP and is strictly handled by the = link configuration before the IP stack is ever even started on the = interface.

Sure, there are a few = link level parameters that have to be passed back up to the IP stack to = allow it to adapt to the underlying link.
These are generally = interface configuration parameters that are passed to the IP stack when = it is started on the interface.

But = that doesn=E2=80=99t require a different specification for IP to adapt = to each 802.x style link.


It might, as per the 802-11e doc above. But that's a long way = from
necessarily needing a multicast MAC address = assignment, either from
the IETF's managed block or = directly from the IEEE. ...

_If_ there is a new = IPv6-over-80211 document then there is new discussion about it, with = more parameters.  Sure it's a long way.

When that is settled then maybe = IPv6-over-80211-OCB is much more straightforward.

You still haven=E2=80=99t provided any sort of coherent = explanation why IPv6 over 802.11OCB needs to be meaningfully different = than IPv6 over any other 802.x link.

Or maybe just write an = IPv6-over-80211-OCB like all other IPv6-over-foo which have inherited = from RFC2464 and get it done.

If you even need = a separate document. So far, nothing you=E2=80=99ve explained leads me = to believe this is even necessary.

Owen


= --Apple-Mail=_F944AD9A-79CE-4184-B91B-7E8DEA6DB1DB-- From nobody Tue Jul 12 08:42:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE77612D123 for ; Tue, 12 Jul 2016 08:42:28 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KF_W6CBtRmJZ for ; Tue, 12 Jul 2016 08:42:27 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 00C2A12D9A1 for ; Tue, 12 Jul 2016 08:32:50 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id o80so30300226wme.1 for ; Tue, 12 Jul 2016 08:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hUXhmfuJlzc334S9ZZdseoaEdJep+kQXr/0v3mJb9eI=; b=UkEKeGzzgfLf4qg/NpuKAZsY0tafI+5/1Uz0a6XdctAqgqkZGHHDixQS+oW3I9lm4y XPSDDpFILt3JWphQgz8AF1msyAmZtROsFOZvaaRS2D99ntRH+idN3hntXcrfGAbJX3zj zXJ2ZinJQdh2Onu4aayKX8jWdEFBJNfKI6jqkuiBR4fEWi6CkWU8mxOjLR5KuwsOQoBo YM6NYpsUzLq9dBKNk4udrHPaM2rrcx+4jb420tJLXBwA4BI1Kq/ohAw5JsE7XfUQ8+QD wggKyWsXZu0K5kGqsOV9gFXgNxWATNSTI5GvJn11qMcl8tYACwX9BVVVPaQx7qlUDaAV IpmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hUXhmfuJlzc334S9ZZdseoaEdJep+kQXr/0v3mJb9eI=; b=KvoXQVVI5y/yiDLI/+y0+7pnQIrjzcbxvGb3WQSYLKNrBaOVzWZGVgt4cfqTmKroCr JrdlpU17kXJYh8nV8GjOEjZsF21iagHeoIFWFx6uK+gjtkAJeGkVvJ2W/9KsSBEV1zZ/ aqNLr+DDzNH7Bj+oA0aBQkSsHKB+e3g2XI+JE+V2xukd9hPRDrqNWT8InbxipKQ4CdaA 94TKD5MUQT/lejFTiIZTll8LFIP8dWSnnY6fYnBGA/vTyZ9+/Gn4J1OnkJROfLWjy/rd BOgL86qGJ8UOeI5kXqw/ghgUxP2q4D5KqJgoSkXAOG6/BS+Lm31DUQ9M/aQZUxqyQt2Z cv8A== X-Gm-Message-State: ALyK8tJiD7K0UKdo10KgQXrG1FI6NGWogv96V3xDazlFhdJtg6FyZK6MbBfgWrI5MkaYnA== X-Received: by 10.28.70.6 with SMTP id t6mr20010170wma.59.1468337569522; Tue, 12 Jul 2016 08:32:49 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id o142sm28918404wme.20.2016.07.12.08.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 08:32:48 -0700 (PDT) To: Alexandre Petrescu , "Fred Baker (fred)" References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <6d4fe183-f47d-a1ad-1ca9-027ffa4c317a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9098a4a4-a3cc-448b-39f8-ad964ed0a7ea@gmail.com> Date: Wed, 13 Jul 2016 03:32:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6d4fe183-f47d-a1ad-1ca9-027ffa4c317a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:42:29 -0000 On 12/07/2016 23:20, Alexandre Petrescu wrote: > Le 11/07/2016 =C3=A0 22:03, Fred Baker (fred) a =C3=A9crit : >> >>> On Jul 11, 2016, at 2:55 AM, Alexandre Petrescu >>> wrote: >>> >>> First: which other 802 style networking? 802.3 Ethernet (rfc2464) >>> or 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? >> >> https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11? >=20 > Fred, >=20 > After quickly skimming through it, the idea of mapping IP fields in > 802.11 QoS fields as proposed in the above draft seem attractive to an > IPv6-over-80211-OCB setting too. That particular wheel certainly only needs inventing once. >=20 > Use-cases in vehicular networks do pertain to such differentiation. Fo= r > example an ambulance sending priority presence messages to all vehicles= > to make place. However, don't fall into the trap of believing that IP diffserv is priori= ty- based. It is more subtle than that. Brian > Some trials of vehicular networks in US make use of IEEE 802.11 QoS > Headers (shown in a public website), although they dont yet employ IPv6= > networking protocols. >=20 > Alex >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Jul 13 07:03:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6C12D748 for ; Wed, 13 Jul 2016 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 6DJdXjI23R5e for ; Wed, 13 Jul 2016 07:03:41 -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 4977812D81D for ; Wed, 13 Jul 2016 07:03:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6DE3ZhH002963; Wed, 13 Jul 2016 16:03:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2CE2A20822C; Wed, 13 Jul 2016 16:03:35 +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 23FF82080DB; Wed, 13 Jul 2016 16:03:35 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6DE3YAD029529; Wed, 13 Jul 2016 16:03:35 +0200 To: Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> From: Alexandre Petrescu Message-ID: Date: Wed, 13 Jul 2016 16:03:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:03:46 -0000 Le 12/07/2016 à 16:56, Owen DeLong a écrit : >>> >>> There should never be a multicast address for IPv6 over FOO for >>> any FOO that isn't a *protocol*. >> >> Sounds as a good principle. But what to do about the existing >> 33-33- prefix for Ethernet multicast groups for which there is no >> MAC multicast protocol (there is no MAC 'join' message like there >> is an IPv6 'join' REPORT MLD protocol). > > Not relevant. The multicast bit being set in the ethernet address > means that switches will flood it accordingly. IIRC, there is no > effective difference between multicast and broadcast on the vast > majority (all) 802 media. If it's vast majority (all) hardware who are right then specs should no longer use this multicast concept as an ideal. > In cases where there is some difference, it’s up to the applicable > hardware to do the right thing. This applies equally in all cases of > multicast regardless of which multicast MAC range is used. > >>> Link layers are not protocols. >> >> But what to think about the title of all IPv6-over-foo RFCs saying >> "Transmission of IPv6 packets over XXX _Networks_". They are not >> link layers, nor protocols. > > Nor do they define new MAC addresses. You are conflating different > things here. > > RFCs for link type adaptation are relatively common. That’s got > nothing to do with the mapping of MAC addresses. There is some misunderstanding here about link layers, networks and mappings. But we may clarify later. >>>> - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA >>>> global) - 01-80-C2- prefix (IEEE allocation) >>>> >>>>> You also argued about "all 1's" not being Ethernet broadcast. >>>>> It is defined as exactly that on page 32 here: >>>>> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf >>>>> >>>> >>>> Thanks for the reference. Yes, it's there. >>>> >>>>> However, it's also defined as "never assigned" as NULL or >>>>> unintialized here: >>>>> https://standards.*ieee*.org/develop/.../eui48.pdf >>>>>> I am trying to identify the precise IEEE authoritative >>>>>> reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' >>>>>> address but I cant. >>>>> >>>>> Same here - still looking, but I see only IANA's assertion >>>>> of ownership based on an RFC. Nothing at the IEEE yet. >>>> >>>> If IEEE has no text about this 33-33- prefix then I think there >>>> can be problems. >>> >>> As others have noted, the link local bit is set, which means it >>> is covered by IEEE specs as being locally managed. >> >> Yes, but this does not stop somebody from sending non-IP messages >> to 33-33- prefixed MAC dst addresses. Especially in settings where >> people dont want IPv6 because of presumably too much overhead. > > So what? Your IPv6 stack should never see a non-IPv6 datagram. This > is no different than the days when we commonly ran Appletalk, > NetBEUI, IPX, and IP all at the same time on the same networks. It’s > not like every host had a separate MAC address for each protocol. > > The ethernet driver would pass the packet to the correct stack based > on the ethernet EtherType field if said stack was available on the > machine. If the machine didn’t have the applicable stack, the packet > was silently ignored. Yes, the ethertype helps to avoid some conflicts. In that sense upper layer processing would have further discarded, basing their decision on other fields. These checks may be consuming though. There are other collisions that would need to be avoided. A random generator of MAC addresses like the one used on WiFi on Windows 10 would need to discard output prefixed by 33-33-, such as to avoid someone using a privacy MAC addresses starting with 33-33-. It's not sufficient to just set the L bit. >> Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no >> conflict with non-IP protocols. > > There’s no conflict anyway. The EtherType field of the ethernet > header insures this. The IEEE has allocated that number for IPv6 and > IIRC, it is 0x0800 for IPv4 and 0x86dd for IPv6. > >> (though it would be funny for IEEE to consider IPv6 as local >> opposed to global, while IPv6 too considers IEEE links as link >> scope as opposed to global Internet). > > IEEE links are by definition link scope. IEEE does not have any > definitions above layer 2. > > There’s no need for IEEE to consider IPv6 as anything other than an > EtherType. But it's IEEE that should specify a random MAC address generator for privacy, not IETF, right? One doesnt want wireshark sniffers along roads to read all cars' constant MAC addresses passing by. One doesnt want to expose her constant MAC address to each other hotspot she visits. > You seem quite lost in your fundamental understandings here. Perhaps > it is time to go back and read the Comer books. > >>> IP is a payload to 802. What that layer ends up sending out over >>> the physical media doesn't matter to IP. >> >> Well but there are huge differences between 802.X variants when it >> comes to parameters relevant to IP like MTU, access control… > > MTU is not a huge variant and as long as it’s at least 1280, IPv6 > doesn’t really care. The MTU is just a parameter passed up the stack > which IPv6 adapts to whether the underlying link is 802.X or some > other medium. But new specs should not refrain from using larger MTUs if the links provided them. It's not because 1998 RFC2464 says that the default MTU size for Ethernet is 1500bytes that 802.11-OCB should say the same. Codec methods and their chip implementations evolved in 20 years, such as where wired Ethernet of 1998 was sending data at 10mbit/s at best, today wireless 802.11 can go as high as 10gb/s. > If the MTU is <1280, then the link adaptation layer must provide for > segmentation and reassembly. I agree with seg/reassembly aspect. > I’m not sure what you mean by “access control” in an IP context, so > you’ll have to explain. If you’re talking about things like WPA for > 802.11, then that is utterly and completely irrelevant to IP and is > strictly handled by the link configuration before the IP stack is > ever even started on the interface. And that link configuration is pre-conditioned by selecting an ESSID. The ESSID with strongest signal, the last ESSID used, a pre-recorded list of sorted ESSIDs, or interactive user selection from a scroll-down list, are all common methods to select an ESSID. But there's no link configuration without this ESSID. It's called "Network Name" in many GUIs. In networks like 802.11-OCB where one can't select an ESSID the entire link configuration is not happening. So there is no link. > Sure, there are a few link level parameters that have to be passed > back up to the IP stack to allow it to adapt to the underlying link. > These are generally interface configuration parameters that are > passed to the IP stack when it is started on the interface. > > But that doesn’t require a different specification for IP to adapt > to each 802.x style link. I disagree. >>> It might, as per the 802-11e doc above. But that's a long way >>> from necessarily needing a multicast MAC address assignment, >>> either from the IETF's managed block or directly from the IEEE. >>> ... >> >> _If_ there is a new IPv6-over-80211 document then there is new >> discussion about it, with more parameters. Sure it's a long way. >> >> When that is settled then maybe IPv6-over-80211-OCB is much more >> straightforward. > > You still haven’t provided any sort of coherent explanation why IPv6 > over 802.11OCB needs to be meaningfully different than IPv6 over any > other 802.x link. Well I am trying to with this ESSID but you seem to not understand what an ESSID is and how important is it in setting up 802.11 links. >> Or maybe just write an IPv6-over-80211-OCB like all other >> IPv6-over-foo which have inherited from RFC2464 and get it done. > > If you even need a separate document. So far, nothing you’ve > explained leads me to believe this is even necessary. I can further explain if necessary. Alex > > Owen > > From nobody Wed Jul 13 07:47:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0412DA13 for ; Wed, 13 Jul 2016 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 r4VwDJzODV5d for ; Wed, 13 Jul 2016 07:47:48 -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 110CB12D9BD for ; Wed, 13 Jul 2016 07:47:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6DElg6x004050; Wed, 13 Jul 2016 16:47:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F7542082FC; Wed, 13 Jul 2016 16:47:42 +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 8F7EE208225; Wed, 13 Jul 2016 16:47:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6DElgUv032569; Wed, 13 Jul 2016 16:47:42 +0200 To: Owen DeLong References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> From: Alexandre Petrescu Message-ID: <37d86819-601b-4f6a-23e7-082d74434b7f@gmail.com> Date: Wed, 13 Jul 2016 16:47:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:47:50 -0000 Le 12/07/2016 à 16:36, Owen DeLong a écrit : >>> The right solution is: >>> >>> 1.Use the correct IPv6 multicast group ID. If you want all nodes on >>> link, then that would be ff02::1. >>> >>> 2.Map that multicast group ID onto the IPv6 multicast MAC range. >>> Assuming ff02::1 as above, then this would be 33-33-0-0-0-1 >> >> Except that ff02 link scope has no meaning in 802.11-OCB networks - >> there is no ESSID, no Association operations, no link. > > Sigh… We’ve been over this before, and it appears you either are resistant > to accepting reality or you just aren’t getting it. It’s unclear which is > the case. > > Link Scope means everything you can reach without crossing a router. Sounds reasonable, and there may be more characteristics of a link scope as thought of in a wired Ethernet. 2. Two link scopes dont overlap, unless they are actually one single big link scope. 3. Everyone hears each other within a link scope. Each one of these 3 characteristics can be unfulfilled in an 802.11-OCB network. > So there is, in fact, a link anywhere there is an interface. Hm? But there is a different scope called "interface scope". > It may be extremely variable what set of other vehicles are participating > in the same link at any given time due to differences in relative position, > propagation, interference, and other factors. There may not be meaningful > notification of host arrival on or departure from said link. Nonetheless, > there is, in fact, a link. > > I agree that the amorphous nature of who is “on link” can present a variety > of unique challenges to applications making use of such links, but it > doesn’t change the fact that there is a link. But I think applications should not be exposed to these challenges of the link. > If you don’t like the Link scope and want to use a different scope for your > destination, that’s quite readily available as well. If you don’t like any > of the existing scopes, there are lots of undefined numbers for scopes so > perhaps you need to write up your new scope definitions in an I-D and try > to get numbers allocated to them. Ok, let's see about that later. >>> If your target is described already by a well known IPv6 multicast >>> address (it is, All-nodes on link, ff02::1) then use the appropriate >>> group ID (::1 in this case) and the appropriate scope (Link = 2). >>> The flags are 0 because (Reserved bit always 0, RP not embedded = 0, >>> Group not based on prefix = 0, Group not transiet = 0). So: >>> Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together >>> to form Address (ff02::1). >> >> Allow me repeat myself: the scopes 'link' and 'site' make little if any >> sense at all in networks of vehicles. > > Repeating the same incorrect assertion over and over doesn’t make it any > less > incorrect. > > See above for ‘link’. > > Site is by definition an “administratively defined” boundary determined > by the > configuration of routers participating within (and at the borders of) > the site, > so while “Site” might not seem like a meaningful term in your context, > the ability > to define a “site” pretty much any way you choose makes it a viable concept > even if the term doesn’t fit comfortably. > > As I’ve said, if you have unique scope requirements, then there’s a process > by which you can attempt to get the IETF to allocate you a scope number for > those particular requirements. > > Nonetheless, it doesn’t change the relationship between the IPv6 multicast > address and the MAC address you should be using. Yes, but there starts the multicast headache - at MAC layer. > > The scope is not part of the last 32 bits of the group ID, so it won’t > change the MAC address. If you want All Nodes in (any possible scope), > it’s still ff0x::1 and the MAC address is still 33-33-0-0-0-1. Noted. The formats you mention make think that: One couldnt get a scope (a ff0x number) for each centimeter-level radius circles around some map point, which is otherwise a perfectly fine GNSS resolution these days, and common talk "all taxis in Rose street". One couldnt get a Group ID (the last X-X-X-X in MAC) for each car kinds. Alex > > Owen > > From nobody Wed Jul 13 07:48:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CA612DA60 for ; Wed, 13 Jul 2016 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ljkefj6Ga7Lg for ; Wed, 13 Jul 2016 07:48:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD212DA57 for ; Wed, 13 Jul 2016 07:48:21 -0700 (PDT) Received: from [192.159.10.213] (delong-dhcp13 [192.159.10.213]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6DElHWl024934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2016 07:47:18 -0700 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 13 Jul 2016 07:47:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <411F8BB3-9A89-4FAE-A051-DAA20FC3F58A@delong.com> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> To: Alexandre Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 13 Jul 2016 07:47:18 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:48:24 -0000 > On Jul 13, 2016, at 07:03, Alexandre Petrescu wrote: >=20 >=20 >=20 > Le 12/07/2016 =A8=A4 16:56, Owen DeLong a =A8=A6crit : >>>>=20 >>>> There should never be a multicast address for IPv6 over FOO for >>>> any FOO that isn't a *protocol*. >>>=20 >>> Sounds as a good principle. But what to do about the existing >>> 33-33- prefix for Ethernet multicast groups for which there is no >>> MAC multicast protocol (there is no MAC 'join' message like there >>> is an IPv6 'join' REPORT MLD protocol). >>=20 >> Not relevant. The multicast bit being set in the ethernet address >> means that switches will flood it accordingly. IIRC, there is no >> effective difference between multicast and broadcast on the vast >> majority (all) 802 media. >=20 > If it's vast majority (all) hardware who are right then specs should no > longer use this multicast concept as an ideal. >=20 At least some switches make use of MLD snooping and other techniques to opti= mize flooding.=20 >> In cases where there is some difference, it=A1=AFs up to the applicable >> hardware to do the right thing. This applies equally in all cases of >> multicast regardless of which multicast MAC range is used. >>=20 >>>> Link layers are not protocols. >>>=20 >>> But what to think about the title of all IPv6-over-foo RFCs saying >>> "Transmission of IPv6 packets over XXX _Networks_". They are not >>> link layers, nor protocols. >>=20 >> Nor do they define new MAC addresses. You are conflating different >> things here. >>=20 >> RFCs for link type adaptation are relatively common. That=A1=AFs got >> nothing to do with the mapping of MAC addresses. >=20 > There is some misunderstanding here about link layers, networks and > mappings. But we may clarify later. If there is, I assure you it is on your end.=20 >=20 >>>>> - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA >>>>> global) - 01-80-C2- prefix (IEEE allocation) >>>>>=20 >>>>>> You also argued about "all 1's" not being Ethernet broadcast. >>>>>> It is defined as exactly that on page 32 here: >>>>>> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf >>>>>> >>>>>=20 >>>>> Thanks for the reference. Yes, it's there. >>>>>=20 >>>>>> However, it's also defined as "never assigned" as NULL or >>>>>> unintialized here: >>>>>> https://standards.*ieee*.org/develop/.../eui48.pdf >>>>>>> I am trying to identify the precise IEEE authoritative >>>>>>> reference that says "33-33-0-0-0-1" is the MAC 'all-nodes' >>>>>>> address but I cant. >>>>>>=20 >>>>>> Same here - still looking, but I see only IANA's assertion >>>>>> of ownership based on an RFC. Nothing at the IEEE yet. >>>>>=20 >>>>> If IEEE has no text about this 33-33- prefix then I think there >>>>> can be problems. >>>>=20 >>>> As others have noted, the link local bit is set, which means it >>>> is covered by IEEE specs as being locally managed. >>>=20 >>> Yes, but this does not stop somebody from sending non-IP messages >>> to 33-33- prefixed MAC dst addresses. Especially in settings where >>> people dont want IPv6 because of presumably too much overhead. >>=20 >> So what? Your IPv6 stack should never see a non-IPv6 datagram. This >> is no different than the days when we commonly ran Appletalk, >> NetBEUI, IPX, and IP all at the same time on the same networks. It=A1=AFs= >> not like every host had a separate MAC address for each protocol. >>=20 >> The ethernet driver would pass the packet to the correct stack based >> on the ethernet EtherType field if said stack was available on the >> machine. If the machine didn=A1=AFt have the applicable stack, the packet= >> was silently ignored. >=20 > Yes, the ethertype helps to avoid some conflicts. In that sense upper > layer processing would have further discarded, basing their decision on > other fields. These checks may be consuming though. The ether type check is not consuming.=20 >=20 > There are other collisions that would need to be avoided. > A random generator of MAC addresses like the one used on WiFi on Windows > 10 would need to discard output prefixed by 33-33-, such as to avoid > someone using a privacy MAC addresses starting with 33-33-. It's not > sufficient to just set the L bit. Privacy MAC addresses would never conflict because they are Unicast and ther= efore would not set the multicast bit. Your argument here is nonsensical.=20= If it's not IPv6, then ether type field eliminates conflict. If it is IPv6, t= hen it is IPv6 multicast and there is no conflict because that is the Intend= ed use.=20 >=20 >>> Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no >>> conflict with non-IP protocols. >>=20 >> There=A1=AFs no conflict anyway. The EtherType field of the ethernet >> header insures this. The IEEE has allocated that number for IPv6 and >> IIRC, it is 0x0800 for IPv4 and 0x86dd for IPv6. >>=20 >>> (though it would be funny for IEEE to consider IPv6 as local >>> opposed to global, while IPv6 too considers IEEE links as link >>> scope as opposed to global Internet). >>=20 >> IEEE links are by definition link scope. IEEE does not have any >> definitions above layer 2. >>=20 >> There=A1=AFs no need for IEEE to consider IPv6 as anything other than an >> EtherType. >=20 > But it's IEEE that should specify a random MAC address generator for > privacy, not IETF, right? No. Random privacy addresses also have the locally administered bit set so t= hey are by definition bit IEEE administered.=20 IEEE only specifies globally unique OUIs.=20 >=20 > One doesnt want wireshark sniffers along roads to read all cars' > constant MAC addresses passing by. I'm not sure how you intend to avoid that.=20 >=20 > One doesnt want to expose her constant MAC address to each other hotspot > she visits. Good luck with that.=20 >=20 >> You seem quite lost in your fundamental understandings here. Perhaps >> it is time to go back and read the Comer books. >>=20 >>>> IP is a payload to 802. What that layer ends up sending out over >>>> the physical media doesn't matter to IP. >>>=20 >>> Well but there are huge differences between 802.X variants when it >>> comes to parameters relevant to IP like MTU, access control=A1=AD >>=20 >> MTU is not a huge variant and as long as it=A1=AFs at least 1280, IPv6 >> doesn=A1=AFt really care. The MTU is just a parameter passed up the stack= >> which IPv6 adapts to whether the underlying link is 802.X or some >> other medium. >=20 > But new specs should not refrain from using larger MTUs if the links > provided them. Sure, but that doesn't require an RFC or any new document. It's just a param= eter passed up the stack when IPv6 is started on the interface.=20 >=20 > It's not because 1998 RFC2464 says that the default MTU size for > Ethernet is 1500bytes that 802.11-OCB should say the same. Even modern Ethernet has jumbo frames and they work just fine. Default is ju= st that. You can always configure a different value if it is supported by pa= rticipating implementations.=20 >=20 > Codec methods and their chip implementations evolved in 20 years, such > as where wired Ethernet of 1998 was sending data at 10mbit/s at best, > today wireless 802.11 can go as high as 10gb/s. >=20 Your point being? >> If the MTU is <1280, then the link adaptation layer must provide for >> segmentation and reassembly. >=20 > I agree with seg/reassembly aspect. >=20 >> I=A1=AFm not sure what you mean by =A1=B0access control=A1=B1 in an IP co= ntext, so >> you=A1=AFll have to explain. If you=A1=AFre talking about things like WPA= for >> 802.11, then that is utterly and completely irrelevant to IP and is >> strictly handled by the link configuration before the IP stack is >> ever even started on the interface. >=20 > And that link configuration is pre-conditioned by selecting an ESSID. The E= SSID with strongest signal, the last ESSID used, a pre-recorded list of sort= ed ESSIDs, or interactive user selection from a scroll-down list, are all co= mmon methods to select an ESSID. But there's no > link configuration without this ESSID. It's called "Network Name" in many= GUIs. >=20 In conventional 802.11 this is true because IP is not started until a networ= k is associated. However, the defining event is starting the IP stack on the= interface. The ESSID and/or AP association are merely a coincidental prereq= uisite to that start in existing 802.11 implementations.=20 Obviously an OCB implementation would require starting the IP stack (and thu= s the link configuration) without association.=20 > In networks like 802.11-OCB where one can't select an ESSID the entire > link configuration is not happening. So there is no link. There's also no ip stack starting so you've got some work to do there. Howev= er, once you are starting the IP stack, you'll have link configuration happe= ning, so I'm not sure why you think this is an issue.=20 >=20 >> Sure, there are a few link level parameters that have to be passed >> back up to the IP stack to allow it to adapt to the underlying link. >> These are generally interface configuration parameters that are >> passed to the IP stack when it is started on the interface. >>=20 >> But that doesn=A1=AFt require a different specification for IP to adapt >> to each 802.x style link. >=20 > I disagree. Feel free, but disagreeing with an existing fact (many 802 networks run just= fine without their own adaptation layer RFCs) seems rather silly.=20 >=20 >>>> It might, as per the 802-11e doc above. But that's a long way >>>> from necessarily needing a multicast MAC address assignment, >>>> either from the IETF's managed block or directly from the IEEE. >>>> ... >>>=20 >>> _If_ there is a new IPv6-over-80211 document then there is new >>> discussion about it, with more parameters. Sure it's a long way. >>>=20 >>> When that is settled then maybe IPv6-over-80211-OCB is much more >>> straightforward. >>=20 >> You still haven=A1=AFt provided any sort of coherent explanation why IPv6= >> over 802.11OCB needs to be meaningfully different than IPv6 over any >> other 802.x link. >=20 > Well I am trying to with this ESSID but you seem to not understand what an= ESSID is and how important is it in setting up 802.11 links. I understand completely. You are the one who is confused because you are put= ting a lot of nonexistent meaning on ESSID (and more accurately association)= which isn't real. What is real is that existing implementations don't start= the IP stack until after association. I took it as a given that you knew th= is and that you knew OCB would have to start the IP stack without associatio= n.=20 Perhaps clarifying this will allow you to see things as they are.=20 >=20 >>> Or maybe just write an IPv6-over-80211-OCB like all other >>> IPv6-over-foo which have inherited from RFC2464 and get it done. >>=20 >> If you even need a separate document. So far, nothing you=A1=AFve >> explained leads me to believe this is even necessary. >=20 > I can further explain if necessary. Hopefully you now further understand and further explanation is unnecessary.= But feel free to further explain if you think there is something useful to e= xplain.=20 Owen >=20 > Alex >=20 >>=20 >> Owen >>=20 >>=20 From nobody Wed Jul 13 08:20:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4CD12D85E for ; Wed, 13 Jul 2016 08:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 p8-t3jnVmx2m for ; Wed, 13 Jul 2016 08:20:00 -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 D780012D105 for ; Wed, 13 Jul 2016 08:19:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6DFJrgP024600; Wed, 13 Jul 2016 17:19:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B7B4F20836B; Wed, 13 Jul 2016 17:19:53 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A76B220830E; Wed, 13 Jul 2016 17:19:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6DFJrxL006913; Wed, 13 Jul 2016 17:19:53 +0200 To: Owen DeLong References: <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> <411F8BB3-9A89-4FAE-A051-DAA20FC3F58A@delong.com> From: Alexandre Petrescu Message-ID: <0e6a425c-23f9-371c-5cb5-247cafad50ef@gmail.com> Date: Wed, 13 Jul 2016 17:19:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <411F8BB3-9A89-4FAE-A051-DAA20FC3F58A@delong.com> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:20:02 -0000 Owen, Le 13/07/2016 16:47, Owen DeLong a crit : [...] >> Yes, the ethertype helps to avoid some conflicts. In that sense >> upper layer processing would have further discarded, basing their >> decision on other fields. These checks may be consuming though. > > The ether type check is not consuming. It depends how fast one wants it done. >> There are other collisions that would need to be avoided. > > >> A random generator of MAC addresses like the one used on WiFi on >> Windows 10 would need to discard output prefixed by 33-33-, such >> as to avoid someone using a privacy MAC addresses starting with >> 33-33-. It's not sufficient to just set the L bit. > > Privacy MAC addresses would never conflict because they are Unicast > and therefore would not set the multicast bit. Your argument here is > nonsensical. Right, that's true. Privacy MAC addresses would have the unicast bit set. [...] >> One doesnt want wireshark sniffers along roads to read all cars' >> constant MAC addresses passing by. > > I'm not sure how you intend to avoid that. For privacy reasons people dont want others know their car was there at that time. (dont expose the OUI, dont expose always same MAC). >> One doesnt want to expose her constant MAC address to each other >> hotspot she visits. > > Good luck with that. You mean Apple is not doing that already? [...] >> But new specs should not refrain from using larger MTUs if the >> links provided them. > > Sure, but that doesn't require an RFC or any new document. It's just > a parameter passed up the stack when IPv6 is started on the > interface. It's not the MTU alone which requires a new document, it's many other things that we discussed, not the least important being that RFC2464 that everybody seems to love is outdated. >> It's not because 1998 RFC2464 says that the default MTU size for >> Ethernet is 1500bytes that 802.11-OCB should say the same. > > Even modern Ethernet has jumbo frames and they work just fine. > Default is just that. You can always configure a different value if > it is supported by participating implementations. If you want to configure some other MTU one has to go to the router and configure it in the RA, make sure you put in the MTU variable some value safely understood by each past present and future neighbor - it's a pain. >> Codec methods and their chip implementations evolved in 20 years, >> such as where wired Ethernet of 1998 was sending data at 10mbit/s >> at best, today wireless 802.11 can go as high as 10gb/s. >> > > Your point being? RFC2464 is outdated. [...] >>> Im not sure what you mean by access control in an IP context, >>> so youll have to explain. If youre talking about things like >>> WPA for 802.11, then that is utterly and completely irrelevant >>> to IP and is strictly handled by the link configuration before >>> the IP stack is ever even started on the interface. >> >> And that link configuration is pre-conditioned by selecting an >> ESSID. The ESSID with strongest signal, the last ESSID used, a >> pre-recorded list of sorted ESSIDs, or interactive user selection >> from a scroll-down list, are all common methods to select an >> ESSID. But there's no link configuration without this ESSID. It's >> called "Network Name" in many GUIs. >> > > In conventional 802.11 this is true because IP is not started until > a network is associated. However, the defining event is starting the > IP stack on the interface. The ESSID and/or AP association are merely > a coincidental prerequisite to that start in existing 802.11 > implementations. > > Obviously an OCB implementation would require starting the IP stack > (and thus the link configuration) without association. True, but there is additional operation in 802.11-OCB. In 802.11-OCB one has to first manually select one of 6 channels on the Host precisely the same as on the Router. Then put the interface up and the IP stack gets configured if it receives a Router Advertisement. In a lab setting that's all. In a road setting a car receives RAs from multiple Routers in that channel; it has no idea which one is a car, an LTE car, or a road-side unit giving access to Internet. This car obviously shouldnt self-configure an address and default route from each of the received RAs. This problem does not exist in other 802.11-X: the computer self-configures an address and a default route only from the RA received from the router on the same ESSID. The admin makes sure there is only one router on that ESSID. Do not think a channel is same as ESSID: whereas one can create an unlimited number of ESSIDs the channels are regulated to be only 6 (and only 1 really powerful). >> In networks like 802.11-OCB where one can't select an ESSID the >> entire link configuration is not happening. So there is no link. > > There's also no ip stack starting so you've got some work to do > there. However, once you are starting the IP stack, you'll have link > configuration happening, so I'm not sure why you think this is an > issue. Because the link configuration that is happening: 1. has to be preceded by manual selection of a channel. There is no automation of this selection like there is automated ESSID selection with user-preferences, last network, or strongest signal. 2. leads to links with an unmanaged number of prefixes and default routers on them. The number can not be managed like it is managed by admins setting ESSIDs and routers on them. [...] >>> You still havent provided any sort of coherent explanation why >>> IPv6 over 802.11OCB needs to be meaningfully different than IPv6 >>> over any other 802.x link. >> >> Well I am trying to with this ESSID but you seem to not understand >> what an ESSID is and how important is it in setting up 802.11 >> links. > > I understand completely. You are the one who is confused because you > are putting a lot of nonexistent meaning on ESSID (and more > accurately association) which isn't real. What is real is that > existing implementations don't start the IP stack until after > association. I took it as a given that you knew this and that you > knew OCB would have to start the IP stack without association. > > Perhaps clarifying this will allow you to see things as they are. In networks where ESSIDs are used the number of Routers and what gets advertised is limited by sysadmins within the scope of a unique ESSID. Without that the WiFi networks would be a complete mess. Alex From nobody Wed Jul 13 08:23:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA80512D838 for ; Wed, 13 Jul 2016 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jc9GKkM71YUz for ; Wed, 13 Jul 2016 08:22:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 553B912D9BA for ; Wed, 13 Jul 2016 08:22:53 -0700 (PDT) Received: from [192.159.10.213] (delong-dhcp13 [192.159.10.213]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6DFLnxx027634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2016 08:21:50 -0700 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (13F69) In-Reply-To: <37d86819-601b-4f6a-23e7-082d74434b7f@gmail.com> Date: Wed, 13 Jul 2016 08:21:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <840BB0F2-FDC3-4522-A328-3415B01C5EAB@delong.com> References: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <9083B61F-A594-40B9-B13B-12E3836D4844@delong.com> <37d86819-601b-4f6a-23e7-082d74434b7f@gmail.c! om> To: Alexandre Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 13 Jul 2016 08:21:50 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:23:00 -0000 > On Jul 13, 2016, at 07:47, Alexandre Petrescu wrote: >=20 >=20 >=20 > Le 12/07/2016 =A8=A4 16:36, Owen DeLong a =A8=A6crit : >>>> The right solution is: >>>>=20 >>>> 1.Use the correct IPv6 multicast group ID. If you want all nodes on >>>> link, then that would be ff02::1. >>>>=20 >>>> 2.Map that multicast group ID onto the IPv6 multicast MAC range. >>>> Assuming ff02::1 as above, then this would be 33-33-0-0-0-1 >>>=20 >>> Except that ff02 link scope has no meaning in 802.11-OCB networks - >>> there is no ESSID, no Association operations, no link. >>=20 >> Sigh=A1=AD We=A1=AFve been over this before, and it appears you either ar= e resistant >> to accepting reality or you just aren=A1=AFt getting it. It=A1=AFs unclea= r which is >> the case. >>=20 >> Link Scope means everything you can reach without crossing a router. >=20 > Sounds reasonable, and there may be more characteristics of a link scope a= s thought of in a wired Ethernet. >=20 > 2. Two link scopes dont overlap, unless they are actually one single > big link scope. >=20 This is usually, though not always true, but you cannot count on it.=20 > 3. Everyone hears each other within a link scope. >=20 By definition.=20 > Each one of these 3 characteristics can be unfulfilled in an 802.11-OCB ne= twork. >=20 Nope. Not true. Item 2 isn't actually valid, even in some wired Ethernet cas= es (think PVLAN implementations for example).=20 Item 1 and 3 apply equally to OCB. The difference is that the members of any= given link are far more transient in OCB than in most 802.11 implementation= s. While that may pose unique challenges to applications running over IPv6 o= ver OCB, it doesn't change the existence of not the behavior of a link.=20 >> So there is, in fact, a link anywhere there is an interface. >=20 > Hm? But there is a different scope called "interface scope". Yes... The interface scope only reaches applications listening on the same i= nterface on the local host. It never actually departs the machine. >> It may be extremely variable what set of other vehicles are participating= >> in the same link at any given time due to differences in relative positio= n, >> propagation, interference, and other factors. There may not be meaningful= >> notification of host arrival on or departure from said link. Nonetheless,= >> there is, in fact, a link. >>=20 >> I agree that the amorphous nature of who is =A1=B0on link=A1=B1 can prese= nt a variety >> of unique challenges to applications making use of such links, but it >> doesn=A1=AFt change the fact that there is a link. >=20 > But I think applications should not be exposed to these challenges of the l= ink. How would you avoid it? When a laptop leaves an 802.11ac network, the other h= osts on that link are no longer able to communicate with it there.=20 I presume it would be the same for an OCB network.=20 >=20 >> If you don=A1=AFt like the Link scope and want to use a different scope f= or your >> destination, that=A1=AFs quite readily available as well. If you don=A1=AF= t like any >> of the existing scopes, there are lots of undefined numbers for scopes so= >> perhaps you need to write up your new scope definitions in an I-D and try= >> to get numbers allocated to them. >=20 > Ok, let's see about that later. >=20 >>>> If your target is described already by a well known IPv6 multicast >>>> address (it is, All-nodes on link, ff02::1) then use the appropriate >>>> group ID (::1 in this case) and the appropriate scope (Link =3D 2). >>>> The flags are 0 because (Reserved bit always 0, RP not embedded =3D 0, >>>> Group not based on prefix =3D 0, Group not transiet =3D 0). So: >>>> Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together >>>> to form Address (ff02::1). >>>=20 >>> Allow me repeat myself: the scopes 'link' and 'site' make little if any >>> sense at all in networks of vehicles. >>=20 >> Repeating the same incorrect assertion over and over doesn=A1=AFt make it= any >> less >> incorrect. >>=20 >> See above for =A1=AElink=A1=AF. >>=20 >> Site is by definition an =A1=B0administratively defined=A1=B1 boundary de= termined >> by the >> configuration of routers participating within (and at the borders of) >> the site, >> so while =A1=B0Site=A1=B1 might not seem like a meaningful term in your c= ontext, >> the ability >> to define a =A1=B0site=A1=B1 pretty much any way you choose makes it a vi= able concept >> even if the term doesn=A1=AFt fit comfortably. >>=20 >> As I=A1=AFve said, if you have unique scope requirements, then there=A1=AF= s a process >> by which you can attempt to get the IETF to allocate you a scope number f= or >> those particular requirements. >>=20 >> Nonetheless, it doesn=A1=AFt change the relationship between the IPv6 mul= ticast >> address and the MAC address you should be using. >=20 > Yes, but there starts the multicast headache - at MAC layer. Huh? What headache? >=20 >>=20 >> The scope is not part of the last 32 bits of the group ID, so it won=A1=AF= t >> change the MAC address. If you want All Nodes in (any possible scope), >> it=A1=AFs still ff0x::1 and the MAC address is still 33-33-0-0-0-1. >=20 > Noted. >=20 > The formats you mention make think that: >=20 > One couldnt get a scope (a ff0x number) for each centimeter-level radius c= ircles around some map point, which is otherwise a perfectly fine GNSS resol= ution these days, and common talk "all taxis in Rose street". I doubt that IETF will use up slots in a 16-slot space for such silliness, b= ut submit an ID if you think that's useful.=20 >=20 > One couldnt get a Group ID (the last X-X-X-X in MAC) for each car kinds. Presumably, one could, but I suspect if you want to do that, you'll need to u= se local group IDs.=20 Owen >=20 > Alex >=20 >>=20 >> Owen >>=20 >>=20 From nobody Wed Jul 13 08:44:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0E812D7BB for ; Wed, 13 Jul 2016 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 7zNfKXxlsq6S for ; Wed, 13 Jul 2016 08:44:44 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80312D198 for ; Wed, 13 Jul 2016 08:39:24 -0700 (PDT) Received: from [192.159.10.213] (delong-dhcp13 [192.159.10.213]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6DFcLVY028835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2016 08:38:22 -0700 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (13F69) In-Reply-To: <0e6a425c-23f9-371c-5cb5-247cafad50ef@gmail.com> Date: Wed, 13 Jul 2016 08:38:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B5F8EE9-87FF-4EC1-AA25-80F5D398E897@delong.com> References: <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <577BE854.2050002@isi.edu> <9f6d961a-1a31-6f4e-ee85-2c23a09ef052@gmail.com> <577ED2D0.1030706@isi.edu> <447b1e9f-d621-f24f-c822-3a59e9f03a47@gmail.com> <577FFBA2.6030205@isi.edu> <57840EEC.4070200@isi.edu> <3ba63315-ea26-5327-bdc2-858368bfeba1@gmail.com> <5621900D-61F7-4B49-9393-9E3EE0833EE3@delong.com> <411F8BB3-9A89-4FAE-A051-DAA20FC3F58A@delong.com> <0e6a425c-23f9-371c-! 5cb5-247cafad50ef@gmail.com> To: Alexandre Petrescu X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 13 Jul 2016 08:38:22 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:44:46 -0000 > On Jul 13, 2016, at 08:19, Alexandre Petrescu wrote: >=20 > Owen, >=20 > Le 13/07/2016 =A8=A4 16:47, Owen DeLong a =A8=A6crit : > [...] >>> Yes, the ethertype helps to avoid some conflicts. In that sense >>> upper layer processing would have further discarded, basing their >>> decision on other fields. These checks may be consuming though. >>=20 >> The ether type check is not consuming. >=20 > It depends how fast one wants it done. It happens in the minter face hardware in most cases. In other cases, the lo= okup table time to determine which networking stack to pass the payload to i= s identical whether the packet is passed to another protocol or not. In most= cases, we are talking sub-microsecond.=20 >=20 >>> There are other collisions that would need to be avoided. >>=20 >>=20 >>> A random generator of MAC addresses like the one used on WiFi on >>> Windows 10 would need to discard output prefixed by 33-33-, such >>> as to avoid someone using a privacy MAC addresses starting with >>> 33-33-. It's not sufficient to just set the L bit. >>=20 >> Privacy MAC addresses would never conflict because they are Unicast >> and therefore would not set the multicast bit. Your argument here is >> nonsensical. >=20 > Right, that's true. Privacy MAC addresses would have the unicast bit set.= >=20 > [...] >>> One doesnt want wireshark sniffers along roads to read all cars' >>> constant MAC addresses passing by. >>=20 >> I'm not sure how you intend to avoid that. >=20 > For privacy reasons people dont want others know their car was there at > that time. (dont expose the OUI, dont expose always same MAC). I understood the desire the first time.=20 It doesn't change my statement as an appropriate ND search will elicit the n= eeded response for detection regardless.=20 >=20 >>> One doesnt want to expose her constant MAC address to each other >>> hotspot she visits. >>=20 >> Good luck with that. >=20 > You mean Apple is not doing that already? >=20 All hosts I know of which implement privacy addresses will still respond to N= D for their persistent EUI-64 address also.=20 If I'm roadside, I can search a 24-bit space fairly frequently with just a f= ew stations.=20 The total ND space is only 24 bits. > [...] >=20 >>> But new specs should not refrain from using larger MTUs if the >>> links provided them. >>=20 >> Sure, but that doesn't require an RFC or any new document. It's just >> a parameter passed up the stack when IPv6 is started on the >> interface. >=20 > It's not the MTU alone which requires a new document, it's many other > things that we discussed, not the least important being that RFC2464 > that everybody seems to love is outdated. The fact that everything still works even with 2464 being so out of date rat= her proves my point.if you feel an update is important or even useful, submi= t an ID.=20 >=20 >>> It's not because 1998 RFC2464 says that the default MTU size for >>> Ethernet is 1500bytes that 802.11-OCB should say the same. >>=20 >> Even modern Ethernet has jumbo frames and they work just fine. >> Default is just that. You can always configure a different value if >> it is supported by participating implementations. >=20 > If you want to configure some other MTU one has to go to the router and > configure it in the RA, make sure you put in the MTU variable some value > safely understood by each past present and future neighbor - it's a pain. So? >=20 >>> Codec methods and their chip implementations evolved in 20 years, >>> such as where wired Ethernet of 1998 was sending data at 10mbit/s >>> at best, today wireless 802.11 can go as high as 10gb/s. >>=20 >> Your point being? >=20 > RFC2464 is outdated. Then submit an ID to update it.=20 >=20 > [...] >>>> I=A1=AFm not sure what you mean by =A1=B0access control=A1=B1 in an IP c= ontext, >>>> so you=A1=AFll have to explain. If you=A1=AFre talking about things lik= e >>>> WPA for 802.11, then that is utterly and completely irrelevant >>>> to IP and is strictly handled by the link configuration before >>>> the IP stack is ever even started on the interface. >>>=20 >>> And that link configuration is pre-conditioned by selecting an >>> ESSID. The ESSID with strongest signal, the last ESSID used, a >>> pre-recorded list of sorted ESSIDs, or interactive user selection >>> from a scroll-down list, are all common methods to select an >>> ESSID. But there's no link configuration without this ESSID. It's >>> called "Network Name" in many GUIs. >>=20 >> In conventional 802.11 this is true because IP is not started until >> a network is associated. However, the defining event is starting the >> IP stack on the interface. The ESSID and/or AP association are merely >> a coincidental prerequisite to that start in existing 802.11 >> implementations. >>=20 >> Obviously an OCB implementation would require starting the IP stack >> (and thus the link configuration) without association. >=20 > True, but there is additional operation in 802.11-OCB. >=20 > In 802.11-OCB one has to first manually select one of 6 channels on the Ho= st precisely the same as on the Router. Then put the interface up and the I= P stack gets configured if it receives a Router Advertisement. >=20 > In a lab setting that's all. >=20 > In a road setting a car receives RAs from multiple Routers in that channel= ; it has no idea which one is a car, an LTE car, or a road-side unit giving a= ccess to Internet. >=20 > This car obviously shouldnt self-configure an address and default route fr= om each of the received RAs. >=20 > This problem does not exist in other 802.11-X: the computer self-configure= s an address and a default route only from the RA received from the router o= n the same ESSID. The admin makes sure there is only one router on that ESS= ID. >=20 > Do not think a channel is same as ESSID: whereas one can create an unlimit= ed number of ESSIDs the channels are regulated to be only 6 (and only 1 real= ly powerful). Clearly this is a challenge in your application, but it has nothing to do wi= th IP. This challenge would exist in your application regardless of the laye= r three protocol.=20 >=20 >>> In networks like 802.11-OCB where one can't select an ESSID the >>> entire link configuration is not happening. So there is no link. >>=20 >> There's also no ip stack starting so you've got some work to do >> there. However, once you are starting the IP stack, you'll have link >> configuration happening, so I'm not sure why you think this is an >> issue. >=20 > Because the link configuration that is happening: >=20 > 1. has to be preceded by manual selection of a channel. There is no > automation of this selection like there is automated ESSID > selection with user-preferences, last network, or strongest signal. That's a problem in your choice of technologies. It doesn't change the exist= ence or concept of a link or the mapping of multicast to MAC. >=20 > 2. leads to links with an unmanaged number of prefixes and default > routers on them. The number can not be managed like it is managed > by admins setting ESSIDs and routers on them. See above.=20 You have made design decisions which are problematic and now you seem to thi= nk IETF should somehow alter the nature of IPv6 to overcome the difficulties= you have created for yourself with your existing design decisions.=20 >=20 > [...] >>>> You still haven=A1=AFt provided any sort of coherent explanation why >>>> IPv6 over 802.11OCB needs to be meaningfully different than IPv6 >>>> over any other 802.x link. >>>=20 >>> Well I am trying to with this ESSID but you seem to not understand >>> what an ESSID is and how important is it in setting up 802.11 >>> links. >>=20 >> I understand completely. You are the one who is confused because you >> are putting a lot of nonexistent meaning on ESSID (and more >> accurately association) which isn't real. What is real is that >> existing implementations don't start the IP stack until after >> association. I took it as a given that you knew this and that you >> knew OCB would have to start the IP stack without association. >>=20 >> Perhaps clarifying this will allow you to see things as they are. >=20 > In networks where ESSIDs are used the number of Routers and what gets adve= rtised is limited by sysadmins within the scope of a unique ESSID. >=20 > Without that the WiFi networks would be a complete mess. >=20 Seems to be an argument as to why OCB is a particularly poor design decision= for your application, but it's your design decision. You get the trade offs= that come with it on both sides.=20 Owen > Alex From nobody Thu Jul 14 02:50:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A312B053 for ; Thu, 14 Jul 2016 02:50:00 -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 autolearn_force=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 UI0k3smpYW6b for ; Thu, 14 Jul 2016 02:49:58 -0700 (PDT) Received: from mails.bitsofnetworks.org (rezine.polyno.me [193.33.56.138]) (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 912D912B046 for ; Thu, 14 Jul 2016 02:49:57 -0700 (PDT) Received: from rev-140-155.legacytubes.illyse.net ([89.234.140.155] helo=lud.polynome.dn42) by mails.bitsofnetworks.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bNdHG-0005Lu-TV; Thu, 14 Jul 2016 11:49:55 +0200 Date: Thu, 14 Jul 2016 11:49:52 +0200 From: Baptiste Jonglez To: Alexandre Petrescu Message-ID: <20160714094952.GA19518@lud.polynome.dn42> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:50:01 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2016 at 11:55:20AM +0200, Alexandre Petrescu wrote: > First: which other 802 style networking? 802.3 Ethernet (rfc2464) or > 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? >=20 > Second: OCB mode of 802.11 is different than other 802.11bgn/ac/ad. For > example, a link scope in 802.11bgn/ac/ad is clearly bound by the > Association operations: whoever associates to a BSSID is within that > link scope. Sending one packet to an IP link-scope destination > naturally gets mapped into a multicast MAC address (be it prefixed by > 33- or 01-). >=20 > But in Out-of-a-Context-of-a-BSSID mode there are no Association > operations; thus it's hard to say who is within link scope, and what > would an "all-nodes" multicast address mean when there is no scope and > no SSID. This sounds a lot like the ad-hoc mode for regular 802.11, or even Power Line Communication. In terms of reachability, these layer-2 links are generally not transitive (and may not be symmetric either). There is some previous work: MANET, "mesh-under" vs. "route-over" architecture [1], Babel [2]. Basically, the sanest way is to define the scope of a link as the set of nodes reachable via radio broadcast. You then have to deal with the fact that this set will change over time (see Babel for unicast dynamic routing). I don't see why you would need to change the semantic of multicast addresses, in particular "all-nodes". It represents all nodes on the layer-2 link, and this set can always change over time (even in classical wired links, where nodes can come and go and bridges can fail). Baptiste [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.188.2437 [2] https://datatracker.ietf.org/wg/babel/documents/ > Le 09/07/2016 =E0 05:12, Owen DeLong a =E9crit : > >I fail to see any reason that the mapping would be different in OCB > >vs. any other 802 style networking. > > > >Owen > > > >>On Jul 8, 2016, at 12:38 , Alexandre Petrescu > >> wrote: > >> > >>Hi, > >> > >>During our discussion of IPv6 and MAC address multicast I laid down > >>a few of comment results of the discussion on this email list, on > >>this Internet Draft referred to below. > >> > >>In my oppinion there is obviously a need to clarify how and what > >>MAC multicast addresses to use below IPv6 in IPv6-over-802.11OCB > >>(Out of the Context of BSSID, aka 802.11p). > >> > >>Alex > >> > >>-------- Message transf=E9r=E9 -------- Sujet : [its] Fwd: I-D Action: > >>draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 > >>21:33:53 +0200 De : Alexandre Petrescu > >> Pour : its@ietf.org > >> > >>Hi, > >> > >>I have just submitted this Internet Draft I co-author with Thierry > >>Ernst. > >> > >>The distinctive aspect is that it tries to suggest the way MAC and > >>IPv6 multicast is used on an IPv6-over-80211-OCB links. > >> > >>Alex > >> > >> > >>-------- Message transf=E9r=E9 -------- Sujet : I-D Action: > >>draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 > >>08:55:47 -0700 De : internet-drafts@ietf.org R=E9pondre =E0 : > >>internet-drafts@ietf.org Pour : i-d-announce@ietf.org > >> > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >>Title : Transmission of IPv6 Packets over IEEE 802.11-OCB > >>Networks Authors : Thierry Ernst Alexandre Petrescu > >>Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages > >>: 5 Date : 2016-07-08 > >> > >>Abstract: In this document the mapping of multicast IPv6 addresses > >>to MAC addresses of 802.11-OCB is proposed. > >> > >> > >>The IETF datatracker status page for this draft is: > >>https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ > >> > >> > >> > There's also a htmlized version available at: > >>https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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/ > >> > >>_______________________________________________ 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 > >> > >>_______________________________________________ its mailing list > >>its@ietf.org https://www.ietf.org/mailman/listinfo/its > >> > >>_______________________________________________ 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 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXh2A8AAoJEL4B7CKgTi5Gg6UP/A+kJKkAGXjSoqDEkI7VSerf nUns9CpoTdWWRikuc9ZJTr4Ea+bBqgBSvRXZyXBl7tqXxfTIAwyfanv48D8b8pFo XBl2UenZqE2BU0bjwdM7QOthdq9irAZgPaX5GpzIIgMl61Mi/9HLncqmnC7TLOmA 1QF3ba7uaSOeyq0tK8ebtzrlrV/onZ5bAoWTt/+XS7V31dfuH/fs9UYTA4qgppKV 08/krdlo0lcvEGfXNI+xHF8NXd1bUCY50CzAnes9zBxWq509MVibsrrjWy0qQfvR 9kPebjaFiF2VyqEr4eSqEES5nzUvCrzK6bvcokiaiOXw0/KKRaerf2uR/MXboDfP B+wmnOZzxlFXsfMOBEkBctjJD0UZeb8narx5/i15F70O+chpJv6KHNznMrMQcIm8 t2C7BYYip94fQ0Ojf6LKisYSGjXpKXmvFHT46S9JUqQNwRfU91uoM094iLkjR6h9 ilLbrSKBvXwSHQEwYJsD3Oh07w3BOYbybcq3qwzxLxvxl/OYZllvVQexpeqyKfkT 209zVPC185KIuk6Ip+mf4VHUlpUsb6zQ1N8nVemKCpEcamvcQL4/UIfiTeI+obV6 zGR2XTDmoq8HJr/rhJO90628HlA6pgH5l8uPFJrEHqEb8PfFgNkju+onZE+8N+2O ZPVJhF04pN133kXDW3GF =Ra3X -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From nobody Thu Jul 14 04:47:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1112B03A for ; Thu, 14 Jul 2016 04:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FuCgzW5oNWkz for ; Thu, 14 Jul 2016 04:47:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AEE128874 for ; Thu, 14 Jul 2016 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141; q=dns/txt; s=iport; t=1468496823; x=1469706423; h=date:from:message-id:to:subject:cc; bh=HztpTzAU8Hq8En5NBGJIpP1v03dI9gnpKZmtuWXGbMc=; b=nIw/JX6PMf1tuqkMZeNcJw7rcWWq5xko1DRGOE0NdSdth97TCm/t0MEo P/M+pkTC/fnQypKMr+pe9HznSfRECiROdP552pwrDVAVBqOINuM6gbUWm WGzeF1luSARvNMwqM/q18aBWxrZLxoei3w3Zf6Q0xNg86EDmVjhrBCx+q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMBgDTeodX/4wNJK1cgz5WfadXkwsih?= =?us-ascii?q?W4JgTM8EAEBAQEBAQFlJ4VcPDSJEAEOwCEBAQEHAQEBAQEiineFDIUPBY58iiO?= =?us-ascii?q?GEoocARVOhAuIbZAZNR+EEYg8AQEB?= X-IronPort-AV: E=Sophos;i="5.28,362,1464652800"; d="scan'208";a="128653184" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2016 11:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6EBl2Dr003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2016 11:47:02 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 u6EBl2ha028877; Thu, 14 Jul 2016 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u6EBl2fk028876; Thu, 14 Jul 2016 04:47:02 -0700 Date: Thu, 14 Jul 2016 04:47:02 -0700 From: fred@cisco.com Message-Id: <201607141147.u6EBl2fk028876@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 11:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations. Please take a look at it and comment. From nobody Thu Jul 14 07:05:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9977D12D942 for ; Thu, 14 Jul 2016 07:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 oguOtc8yGJUU for ; Thu, 14 Jul 2016 07:05:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A7F12D61F for ; Thu, 14 Jul 2016 07:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2174; q=dns/txt; s=iport; t=1468505103; x=1469714703; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bac8o2xBuqmKsgWscluweAeDLRnrGROSMPyHojlj4is=; b=f394F/VC08FKgVwdFhoY93Bl0RYIAB10+5qgjysib8VcpQ3fZvnuMHNh xJ+GVIDg4VYCvtlXayzBxcQJTgjTLiN/ZR7LB8l0oBFssgOfnIW0pDMor mhAb9SAOkRD6h0qQoXaK8pGjH49TkFo/CQkf6G9EDkBEcdvz2xKSnsluH w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQB0m4dX/4QNJK1cgz5WfAa4Y4F7I?= =?us-ascii?q?oV3AoExOBQBAQEBAQEBZRwLhFwBAQQBeQULAgEIGC4yJQIEDgUOiBoIDsBqAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEPDogiglWHbIIvBZkfAYM1gW5uiEeBVRZOhAuIb?= =?us-ascii?q?ZAYAR42g3Fuhm9/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,363,1464652800"; d="asc'?scan'208";a="296926248" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2016 14:05:02 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6EE52Lb014386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jul 2016 14:05:02 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 14 Jul 2016 09:05:02 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Thu, 14 Jul 2016 09:05:02 -0500 From: "Fred Baker (fred)" To: "draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org" Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations Thread-Index: AQHR3di2U/Ux4bSe50iSj3qzCOUAaQ== Date: Thu, 14 Jul 2016 14:05:01 +0000 Message-ID: <0BA26A87-DB40-4CD0-9DF3-BDB159E15B9B@cisco.com> References: <201607141147.u6EBl2fk028876@irp-lnx1.cisco.com> In-Reply-To: <201607141147.u6EBl2fk028876@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_E68E661A-4874-4F46-909D-42F527D9A63F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IPv6 Ops WG , "Lee.Howard@charter.com" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 14:05:07 -0000 --Apple-Mail=_E68E661A-4874-4F46-909D-42F527D9A63F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 14, 2016, at 4:47 AM, Fred Baker (fred) wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations. = Please take a look at it and comment. Guys: I'm very perplexed. This draft is dated February 6, and expires next = month, but is just now showing up in the repository. What happened? Fred > Internet Engineering Task Force B. = Liu > Internet-Draft S. = Jiang > Intended status: Informational Huawei = Technologies > Expires: August 9, 2016 February 6, = 2016 >=20 >=20 > Considerations For Using Unique Local Addresses > draft-ietf-v6ops-ula-usage-considerations-00 --Apple-Mail=_E68E661A-4874-4F46-909D-42F527D9A63F 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 iQIVAwUBV4ecDEayAOS/EQ8MAQLOnBAAit322ihxVpQVwpp1PznIsnA2iyVuGN7q 5bFuqPKtpS2KMG8hvT/SyssmoePdUvMO7sj/eE4HhXgRrXvHZnJzK1fMl5exNOcW PbUQmJz+8csRt4qOOMiW1NPGUlaetEzQdTiW4g//9c3GEhyMlutIA9tcrLGPI5iL Bpch0W+ez6t3lvtfwSKFunMhbmnblxIXpgFE5ZDiRt8u4Rjngl9KZDPwY3fVOZF6 emrrSyrPSJCVoz0T7a6AdGDFntZ5wgUO04S2OkDkNBPXca4gKgw2ZTa4IySLOwXa /pvibkiOU5N8hhWuEdokV11ljF8n30QHYhuEGNzNIlECRZkbIQ0mS81sX3oasMoA Wcyf1mYoO2Fw/TM0UWYL3DOn1OiNXw6l4ZSDmPiRfz4ePsUhIpT8KP5SME6XVwyO et/mha4q2kCcOK+4diBmYV4sUvKH6iHBZL+sRIr1YNEIhZUSvYkr1oYd3QTxWlqt aNoi3zVDT5WjRGLpB70WYV7jIN/fIblmOuykLumb4YxYrfOXmR7lHa7xjukxmgKi AGxKY+4cInLpJ7TUHDzpyhtWej4fChn6vBQceXanWDzjDMuMu03QWhyHeU2RsgdF JxSO4JzKwvsAacW1Oo1ChzVxigPeMCN4FjFc7HLx3d6TIEIGtJ1fWzHbqOsOw8Ss +4zG9gYLUHI= =o6yN -----END PGP SIGNATURE----- --Apple-Mail=_E68E661A-4874-4F46-909D-42F527D9A63F-- From nobody Thu Jul 14 07:19:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89212D143 for ; Thu, 14 Jul 2016 07:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=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 nkarsYytTSFi for ; Thu, 14 Jul 2016 07:19:44 -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 32CCE12D107 for ; Thu, 14 Jul 2016 07:12:43 -0700 (PDT) Received: from dhcp-b257.meeting.ietf.org (dhcp-b257.meeting.ietf.org [31.133.178.87]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u6EECZaT059188 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 14 Jul 2016 14:12:37 GMT (envelope-from joelja@bogus.com) To: "Fred Baker (fred)" , "draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org" References: <201607141147.u6EBl2fk028876@irp-lnx1.cisco.com> <0BA26A87-DB40-4CD0-9DF3-BDB159E15B9B@cisco.com> From: joel jaeggli Message-ID: <034b4064-b99b-b91b-454b-75c669af9bd4@bogus.com> Date: Thu, 14 Jul 2016 16:12:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <0BA26A87-DB40-4CD0-9DF3-BDB159E15B9B@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UTLMa4S65iITJuXowo1AUASfmWnlm0xw0" Archived-At: Cc: IPv6 Ops WG , "Lee.Howard@charter.com" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 14:19:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UTLMa4S65iITJuXowo1AUASfmWnlm0xw0 Content-Type: multipart/mixed; boundary="OaLDf3EbSlVsngdkd7NmEkO0Qff3AFm3D" From: joel jaeggli To: "Fred Baker (fred)" , "draft-ietf-v6ops-ula-usage-considerations@tools.ietf.org" Cc: IPv6 Ops WG , "Lee.Howard@charter.com" Message-ID: <034b4064-b99b-b91b-454b-75c669af9bd4@bogus.com> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ula-usage-considerations References: <201607141147.u6EBl2fk028876@irp-lnx1.cisco.com> <0BA26A87-DB40-4CD0-9DF3-BDB159E15B9B@cisco.com> In-Reply-To: <0BA26A87-DB40-4CD0-9DF3-BDB159E15B9B@cisco.com> --OaLDf3EbSlVsngdkd7NmEkO0Qff3AFm3D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/14/16 4:05 PM, Fred Baker (fred) wrote: >=20 >> On Jul 14, 2016, at 4:47 AM, Fred Baker (fred) >> wrote: >>=20 >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations. >> Please take a look at it and comment. >=20 > Guys: >=20 > I'm very perplexed. This draft is dated February 6, and expires next > month, but is just now showing up in the repository. What happened? hrm you did the replaced by on 2/8 so it's been there a while. Date Rev. By Action 2016-02-08 00 Fred Baker This document now replaces draft-ietf-v6ops-ula-usage-recommendations instead of None 2016-02-08 00 Bing Liu New version available: draft-ietf-v6ops-ula-usage-considerations-00.txt if there's an updated draft then this isn't it. > Fred >=20 >> Internet Engineering Task Force >> B. Liu Internet-Draft >> S. Jiang Intended status: Informational >> Huawei Technologies Expires: August 9, 2016 >> February 6, 2016 >>=20 >>=20 >> Considerations For Using Unique Local Addresses=20 >> draft-ietf-v6ops-ula-usage-considerations-00 >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --OaLDf3EbSlVsngdkd7NmEkO0Qff3AFm3D-- --UTLMa4S65iITJuXowo1AUASfmWnlm0xw0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAleHndEACgkQ8AA1q7Z/VrISaACcDPM2iOFzh7jJxSN4kHvTQ32N Ib0Anjn1VXYMbXibW/PS7pVvE/04WjKA =i0wj -----END PGP SIGNATURE----- --UTLMa4S65iITJuXowo1AUASfmWnlm0xw0-- From nobody Thu Jul 14 09:55:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5612B04D for ; Thu, 14 Jul 2016 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 nSRyICbzY3kI for ; Thu, 14 Jul 2016 09:55:55 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985DA12B034 for ; Thu, 14 Jul 2016 09:55:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6EGtpEn029326; Thu, 14 Jul 2016 18:55:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09E662083C8; Thu, 14 Jul 2016 18:55:51 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F09D9200C1C; Thu, 14 Jul 2016 18:55:50 +0200 (CEST) Received: from [132.166.84.64] ([132.166.84.64]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6EGtnDG013566; Thu, 14 Jul 2016 18:55:50 +0200 To: Baptiste Jonglez References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <20160714094952.GA19518@lud.polynome.dn42> From: Alexandre Petrescu Message-ID: Date: Thu, 14 Jul 2016 18:55:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160714094952.GA19518@lud.polynome.dn42> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:55:57 -0000 Le 14/07/2016 11:49, Baptiste Jonglez a crit : > On Mon, Jul 11, 2016 at 11:55:20AM +0200, Alexandre Petrescu wrote: >> First: which other 802 style networking? 802.3 Ethernet (rfc2464) >> or 802.11 WiFi (no RFC)? Destination prefix 33- or 01-? >> >> Second: OCB mode of 802.11 is different than other 802.11bgn/ac/ad. >> For example, a link scope in 802.11bgn/ac/ad is clearly bound by >> the Association operations: whoever associates to a BSSID is within >> that link scope. Sending one packet to an IP link-scope >> destination naturally gets mapped into a multicast MAC address (be >> it prefixed by 33- or 01-). >> >> But in Out-of-a-Context-of-a-BSSID mode there are no Association >> operations; thus it's hard to say who is within link scope, and >> what would an "all-nodes" multicast address mean when there is no >> scope and no SSID. > > This sounds a lot like the ad-hoc mode for regular 802.11, or even > Power Line Communication. Yes it sounds a lot like ad-hoc mode. Both OCB and ad-hoc mode are "unmanaged". But OCB is even further relieved from structure. In ad-hoc mode there is still separation - there is association messaging, and once in an ad-hoc ESSID (the "MAC address" of the ad-hoc "cell"), nodes dont here other stations on other ESSIDs. In OCB there is no such separation at all: everybody hears everybody else in the same channel. > In terms of reachability, these layer-2 links are generally not > transitive (and may not be symmetric either). YEs. > There is some previous work: MANET, "mesh-under" vs. "route-over" > architecture [1], Babel [2]. YEs, but it is not satisfactory in vehicular reasons for many other reasons. > Basically, the sanest way is to define the scope of a link as the set > of nodes reachable via radio broadcast. You then have to deal with > the fact that this set will change over time (see Babel for unicast > dynamic routing). Such scope can make sense, but it is still dependent on the user. There is a different scope for each user. On another hand, a link scope in AP-mode or ad-hoc mode is the scope covering that ESSID: a link scope is different for each ESSID (not different for each user). The fact that within AP-mode or ad-hoc mode link scope some hosts can not see each other (non transitivity: A sees B sees C doesnt mean A sees C) is commonly understood as a configuration problem: one is not supposed to build networks with only one ESSID bigger than the WiFi radio range. To solve this non-transitivity problem in AP-mode or ad-hoc mode one should define an "ESSID scope" (not a link scope). At that point we talk about nodes in ESSID scope are agreed to be non-transitive. And routers to forward between link scopes but within same ESSID scope. But that is not my problem here. It is an IPv6-over-80211 problem in the first place. And we dont have such an RFC. My problem here is the scope for OCB-mode, which has no ESSID. > I don't see why you would need to change the semantic of multicast > addresses, in particular "all-nodes". It represents all nodes on > the layer-2 link, and this set can always change over time (even in > classical wired links, where nodes can come and go and bridges can > fail). Noted but non implementable. The "all nodes" Group ID is defined to be able to live within link scope (ff02::1), site scope (ff0X::1) and more other scopes. Nodes that come and go from link scopes can indeed be managed but _only_ if we have a solid scope. In 802.11 there are no bridges (yes there are bridges between 802.11 and 802.3 but not between different 802.11 ESSIDs). Alex > > Baptiste > > [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.188.2437 > [2] https://datatracker.ietf.org/wg/babel/documents/ > >> Le 09/07/2016 05:12, Owen DeLong a crit : >>> I fail to see any reason that the mapping would be different in >>> OCB vs. any other 802 style networking. >>> >>> Owen >>> >>>> On Jul 8, 2016, at 12:38 , Alexandre Petrescu >>>> wrote: >>>> >>>> Hi, >>>> >>>> During our discussion of IPv6 and MAC address multicast I laid >>>> down a few of comment results of the discussion on this email >>>> list, on this Internet Draft referred to below. >>>> >>>> In my oppinion there is obviously a need to clarify how and >>>> what MAC multicast addresses to use below IPv6 in >>>> IPv6-over-802.11OCB (Out of the Context of BSSID, aka >>>> 802.11p). >>>> >>>> Alex >>>> >>>> -------- Message transfr -------- Sujet : [its] Fwd: I-D >>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 >>>> Jul 2016 21:33:53 +0200 De : Alexandre Petrescu >>>> Pour : its@ietf.org >>>> >>>> >>>> Hi, >>>> >>>> I have just submitted this Internet Draft I co-author with >>>> Thierry Ernst. >>>> >>>> The distinctive aspect is that it tries to suggest the way MAC >>>> and IPv6 multicast is used on an IPv6-over-80211-OCB links. >>>> >>>> Alex >>>> >>>> >>>> -------- Message transfr -------- Sujet : I-D Action: >>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul >>>> 2016 08:55:47 -0700 De : internet-drafts@ietf.org Rpondre : >>>> internet-drafts@ietf.org Pour : i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. >>>> >>>> >>>> Title : Transmission of IPv6 Packets over IEEE >>>> 802.11-OCB Networks Authors : Thierry Ernst Alexandre >>>> Petrescu Filename : >>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date >>>> : 2016-07-08 >>>> >>>> Abstract: In this document the mapping of multicast IPv6 >>>> addresses to MAC addresses of 802.11-OCB is proposed. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >>>> >>>> >>>> >> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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/ >>>> >>>> _______________________________________________ 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 >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> _______________________________________________ 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 Jul 14 10:08:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF91712D09A for ; Thu, 14 Jul 2016 10:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uqsnqzufBiMc for ; Thu, 14 Jul 2016 10:08:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id E642412B04F for ; Thu, 14 Jul 2016 10:08:34 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6EH6R5Y022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jul 2016 10:06:27 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Thu, 14 Jul 2016 10:06:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <20160714094952.GA19518@lud.polynome.dn42> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 14 Jul 2016 10:06:28 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 17:08:37 -0000 >> In terms of reachability, these layer-2 links are generally not >> transitive (and may not be symmetric either). >=20 > YEs. >=20 >> There is some previous work: MANET, "mesh-under" vs. "route-over" >> architecture [1], Babel [2]. >=20 > YEs, but it is not satisfactory in vehicular reasons for many other = reasons. >=20 >> Basically, the sanest way is to define the scope of a link as the set >> of nodes reachable via radio broadcast. You then have to deal with >> the fact that this set will change over time (see Babel for unicast >> dynamic routing). >=20 > Such scope can make sense, but it is still dependent on the user. This is an inevitable consequence of your design decision to use OCB. > There is a different scope for each user. >=20 > On another hand, a link scope in AP-mode or ad-hoc mode is the scope = covering that ESSID: a link scope is different for each ESSID (not = different for each user). That is a property difference between OCB and ESSID modes of operation. = It has nothing to do with IP or the IP concept of a link. > The fact that within AP-mode or ad-hoc mode link scope some hosts can = not see each other (non transitivity: A sees B sees C doesnt mean A sees = C) is commonly understood as a configuration problem: one is not = supposed to build networks with only one ESSID bigger than the WiFi = radio range. Or if one, does, one is expected to provide transitivity between APs = sharing the same ESSID to overcome this. However, in OCB mode, you don=92t have those facilities, so your link is = limited to being different for east combination of station, time, = position, and relative position of other stations as well as propagation = factors. > To solve this non-transitivity problem in AP-mode or ad-hoc mode one = should define an "ESSID scope" (not a link scope). At that point we = talk about nodes in ESSID scope are agreed to be non-transitive. And = routers to forward between link scopes but within same ESSID scope. This is completely illogical and is not how any Wireless network I=92ve = worked with is implemented. Instead, multiple APs are connected with the same ESSID using bridging = and/or other technologies on the wired side to provide this = transitivity. In some cases, there are also wireless protocols that can = be used to extend an ESSID wirelessly between two or more APs, but these = are obviously suboptimal due to spectrum utilization for forwarding = between the APs. However, none of this is relevant to your situation because of your = design decision to use OCB. > But that is not my problem here. It is an IPv6-over-80211 problem in = the first place. And we dont have such an RFC. Nor do we have an actual need for one as it is a problem which everyone = so far solves at layer 2 using media adapters and bridging. > My problem here is the scope for OCB-mode, which has no ESSID. What is the problem? As you have mentioned, each user has a unique link = scope. If you don=92t like that, don=92t use OCB or don=92t use link scope for = your application(s). >=20 >> I don't see why you would need to change the semantic of multicast >> addresses, in particular "all-nodes". It represents all nodes on >> the layer-2 link, and this set can always change over time (even in >> classical wired links, where nodes can come and go and bridges can >> fail). >=20 > Noted but non implementable. Why not? > The "all nodes" Group ID is defined to be able to live within link = scope (ff02::1), site scope (ff0X::1) and more other scopes. Sure. Use the scope that best meets your needs. > Nodes that come and go from link scopes can indeed be managed but = _only_ if we have a solid scope. What do you mean by solid scope? If nodes are arriving and departing = from the scope, by definition, it lacks solidity from at least one = perspective on the term. > In 802.11 there are no bridges (yes there are bridges between 802.11 = and 802.3 but not between different 802.11 ESSIDs). Since you are not using ESSIDs to begin with, I=92m not sure how that is = relevant. Owen >=20 > Alex >=20 >>=20 >> Baptiste >>=20 >> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.188.2437 >> [2] https://datatracker.ietf.org/wg/babel/documents/ >>=20 >>> Le 09/07/2016 =E0 05:12, Owen DeLong a =E9crit : >>>> I fail to see any reason that the mapping would be different in >>>> OCB vs. any other 802 style networking. >>>>=20 >>>> Owen >>>>=20 >>>>> On Jul 8, 2016, at 12:38 , Alexandre Petrescu >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> During our discussion of IPv6 and MAC address multicast I laid >>>>> down a few of comment results of the discussion on this email >>>>> list, on this Internet Draft referred to below. >>>>>=20 >>>>> In my oppinion there is obviously a need to clarify how and >>>>> what MAC multicast addresses to use below IPv6 in >>>>> IPv6-over-802.11OCB (Out of the Context of BSSID, aka >>>>> 802.11p). >>>>>=20 >>>>> Alex >>>>>=20 >>>>> -------- Message transf=E9r=E9 -------- Sujet : [its] Fwd: I-D >>>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 >>>>> Jul 2016 21:33:53 +0200 De : Alexandre Petrescu >>>>> Pour : its@ietf.org >>>>> >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I have just submitted this Internet Draft I co-author with >>>>> Thierry Ernst. >>>>>=20 >>>>> The distinctive aspect is that it tries to suggest the way MAC >>>>> and IPv6 multicast is used on an IPv6-over-80211-OCB links. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>=20 >>>>> -------- Message transf=E9r=E9 -------- Sujet : I-D Action: >>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul >>>>> 2016 08:55:47 -0700 De : internet-drafts@ietf.org R=E9pondre =E0 : >>>>> internet-drafts@ietf.org Pour : i-d-announce@ietf.org >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>>=20 >>>>>=20 >>>>> Title : Transmission of IPv6 Packets over IEEE >>>>> 802.11-OCB Networks Authors : Thierry Ernst Alexandre >>>>> Petrescu Filename : >>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date >>>>> : 2016-07-08 >>>>>=20 >>>>> Abstract: In this document the mapping of multicast IPv6 >>>>> addresses to MAC addresses of 802.11-OCB is proposed. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> = https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>>>=20 > There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00 >>>>>=20 >>>>>=20 >>>>>=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 >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=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 From nobody Sat Jul 16 11:39:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01D312D0DF; Sat, 16 Jul 2016 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 r07Qb34AbToe; Sat, 16 Jul 2016 11:39:01 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id DEBBD12B061; Sat, 16 Jul 2016 11:39:00 -0700 (PDT) X-SENDER-IP: 10.64.163.154 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.28,375,1464667200"; d="scan'208,217";a="618249218" Received: from unknown (HELO exchpapp13.corp.twcable.com) ([10.64.163.154]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 16 Jul 2016 14:33:29 -0400 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp13.corp.twcable.com (10.64.163.154) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 16 Jul 2016 14:38:58 -0400 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1178.000; Sat, 16 Jul 2016 14:38:58 -0400 From: "Howard, Lee" To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKKAblL6A Date: Sat, 16 Jul 2016 18:38:58 +0000 Message-ID: <7FE9B6A2-5013-4B4A-9959-554BDC9DA120@charter.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150911 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22454.004 x-tm-as-result: No--49.724000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7FE9B6A250134B4A9959554BDC9DA120chartercom_" MIME-Version: 1.0 Archived-At: Cc: "fgont@si6networks.com" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 18:39:05 -0000 --_000_7FE9B6A250134B4A9959554BDC9DA120chartercom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGRvbmUgYSB0aG9yb3VnaCByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCAoZXZlbiBhcyBp dCB3YXMgdXBkYXRlZCBmcm9tIOKAkzggdG8g4oCTMDksIHNvIHRoZSByZWxldmFuY2Ugb2YgbXkg Y29tbWVudHMgbWF5IGNoYW5nZSBwYXJ0d2F5IHRocm91Z2guIEkgZGlkIHRha2UgYSBsb25nIHRp bWUsIGJ1dCBpdCdzIGJlY2F1c2UgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlbGV2YW50IGFu ZCBpdCBzaG91bGQgYmUgdmVyeSBnb29kIGFuZCByZWFkYWJsZSB0byBtYWtlIGl0IGFzIHVzZWZ1 bCBhcyBwb3NzaWJsZS4NCg0KTm90ZXMgYmVsb3cuDQoNCkxlZQ0KDQotLQ0KDQpUaGlzIGlzIGxp c3RlZCBhcyBJbmZvcm1hdGlvbmFsLCBidXQgaW4gc29tZSBwbGFjZXMgaXMgcmVjb21tZW5kaW5n IGJlc3QgcHJhY3RpY2UuIElzIHRoaXMgcmVhbGx5IGludGVuZGVkIHRvIGJlIGEgQkNQPyBJIGFs d2F5cyBmZWVsIHN0cmFuZ2Ugc2VlaW5nIFJGQzIxMTkgYm9pbGVycGxhdGUgYW5kIGxhbmd1YWdl IGluIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQuIEZvciBpbnN0YW5jZSwgMi4xLjQgc2F5cywg 4oCcSXQgbXVzdCBiZSBub3RlZCB0aGF0LuKAnSAgVGhhdOKAmXMgbm90IGFuIFJGQyAyMTE5IHVz ZSBvZiDigJxtdXN0LOKAnSBkZXNwaXRlIHdoYXQgMS4xIHNheXMuICBCdXQgMi4zLjUgc2F5cyDi gJxwcmVmaXggbXVzdCBub3QgYmUgdXNlZCBmb3Igb24tbGluayBkZXRlcm1pbmF0aW9uLuKAnSBO b3Qgc3VyZSBpZiB0aGF04oCZcyBnb29kIGFkdmljZSBvciByZWZlcnMgdG8gYSAzR1BQIHNwZWNp ZmljYXRpb24sIHNvIGl04oCZcyB1bmNsZWFyLg0KDQpJIHRoaW5rIHRoZSB0b25lIHN1Z2dlc3Rp bmcgSVB2NiBpcyBuZXcgaXMgbWlzcGxhY2VkLiBUaGlzIHN0YXJ0cyByaWdodCBpbiB0aGUgYWJz dHJhY3QsIGJ1dCBSRkMgNDk0MiB3YXMgcHVibGlzaGVkIDkgeWVhcnMgYWdvLiBNYXliZSBjaGFu Z2UgaXQgdG8sIOKAnFNvbWUgb2YgdGhlIHNlY3VyaXR5IGNoYWxsZW5nZXMgaW4gSVB2NiBhcmUg ZGlmZmVyZW50IHRoYW4gdGhvc2UgaW4gSVB2NC7igJ0NCg0KVGhlIEludHJvZHVjdGlvbiBjb250 aW51ZXMgdGhlIHRoZW1lIHRoYXQgSVB2NiBpcyBuZXcuIEl0IGFsc28gZG9lc27igJl0IHNheSBt dWNoIGJ5IHdheSBvZiBpbnRyb2R1Y2luZyB0aGUgZG9jdW1lbnQuICBDdXQgdGhlIGZpcnN0IHR3 byBwYXJhZ3JhcGhzLg0KDQoNClNlY3Rpb24gMiB0aXRsZSBzaG91bGQgcHJvYmFibHkgYmUg4oCc R2VuZXJhbCBTZWN1cml0eSBDb25zaWRlcmF0aW9uc+KAnSBub3Qg4oCcR2VuZXJpYyBTZWN1cml0 eSBDb25zaWRlcmF0aW9uc+KAnQ0KDQpJ4oCZZCBsaWtlIHRvIHNlZSBzb21lIGRlc2NyaXB0aW9u IG9mIHdoeSBpdOKAmXMgaGFyZCB0byByZW51bWJlci4gQSBwb2ludGVyIHRvIGF0IGxlYXN0IFJG QzY4NjYsIGFuZCBtYXliZSBSRkM2ODc5IGFuZCBSRkM3MDEwLiBZb3UgY291bGQgbWVudGlvbiBv bmdvaW5nIHdvcmsgaW4gU1VQQSBvciBBTklNQSwgYnV0IGRvbuKAmXQgaGF2ZSB0by4gVGhlIG1v c3QgcmVsZXZhbnQgbm90ZSBpbiByZW51bWJlcmluZyBpcyByZmM2ODY2IDIuOCwgdGhhdCBBQ0xz IChhbmQgYnkgZXh0ZW5zaW9uLCBmaXJld2FsbCBydWxlcykgbmVlZCB0byBiZSB1cGRhdGVkLg0K DQpZb3UgZG9u4oCZdCBzYXkgYW55dGhpbmcgaW4gMi4xIGFib3V0IHVzaW5nIGJpdHMgZm9yIGZ1 bmN0aW9uYWwgcHVycG9zZXMuIFlvdSBzYXkgdGhhdCBnZW9ncmFwaGljIGJvdW5kYXJpZXMgYXJl IGdvb2QgZm9yIHNpbXBsaWZ5aW5nIHNlY3VyaXR5IHBvbGljaWVzIChhbmQgSSBhZ3JlZSwgYW5k IHdpc2ggaXQgd2VyZSBhcHByb3ByaWF0ZSB0byBub3RlIHRoYXQgYW4gQUNMIGNhbiBnbyBmcm9t IDIwMCBsaW5lcyBncm93biBvcmdhbmljYWxseSBvdmVyIGEgZGVjYWRlIGluIElQdjQgdG8gNCBs aW5lcyB3aXRoIGFuIElQdjYgYWRkcmVzcyBwbGFuIGRlc2lnbmVkIGZvciBncm93dGgpLCBidXQg aXQgY2FuIGJlIHVzZWZ1bCB0byBoYXZlLCBzYXksIGEgbWFuYWdlbWVudCBuZXR3b3JrIGJlIGEg c3BlY2lmaWMgc3VibmV0IG91dCBvZiB0aGUgcmVnaW9uYWwgc3VwZXJuZXRzLiB4Onk6ejo2NjY6 Oi80OCwgZm9yIGluc3RhbmNlLiBPciBkbyB5b3UgZGlzYWdyZWU/DQoNCldlIGNvdWxkIGRlYmF0 ZSB0aGUgcm9sZSBvZiBsYXcgZW5mb3JjZW1lbnQsIGJ1dCBJ4oCZZCBsaWtlIHRvIHJld29yZDoN Ckhvd2V2ZXIsIG9uZSBhc3BlY3QgdG8ga2VlcCBpbiBtaW5kIGlzIHdobyBoYXMgb3duZXJzaGlw IG9mIHRoZQ0KICAgYWRkcmVzcyBzcGFjZSBhbmQgd2hvIGlzIHJlc3BvbnNpYmxlIGlmL3doZW4g TGF3IEVuZm9yY2VtZW50IG1heSBuZWVkDQogICB0byBlbmZvcmNlIHJlc3RyaWN0aW9ucyBvbiBy b3V0YWJpbGl0eSBvZiB0aGUgc3BhY2UgZHVlIHRvIG1hbGljaW91cw0KICAgY3JpbWluYWwgYWN0 aXZpdHkuDQoNClRvDQpUaGUgcG9pbnQgb2YgY29udGFjdCBsaXN0ZWQgaW4gcHVibGljIHJlZ2lz dHJpZXMgaXMgdGhlIG9uZSB3aG8gd2lsbCBoYXZlIHRvIHJlc3BvbmQgdG8gbGVnYWwgaW5xdWly aWVzLCBhbmQgcG90ZW50aWFsbHkgdGFrZSBhY3Rpb24gYXMgcmVxdWlyZWQgYnkgbGVnYWwgYXV0 aG9yaXR5Lg0KDQpJbiAyLjEuMSwgaXQgd291bGQgYmUgbmljZSB0byBhY2tub3dsZWRnZSB0aGUg ZGlmZmVyZW50IGtpbmRzIG9mIG5vZGVzLCBhbmQgd2hlcmUgc3RhdGljIGFkZHJlc3NlcyBtYWtl IHNlbnNlLiBTZXJ2ZXJzIGFyZSBkaWZmZXJlbnQgZnJvbSB3b3Jrc3RhdGlvbnMgb3IgcmVzaWRl bnRpYWwgdXNlcnMuIFJvdXRlcnMgYW5kIGZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBjb25zaWRl cmF0aW9ucy4gV2hhdCBhYm91dCBwcmludGVycz8gU2hvdWxkIElQIHBob25lcyBiZSBudW1iZXJl ZCB0aGUgc2FtZSB3YXkgYXMgZGVza3RvcHM/DQoNCjIuMS4yIHNheXMNClRoZSBpbXBsaWNpdCBl eHBlY3RhdGlvbiBmcm9tIHRoZSBSRkMgaXMgdGhhdCBhbGwgVUxBcw0KICAgd2lsbCBiZSByYW5k b21seSBjcmVhdGVkIGFzIC80OHMuICBBbnkgdXNlIG9mIFVMQXMgdGhhdCBhcmUgbm90DQogICBj cmVhdGVkIGFzIGEgLzQ4IHZpb2xhdGVzIFJGQzQxOTM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzQxOTM+IFtSRkM0MTkzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTkz Pl0uDQoNClRoZXNlIHR3byBzZW50ZW5jZXMgYXJlIHN0cmFuZ2UuIElzIGl0IGltcGxpY2l0IG9y IGV4cGxpY2l0PyAgSWYgaXTigJlzIGltcGxpY2l0LCBjYW4geW91IGV4cGxhaW4gaG93IFJGQyA0 MTkzIGltcGxpZXMgdGhhdD8gIElmIGl04oCZcyBvbmx5IGltcGxpZWQsIHRoZW4gaXMgaXQgYSB2 aW9sYXRpb24/ICBJIHRoaW5rIHRoZXNlIHR3byBzZW50ZW5jZXMgc2hvdWxkIGJlIHJld3JpdHRl biwgYW5kIHlvdSBkb27igJl0IG5lZWQgYm90aCBvZiB0aGVtLg0KDQpMTEEgY2FuIG9ubHkgcmVw bGFjZSBVTEEgZm9yIGEgc2luZ2xlIHN1Ym5ldC4NCg0KQWx0aG91Z2ggVUxBcyBhcmUgc3VwcG9z ZWQgdG8gYmUgdXNlZA0KICAgaW4gY29uanVuY3Rpb24gd2l0aCBnbG9iYWwgYWRkcmVzc2VzIGZv ciBob3N0cyB0aGF0IGRlc2lyZSBleHRlcm5hbA0KICAgY29ubmVjdGl2aXR5LA0KW2NpdGF0aW9u IG5lZWRlZF0NCg0K4oCcVUxBcyBpbiBjb25qdW5jdGlvbiB3aXRoIHNvbWUgc29ydCBvZiBhZGRy ZXNzIHRyYW5zbGF0aW9u4oCdICBQbGVhc2UgY2l0ZSByZmM2Mjk2LiBZb3UgbWlnaHQgYWxzbyB3 YW50IHRvIGluY2x1ZGUgcmVmZXJlbmNlIHRvIGl0cyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uLCBhbmQgaW4gZmFjdCB5b3VyIG93biBkaXNjdXNzaW9uIG9mIHBlcmltZXRlciBzZWN1 cml0eSBpbiBwYXJhZ3JhcGggMiBvZiAyLjEuMS4NCg0K4oCcKHRoZSBhdXRob3JzIG9mIHRoaXMg ZG9jdW1lbnQgZG8gbm90IHNoYXJlIHRoaXMgcG9pbnQgb2YgdmlldynigJ0gaXNu4oCZdCByZWFs bHkgYXBwcm9wcmlhdGUgY29tbWVudGFyeSBpbiBhIFdHIGRvY3VtZW50LiBGb3IgdGhpcyB0byBi ZSBJRVRGIHN0cmVhbSwgaXQgbmVlZHMgdG8gcmVmbGVjdCBjb25zZW5zdXMuDQoNClNvLCBrbm93 aW5nIHRoYXQgVUxBcyBhcmUgYSB0aG9ybnkgbmVzdCBpbiBhIHJhdGhvbGUsIEkgc3VnZ2VzdDoN CiBVbmlxdWUgTG9jYWwgQWRkcmVzc2luZyAoVUxBLCBbUkZDIDQxOTNdKSBpcyDigJxnbG9iYWxs eSB1bmlxdWUgYW5kIGlzIGludGVuZGVkIGZvciBsb2NhbCBjb21tdW5pY2F0aW9uc+KAnSBbUkZD IDQxOTNdLiAgVUxBcyBjb3VsZCBiZSB1c2VkIGZvciBzeXN0ZW1zIHRoYXQgZG8gbm90IHJlcXVp cmUgSW50ZXJuZXQgY29ubmVjdGl2aXR5LCBzdWNoIGFzIGEgbWFuYWdlbWVudCBuZXR3b3JrLCBv ciBiYWNrLWVuZCBzZXJ2ZXJzLCBhcyBsb25nIGFzIHNvZnR3YXJlIHVwZGF0ZXMgY2FuIGJlIGRv bmUgbG9jYWxseS4gT24gYSBzaW5nbGUgc3VibmV0LCBMaW5rLUxvY2FsIEFkZHJlc3NlcyAoTExB LCBbUkZDIDc0MDRdKSBjYW4gYmUgdXNlZCBpbnN0ZWFkLiBTb21lIGNhc2VzIG1heSBiZSBjb3Zl cmVkIGJ5IHByaXZhY3kgZXh0ZW5zaW9uczsgc2VlIHNlY3Rpb24gMi4xLjQgYmVsb3cuDQoNClVM QXMgY2FuIGJlIHVzZWQgd2l0aCBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBUNjYsIFtS RkM2Mjk2XSkgdG8gcmVhY2ggdGhlIEludGVybmV0IHdoaWxlIGhpZGluZyBpbmZyYXN0cnVjdHVy ZSBhZGRyZXNzZXMuIEhvd2V2ZXIsIHNpbmNlIHRoaXMgaXMgYSAxOjEgbWFwcGluZyBvZiBpbnNp ZGUgYW5kIG91dHNpZGUgYWRkcmVzc2VzLCBpdCBkb2VzIG5vdCBwcm92aWRlIHRoZSBzYW1lIGxl dmVsIG9mIG9ic2N1cml0eSBhcyBOQVBUNDQgW1JGQz9dOyB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBvZiBbUkZDIDYyOTZdIHByb3ZpZGVzIGEgZ29vZCBkZXNjcmlwdGlvbi4g VGhlIHVzZSBvZiBnb29kIHBlcmltZXRlciBzZWN1cml0eSBjb250cm9scyAoc3RhdGVmdWwgZmly ZXdhbGwgcnVsZXMsIGxvZ2dpbmcgW1JGQzYzMDJdKSBwcm92aWRlcyBiZXR0ZXIgc2VjdXJpdHkg dGhhbiBhZGRyZXNzIHRyYW5zbGF0aW9uLiAgKG5vdGU6IGRpc2N1c3Npb24gb2YgZGlmZmVyZW5j ZSBiZXR3ZWVuIE5BUFQ0NCBhbmQgc3RhdGVmdWwgZmlyZXdhbGwgd291bGQgYmUgZmluZSBoZXJl LCBpZiB5b3UgY2Fu4oCZdCBmaW5kIGFub3RoZXIgZG9jdW1lbnQgdG8gcmVmZXJlbmNlKQ0KDQpJ biAyLjEuMyBjaGFuZ2U6DQogICAgICAgICAgICBUaGUgb3BlcmF0aW9uYWwgZGlzYWR2YW50YWdl cyBuZWVkIGFsc28gdG8gYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgUkZDNzQwNA0KVG8NCiAgICAg ICAgICAgIFRoZSBvcGVyYXRpb25hbCBjYXZlYXRzIGRlc2NyaWJlZCBpbiBbUkZDNzQwNF0gbmVl ZCB0byBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZC4NCg0KSW4gMi4xLjQsIEkgZG9u4oCZdCB1bmRl cnN0YW5kIGhvdyBwcml2YWN5IGV4dGVuc2lvbnMg4oCccmVkdWNlIHRoZSBhdHRhY2sgZXhwb3N1 cmUgd2luZG93LuKAnSBEbyB5b3UgbWVhbiB0aGF0IGlmIGFuIElQIGFkZHJlc3MgaXMgdGFyZ2V0 ZWQsIGEgbm9kZSBvbmx5IHVzZXMgdGhhdCBhZGRyZXNzIGZvciAoZGVmYXVsdCkgMjQgaG91cnM/ IE9yIGRvIHlvdSBtZWFuIGZld2VyIHBvcnRzIGFyZSBleHBvc2VkPyBXaGF0IGtpbmQgb2Ygd2lu ZG93IGRvIHlvdSBtZWFuPw0KDQpJIHRoaW5rIOKAnG1hbGV2b2xlbnTigJ0gaXMgdGhlIHdyb25n IHdvcmQuIOKAnE1hbGV2b2xlbnTigJ0gbWVhbnMgd2lzaGluZyBldmlsIHVwb24gYSBwZXJzb246 IGJhZCB3aWxsLiDigJxNYWxpY2lvdXPigJ0gbWVhbnMgaW50ZW5kaW5nIHRvIGRvIGV2aWwuIOKA nE1hbGV2b2xlbnTigJ0gaXMgbW9yZSBsaWtlIGhhdHJlZCwgd2hpY2ggbWF5IG9yIG1heSBub3Qg aW5jbHVkZSBhY3Rpb24uIOKAnE1hbGljaW91c+KAnSBpcyBhbiBpbnRlbnQgdG8gZG8gaGFybTsg dGhlcmVmb3JlLCBiYWQgYWN0b3JzIHBhcnRpY2lwYXRlIGluIOKAnG1hbGljaW91cyBhY3Rpdml0 aWVzLuKAnSBIb3dldmVyLCBzaW5jZSB5b3UgdGhlbiBzYXksIOKAnCh3aGV0aGVyIG9uIHB1cnBv c2Ugb3Igbm90KeKAnSBuZWl0aGVyIG9uZSBpcyB0aGUgcmlnaHQgd29yZC4gSXQgdG9vayBtZSBz ZXZlcmFsIHRpbWVzIHJlYWRpbmcsIGJ1dCBJIHRoaW5rIHlvdSBtZWFuOg0KDQpBcyBwcml2YWN5 IGV4dGVuc2lvbiBhZGRyZXNzZXMgY291bGQgYWxzbyBiZSB1c2VkIHRvIG9iZnVzY2F0ZSAoaW50 ZW50aW9uYWxseSBvciB1bmludGVudGlvbmFsbHkpIG1hbGljaW91cyBvciBwcm9oaWJpdGVkIGFj dGl2aXRpZXMsIGl0IGlzIGltcG9ydGFudCB0byBkaXNhYmxlIFNMQUFDIGFuZCByZWx5IG9uIERI Q1B2NiBpbiBzY2VuYXJpb3Mgd2hlcmUgdXNlciBhdHRyaWJ1dGlvbiBpcyBpbXBvcnRhbnQuDQoN Ckhvd2V2ZXIsIGFzIHdhcyBwb2ludGVkIG91dCBpbiBvYmplY3Rpb24gdG8gZGhjcHY2LXNsYWFj LXByb2JsZW0sIERIQ1B2NiBkb2VzbuKAmXQgcHJvdmlkZSBhIGJldHRlciByZWNvcmQ7IGlmIHlv dSB3YW50IGF0dHJpYnV0aW9uLCB5b3UgbmVlZCB0byBsb2cgTkQuDQoNClRoZSBmb2xsb3dpbmcg c2VudGVuY2UgaXMgYSBncmFtbWF0aWNhbCB3cmVjay4NCkhvd2V2ZXIsIGluIHNjZW5hcmlvcyB3 aGVyZSBhbm9ueW1pdHkgaXMgYQ0KICAgc3Ryb25nIGRlc2lyZSBzaW5jZSBwcm90ZWN0aW5nIHVz ZXIgcHJpdmFjeSBpcyBtb3JlIGltcG9ydGFudCB0aGFuDQogICB1c2VyIGF0dHJpYnV0aW9uLCBw cml2YWN5IGV4dGVuc2lvbiBhZGRyZXNzZXMgc2hvdWxkIGJlIHVzZWQNCg0KUHJvcG9zZToNCiAg ICAgICAgICAgIEhvd2V2ZXIsIGluIHNjZW5hcmlvcyB3aGVyZSBwcm90ZWN0aW5nIHVzZXIgcHJp dmFjeSBpcyBtb3JlIGltcG9ydGFudCB0aGFuIHVzZXIgYXR0cmlidXRpb24sIHByaXZhY3kgZXh0 ZW5zaW9uIGFkZHJlc3NlcyBhcmUgbW9yZSBhcHByb3ByaWF0ZS4NCg0KVGhlIHJlZmVyZW5jZSB0 byByZmM3MjE3IHNob3VsZCBjb21lIGVhcmxpZXIgaW4gdGhlIHNlY3Rpb24sIHNpbmNlIGFsbCBj b25zaWRlcmF0aW9ucyBmb3IgcHJpdmFjeSBleHRlbnNpb25zIGFwcGx5IHRvIHRob3NlIGFkZHJl c3NlcyB0b28uDQoNCjIuMS41IGlzIHRydWUsIGJ1dCBJIHRoaW5rIHRoZSBkb2N1bWVudCB3b3Vs ZCBiZSBtb3JlIHVzYWJsZSBpZiB5b3UgZ2F2ZSBhdCBsZWFzdCBvZiBoaW50IG9mIHdoYXQgcmVh ZGVycyB3aWxsIGZpbmQgaW4gQXBwZW5kaXggQSBvZiBSRkM3MjE3IGFuZCBpbiBSRkM3NzIuICBT dWdnZXN0Og0KSG93ZXZlciwgdGhlcmUgYXJlIHNldmVyYWwgcHJpdmFjeSBpc3N1ZXMgc3RpbGwg cHJlc2VudCB3aXRoDQogICBbUkZDNDk0MTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NDk0MT5dIHN1Y2ggYXMgaG9zdCB0cmFja2luZywgYW5kIGFkZHJlc3Mgc2Nhbm5pbmcgYXR0YWNr cyBhcmUNCiAgIHN0aWxsIHBvc3NpYmxlLiAgRGV0YWlscyBvbiBtZWNoYW5pc21zIGZvciBmb3Jt aW5nIGludGVyZmFjZSBpZGVudGlmaWVycyBhcmUgcHJvdmlkZWQgaW4gQXBwZW5kaXggQS4gb2Yg W1JGQzcyMTddPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjE3I2FwcGVuZGl4LUE+ LCBbUkZDNzcyMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzcyMT5dIGRlc2NyaWJl cyBzZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBpbiBkZXB0aCBmb3Igc2V2ZXJh bCBtZWNoYW5pc21zIHVzZWQgdG8gZ2VuZXJhdGUgSVB2NiBhZGRyZXNzZXMuDQoNCjIuMS42IOKA nGF1ZGliaWxpdHnigJ0gc2hvdWxkIGJlIOKAnGF1ZGl0YWJpbGl0eeKAnQ0KDQrigJxETlMgaXMg b2Z0ZW4gdXNlZCBmb3IgbWFsd2FyZSBhY3Rpdml0aWVz4oCdIG1ha2VzIGl0IHNvdW5kIGxpa2Ug aXTigJlzIGFuIGF0dGFjayB2ZWN0b3IgdGhhdCBzaG91bGQgYmUgc2h1dCBkb3duLiAgQWxzbywg d2h5IGlzIEROUyBkaXNjdXNzZWQgdW5kZXIg4oCcQWRkcmVzc2luZyBBcmNoaXRlY3R1cmXigJ0/ DQoNCjIuMiBpc27igJl0IGV2ZW4gd3JpdHRlbi4gRG9u4oCZdCBhc2sgZm9yIHJldmlldyB1bnRp bCB5b3UgZmluaXNoIHdyaXRpbmcgeW91ciBkb2N1bWVudC4NCg0KMi4zLjEg4oCcZ2VuZXJpYyBv cGVyYXRpbmcgc3lzdGVtc+KAnSAgRG8geW91IG1lYW4gU2VORCBpc27igJl0IHN1cHBvcnRlZCBp biByb3V0ZXJzLCBvciBpbiBob3N0cz8NCg0KMi4zLjIgU2hvdWxkbuKAmXQg4oCcU2VjdXJpbmcg REhDUOKAnSBiZSB1bmRlciAyLjEuNiDigJxESENQ4oCdPyBPciBzaG91bGQgMi4xLjYgYmUgaGVy ZT8NCg0KRm9ybWF0dGluZyBlcnJvciBjcmVhdGVzIGNvbmZ1c2lvbjoNCnRocmVhdHMgYWdhaW5z dCBESENQIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5DQogICBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uIG9mIFJGQzMzMTU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMzMTU+IFtS RkMzMzE1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMzE1Pl1ESENQLXNoaWVsZA0K DQogICBSRkM3NjEwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjEwPiBbUkZDNzYx MDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYxMD5dIHNwZWNpZmllcyBhIG1lY2hh bmlzbSBmb3IgcHJvdGVjdGluZyBob3N0cw0KDQoyLjMuMyBJIHRoaW5rIE5EL1JBIHZ1bG5lcmFi aWxpdHkgaXMgYSBtYWluIHNlY3Rpb24sIHdpdGggUmF0ZSBMaW1pdGluZyBhbmQgRmlsdGVyaW5n IGFzIHN1YnNlY3Rpb25zLg0KDQoNCiAyLjMuNSAgVGhpcyBzZWN0aW9uIGlzIGVkdWNhdGlvbmFs IGZvciBtZS4NCknigJltIGNvbmZ1c2VkIGFib3V0IOKAnHRoZSBhZHZlcnRpc2VkIC82NCBvbiB0 aGUgbGlua+KAnSBpZiB0aGVyZeKAmXMgb25seSBMTEEuIElzIHRoZXJlIGFuIGFkdmVydGlzZWQg R1VBPyBEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gcmV3b3JkIHRoaXM/DQpUaGUgR0dTTi9QR1cgbmV2 ZXINCiAgIGNvbmZpZ3VyZXMgYSBub24gbGluay1sb2NhbCBhZGRyZXNzIG9uIHRoZSBsaW5rIHVz aW5nIHRoZSBhZHZlcnRpc2VkDQogICAvNjQgcHJlZml4IG9uIGl0Lg0KVG8NClRoZSBHR1NOL1BH VyBuZXZlciBjb25maWd1cmVzIGFueXRoaW5nIG90aGVyIHRoYW4gYSBub24gbGluay1sb2NhbCBh ZGRyZXNzIG9uIHRoZSBsaW5rLg0KDQrigJxUaGVyZSBpcyBubyBuZWVkIGZvciBhZGRyZXNzIHJl c29sdXRpb27igKbigJ0gY291bGQgYmUgc3BlY2lmaWNhbGx5IOKAnGFkZHJlc3MgcmVzb2x1dGlv biB0aHJvdWdoIE5laWdoYm9yIERpc2NvdmVyeeKApuKAnQ0KDQpTdGlsbCBjb25mdXNlZC4gVGhl IEdHU04vUEdXIGFzc2lnbnMgYSBHVUEgdG8gdGhlIExMQSBsaW5rPyAgT3IgYSBVTEE/IE9yIHNv bWUgb3RoZXIgc2NvcGUgb2Yg4oCcdW5pcXVl4oCdPyAgQW5kIGl04oCZcyBhc3NpZ25lZCB0byBh IGxpbmsgdGhhdCB1c2VzIG9ubHkgTExBPw0KDQoyLjQgVGhhbmtzIGZvciBpbmNsdWRpbmcgdGhl IGRlZmluaXRpb24gb2Yg4oCcY29udHJvbCBwbGFuZeKAnSBoZXJlLCBidXQgc2luY2UgaXTigJlz IHF1b3RlZCwgd291bGQgeW91IHVzZSBibG9ja3F1b3RlIGZvcm1hdD8gVGhhdCB3YXkgSeKAmWxs IGtub3cgd2hlbiB0aGUgcXVvdGUgZW5kcyBhbmQgb3JpZ2luYWwgdGV4dCBiZWdpbnMuDQoNCkkg dGhpbmsgeW91IG1lYW4g4oCcZ2VuZXJhbCBwdXJwb3NlIHByb2Nlc3NvcuKAnSByYXRoZXIgdGhh biDigJxnZW5lcmljIHByb2Nlc3Nvci7igJ0gSSByZWFkIOKAnGdlbmVyaWPigJ0gYW5kIHRoaW5r IHlvdSBtZWFuIGl0IGhhcyBubyBicmFuZCBuYW1lIGF0dGFjaGVkLCBidXQgSSB0aGluayB5b3Ug bWVhbiBpdOKAmXMgbm90IGN1c3RvbSBzaWxpY29uLCBldmVuIGlmIGl04oCZcyBtYWRlIGJ5IElu dGVsLCBCcm9hZGNvbSwgUXVhbGNvbW0sIG9yIHdoYXRldmVyLg0KDQpUd28gbWl0aWdhdGlvbiB0 ZWNobmlxdWVzIGFyZSBnaXZlbiBmb3IgY29udHJvbCBwbGFuZSBwcm90ZWN0aW9uIChuZWl0aGVy IG9mIHdoaWNoIGlzIHNwZWNpZmljIHRvIElQdjYsIGJ0dyksIGJ1dCBJ4oCZbSBub3QgY2xlYXIg b24gaG93IHRoZXkgYXJlIHRvIGJlIGltcGxlbWVudGVkLiBIb3cgZG8gSSBpZGVudGlmeSDigJxu b24tbGVnaXQgY29udHJvbCBwbGFuZSBwYWNrZXRbc13igJ0gaW4gYW4gQUNMPyBJcyB0aGF0IHdo YXQgc2VjdGlvbiAyLjQuMSBpcz8gQ2FuIHlvdSBnaXZlIGd1aWRhbmNlIG9uIHJhdGUgbGltaXRp bmc/IElzIHRoZXJlIGd1aWRhbmNlIG9uIHByb3RvY29sLXNwZWNpZmljIHByb3RlY3Rpb24gZm9y IGVhY2ggb2YgdGhlc2UgcHJvdG9jb2xzPw0KDQoyLjQuMg0KUGxlYXNlIHJld29yZDoNCihmb3Ig ZXhhbXBsZSwgcGVybWl0IFRDUCAyMiBhbmQgZHJvcCBhbGwNCiAgICAgIHdoZW4gb25seSBTU0gg aXMgdXNlZCkNCnRvDQooZS5nLiwgdG8gYWxsb3cgU1NIIG9ubHksIHBlcm1pdCBUQ1AgMjIgYW5k IGRyb3AgYWxsIG90aGVycykNCg0KSSBsaWtlIHRoZSBleGFtcGxlIG9mIHRoZSBOT0MgcHJlZml4 LiBJbiBmYWN0LCBJIHRoaW5rIHRoaXMgaXMgYSBzZWN1cml0eSBhZHZhbnRhZ2Ugb2YgSVB2Niwg c2luY2UgdGhlIGFkZHJlc3MgYXJjaGl0ZWN0dXJlIG1heSBiZSBtdWNoIGNsZWFuZXIsIHNvIHlv dSBjYW4gd3JpdGUgYW4gQUNMIHRvIG1hdGNoIHNlY3VyaXR5IHBvbGljeSBpbiBqdXN0IGEgbGlu ZSBvciB0d28gb2YgQUNMLCBpbnN0ZWFkIG9mIGh1bmRyZWRzLiBCdXQgSeKAmW0gbm90IHN1cmUg dGhhdOKAmXMgd29ydGggc2F5aW5nLg0KDQoNCjIuNC4zIFRoaXMgc2VjdGlvbiBpcyB2ZXJ5IGZy dXN0cmF0aW5nIChub3QgdGhlIGF1dGhvcnPigJkgZmF1bHQpOg0KVGhlIG9ubHkgcHJvdGVjdGlv biBmb3IgdGhlIFJQIGlzIHRvIGxpbWl0DQogICB0aGUgcmF0ZSBvZiB0aG9zZSBwYWNrZXQgZXhj ZXB0aW9ucyBmb3J3YXJkZWQgdG8gdGhlIFJQLCB0aGlzIG1lYW5zDQogICB0aGF0IHNvbWUgZGF0 YSBwbGFuZSBwYWNrZXRzIHdpbGwgYmUgZHJvcHBlZCB3aXRob3V0IGFueSBJQ01QDQogICBtZXNz YWdlcyBiYWNrIHRvIHRoZSBzb3VyY2Ugd2hpY2ggd2lsbCBjYXVzZSBQYXRoIE1UVSBob2xlcy4g IEJ1dCwNCiAgIHRoZXJlIGlzIG5vIG90aGVyIHNvbHV0aW9uLg0KDQpJcyBpdCBwb3NzaWJsZSB0 byBkbyBtb3JlIGFkdmFuY2VkIHF1ZXVlaW5nLCB0byByYXRlIGxpbWl0IG9ubHkgSEJIIHBhY2tl dHMsIG9yIHRvIGRlcXVldWUgYmFzZWQgb24gc291cmNlIGFkZHJlc3MgKHNvIHRoYXQgYW4gYXR0 YWNrZXIgZ2V0cyBubyBtb3JlIHRpbWUgb24gdGhlIFJQIHRoYW4gYW55b25lIGVsc2UpPyBJdCBt aWdodCBub3QgYmU7IGVpdGhlciBiZWNhdXNlIGF0dGFja3MgdGVuZCB0byBiZSBkaXN0cmlidXRl ZCBhbnl3YXksIG9yIGJlY2F1c2UgdGhlIG92ZXJoZWFkIG9mIHRoYXQgbXVjaCBhbmFseXNpcyB3 b3VsZCBvZmZzZXQgdGhlIHByb3RlY3Rpb24gaXQgd291bGQgcHJvdmlkZS4gQXQgd29yc3QsIGNv dWxkIHlvdSBzYXkgaW5zdGVhZCwg4oCcVGhlcmUgaXMgbm8ga25vd24gY3VycmVudCBzb2x1dGlv bjsgdGhpcyBpcyBhbiBhcmVhIGZvciBmdXR1cmUgd29yay7igJ0/DQoNCjIuNS4xDQptaXNzaW5n IGNsb3NlIHBhcmVudGhlc2lzOg0KDQood2hpY2ggb2Jzb2xldGVzIFJGQzY1MDY8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY1MDY+IFtSRkM2NTA2PGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NTA2Pl0NCg0KVGhlcmUgYXJlIHR3byBsb25nIHBhcmFncmFwaHMgb24gT1NQ RnYzLCBidXQgbm8gc3BlY2lmaWMgZGlzY3Vzc2lvbiBvZiBhbnkgb3RoZXIgcm91dGluZyBwcm90 b2NvbHMuIElzIGFueSBvZiB0aGlzIHNwZWNpZmljIHRvIElQdjY/DQoNCjIuNS4yDQpObyByZWNv bW1lbmRhdGlvbnM/IFN1Z2dlc3Rpb25zIGZvciBmdXR1cmUgd29yaz8NClJpc2tzPyBJIG1lYW4s IHR3byBwZWVycyBvbiBhIHBvaW50LXRvLXBvaW50IGxpbmsgaGF2ZSBsaW1pdGVkIGV4cG9zdXJl LiBQZWVycyB3aXRoIG11bHRpaG9wIG9yIHVzaW5nIHZpcnR1YWwgY29ubmVjdGlvbnMgaGF2ZSBn cmVhdGVyIGV4cG9zdXJlLg0KDQoyLjUuMw0KQSBsaW5rIHRvIFJGQzY4OTAsIG1heWJlIHdpdGgg Y29tbWVudGFyeSwgd291bGQgYmUgd2VsY29tZSBpbiB0aGUgZGlzY3Vzc2lvbiBvZiByZXNlcnZl ZCBwcmVmaXhlcy4NCg0KMi42LjEgVGhlc2Ugc2VjdGlvbnMgZmVlbCBhIGxpdHRsZSBsaWdodCBv biB3aGF0IHNob3VsZCBiZSBsb2dnZWQgYW5kIHdoeS4gT2gsIG5vdyBJIHNlZSB0aGF0IOKAnHdo eeKAnSBpcyBjb3ZlcmVkIGluIDIuNi4yLg0KDQoyLjYuMS4xIFJlZHVuZGFuY3kgaW4gdGhlIHNl Y29uZCBwYXJhZ3JhcGgNCg0KMi43IOKAnHNvbWUgdGV4dOKAnT8NCg0KMi43LjINCuKAnFRvIG1p dGlnYXRlIGJ5cGFzc2luZyBvZiBzZWN1cml0eSBwb2xpY2llc+KAnSBtaWdodCBiZXR0ZXIgYmUs IOKAnFRvIHByZXZlbnQgYnlwYXNzaW5nIHNlY3VyaXR5IHBvbGljaWVzLCB3aGV0aGVyIGltcGxl bWVudGVkIG9uIGEgZmlyZXdhbGwgb3IganVzdCBhIGxheWVyIDQgQUNMLOKAnQ0KDQoyLjcuMi4x IOKAnHRyYWZmaWMgaW50ZXJjZXB0aW9uIGFkIHR1bm5lbCBpbmplY3Rpb27igJ0gc2hvdWxkIGJl IOKAnGFuZOKAnQ0KDQoyLjcuMi4yIOKAnGFuZCBhbmTigJ0NCg0KMi43LjIuMyDigJxibG9jayBh bGwgVURQIG91dGJvdW5kIHRyYWZmaWPigJ0NClRoYXQgZG9lc27igJl0IHNlZW0gYSBiaXQgZHJh Y29uaWFuPyBUaGVyZSBhcmUgbG90cyBvZiBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgVURQLCBhbmQg bWFueSBvZiB0aGVtIHVzZSBpdCBzcGVjaWZpY2FsbHkgdG8gZ2V0IGFyb3VuZCBmaXJld2FsbHMu IEdhbWVzLCBSVFAsIFFVSUMsIC4gLiAuDQoNCjIuNy4yLjggSSB0aGluayBJIHNhaWQgdGhpcyBi ZWZvcmUsIGJ1dCBSRkMgMjExOSDigJxNVVNU4oCdIGlzbuKAmXQgcmVhbGx5IGFwcHJvcHJpYXRl IGluIGFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQsIG9yIGV2ZW4gYSBCQ1AuIFJGQyAyMTE5IHNh eXMgaXTigJlzIGZvciBzcGVjaWZpY2F0aW9ucywgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHku DQoNCjQuMSBCYWNrIGluIDIuNS4xIHlvdSBoYWQgZGlzY3Vzc2lvbiBvZiBPU1BGdjMuIEFyZSB0 aGVyZSBhbnkgQkdQIG5vdGVzIGluIDQuMSB0aGF0IHdvdWxkIGFwcGx5IHRoZXJlLCBpbiB0aGUg Y29udHJvbCBwbGFuZSBzZWN0aW9uPw0KDQo0LjMgIFlvdSBzYXkgbGF3ZnVsIGludGVyY2VwdCBj YW4gdGFyZ2V0IOKAnHNpbmdsZSBob3N0IChhIC8xMjggdGFyZ2V0KeKAnSBidXQgaWYgdGhlIGNs aWVudCBpcyB1c2luZyBwcml2YWN5IGV4dGVuc2lvbnMsIHRoYXQgd2lsbCBub3QgYmUgZW5vdWdo IGRldGFpbC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K --_000_7FE9B6A250134B4A9959554BDC9DA120chartercom_ Content-Type: text/html; charset="utf-8" Content-ID: <6C485D8C81D9F641BE3CDD13CFF0C1B0@twcable.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlRpdGxlIiBjb250ZW50PSIi Pg0KPG1ldGEgbmFtZT0iS2V5d29yZHMiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJQcm9nSWQi IGNvbnRlbnQ9IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iZmlsZTovL2xv Y2FsaG9zdC9Vc2Vycy9MZWVIb3dhcmQvTGlicmFyeS9Hcm91cCUyMENvbnRhaW5lcnMvVUJGOFQz NDZHOS5PZmZpY2UvbXNvY2xpcDEvMDEvY2xpcF9maWxlbGlzdC54bWwiPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxvOkFsbG93UE5HLz4N CiAgPG86UGl4ZWxzUGVySW5jaD45NjwvbzpQaXhlbHNQZXJJbmNoPg0KIDwvbzpPZmZpY2VEb2N1 bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PGxpbmsgcmVsPSJ0aGVtZURhdGEiIGhy ZWY9ImZpbGU6Ly9sb2NhbGhvc3QvVXNlcnMvTGVlSG93YXJkL0xpYnJhcnkvR3JvdXAlMjBDb250 YWluZXJzL1VCRjhUMzQ2RzkuT2ZmaWNlL21zb2NsaXAxLzAxL2NsaXBfdGhlbWVkYXRhLnRobXgi PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6Vmlldz5O b3JtYWw8L3c6Vmlldz4NCiAgPHc6Wm9vbT4wPC93Olpvb20+DQogIDx3OlRyYWNrTW92ZXMvPg0K ICA8dzpUcmFja0Zvcm1hdHRpbmcvPg0KICA8dzpQdW5jdHVhdGlvbktlcm5pbmcvPg0KICA8dzpW YWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCiAgPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpT YXZlSWZYTUxJbnZhbGlkPg0KICA8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3Jl TWl4ZWRDb250ZW50Pg0KICA8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93OkFs d2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQogIDx3OkRvTm90UHJvbW90ZVFGLz4NCiAgPHc6TGlk VGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KICA8dzpMaWRUaGVtZUFzaWFuPlgt Tk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KICA8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05F PC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkJy ZWFrV3JhcHBlZFRhYmxlcy8+DQogICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4NCiAgIDx3OldyYXBU ZXh0V2l0aFB1bmN0Lz4NCiAgIDx3OlVzZUFzaWFuQnJlYWtSdWxlcy8+DQogICA8dzpEb250R3Jv d0F1dG9maXQvPg0KICAgPHc6U3BsaXRQZ0JyZWFrQW5kUGFyYU1hcmsvPg0KICAgPHc6RW5hYmxl T3BlblR5cGVLZXJuaW5nLz4NCiAgIDx3OkRvbnRGbGlwTWlycm9ySW5kZW50cy8+DQogICA8dzpP dmVycmlkZVRhYmxlU3R5bGVIcHMvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPG06bWF0aFBy Pg0KICAgPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KICAgPG06YnJrQmluIG06 dmFsPSJiZWZvcmUiLz4NCiAgIDxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQogICA8bTpz bWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KICAgPG06ZGlzcERlZi8+DQogICA8bTpsTWFyZ2luIG06 dmFsPSIwIi8+DQogICA8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQogICA8bTpkZWZKYyBtOnZhbD0i Y2VudGVyR3JvdXAiLz4NCiAgIDxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCiAgIDxtOmlu dExpbSBtOnZhbD0ic3ViU3VwIi8+DQogICA8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCiAg PC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIg RGVmVW5oaWRlV2hlblVzZWQ9ImZhbHNlIg0KICBEZWZTZW1pSGlkZGVuPSJmYWxzZSIgRGVmUUZv cm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSINCiAgTGF0ZW50U3R5bGVDb3VudD0iMzgwIj4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIwIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJOb3JtYWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAg VW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49 InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg U2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0 cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNl bWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iaGVhZGluZyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImluZGV4IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog ICBOYW1lPSJpbmRleCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImluZGV4IDQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog ICBOYW1lPSJpbmRleCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImluZGV4IDciLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggOCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQog ICBOYW1lPSJpbmRleCA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0idG9jIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1p SGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49 InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJ0b2MgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9InRvYyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iaGVhZGVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImZvb3RlciIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzUiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZW52 ZWxvcGUgcmV0dXJuIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImZvb3Rub3RlIHJlZmVy ZW5jZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJsaW5lIG51bWJlciIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJwYWdlIG51bWJlciIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJl bmRub3RlIHJlZmVyZW5jZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJlbmRub3RlIHRl eHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0ibWFjcm8iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAg TmFtZT0idG9hIGhlYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi DQogICBOYW1lPSJMaXN0IE51bWJlciIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0 IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCAzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9Ikxpc3QgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h bWU9Ikxpc3QgQnVsbGV0IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBCdWxs ZXQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K ICAgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0 IE51bWJlciA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h bWU9IkNsb3NpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iU2lnbmF0dXJlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0i dHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBG b250Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgSW5kZW50Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9Ikxpc3QgQ29udGludWUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBD b250aW51ZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQ29udGludWUgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRpbnVlIDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBDb250aW51ZSA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9Ik1lc3NhZ2UgSGVhZGVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMTEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9IlNhbHV0YXRpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iRGF0ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5k ZW50Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIEhlYWRpbmciLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iQm9keSBUZXh0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IElu ZGVudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCbG9jayBUZXh0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9Ikh5cGVybGluayIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJGb2xs b3dlZEh5cGVybGluayIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFz aXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iRG9jdW1lbnQgTWFwIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9IlBsYWluIFRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iRS1tYWlsIFNpZ25hdHVyZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIFRv cCBvZiBGb3JtIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgQm90dG9tIG9mIEZv cm0iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm9ybWFsIChXZWIpIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgQWNyb255bSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJIVE1MIEFkZHJlc3MiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBDaXRl Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgQ29kZSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJIVE1MIERlZmluaXRpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iSFRNTCBLZXlib2FyZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIFByZWZv cm1hdHRlZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIFNhbXBsZSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIFR5cGV3cml0ZXIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iSFRNTCBWYXJpYWJsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJO b3JtYWwgVGFibGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iYW5ub3RhdGlvbiBzdWJq ZWN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vIExpc3QiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIg0KICAgTmFtZT0iT3V0bGluZSBMaXN0IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iT3V0bGluZSBMaXN0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iT3V0bGluZSBM aXN0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU2ltcGxlIDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU2ltcGxlIDIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iVGFibGUgU2ltcGxlIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i VGFibGUgQ2xhc3NpYyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENsYXNz aWMgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDbGFzc2ljIDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ2xhc3NpYyA0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9IlRhYmxlIENvbG9yZnVsIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iVGFibGUgQ29sb3JmdWwgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBD b2xvcmZ1bCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbHVtbnMgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1bW5zIDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9IlRhYmxlIENvbHVtbnMgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs ZSBDb2x1bW5zIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgR3JpZCAxIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgMiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i VGFibGUgR3JpZCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgNSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDYiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIg0KICAgTmFtZT0iVGFibGUgR3JpZCA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IlRhYmxlIEdyaWQgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDEi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCAyIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJUYWJsZSBMaXN0IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCA1 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgNiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iVGFibGUgTGlzdCA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIDNEIGVm ZmVjdHMgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAzIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbnRlbXBvcmFyeSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJUYWJsZSBFbGVnYW50Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IlRhYmxlIFByb2Zlc3Npb25hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBT dWJ0bGUgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBTdWJ0bGUgMiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBXZWIgMSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi DQogICBOYW1lPSJUYWJsZSBXZWIgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs ZSBXZWIgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJCYWxsb29uIFRleHQiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0iVGFibGUg R3JpZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBUaGVtZSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAg TmFtZT0iTm90ZSBMZXZlbCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2 ZWwgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9Ik5vdGUgTGV2ZWwgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExl dmVsIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA4Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgOSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFFGb3JtYXQ9 InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdy aWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExp c3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIE5hbWU9IlJldmlzaW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzQiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJMaXN0IFBhcmFn cmFwaCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iSW50ZW5zZSBRdW90 ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwg R3JpZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0i TGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2Vu dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5h bWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBT aGFkaW5nIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVt IExpc3QgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNj ZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsg TGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIg TmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRp dW0gTGlzdCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYw IiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQg R3JpZCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAz IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNv bG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5n IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBB Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iU3VidGxlIEVtcGhhc2lz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3Jt YXQ9InRydWUiDQogICBOYW1lPSJJbnRlbnNlIEVtcGhhc2lzIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJT dWJ0bGUgUmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzIiIFFGb3JtYXQ9InRydWUiDQogICBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzciIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MSIgTmFtZT0iUGxhaW4gVGFibGUgMSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBOYW1lPSJQbGFpbiBU YWJsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMi IE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NCIgTmFtZT0iUGxhaW4gVGFibGUgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFi bGUgTGlnaHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp ZCBUYWJsZSA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRh YmxlIDcgQ29sb3JmdWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NiINCiAgIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxl IDIgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJH cmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2Vu dCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQog ICBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9IkdyaWQgVGFibGUgMSBM aWdodCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iR3Jp ZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNj ZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIN CiAgIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50 IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt ZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxl IDUgRGFyayBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJH cmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2Nl bnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFi bGUgNCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiDQogICBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9 IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBU YWJsZSAzIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBB Y2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUx Ig0KICAgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJHcmlkIFRhYmxl IDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NiINCiAgIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlk IFRhYmxlIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO YW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVs IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTIiDQogICBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAx IExpZ2h0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci IE5hbWU9Ikxpc3QgVGFibGUgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUg NSBEYXJrIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEi IE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9Ikxp c3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJs ZSAzIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2Nl bnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0K ICAgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJMaXN0IFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRh YmxlIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi DQogICBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9Ikxpc3QgVGFibGUg MSBMaWdodCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2Vu dCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0i TGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwg QWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNj ZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIg TmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRh YmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1l PSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBB Y2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3 IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3Qg VGFibGUgNCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIg0KICAgTmFtZT0iTGlzdCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiINCiAgIE5h bWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDYiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlz dCBUYWJsZSAzIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy ayBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiDQogICBOYW1lPSJMaXN0IFRh YmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCiA8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFb ZW5kaWZdLS0+PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1 IDIgNCA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTph dXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2 ODU5OTA1IC0xMDczNzExMDM3IDkgMCA1MTEgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7DQoJbXNvLWZv bnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQt cGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTEwNzMwNTcy NyAwIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2Vu ZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1m b250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEwNzM3ODYxMTEgMSAwIDQxNSAwO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28t c3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFz Y2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1oYW5zaS1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLXRoZW1l LWZvbnQ6bWlub3ItYmlkaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgltc28tdGhlbWVjb2xv cjpmb2xsb3dlZGh5cGVybGluazsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQt dW5kZXJsaW5lOnNpbmdsZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1sYXRpbjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXVuaGlk ZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1oYW5zaS1mb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVz Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1z by1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9y LWxhdGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1i aWRpLXRoZW1lLWZvbnQ6bWlub3ItYmlkaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFk ZXItbWFyZ2luOi41aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291 cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1h bCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6 ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0 Ow0KCW1zby1wYXJhLW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+SSBoYXZlIGRvbmUg YSB0aG9yb3VnaCByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCAoZXZlbiBhcyBpdCB3YXMgdXBkYXRl ZCBmcm9tIOKAkzggdG8g4oCTMDksIHNvIHRoZSByZWxldmFuY2Ugb2YgbXkgY29tbWVudHMgbWF5 IGNoYW5nZSBwYXJ0d2F5IHRocm91Z2guIEkgZGlkIHRha2UgYSBsb25nIHRpbWUsIGJ1dCBpdCdz IGJlY2F1c2UgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlbGV2YW50IGFuZCBpdCBzaG91bGQg YmUgdmVyeSBnb29kIGFuZA0KIHJlYWRhYmxlIHRvIG1ha2UgaXQgYXMgdXNlZnVsIGFzIHBvc3Np YmxlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm90ZXMgYmVsb3cuPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TGVlPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4tLTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86QWxs b3dQTkcvPg0KICA8bzpQaXhlbHNQZXJJbmNoPjk2PC9vOlBpeGVsc1BlckluY2g+DQogPC9vOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlZpZXc+Tm9ybWFsPC93OlZpZXc+DQog IDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpUcmFja01vdmVzLz4NCiAgPHc6VHJhY2tGb3JtYXR0 aW5nLz4NCiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2No ZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4N CiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAg PHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xk ZXJUZXh0Pg0KICA8dzpEb05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8 L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCiAgPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBs ZXhTY3JpcHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpCcmVha1dyYXBwZWRUYWJsZXMv Pg0KICAgPHc6U25hcFRvR3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQog ICA8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0Lz4NCiAgIDx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCiAgIDx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+ DQogICA8dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0KICAgPHc6T3ZlcnJpZGVUYWJsZVN0eWxl SHBzLz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDxtOm1hdGhQcj4NCiAgIDxtOm1hdGhGb250 IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCiAgIDxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQog ICA8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KICAgPG06c21hbGxGcmFjIG06dmFsPSJv ZmYiLz4NCiAgIDxtOmRpc3BEZWYvPg0KICAgPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06 ck1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQog ICA8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQogICA8bTppbnRMaW0gbTp2YWw9InN1YlN1 cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQogIDwvbTptYXRoUHI+PC93Oldv cmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSINCiAgRGVmU2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQ cmlvcml0eT0iOTkiDQogIExhdGVudFN0eWxlQ291bnQ9IjM4MCI+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFs Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRl V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUi DQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJoZWFkaW5nIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0K ICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggNiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggOSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlk ZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJ0b2MgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzki IFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJOb3JtYWwgSW5kZW50Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImZvb3Rub3RlIHRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iYW5u b3RhdGlvbiB0ZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImhlYWRlciIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJmb290ZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iaW5kZXggaGVhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i dGFibGUgb2YgZmlndXJlcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJlbnZlbG9wZSBh ZGRyZXNzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iYW5ub3RhdGlvbiByZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0ibGluZSBudW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0icGFn ZSBudW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZW5kbm90ZSByZWZlcmVuY2Ui Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9Im1hY3JvIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9InRvYSBoZWFkaW5n Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K ICAgTmFtZT0iTGlzdCBCdWxsZXQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBO dW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCAyIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9Ikxpc3QgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i TGlzdCBCdWxsZXQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJMaXN0IE51bWJlciAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVt YmVyIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJUaXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJDbG9zaW5nIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlNpZ25hdHVyZSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i Qm9keSBUZXh0IEluZGVudCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRp bnVlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 Ikxpc3QgQ29udGludWUgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJNZXNzYWdlIEhl YWRlciIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJTYWx1dGF0aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkRhdGUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50IDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIg0KICAgTmFtZT0iTm90ZSBIZWFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IkJvZHkgVGV4dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iQmxvY2sgVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIeXBl cmxpbmsiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iRm9sbG93ZWRIeXBlcmxpbmsiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJQbGFpbiBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkUtbWFpbCBTaWduYXR1 cmUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBBZGRyZXNz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJIVE1MIENvZGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRN TCBEZWZpbml0aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgS2V5Ym9hcmQi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAg TmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwg VmFyaWFibGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJObyBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91 dGxpbmUgTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91dGxpbmUgTGlzdCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxl IFNpbXBsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs ZSBDb2xvcmZ1bCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbG9yZnVs IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IlRhYmxlIENvbHVtbnMgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1 bW5zIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi DQogICBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi bGUgR3JpZCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRh YmxlIEdyaWQgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJU YWJsZSBMaXN0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i VGFibGUgTGlzdCA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgOCIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi bGUgRWxlZ2FudCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBQcm9mZXNzaW9u YWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K ICAgTmFtZT0iVGFibGUgV2ViIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUg V2ViIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgV2ViIDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgVGhlbWUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iTm90ZSBMZXZlbCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVsIDMiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5h bWU9Ik5vdGUgTGV2ZWwgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJOb3RlIExldmVs IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm90ZSBMZXZlbCA3Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9Ik5vdGUgTGV2ZWwgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJOb3RlIExldmVsIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBT cGFjaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAi IE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdy aWQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBO YW1lPSJNZWRpdW0gR3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRp bmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFt ZT0iQ29sb3JmdWwgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1l PSJSZXZpc2lvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM0IiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iUXVvdGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz MCIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVk aXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBB Y2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGln aHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAx IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0 IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJM aWdodCBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0i TWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlk IDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1l PSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQg NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5h bWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExp c3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBM aXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg NiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1l PSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwg U2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIg UUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFt ZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMxIiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0 PSJ0cnVlIg0KICAgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBU aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBT ZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dy YXBoeSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUi IE5hbWU9IlRPQyBIZWFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MiIgTmFtZT0iUGxhaW4gVGFibGUgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQzIiBOYW1lPSJQbGFpbiBUYWJs ZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQiIE5h bWU9IlBsYWluIFRhYmxlIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NSIgTmFtZT0iUGxhaW4gVGFibGUgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRhYmxlIExpZ2h0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi bGUgMSBMaWdodCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRh YmxlIDUgRGFyayIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1l PSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAxIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQg VGFibGUgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJs ZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3Jp ZCBUYWJsZSAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNj ZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1 bCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5h bWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9y ZnVsIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAy IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3Jp ZCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAg TmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGln aHQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH cmlkIFRhYmxlIDQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQog ICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 IkdyaWQgVGFibGUgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1 IERhcmsgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3Jp ZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxl IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt ZT0iTGlzdCBUYWJsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxl IDYgQ29sb3JmdWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0 IFRhYmxlIDQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAx Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBO YW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxp c3QgVGFibGUgMyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERh cmsgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBU YWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQg QWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xv cmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0 IFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUg MyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAg IE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJs ZSAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0K ICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEg TGlnaHQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQg NiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxp c3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFj Y2VudCA2Ii8+DQogPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1z b05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5 bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5 bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVu dDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1t YXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5h dGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS10aGVtZS1m b250Om1pbm9yLWxhdGluOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1o YW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGluO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0t U3RhcnRGcmFnbWVudC0tPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBsaXN0ZWQgYXMg SW5mb3JtYXRpb25hbCwgYnV0IGluIHNvbWUgcGxhY2VzIGlzIHJlY29tbWVuZGluZyBiZXN0IHBy YWN0aWNlLiBJcyB0aGlzIHJlYWxseSBpbnRlbmRlZCB0byBiZSBhIEJDUD8gSSBhbHdheXMgZmVl bCBzdHJhbmdlIHNlZWluZyBSRkMyMTE5IGJvaWxlcnBsYXRlIGFuZCBsYW5ndWFnZSBpbiBhbiBJ bmZvcm1hdGlvbmFsIGRvY3VtZW50LiBGb3IgaW5zdGFuY2UsIDIuMS40IHNheXMsDQog4oCcSXQg bXVzdCBiZSBub3RlZCB0aGF0LuKAnSZuYnNwOyBUaGF04oCZcyBub3QgYW4gUkZDIDIxMTkgdXNl IG9mIOKAnG11c3Qs4oCdIGRlc3BpdGUgd2hhdCAxLjEgc2F5cy4mbmJzcDsgQnV0IDIuMy41IHNh eXMg4oCccHJlZml4IG11c3Qgbm90IGJlIHVzZWQgZm9yIG9uLWxpbmsgZGV0ZXJtaW5hdGlvbi7i gJ0gTm90IHN1cmUgaWYgdGhhdOKAmXMgZ29vZCBhZHZpY2Ugb3IgcmVmZXJzIHRvIGEgM0dQUCBz cGVjaWZpY2F0aW9uLCBzbyBpdOKAmXMgdW5jbGVhci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHRoaW5rIHRoZSB0b25lIHN1Z2dlc3RpbmcgSVB2NiBpcyBuZXcgaXMgbWlzcGxhY2VkLiBU aGlzIHN0YXJ0cyByaWdodCBpbiB0aGUgYWJzdHJhY3QsIGJ1dCBSRkMgNDk0MiB3YXMgcHVibGlz aGVkIDkgeWVhcnMgYWdvLiBNYXliZSBjaGFuZ2UgaXQgdG8sIOKAnFNvbWUgb2YgdGhlIHNlY3Vy aXR5IGNoYWxsZW5nZXMgaW4gSVB2NiBhcmUgZGlmZmVyZW50IHRoYW4gdGhvc2UgaW4gSVB2NC7i gJ0mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgSW50cm9kdWN0aW9uIGNvbnRp bnVlcyB0aGUgdGhlbWUgdGhhdCBJUHY2IGlzIG5ldy4gSXQgYWxzbyBkb2VzbuKAmXQgc2F5IG11 Y2ggYnkgd2F5IG9mIGludHJvZHVjaW5nIHRoZSBkb2N1bWVudC4mbmJzcDsgQ3V0IHRoZSBmaXJz dCB0d28gcGFyYWdyYXBocy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDIgdGl0bGUgc2hvdWxkIHByb2Jh Ymx5IGJlIOKAnEdlbmVyYWwgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ0gbm90IOKAnEdlbmVy aWMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKA mWQgbGlrZSB0byBzZWUgc29tZSBkZXNjcmlwdGlvbiBvZiB3aHkgaXTigJlzIGhhcmQgdG8gcmVu dW1iZXIuIEEgcG9pbnRlciB0byBhdCBsZWFzdCBSRkM2ODY2LCBhbmQgbWF5YmUgUkZDNjg3OSBh bmQgUkZDNzAxMC4gWW91IGNvdWxkIG1lbnRpb24gb25nb2luZyB3b3JrIGluIFNVUEEgb3IgQU5J TUEsIGJ1dCBkb27igJl0IGhhdmUgdG8uIFRoZSBtb3N0IHJlbGV2YW50IG5vdGUgaW4gcmVudW1i ZXJpbmcgaXMgcmZjNjg2Ng0KIDIuOCwgdGhhdCBBQ0xzIChhbmQgYnkgZXh0ZW5zaW9uLCBmaXJl d2FsbCBydWxlcykgbmVlZCB0byBiZSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z b3UgZG9u4oCZdCBzYXkgYW55dGhpbmcgaW4gMi4xIGFib3V0IHVzaW5nIGJpdHMgZm9yIGZ1bmN0 aW9uYWwgcHVycG9zZXMuIFlvdSBzYXkgdGhhdCBnZW9ncmFwaGljIGJvdW5kYXJpZXMgYXJlIGdv b2QgZm9yIHNpbXBsaWZ5aW5nIHNlY3VyaXR5IHBvbGljaWVzIChhbmQgSSBhZ3JlZSwgYW5kIHdp c2ggaXQgd2VyZSBhcHByb3ByaWF0ZSB0byBub3RlIHRoYXQgYW4gQUNMIGNhbiBnbyBmcm9tIDIw MCBsaW5lcyBncm93bg0KIG9yZ2FuaWNhbGx5IG92ZXIgYSBkZWNhZGUgaW4gSVB2NCB0byA0IGxp bmVzIHdpdGggYW4gSVB2NiBhZGRyZXNzIHBsYW4gZGVzaWduZWQgZm9yIGdyb3d0aCksIGJ1dCBp dCBjYW4gYmUgdXNlZnVsIHRvIGhhdmUsIHNheSwgYSBtYW5hZ2VtZW50IG5ldHdvcmsgYmUgYSBz cGVjaWZpYyBzdWJuZXQgb3V0IG9mIHRoZSByZWdpb25hbCBzdXBlcm5ldHMuIHg6eTp6OjY2Njo6 LzQ4LCBmb3IgaW5zdGFuY2UuIE9yIGRvIHlvdSBkaXNhZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UgY291bGQgZGViYXRlIHRoZSByb2xlIG9mIGxhdyBlbmZvcmNlbWVudCwgYnV0IEni gJlkIGxpa2UgdG8gcmV3b3JkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 Ij5Ib3dldmVyLCBvbmUgYXNwZWN0IHRvIGtlZXAgaW4gbWluZCBpcyB3aG8gaGFzIG93bmVyc2hp cCBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZu YnNwOyZuYnNwOyBhZGRyZXNzIHNwYWNlIGFuZCB3aG8gaXMgcmVzcG9uc2libGUgaWYvd2hlbiBM YXcgRW5mb3JjZW1lbnQgbWF5IG5lZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0Nv dXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyB0byBlbmZvcmNlIHJlc3RyaWN0aW9ucyBvbiByb3V0 YWJpbGl0eSBvZiB0aGUgc3BhY2UgZHVlIHRvIG1hbGljaW91czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7IGNyaW1pbmFsIGFjdGl2aXR5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBwb2ludCBvZiBjb250YWN0IGxpc3RlZCBpbiBwdWJs aWMgcmVnaXN0cmllcyBpcyB0aGUgb25lIHdobyB3aWxsIGhhdmUgdG8gcmVzcG9uZCB0byBsZWdh bCBpbnF1aXJpZXMsIGFuZCBwb3RlbnRpYWxseSB0YWtlIGFjdGlvbiBhcyByZXF1aXJlZCBieSBs ZWdhbCBhdXRob3JpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiAyLjEuMSwg aXQgd291bGQgYmUgbmljZSB0byBhY2tub3dsZWRnZSB0aGUgZGlmZmVyZW50IGtpbmRzIG9mIG5v ZGVzLCBhbmQgd2hlcmUgc3RhdGljIGFkZHJlc3NlcyBtYWtlIHNlbnNlLiBTZXJ2ZXJzIGFyZSBk aWZmZXJlbnQgZnJvbSB3b3Jrc3RhdGlvbnMgb3IgcmVzaWRlbnRpYWwgdXNlcnMuIFJvdXRlcnMg YW5kIGZpcmV3YWxscyBoYXZlIGRpZmZlcmVudCBjb25zaWRlcmF0aW9ucy4gV2hhdCBhYm91dA0K IHByaW50ZXJzPyBTaG91bGQgSVAgcGhvbmVzIGJlIG51bWJlcmVkIHRoZSBzYW1lIHdheSBhcyBk ZXNrdG9wcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4xLjIgc2F5cyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+VGhlIGltcGxpY2l0IGV4cGVjdGF0aW9uIGZyb20g dGhlIFJGQyBpcyB0aGF0IGFsbCBVTEFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdD b3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsgd2lsbCBiZSByYW5kb21seSBjcmVhdGVkIGFzIC80 OHMuJm5ic3A7IEFueSB1c2Ugb2YgVUxBcyB0aGF0IGFyZSBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyBjcmVhdGVkIGFzIGEgLzQ4 IHZpb2xhdGVzDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQxOTMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmU7dGV4dC11 bmRlcmxpbmU6bm9uZSI+UkZDNDE5Mzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4gWzwvc3Bhbj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDE5MyIgdGl0bGU9IiZxdW90O1VuaXF1ZSBMb2Nh bCBJUHY2IFVuaWNhc3QgQWRkcmVzc2VzJnF1b3Q7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0K MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3Rl eHQtZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOg0Kbm9uZSI+UkZDNDE5Mzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7Ij5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgdHdvIHNlbnRlbmNl cyBhcmUgc3RyYW5nZS4gSXMgaXQgaW1wbGljaXQgb3IgZXhwbGljaXQ/Jm5ic3A7IElmIGl04oCZ cyBpbXBsaWNpdCwgY2FuIHlvdSBleHBsYWluIGhvdyBSRkMgNDE5MyBpbXBsaWVzIHRoYXQ/Jm5i c3A7IElmIGl04oCZcyBvbmx5IGltcGxpZWQsIHRoZW4gaXMgaXQgYSB2aW9sYXRpb24/Jm5ic3A7 IEkgdGhpbmsgdGhlc2UgdHdvIHNlbnRlbmNlcyBzaG91bGQgYmUgcmV3cml0dGVuLCBhbmQgeW91 IGRvbuKAmXQgbmVlZA0KIGJvdGggb2YgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TExB IGNhbiBvbmx5IHJlcGxhY2UgVUxBIGZvciBhIHNpbmdsZSBzdWJuZXQuIDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7Ij5BbHRob3VnaCBVTEFzIGFyZSBzdXBwb3NlZCB0byBiZSB1c2VkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsgaW4gY29u anVuY3Rpb24gd2l0aCBnbG9iYWwgYWRkcmVzc2VzIGZvciBob3N0cyB0aGF0IGRlc2lyZSBleHRl cm5hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7 Jm5ic3A7IGNvbm5lY3Rpdml0eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bY2l0YXRpb24gbmVlZGVkXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxVTEFz IGluIGNvbmp1bmN0aW9uIHdpdGggc29tZSBzb3J0IG9mIGFkZHJlc3MgdHJhbnNsYXRpb27igJ0m bmJzcDsgUGxlYXNlIGNpdGUgcmZjNjI5Ni4gWW91IG1pZ2h0IGFsc28gd2FudCB0byBpbmNsdWRl IHJlZmVyZW5jZSB0byBpdHMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYW5kIGlu IGZhY3QgeW91ciBvd24gZGlzY3Vzc2lvbiBvZiBwZXJpbWV0ZXIgc2VjdXJpdHkgaW4gcGFyYWdy YXBoIDIgb2YgMi4xLjEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnCh0aGUgYXV0aG9ycyBv ZiB0aGlzIGRvY3VtZW50IGRvIG5vdCBzaGFyZSB0aGlzIHBvaW50IG9mIHZpZXcp4oCdIGlzbuKA mXQgcmVhbGx5IGFwcHJvcHJpYXRlIGNvbW1lbnRhcnkgaW4gYSBXRyBkb2N1bWVudC4gRm9yIHRo aXMgdG8gYmUgSUVURiBzdHJlYW0sIGl0IG5lZWRzIHRvIHJlZmxlY3QgY29uc2Vuc3VzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tbywga25vd2luZyB0aGF0IFVMQXMgYXJlIGEgdGhvcm55IG5l c3QgaW4gYSByYXRob2xlLCBJIHN1Z2dlc3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7VW5pcXVlIExvY2FsIEFkZHJl c3NpbmcgKFVMQSwgW1JGQyA0MTkzXSkgaXMg4oCcZ2xvYmFsbHkgdW5pcXVlIGFuZCBpcyBpbnRl bmRlZCBmb3IgbG9jYWwgY29tbXVuaWNhdGlvbnPigJ0gW1JGQyA0MTkzXS4gJm5ic3A7VUxBcyBj b3VsZCBiZSB1c2VkIGZvciBzeXN0ZW1zIHRoYXQgZG8gbm90IHJlcXVpcmUgSW50ZXJuZXQgY29u bmVjdGl2aXR5LCBzdWNoIGFzIGEgbWFuYWdlbWVudA0KIG5ldHdvcmssIG9yIGJhY2stZW5kIHNl cnZlcnMsIGFzIGxvbmcgYXMgc29mdHdhcmUgdXBkYXRlcyBjYW4gYmUgZG9uZSBsb2NhbGx5LiBP biBhIHNpbmdsZSBzdWJuZXQsIExpbmstTG9jYWwgQWRkcmVzc2VzIChMTEEsIFtSRkMgNzQwNF0p IGNhbiBiZSB1c2VkIGluc3RlYWQuIFNvbWUgY2FzZXMgbWF5IGJlIGNvdmVyZWQgYnkgcHJpdmFj eSBleHRlbnNpb25zOyBzZWUgc2VjdGlvbiAyLjEuNCBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5V TEFzIGNhbiBiZSB1c2VkIHdpdGggTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24gKE5QVDY2LCBb UkZDNjI5Nl0pIHRvIHJlYWNoIHRoZSBJbnRlcm5ldCB3aGlsZSBoaWRpbmcgaW5mcmFzdHJ1Y3R1 cmUgYWRkcmVzc2VzLiBIb3dldmVyLCBzaW5jZSB0aGlzIGlzIGEgMToxIG1hcHBpbmcgb2YgaW5z aWRlIGFuZCBvdXRzaWRlIGFkZHJlc3NlcywgaXQgZG9lcyBub3QNCiBwcm92aWRlIHRoZSBzYW1l IGxldmVsIG9mIG9ic2N1cml0eSBhcyBOQVBUNDQgW1JGQz9dOyB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBvZiBbUkZDIDYyOTZdIHByb3ZpZGVzIGEgZ29vZCBkZXNjcmlwdGlv bi4gVGhlIHVzZSBvZiBnb29kIHBlcmltZXRlciBzZWN1cml0eSBjb250cm9scyAoc3RhdGVmdWwg ZmlyZXdhbGwgcnVsZXMsIGxvZ2dpbmcgW1JGQzYzMDJdKSBwcm92aWRlcyBiZXR0ZXIgc2VjdXJp dHkgdGhhbiBhZGRyZXNzDQogdHJhbnNsYXRpb24uJm5ic3A7IChub3RlOiBkaXNjdXNzaW9uIG9m IGRpZmZlcmVuY2UgYmV0d2VlbiBOQVBUNDQgYW5kIHN0YXRlZnVsIGZpcmV3YWxsIHdvdWxkIGJl IGZpbmUgaGVyZSwgaWYgeW91IGNhbuKAmXQgZmluZCBhbm90aGVyIGRvY3VtZW50IHRvIHJlZmVy ZW5jZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gMi4xLjMgY2hhbmdlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBvcGVyYXRpb25hbCBkaXNh ZHZhbnRhZ2VzIG5lZWQgYWxzbyB0byBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZCBSRkM3NDA0DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIG9wZXJhdGlvbmFsIGNhdmVhdHMgZGVz Y3JpYmVkIGluIFtSRkM3NDA0XSBuZWVkIHRvIGJlIGNhcmVmdWxseSBjb25zaWRlcmVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiAyLjEuNCwgSSBkb27igJl0IHVuZGVyc3RhbmQgaG93IHBy aXZhY3kgZXh0ZW5zaW9ucyDigJxyZWR1Y2UgdGhlIGF0dGFjayBleHBvc3VyZSB3aW5kb3cu4oCd IERvIHlvdSBtZWFuIHRoYXQgaWYgYW4gSVAgYWRkcmVzcyBpcyB0YXJnZXRlZCwgYSBub2RlIG9u bHkgdXNlcyB0aGF0IGFkZHJlc3MgZm9yIChkZWZhdWx0KSAyNCBob3Vycz8gT3IgZG8geW91IG1l YW4gZmV3ZXIgcG9ydHMgYXJlIGV4cG9zZWQ/IFdoYXQga2luZA0KIG9mIHdpbmRvdyBkbyB5b3Ug bWVhbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayDigJxtYWxldm9sZW504oCdIGlz IHRoZSB3cm9uZyB3b3JkLiDigJxNYWxldm9sZW504oCdIG1lYW5zIHdpc2hpbmcgZXZpbCB1cG9u IGEgcGVyc29uOiBiYWQgd2lsbC4g4oCcTWFsaWNpb3Vz4oCdIG1lYW5zIGludGVuZGluZyB0byBk byBldmlsLiDigJxNYWxldm9sZW504oCdIGlzIG1vcmUgbGlrZSBoYXRyZWQsIHdoaWNoIG1heSBv ciBtYXkgbm90IGluY2x1ZGUgYWN0aW9uLiDigJxNYWxpY2lvdXPigJ0gaXMgYW4gaW50ZW50IHRv DQogZG8gaGFybTsgdGhlcmVmb3JlLCBiYWQgYWN0b3JzIHBhcnRpY2lwYXRlIGluIOKAnG1hbGlj aW91cyBhY3Rpdml0aWVzLuKAnSBIb3dldmVyLCBzaW5jZSB5b3UgdGhlbiBzYXksIOKAnCh3aGV0 aGVyIG9uIHB1cnBvc2Ugb3Igbm90KeKAnSBuZWl0aGVyIG9uZSBpcyB0aGUgcmlnaHQgd29yZC4g SXQgdG9vayBtZSBzZXZlcmFsIHRpbWVzIHJlYWRpbmcsIGJ1dCBJIHRoaW5rIHlvdSBtZWFuOiZu YnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5B cyBwcml2YWN5IGV4dGVuc2lvbiBhZGRyZXNzZXMgY291bGQgYWxzbyBiZSB1c2VkIHRvIG9iZnVz Y2F0ZSAoaW50ZW50aW9uYWxseSBvciB1bmludGVudGlvbmFsbHkpIG1hbGljaW91cyBvciBwcm9o aWJpdGVkIGFjdGl2aXRpZXMsIGl0IGlzIGltcG9ydGFudCB0byBkaXNhYmxlIFNMQUFDIGFuZCBy ZWx5IG9uIERIQ1B2NiBpbiBzY2VuYXJpb3Mgd2hlcmUgdXNlciBhdHRyaWJ1dGlvbg0KIGlzIGlt cG9ydGFudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgYXMgd2FzIHBvaW50ZWQg b3V0IGluIG9iamVjdGlvbiB0byBkaGNwdjYtc2xhYWMtcHJvYmxlbSwgREhDUHY2IGRvZXNu4oCZ dCBwcm92aWRlIGEgYmV0dGVyIHJlY29yZDsgaWYgeW91IHdhbnQgYXR0cmlidXRpb24sIHlvdSBu ZWVkIHRvIGxvZyBORC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZvbGxvd2luZyBzZW50 ZW5jZSBpcyBhIGdyYW1tYXRpY2FsIHdyZWNrLiZuYnNwOyA8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij5Ib3dldmVyLCBpbiBzY2VuYXJpb3Mgd2hlcmUg YW5vbnltaXR5IGlzIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsiPiZuYnNwOyZuYnNwOyBzdHJvbmcgZGVzaXJlIHNpbmNlIHByb3RlY3RpbmcgdXNlciBwcml2 YWN5IGlzIG1vcmUgaW1wb3J0YW50IHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyB1c2VyIGF0dHJpYnV0aW9uLCBwcml2YWN5IGV4 dGVuc2lvbiBhZGRyZXNzZXMgc2hvdWxkIGJlIHVzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5Og0KJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJv cG9zZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIb3dl dmVyLCBpbiBzY2VuYXJpb3Mgd2hlcmUgcHJvdGVjdGluZyB1c2VyIHByaXZhY3kgaXMgbW9yZSBp bXBvcnRhbnQgdGhhbiB1c2VyIGF0dHJpYnV0aW9uLCBwcml2YWN5IGV4dGVuc2lvbiBhZGRyZXNz ZXMgYXJlIG1vcmUgYXBwcm9wcmlhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWZl cmVuY2UgdG8gcmZjNzIxNyBzaG91bGQgY29tZSBlYXJsaWVyIGluIHRoZSBzZWN0aW9uLCBzaW5j ZSBhbGwgY29uc2lkZXJhdGlvbnMgZm9yIHByaXZhY3kgZXh0ZW5zaW9ucyBhcHBseSB0byB0aG9z ZSBhZGRyZXNzZXMgdG9vLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLjEuNSBpcyB0cnVlLCBi dXQgSSB0aGluayB0aGUgZG9jdW1lbnQgd291bGQgYmUgbW9yZSB1c2FibGUgaWYgeW91IGdhdmUg YXQgbGVhc3Qgb2YgaGludCBvZiB3aGF0IHJlYWRlcnMgd2lsbCBmaW5kIGluIEFwcGVuZGl4IEEg b2YgUkZDNzIxNyBhbmQgaW4gUkZDNzcyLiZuYnNwOyBTdWdnZXN0OjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij5Ib3dldmVyLCB0aGVyZSBhcmUgc2V2ZXJh bCBwcml2YWN5IGlzc3VlcyBzdGlsbCBwcmVzZW50IHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyBbPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTQxIiB0aXRsZT0iJnF1b3Q7UHJpdmFjeSBF eHRlbnNpb25zIGZvciBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbiBJUHY2 JnF1b3Q7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246DQpub25lO3RleHQt dW5kZXJsaW5lOm5vbmUiPlJGQzQ5NDE8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+XQ0KIHN1Y2ggYXMgaG9zdCB0cmFj a2luZywgYW5kIGFkZHJlc3Mgc2Nhbm5pbmcgYXR0YWNrcyBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyBzdGlsbCBwb3NzaWJsZS4m bmJzcDsgRGV0YWlscyBvbiBtZWNoYW5pc21zIGZvciBmb3JtaW5nIGludGVyZmFjZSBpZGVudGlm aWVycyBhcmUgcHJvdmlkZWQgaW4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzIxNyNhcHBlbmRpeC1BIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQt ZGVjb3JhdGlvbjpub25lO3RleHQtdW5kZXJsaW5lOg0Kbm9uZSI+QXBwZW5kaXgmbmJzcDtBLiBv ZiBbUkZDNzIxN108L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyI+LA0KIFs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzc3MjEiIHRpdGxlPSImcXVvdDtTZWN1cml0eSBhbmQgUHJpdmFj eSBDb25zaWRlcmF0aW9ucyBmb3IgSVB2NiBBZGRyZXNzIEdlbmVyYXRpb24gTWVjaGFuaXNtcyZx dW90OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOg0Kbm9uZTt0ZXh0LXVu ZGVybGluZTpub25lIj5SRkM3NzIxPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPl0NCiBkZXNjcmliZXMgc2VjdXJpdHkg YW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgaW4gZGVwdGggZm9yIHNldmVyYWwgbWVjaGFuaXNt cyB1c2VkIHRvIGdlbmVyYXRlIElQdjYgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjIuMS42IOKAnGF1ZGliaWxpdHnigJ0gc2hvdWxkIGJlIOKAnGF1ZGl0YWJpbGl0eeKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxETlMgaXMgb2Z0ZW4gdXNlZCBmb3IgbWFsd2Fy ZSBhY3Rpdml0aWVz4oCdIG1ha2VzIGl0IHNvdW5kIGxpa2UgaXTigJlzIGFuIGF0dGFjayB2ZWN0 b3IgdGhhdCBzaG91bGQgYmUgc2h1dCBkb3duLiZuYnNwOyBBbHNvLCB3aHkgaXMgRE5TIGRpc2N1 c3NlZCB1bmRlciDigJxBZGRyZXNzaW5nIEFyY2hpdGVjdHVyZeKAnT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Mi4yIGlzbuKAmXQgZXZlbiB3cml0dGVuLiBEb27igJl0IGFzayBmb3IgcmV2aWV3 IHVudGlsIHlvdSBmaW5pc2ggd3JpdGluZyB5b3VyIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4yLjMuMSDigJxnZW5lcmljIG9wZXJhdGluZyBzeXN0ZW1z4oCdJm5ic3A7IERvIHlv dSBtZWFuIFNlTkQgaXNu4oCZdCBzdXBwb3J0ZWQgaW4gcm91dGVycywgb3IgaW4gaG9zdHM/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuMy4yIFNob3VsZG7igJl0IOKAnFNlY3VyaW5nIERIQ1Di gJ0gYmUgdW5kZXIgMi4xLjYg4oCcREhDUOKAnT8gT3Igc2hvdWxkIDIuMS42IGJlIGhlcmU/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvcm1hdHRpbmcgZXJyb3IgY3JlYXRlcyBjb25mdXNpb246 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPnRocmVhdHMg YWdhaW5zdCBESENQIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBvZg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMzMzE1Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lO3Rl eHQtdW5kZXJsaW5lOm5vbmUiPlJGQzMzMTU8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+IFs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMzMTUiIHRpdGxlPSImcXVvdDtEeW5hbWlj IEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSZxdW90OyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOg0Kbm9uZTt0ZXh0LXVuZGVybGluZTpu b25lIj5SRkMzMzE1PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPl1ESENQLXNoaWVsZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc2MTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0 aW9uOm5vbmU7dGV4dC11bmRlcmxpbmU6bm9uZSI+UkZDNzYxMDwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4gWzwvc3Bh bj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYxMCIgdGl0bGU9IiZx dW90O0RIQ1B2Ni1TaGllbGQ6IFByb3RlY3RpbmcgYWdhaW5zdCBSb2d1ZSBESENQdjYgU2VydmVy cyZxdW90OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOg0Kbm9uZTt0ZXh0 LXVuZGVybGluZTpub25lIj5SRkM3NjEwPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPl0NCiBzcGVjaWZpZXMgYSBtZWNo YW5pc20gZm9yIHByb3RlY3RpbmcgaG9zdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjIuMy4zIEkgdGhpbmsgTkQvUkEgdnVsbmVyYWJpbGl0eSBpcyBhIG1haW4gc2VjdGlvbiwgd2l0 aCBSYXRlIExpbWl0aW5nIGFuZCBGaWx0ZXJpbmcgYXMgc3Vic2VjdGlvbnMuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsyLjMuNSZuYnNwOyBUaGlzIHNlY3Rpb24gaXMgZWR1Y2F0aW9uYWwgZm9yIG1lLiZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGNvbmZ1c2Vk IGFib3V0IOKAnHRoZSBhZHZlcnRpc2VkIC82NCBvbiB0aGUgbGlua+KAnSBpZiB0aGVyZeKAmXMg b25seSBMTEEuIElzIHRoZXJlIGFuIGFkdmVydGlzZWQgR1VBPyBEb2VzIGl0IG1ha2Ugc2Vuc2Ug dG8gcmV3b3JkIHRoaXM/PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 ICdDb3VyaWVyIE5ldyc7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsiPlRoZSBHR1NOL1BHVyBuZXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyZXMgYSBub24gbGluay1sb2NhbCBh ZGRyZXNzIG9uIHRoZSBsaW5rIHVzaW5nIHRoZSBhZHZlcnRpc2VkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsgLzY0IHByZWZpeCBvbiBp dC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPlRoZSBHR1NOL1BHVyBu ZXZlciBjb25maWd1cmVzIGFueXRoaW5nIG90aGVyIHRoYW4gYSBub24gbGluay1sb2NhbCBhZGRy ZXNzIG9uIHRoZSBsaW5rLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxUaGVy ZSBpcyBubyBuZWVkIGZvciBhZGRyZXNzIHJlc29sdXRpb27igKbigJ0gY291bGQgYmUgc3BlY2lm aWNhbGx5IOKAnGFkZHJlc3MgcmVzb2x1dGlvbiB0aHJvdWdoIE5laWdoYm9yIERpc2NvdmVyeeKA puKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGlsbCBjb25mdXNlZC4gVGhlIEdHU04vUEdX IGFzc2lnbnMgYSBHVUEgdG8gdGhlIExMQSBsaW5rPyZuYnNwOyBPciBhIFVMQT8gT3Igc29tZSBv dGhlciBzY29wZSBvZiDigJx1bmlxdWXigJ0/Jm5ic3A7IEFuZCBpdOKAmXMgYXNzaWduZWQgdG8g YSBsaW5rIHRoYXQgdXNlcyBvbmx5IExMQT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi40IFRo YW5rcyBmb3IgaW5jbHVkaW5nIHRoZSBkZWZpbml0aW9uIG9mIOKAnGNvbnRyb2wgcGxhbmXigJ0g aGVyZSwgYnV0IHNpbmNlIGl04oCZcyBxdW90ZWQsIHdvdWxkIHlvdSB1c2UgYmxvY2txdW90ZSBm b3JtYXQ/IFRoYXQgd2F5IEnigJlsbCBrbm93IHdoZW4gdGhlIHF1b3RlIGVuZHMgYW5kIG9yaWdp bmFsIHRleHQgYmVnaW5zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBtZWFu IOKAnGdlbmVyYWwgcHVycG9zZSBwcm9jZXNzb3LigJ0gcmF0aGVyIHRoYW4g4oCcZ2VuZXJpYyBw cm9jZXNzb3Iu4oCdIEkgcmVhZCDigJxnZW5lcmlj4oCdIGFuZCB0aGluayB5b3UgbWVhbiBpdCBo YXMgbm8gYnJhbmQgbmFtZSBhdHRhY2hlZCwgYnV0IEkgdGhpbmsgeW91IG1lYW4gaXTigJlzIG5v dCBjdXN0b20gc2lsaWNvbiwgZXZlbiBpZiBpdOKAmXMgbWFkZSBieSBJbnRlbCwgQnJvYWRjb20s IFF1YWxjb21tLA0KIG9yIHdoYXRldmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ud28gbWl0 aWdhdGlvbiB0ZWNobmlxdWVzIGFyZSBnaXZlbiBmb3IgY29udHJvbCBwbGFuZSBwcm90ZWN0aW9u IChuZWl0aGVyIG9mIHdoaWNoIGlzIHNwZWNpZmljIHRvIElQdjYsIGJ0dyksIGJ1dCBJ4oCZbSBu b3QgY2xlYXIgb24gaG93IHRoZXkgYXJlIHRvIGJlIGltcGxlbWVudGVkLiBIb3cgZG8gSSBpZGVu dGlmeSDigJxub24tbGVnaXQgY29udHJvbCBwbGFuZSBwYWNrZXRbc13igJ0gaW4gYW4gQUNMPyBJ cyB0aGF0DQogd2hhdCBzZWN0aW9uIDIuNC4xIGlzPyBDYW4geW91IGdpdmUgZ3VpZGFuY2Ugb24g cmF0ZSBsaW1pdGluZz8gSXMgdGhlcmUgZ3VpZGFuY2Ugb24gcHJvdG9jb2wtc3BlY2lmaWMgcHJv dGVjdGlvbiBmb3IgZWFjaCBvZiB0aGVzZSBwcm90b2NvbHM/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIuNC4yIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHJl d29yZDo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+KGZv ciBleGFtcGxlLCBwZXJtaXQgVENQIDIyIGFuZCBkcm9wIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHdoZW4gb25seSBTU0ggaXMgdXNlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50bzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7Ij4oZS5nLiwgdG8gYWxsb3cgU1NIIG9ubHksIHBlcm1pdCBUQ1AgMjIgYW5kIGRyb3AgYWxs IG90aGVycyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZu YnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgdGhlIGV4YW1wbGUg b2YgdGhlIE5PQyBwcmVmaXguIEluIGZhY3QsIEkgdGhpbmsgdGhpcyBpcyBhIHNlY3VyaXR5IGFk dmFudGFnZSBvZiBJUHY2LCBzaW5jZSB0aGUgYWRkcmVzcyBhcmNoaXRlY3R1cmUgbWF5IGJlIG11 Y2ggY2xlYW5lciwgc28geW91IGNhbiB3cml0ZSBhbiBBQ0wgdG8gbWF0Y2ggc2VjdXJpdHkgcG9s aWN5IGluIGp1c3QgYSBsaW5lIG9yIHR3byBvZiBBQ0wsIGluc3RlYWQgb2YgaHVuZHJlZHMuDQog QnV0IEnigJltIG5vdCBzdXJlIHRoYXTigJlzIHdvcnRoIHNheWluZy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLjQu MyBUaGlzIHNlY3Rpb24gaXMgdmVyeSBmcnVzdHJhdGluZyAobm90IHRoZSBhdXRob3Jz4oCZIGZh dWx0KTo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+VGhl IG9ubHkgcHJvdGVjdGlvbiBmb3IgdGhlIFJQIGlzIHRvIGxpbWl0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsgdGhlIHJhdGUgb2YgdGhv c2UgcGFja2V0IGV4Y2VwdGlvbnMgZm9yd2FyZGVkIHRvIHRoZSBSUCwgdGhpcyBtZWFuczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7IHRo YXQgc29tZSBkYXRhIHBsYW5lIHBhY2tldHMgd2lsbCBiZSBkcm9wcGVkIHdpdGhvdXQgYW55IElD TVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZu YnNwOyBtZXNzYWdlcyBiYWNrIHRvIHRoZSBzb3VyY2Ugd2hpY2ggd2lsbCBjYXVzZSBQYXRoIE1U VSBob2xlcy4mbmJzcDsgQnV0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmll ciBOZXcnOyI+Jm5ic3A7Jm5ic3A7IHRoZXJlIGlzIG5vIG90aGVyIHNvbHV0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgaXQgcG9zc2libGUgdG8gZG8gbW9yZSBhZHZhbmNl ZCBxdWV1ZWluZywgdG8gcmF0ZSBsaW1pdCBvbmx5IEhCSCBwYWNrZXRzLCBvciB0byBkZXF1ZXVl IGJhc2VkIG9uIHNvdXJjZSBhZGRyZXNzIChzbyB0aGF0IGFuIGF0dGFja2VyIGdldHMgbm8gbW9y ZSB0aW1lIG9uIHRoZSBSUCB0aGFuIGFueW9uZSBlbHNlKT8gSXQgbWlnaHQgbm90IGJlOyBlaXRo ZXIgYmVjYXVzZSBhdHRhY2tzIHRlbmQgdG8gYmUgZGlzdHJpYnV0ZWQNCiBhbnl3YXksIG9yIGJl Y2F1c2UgdGhlIG92ZXJoZWFkIG9mIHRoYXQgbXVjaCBhbmFseXNpcyB3b3VsZCBvZmZzZXQgdGhl IHByb3RlY3Rpb24gaXQgd291bGQgcHJvdmlkZS4gQXQgd29yc3QsIGNvdWxkIHlvdSBzYXkgaW5z dGVhZCwg4oCcVGhlcmUgaXMgbm8ga25vd24gY3VycmVudCBzb2x1dGlvbjsgdGhpcyBpcyBhbiBh cmVhIGZvciBmdXR1cmUgd29yay7igJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuNS4xIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWlzc2luZyBjbG9zZSBwYXJlbnRo ZXNpczo8bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+KHdoaWNoIG9ic29sZXRlcyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjUwNiI+UkZDNjUwNjwvYT4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2NTA2IiB0aXRsZT0iJnF1b3Q7U3VwcG9ydGluZyBBdXRoZW50aWNhdGlvbiBUcmFpbGVy IGZvciBPU1BGdjMmcXVvdDsiPlJGQzY1MDY8L2E+XTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXJlIGFyZSB0d28gbG9uZyBwYXJhZ3JhcGhzIG9uIE9TUEZ2MywgYnV0IG5vIHNwZWNpZmlj IGRpc2N1c3Npb24gb2YgYW55IG90aGVyIHJvdXRpbmcgcHJvdG9jb2xzLiBJcyBhbnkgb2YgdGhp cyBzcGVjaWZpYyB0byBJUHY2PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLjUuMjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8gcmVjb21tZW5kYXRpb25zPyBTdWdnZXN0 aW9ucyBmb3IgZnV0dXJlIHdvcms/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SaXNrcz8gSSBtZWFuLCB0d28gcGVlcnMgb24gYSBwb2ludC10by1wb2ludCBsaW5rIGhhdmUg bGltaXRlZCBleHBvc3VyZS4gUGVlcnMgd2l0aCBtdWx0aWhvcCBvciB1c2luZyB2aXJ0dWFsIGNv bm5lY3Rpb25zIGhhdmUgZ3JlYXRlciBleHBvc3VyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Mi41LjM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbGluayB0byBSRkM2 ODkwLCBtYXliZSB3aXRoIGNvbW1lbnRhcnksIHdvdWxkIGJlIHdlbGNvbWUgaW4gdGhlIGRpc2N1 c3Npb24gb2YgcmVzZXJ2ZWQgcHJlZml4ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuNi4x IFRoZXNlIHNlY3Rpb25zIGZlZWwgYSBsaXR0bGUgbGlnaHQgb24gd2hhdCBzaG91bGQgYmUgbG9n Z2VkIGFuZCB3aHkuIE9oLCBub3cgSSBzZWUgdGhhdCDigJx3aHnigJ0gaXMgY292ZXJlZCBpbiAy LjYuMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi42LjEuMSBSZWR1bmRhbmN5IGluIHRoZSBz ZWNvbmQgcGFyYWdyYXBoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuNyDigJxzb21lIHRleHTi gJ0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuNy4yPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igJxUbyBtaXRpZ2F0ZSBieXBhc3Npbmcgb2Ygc2VjdXJpdHkgcG9saWNp ZXPigJ0gbWlnaHQgYmV0dGVyIGJlLCDigJxUbyBwcmV2ZW50IGJ5cGFzc2luZyBzZWN1cml0eSBw b2xpY2llcywgd2hldGhlciBpbXBsZW1lbnRlZCBvbiBhIGZpcmV3YWxsIG9yIGp1c3QgYSBsYXll ciA0IEFDTCzigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi43LjIuMSDigJx0cmFmZmljIGlu dGVyY2VwdGlvbiBhZCB0dW5uZWwgaW5qZWN0aW9u4oCdIHNob3VsZCBiZSDigJxhbmTigJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi43LjIuMiDigJxhbmQgYW5k4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIuNy4yLjMg4oCcYmxvY2sgYWxsIFVEUCBvdXRib3VuZCB0cmFmZmlj4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGRvZXNu4oCZdCBzZWVtIGEg Yml0IGRyYWNvbmlhbj8gVGhlcmUgYXJlIGxvdHMgb2YgYXBwbGljYXRpb25zIHRoYXQgdXNlIFVE UCwgYW5kIG1hbnkgb2YgdGhlbSB1c2UgaXQgc3BlY2lmaWNhbGx5IHRvIGdldCBhcm91bmQgZmly ZXdhbGxzLiBHYW1lcywgUlRQLCBRVUlDLCAuIC4gLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y LjcuMi44IEkgdGhpbmsgSSBzYWlkIHRoaXMgYmVmb3JlLCBidXQgUkZDIDIxMTkg4oCcTVVTVOKA nSBpc27igJl0IHJlYWxseSBhcHByb3ByaWF0ZSBpbiBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50 LCBvciBldmVuIGEgQkNQLiBSRkMgMjExOSBzYXlzIGl04oCZcyBmb3Igc3BlY2lmaWNhdGlvbnMs IHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjEg QmFjayBpbiAyLjUuMSB5b3UgaGFkIGRpc2N1c3Npb24gb2YgT1NQRnYzLiBBcmUgdGhlcmUgYW55 IEJHUCBub3RlcyBpbiA0LjEgdGhhdCB3b3VsZCBhcHBseSB0aGVyZSwgaW4gdGhlIGNvbnRyb2wg cGxhbmUgc2VjdGlvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4zJm5ic3A7IFlvdSBzYXkg bGF3ZnVsIGludGVyY2VwdCBjYW4gdGFyZ2V0IOKAnHNpbmdsZSBob3N0IChhIC8xMjggdGFyZ2V0 KeKAnSBidXQgaWYgdGhlIGNsaWVudCBpcyB1c2luZyBwcml2YWN5IGV4dGVuc2lvbnMsIHRoYXQg d2lsbCBub3QgYmUgZW5vdWdoIGRldGFpbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8IS0tRW5kRnJhZ21lbnQtLT48L2Rpdj4NCjxicj4NCjxocj4NCjxm b250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KVGhpcyBFLW1haWwg YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvDQogd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9y IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1l bnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heQ0KIGJlIHVu bGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxi cj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7FE9B6A250134B4A9959554BDC9DA120chartercom_-- From nobody Mon Jul 18 02:25:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4890712D610; Mon, 18 Jul 2016 02:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YnugdCSxR_ld; Mon, 18 Jul 2016 02:25:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6AA3C12D625; Mon, 18 Jul 2016 02:25:17 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 24230CE3407D; Mon, 18 Jul 2016 09:25:13 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6I9PE4K016755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 09:25:15 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6I9Oshe004053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jul 2016 11:25:13 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.53]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 18 Jul 2016 11:23:39 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: "Bernie Volz (volz)" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 Thread-Index: AdHZ9jkImKwO3BL9SIKp8q8qdOfqZQG39fEA Date: Mon, 18 Jul 2016 09:23:38 +0000 Message-ID: <77EB26C9-5B6A-496A-93D1-38621B4DD257@alcatel-lucent.com> References: <413035d09b9f424a8e6a741234ae1dbf@XCH-ALN-003.cisco.com> In-Reply-To: <413035d09b9f424a8e6a741234ae1dbf@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_77EB26C95B6A496A93D138621B4DD257alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:25:55 -0000 --_000_77EB26C95B6A496A93D138621B4DD257alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVwLCBnb29kIGNhdGNoLiBJIGluZGVlZCBtaXNzZWQgdGhlc2Ugd2hlbiBkb2luZyB0aGUgZWRp dCBvbiB0aGlzIGxhdGVzdCB2ZXJzaW9uIHRvIHNwbGl0IG91dCB0aGUgLzY0IGFzc2lnbm1lbnQg cGVyIGhvc3QuDQoNCk5leHQgdmVyc2lvbiBJ4oCZbGwgdGFrZSB0aGlzIGNvbW1lbnQgaW50byBh Y2NvdW50Lg0KDQpNYW55IHRoYW5rcywNCkcvDQoNCg0KDQpGcm9tOiAiQmVybmllIFZvbHogKHZv bHopIiA8dm9sekBjaXNjby5jb20+DQpEYXRlOiBTYXR1cmRheSA5IEp1bHkgMjAxNiBhdCAxNzoy Nw0KVG86ICJkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEBpZXRm Lm9yZyIgPGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYu b3JnPg0KQ2M6ICJ2Nm9wc0BpZXRmLm9yZyIgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogZHJh ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDENClJlc2VudC1Gcm9t OiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGpvaG5fYnJ6b3pvd3NraUBj YWJsZS5jb21jYXN0LmNvbT4sIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4NClJlc2Vu dC1EYXRlOiBTYXR1cmRheSA5IEp1bHkgMjAxNiBhdCAxNzoyNw0KDQpIaToNCg0KRGlkIHlvdSBw ZXJoYXBzIG1pc3Mgc29tZSBlZGl0cyBsYXRlIGluIHRoZSBkb2N1bWVudCAoU2VjdGlvbiA1KToN Cg0KICAgQW4gb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbiB3aGVuIHVzaW5nIElQdjYgYWRkcmVz cyBhc3NpZ25tZW50IHVzaW5nDQogICBJUHY2IFNMQUFDIGlzIHRoYXQgYWZ0ZXIgdGhlIG9uYm9h cmRpbmcgcHJvY2VkdXJlIHRoZSBVRS9zdWJzY3JpYmVyDQogICB3aWxsIGhhdmUgYSBwcmVmaXgg d2l0aCBjZXJ0YWluIHByZWZlcnJlZCBhbmQgdmFsaWQgbGlmZXRpbWVzLiAgVGhlDQogICBGaXJz dCBIb3AgUHJvdmlkZXIgUm91dGVyIGV4dGVuZHMgdGhlc2UgbGlmZXRpbWVzIGJ5IHNlbmRpbmcg YW4NCiAgIHVuc29saWNpdGVkIFJBLCB0aGUgYXBwbGljYWJsZSBNYXhSdHJBZHZJbnRlcnZhbCBv biB0aGUgV0xBTi1HVyBNVVNUDQogICB0aGVyZWZvcmUgYmUgbG93ZXIgdGhhbiB0aGUgcHJlZmVy cmVkIGxpZmV0aW1lLiAgQXMgYSBjb25zZXF1ZW5jZSBvZg0KICAgdGhpcyBwcm9jZXNzIGlzIHRo YXQgdGhlIEZpcnN0IEhvcCBSb3V0ZXIgbmV2ZXIga25vd3Mgd2hlbiBhIFVFLw0KICAgc3Vic2Ny aWJlciBzdG9wcyB1c2luZyBhZGRyZXNzZXMgZnJvbSBhIHByZWZpeCBhbmQgYWRkaXRpb25hbA0K ICAgcHJvY2VkdXJlcyBhcmUgcmVxdWlyZWQgdG8gaGVscCB0aGUgRmlyc3QgSG9wIFJvdXRlciB0 byBnYWluIHRoaXMNCiAgIGluZm9ybWF0aW9uLiAgV2hlbiB1c2luZyBzdGF0ZWZ1bCBESENQdjYg SUFfTkEgZm9yIElQdjYgVUUvc3Vic2NyaWJlcg0KICAgYWRkcmVzcyBhc3NpZ25tZW50IHRoaXMg dW5jZXJ0YWludHkgb24gdGhlIEZpcnN0IEhvcCBSb3V0ZXIgaXMgbm90IG9mDQogICBpbXBhY3Qg ZHVlIHRvIHRoZSBzdGF0ZWZ1bCBuYXR1cmUgb2YgREhDUHY2IElBX05BIGFkZHJlc3MgYXNzaWdu bWVudC4NCg0KQW5kIEnigJltIG5vdCByZWFsbHkgc3VyZSBob3cgdGhlIHN0YXRlZnVsIG5hdHVy ZSBvZiBESENQIGhlbHBzIHNpZ25pZmljYW50bHkgd2l0aCB0aGlzIGlzc3VlLiBUaGUgUkHigJlz IHByZWZlcnJlZC92YWxpZCBsaWZldGltZSBhcmUgcmVhbGx5IG5vIGRpZmZlcmVudCB0aGFuIERI Q1B2NuKAmXMgcHJlZmVycmVkL3ZhbGlkIGxpZmV0aW1lcyBhbmQgY291bGQgZWFzaWx5IGJlIG1h ZGUgdGhlIHNhbWUuIChXaGlsZSBhIERIQ1B2NiBjbGllbnQgd291bGQgbm9ybWFsbHkgcmVuZXcg YXQgwr0gdGhlIHByZWZlcnJlZCBsaWZldGltZSwgdGhhdCBpcyBub3QgYSBoYXJkIHJlcXVpcmVt ZW50IGFuZCB0aGVyZWZvcmUgYSBESENQdjYgc2VydmVyIG11c3Qgc3RpbGwgYXNzdW1lIHRoYXQg dGhlIGFkZHJlc3MgaXMgaW4gdXNlIHVudGlsIHRoZSB2YWxpZC1saWZldGltZSBoYXMgZXhwaXJl ZC4pIFN1cmUsIGEgREhDUHY2IGNsaWVudCBDT1VMRCBzZW5kIGEgUmVsZWFzZSBtZXNzYWdlIHRv IGdpdmUgdXAgaXRzIGFkZHJlc3MsIGJ1dCB0aGF0IGlzIHJhcmVseSBkb25lIGluIHByYWN0aWNl Lg0KDQpBbmQgYSBiaXQgbGF0ZXIgKFJGQzQ5NDEpOg0KDQogICBXaGVuIGVtcGxveWluZyBzdGF0 ZWxlc3MgSVB2NiBhZGRyZXNzIGFzc2lnbm1lbnQgYSBudW1iZXIgb2Ygd2lkZWx5DQogICBkZXBs b3llZCBvcGVyYXRpbmcgc3lzdGVtcyB3aWxsIGF0dGVtcHQgdG8gdXRpbGl6ZSBSRkMgNDk0MSBS RkM0OTQxDQogICBbUkZDNDk0MV0gdGVtcG9yYXJ5ICdwcml2YXRlJyBhZGRyZXNzZXMuICBUaGlz IGNhbiBsZWFkIHRvIHRoZQ0KDQpBbmQgaXMgdGhlcmUgbXVjaCBiZW5lZml0IGlzIGluY2x1ZGlu ZzoNCg0KNi4gIEZ1dHVyZSB3b3JrDQoNCiAgIG8gIEluZm9ybWF0aW9uYWwgZHJhZnQgcmVnYXJk aW5nIFdMQU4gSVB2NiBEZXBsb3ltZW50IHRlY2hub2xvZ3kNCiAgICAgIGV4cGVyaWVuY2VzIHJv bGwtb3V0DQoNCkl0IHdvdWxkIHBlcmhhcHMgYmUgdXNlZnVsIGlmIHlvdSBoYWQgYSBkcmFmdCB0 byByZWZlcmVuY2UsIGJ1dCBvdGhlcndpc2Ugbm90IHNvIG11Y2g/DQoNCg0KLSAgICAgICAgICBC ZXJuaWUNCg== --_000_77EB26C95B6A496A93D138621B4DD257alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjE3MjUzNzU0NjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjkwODkwMjk0MCAtMTkyMzg1NTgzMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjEwMDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVwLCBnb29kIGNhdGNoLiBJIGluZGVlZCBtaXNzZWQgdGhlc2Ugd2hlbiBkb2luZyB0aGUg ZWRpdCBvbiB0aGlzIGxhdGVzdCB2ZXJzaW9uIHRvIHNwbGl0IG91dCB0aGUgLzY0IGFzc2lnbm1l bnQgcGVyIGhvc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5leHQgdmVyc2lvbiBJ4oCZbGwg dGFrZSB0aGlzIGNvbW1lbnQgaW50byBhY2NvdW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YW55IHRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkcvPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtCZXJuaWUgVm9seiAodm9s eikmcXVvdDsgJmx0O3ZvbHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRh eSA5IEp1bHkgMjAxNiBhdCAxNzoyNzxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7ZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7djZvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Y2b3BzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdC0wMTxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+Jmx0O2pvaG5fYnJ6b3pvd3Nr aUBjYWJsZS5jb21jYXN0LmNvbSZndDssICZsdDtndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNv bSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTogPC9iPlNhdHVyZGF5IDkgSnVseSAyMDE2IGF0IDE3 OjI3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZCB5b3UgcGVyaGFwcyBt aXNzIHNvbWUgZWRpdHMgbGF0ZSBpbiB0aGUgZG9jdW1lbnQgKFNlY3Rpb24gNSk6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFuIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb24gd2hlbiB1 c2luZyBJUHY2IGFkZHJlc3MgYXNzaWdubWVudCB1c2luZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElQdjYgU0xBQUMgaXMgdGhhdCBhZnRlciB0aGUg b25ib2FyZGluZyBwcm9jZWR1cmUgdGhlIFVFL3N1YnNjcmliZXI8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aWxsIGhhdmUgYSBwcmVmaXggd2l0aCBj ZXJ0YWluIHByZWZlcnJlZCBhbmQgdmFsaWQgbGlmZXRpbWVzLiZuYnNwOyBUaGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBGaXJzdCBIb3AgUHJvdmlk ZXIgUm91dGVyIGV4dGVuZHMgdGhlc2UgbGlmZXRpbWVzIGJ5IHNlbmRpbmcgYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bnNvbGljaXRlZCBSQSwg dGhlIGFwcGxpY2FibGUgTWF4UnRyQWR2SW50ZXJ2YWwgb24gdGhlDQo8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPldMQU4tR1c8L3NwYW4+IE1VU1Q8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGVyZWZv cmUgYmUgbG93ZXIgdGhhbiB0aGUgcHJlZmVycmVkIGxpZmV0aW1lLiZuYnNwOyBBcyBhIGNvbnNl cXVlbmNlIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgdGhpcyBwcm9jZXNzIGlzIHRoYXQgdGhlIEZpcnN0IEhvcCBSb3V0ZXIgbmV2ZXIga25vd3Mg d2hlbiBhIFVFLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IHN1YnNjcmliZXIgc3RvcHMgdXNpbmcgYWRkcmVzc2VzIGZyb20gYSBwcmVmaXggYW5kIGFk ZGl0aW9uYWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBwcm9jZWR1cmVzIGFyZSByZXF1aXJlZCB0byBoZWxwIHRoZSBGaXJzdCBIb3AgUm91dGVyIHRv IGdhaW4gdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IGluZm9ybWF0aW9uLiZuYnNwOyBXaGVuIHVzaW5nIHN0YXRlZnVsIERIQ1B2NiBJQV9OQSBm b3IgSVB2NiBVRS9zdWJzY3JpYmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcyBhc3NpZ25tZW50IHRoaXMgdW5jZXJ0YWludHkgb24gdGhl IEZpcnN0IEhvcCBSb3V0ZXIgaXMgbm90IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW1wYWN0IGR1ZSB0byB0aGUgc3RhdGVmdWwgbmF0dXJlIG9m IERIQ1B2NiBJQV9OQSBhZGRyZXNzIGFzc2lnbm1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbmQgSeKAmW0gbm90IHJlYWxseSBzdXJlIGhvdyB0aGUgc3RhdGVmdWwgbmF0dXJl IG9mIERIQ1AgaGVscHMgc2lnbmlmaWNhbnRseSB3aXRoIHRoaXMgaXNzdWUuIFRoZSBSQeKAmXMg cHJlZmVycmVkL3ZhbGlkIGxpZmV0aW1lIGFyZSByZWFsbHkgbm8gZGlmZmVyZW50IHRoYW4gREhD UHY24oCZcyBwcmVmZXJyZWQvdmFsaWQgbGlmZXRpbWVzIGFuZCBjb3VsZCBlYXNpbHkgYmUgbWFk ZSB0aGUgc2FtZS4gKFdoaWxlIGEgREhDUHY2DQogY2xpZW50IHdvdWxkIG5vcm1hbGx5IHJlbmV3 IGF0IMK9IHRoZSBwcmVmZXJyZWQgbGlmZXRpbWUsIHRoYXQgaXMgbm90IGEgaGFyZCByZXF1aXJl bWVudCBhbmQgdGhlcmVmb3JlIGEgREhDUHY2IHNlcnZlciBtdXN0IHN0aWxsIGFzc3VtZSB0aGF0 IHRoZSBhZGRyZXNzIGlzIGluIHVzZSB1bnRpbCB0aGUgdmFsaWQtbGlmZXRpbWUgaGFzIGV4cGly ZWQuKSBTdXJlLCBhIERIQ1B2NiBjbGllbnQgQ09VTEQgc2VuZCBhIFJlbGVhc2UgbWVzc2FnZSB0 bw0KIGdpdmUgdXAgaXRzIGFkZHJlc3MsIGJ1dCB0aGF0IGlzIHJhcmVseSBkb25lIGluIHByYWN0 aWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgYSBiaXQgbGF0ZXIgKFJGQzQ5NDEpOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXaGVuIGVtcGxveWluZyBzdGF0ZWxlc3MgSVB2 NiBhZGRyZXNzIGFzc2lnbm1lbnQgYSBudW1iZXIgb2Ygd2lkZWx5PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGVwbG95ZWQgb3BlcmF0aW5nIHN5c3Rl bXMgd2lsbCBhdHRlbXB0IHRvIHV0aWxpemUgUkZDIDQ5NDEgUkZDNDk0MTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFtSRkM0OTQxXSB0ZW1wb3Jhcnkg J3ByaXZhdGUnIGFkZHJlc3Nlcy4mbmJzcDsgVGhpcyBjYW4gbGVhZCB0byB0aGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBpcyB0aGVyZSBtdWNoIGJlbmVmaXQgaXMgaW5jbHVk aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjYuJm5ic3A7IEZ1dHVyZSB3b3JrPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEluZm9ybWF0aW9uYWwgZHJhZnQgcmVnYXJk aW5nIFdMQU4gSVB2NiBEZXBsb3ltZW50IHRlY2hub2xvZ3k8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleHBlcmllbmNl cyByb2xsLW91dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgcGVyaGFw cyBiZSB1c2VmdWwgaWYgeW91IGhhZCBhIGRyYWZ0IHRvIHJlZmVyZW5jZSwgYnV0IG90aGVyd2lz ZSBub3Qgc28gbXVjaD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkJl cm5pZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_77EB26C95B6A496A93D138621B4DD257alcatellucentcom_-- From nobody Mon Jul 18 03:49:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5D812D86C; Mon, 18 Jul 2016 03:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.807 X-Spam-Level: X-Spam-Status: No, score=-115.807 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 95L0PdTxGx8j; Mon, 18 Jul 2016 03:49:22 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23E612D85C; Mon, 18 Jul 2016 03:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3645; q=dns/txt; s=iport; t=1468838961; x=1470048561; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Vav0EdUl+sSoaom2J9siQCyALYnK+goM25zfmWZ+2nM=; b=KjPrpha2VStT1tGw6bjUu/4HHWAybic5/OV3/rN+Yn6NOciw1Aabw9ei s5KyhsOz0yREy3TfYKDU6n92qkUqYGfJMGjOLWN6tJ8mh2Fptb3YCQ+1o dKeoDxF6+1js/ZcfTDyEwp+ov2a+CwRqkNZRuUVTFIwljjx11ExAWNjbV E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBQB9s4xX/4YNJK1bgnFOgVIGs2+FB?= =?us-ascii?q?IF5hhoCgTI5EwEBAQEBAQFlJ4RcAQEEASNWBQsCAQgEARMqAgIyJQIEDgUOiBo?= =?us-ascii?q?IsGCNZgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OiCIIgk2HQSuCLwWZJAGDNoFui?= =?us-ascii?q?TqPN5AdASADMYNzboY/fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,383,1464652800"; d="asc'?scan'208,217";a="297214786" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 10:49:21 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6IAnKwa018662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jul 2016 10:49:21 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 05:49:20 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 05:49:20 -0500 From: "Fred Baker (fred)" To: "Howard, Lee" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHR4OIJsOqAEyfHyU2Aa5Q9BpsY/Q== Date: Mon, 18 Jul 2016 10:49:20 +0000 Message-ID: <731BDBF9-6EEB-4721-B2E3-32AC66695A43@cisco.com> References: <7FE9B6A2-5013-4B4A-9959-554BDC9DA120@charter.com> In-Reply-To: <7FE9B6A2-5013-4B4A-9959-554BDC9DA120@charter.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.202.126] Content-Type: multipart/signed; boundary="Apple-Mail=_4228E6C1-D195-47A9-887B-3059ED74D2CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "fgont@si6networks.com" Subject: Re: [v6ops] Asking for a review of draft-ietf-opsec-v6-08 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 10:49:24 -0000 --Apple-Mail=_4228E6C1-D195-47A9-887B-3059ED74D2CE Content-Type: multipart/alternative; boundary="Apple-Mail=_CE6A92FD-5D8D-4B6A-ADBF-DAEC586D7EB0" --Apple-Mail=_CE6A92FD-5D8D-4B6A-ADBF-DAEC586D7EB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 16, 2016, at 8:38 PM, Howard, Lee = wrote: >=20 > 4.3 You say lawful intercept can target =E2=80=9Csingle host (a /128 = target)=E2=80=9D but if the client is using privacy extensions, that = will not be enough detail. It's theoretically possible to target a single address. However, = practically speaking, such a warrant specifies a subscriber, and targets = all of his/her communications. So I would think that usually becomes a = /64 or whatever is allocated to the subscriber, not a /128. --Apple-Mail=_CE6A92FD-5D8D-4B6A-ADBF-DAEC586D7EB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 16, 2016, at 8:38 PM, Howard, Lee <lee.howard@twcable.com> wrote:

4.3  You say = lawful intercept can target =E2=80=9Csingle host (a /128 target)=E2=80=9D = but if the client is using privacy extensions, that will not be enough = detail.

It's theoretically possible to target a = single address. However, practically speaking, such a warrant specifies = a subscriber, and targets all of his/her communications. So I would = think that usually becomes a /64 or whatever is allocated to the = subscriber, not a /128.
= --Apple-Mail=_CE6A92FD-5D8D-4B6A-ADBF-DAEC586D7EB0-- --Apple-Mail=_4228E6C1-D195-47A9-887B-3059ED74D2CE 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 iQIVAwUBV4y0LkayAOS/EQ8MAQJ6YRAAkENvslyqT9IUHHn+AcEBTxHfbjMjNXNo 4LvOX7N5UFzAgW8w7ffvnZRwdjv0jzcCX2g3PGVTFJ98DvJ6TaXub/UDZ7EbPtoy nO/VJRV4HUAvv8Pf3rlbC3m6oRSh6uMqNhD5WaZFgdPHMhd9GxQT7uChkBedWdUh ys8HsJc1OEkMpxNzLccNcoiIIj/xacZN5TqHkuPUcJel9FerHlblDnPB1Z+RO7qE Z1hm+hjIe9srBROpl6JRgnamKqtqnfM/fc1zrejsUt3EPLsz4SeCmuq9ZfwPKU4E Yg3TtVRyrMFsVTW4CAqWBiPj+JJicsUQeBradVsPZgVITwhSIyIQ9VUeieqRuQ1/ TDdebq9mNp+Sp0yQU2WC+IQUviE/tRyWMtL3dXzfoLi27+tYOBHwnRY0VqeikVlC YZWOpR2FeDeI2XR3KErXzHdMcQFSC+8Ip7JG7G5H0b6kX30TwXJ6TN6WolJ2fje5 AdoXBzKPSsB1AfuOY0j6G2WX07gx5yKfE1/Vlx7MBN7HLLzaqelmuCOfGLPMXSkl YUuDg6uES3vUdfyBctj/XlwN2nnlcWrj6guyIkQ2PDJMToI8mfgBpLLCiEAT1120 1MrGv1xQHx6lgAGqqovNFQ2Fn3QmXuj7QkPKdxIhC8bELRC85I8vXpz7GC/b9sJk FSRXnvmPRco= =GvRG -----END PGP SIGNATURE----- --Apple-Mail=_4228E6C1-D195-47A9-887B-3059ED74D2CE-- From nobody Mon Jul 18 22:10:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DF12DC77 for ; Mon, 18 Jul 2016 22:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T0j59ieCXsfP for ; Mon, 18 Jul 2016 22:10:18 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 E3FE912DC79 for ; Mon, 18 Jul 2016 22:10:17 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id x130so10010022vkc.0 for ; Mon, 18 Jul 2016 22:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3rNQ9sgiyMlDdKh+0ij3yqb39pYwWgjROcPr58gSifQ=; b=ichPssGRT3Xcr+48y/JP2Nu4sUa8MaSygbmM/lnrpb+ewSdMUihmWBqkwrlQbRIgRF 7pzK6Rwla7yBGCuJ6ykWjsgXMI5U15I3VCJGkglrA/+iNpLGfdu4ClOa0lgOtSqpD3Ex T3YMgGlOXlDiKVGTu5pu2ndxH+GmQNLsSseC6LwWX5lQi36QtSOXwoKDjWz7L+RlPaYh ckIPE3/ntYmDk/wdsi8OCL16xsv8PBJbL8T+RbwJDkNnsPMxzxN2VrA8Ru5xDUxkDdUB c6dKu7AOCd2H2YG732TG48m6yVzzjVwb+IS6KLt01EIkDRGlJJqrtPQXqPzG2OSoo0Eu gf+A== 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-transfer-encoding; bh=3rNQ9sgiyMlDdKh+0ij3yqb39pYwWgjROcPr58gSifQ=; b=VA8hQgCbtCtmnUyfT5HmvE4y2tG8gBGByveGp82PIq7l1JB/kxRiAYZTBf6/UYN/zM J35hrUDZ5sm6oPy3+KpRAuhXZM9ZaGdROLR019aHev5XA0ADmCbrFS2oHopjCbsAfXPz GfMwudnTupK9l5IgDDuwDjpdlISI295IUkSxCrMT/L/d+gTMxoMA6vcRQCofEuNQJRhc SOQvoHCxhUpmTj5y1LEMWz3O51rFS3QRXeeCfIv8ABsMfiq/c4WSEDExPcoTKPw0AO6R 77WbdIy704VDS6CmmrFCyJiLjTYlXxaaEFBMsabg4VlEgKkJ6jT98RPu4rLoLfSjkQlf WcIw== X-Gm-Message-State: ALyK8tJLUGCXbECtdzoY/4fxaMJ9LaGGWKxi9l8hoHgmAcYZUJaGvhd9acMthRy0e+ybUFKwxS8Uu/fmnmJPew== X-Received: by 10.176.0.56 with SMTP id 53mr19962880uai.113.1468905017025; Mon, 18 Jul 2016 22:10:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Mon, 18 Jul 2016 22:09:47 -0700 (PDT) In-Reply-To: <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> References: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> From: Mark Smith Date: Tue, 19 Jul 2016 15:09:47 +1000 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 05:10:19 -0000 Hi, On 5 July 2016 at 04:16, Alexandre Petrescu wrote: > > > Le 23/06/2016 =C3=A0 22:51, Joe Touch a =C3=A9crit : >> >> >> >> On 6/23/2016 1:33 PM, Owen DeLong wrote: >>>> >>>> So I think we should suggest to use 33:33::1 MAC address instead >>>> of the ff:ff:ff:ff:ff:ff MAC address when IPv6 is used over >>>> these links. I will put that in some draft. >>> >>> That=E2=80=99s probably a good start. >> >> >> IMO, it'd be better to say you're using "all nodes" and cite RFC2464 >> rather than opaquely using the MAC that results. > > In this context, I believe it can make sense to think of requesting IANA > (rather than IEEE) for an allocation of a 112bit Group ID named "All > 802.11-OCB interfaces"; this Group ID could then be used with > scope link, or site, or admin - to make a full multicast IP address. > Then it would come down to define a link scope to be the scope between a > few nearby cars, site scope to be the scope between one platoon, and so o= n. > > What do you think? > No specific to above, however related. I think it is better to avoid using generic "all node" IPv6 addresses if possible, and instead use a function specific multicast address. While I don't really like the layer violation, function specific IPv6 multicast addresses can more easily facilitate IPv6 packet filtering at layer 2, because the IPv6 addresses are in a fixed location in the frame, meaning the layer 2 device doesn't have to do as much frame/packet parsing to perform IPv6 packet filtering. For example, as All_DHCP_Relay_Agents_and_Servers in DHCPv6 has exclusive use of the FF02::1:2 multicast address, a simple way to implement DHCPv6 guard would be to prevent any packets to those multicast addresses being flooded to layer 2 device egress ports that are not configured as attached to link authorised DHCPv6 servers. RA Guard in part can be implemented that way - RSes are sent to the All Routers (FF01::2) multicast address, so the layer 2 device could control the flooding of those to only authorised ports attached to authorised routers. However, RAs are sent to the all nodes multicast address that isn't exclusive to all Router clients. That means it wouldn't be possible to apply an ingress layer 2 port filter to drop RAs from rogue routers. Ideally, there would have been an "All router clients" specific multicast address instead that RAs were sent to, that could have facilitated ingress layer 2 filtering. (DHCPv6 doesn't have this problem because DHCPv6 servers and relays don't periodically announce themselves.) It is probably wasteful to use function specific multicast addresses for all functions/applications that somebody might want to filter in a layer 2 device, as they're in effect encoding upper layer identifiers such as UDP ports or ICMP types in addresses. Use of functional multicast addresses could be limited to fundamental IPv6 operations that might be typical of what people might want to filter in layer 2 devices. Regards, Mark. > Alex > >> >> Joe >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 19 04:59:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6A512D596 for ; Tue, 19 Jul 2016 04:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=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 dvGOhWIcqck8 for ; Tue, 19 Jul 2016 04:59:10 -0700 (PDT) Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 377B512D57B for ; Tue, 19 Jul 2016 04:59:10 -0700 (PDT) X-SENDER-IP: 10.64.163.155 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.28,389,1464667200"; d="scan'208,217";a="1106270179" Received: from unknown (HELO exchpapp14.corp.twcable.com) ([10.64.163.155]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 19 Jul 2016 07:53:32 -0400 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp14.corp.twcable.com (10.64.163.155) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 07:59:08 -0400 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 07:59:08 -0400 From: "Howard, Lee" To: 'IPv6 Operations' Thread-Topic: meeting help Thread-Index: AQHR4bT0no9AsIzjnkq3RnkPhtUXxQ== Date: Tue, 19 Jul 2016 11:59:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150911 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22460.005 x-tm-as-result: No--33.770500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B1A8289453DB493CACA152C622753F7Ftwcablecom_" MIME-Version: 1.0 Archived-At: Subject: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:59:12 -0000 --_000_B1A8289453DB493CACA152C622753F7Ftwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UncmUgbG9va2luZyBmb3Igdm9sdW50ZWVycyB0byB0YWtlIG1pbnV0ZXMgYW5kIGphYmJlciBz Y3JpYmUuDQpJdCdzIGEgc2hvcnQgYWdlbmRhLCBzbyBpdCBzaG91bGRuJ3QgYmUgdG9vIGhhcmQu DQoNCkFueSB2b2x1bnRlZXJzPw0KDQpUaGFua3MsDQpMZWUNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0 IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8g dGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMg RS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_B1A8289453DB493CACA152C622753F7Ftwcablecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5XZSdyZSBsb29r aW5nIGZvciB2b2x1bnRlZXJzIHRvIHRha2UgbWludXRlcyBhbmQgamFiYmVyIHNjcmliZS48L2Rp dj4NCjxkaXY+SXQncyBhIHNob3J0IGFnZW5kYSwgc28gaXQgc2hvdWxkbid0IGJlIHRvbyBoYXJk LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW55IHZvbHVudGVlcnM/PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkxlZTwvZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjxicj4N Cjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvDQogd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5k IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eQ0KIGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHBy aW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B1A8289453DB493CACA152C622753F7Ftwcablecom_-- From nobody Tue Jul 19 08:07:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099C912D7B9 for ; Tue, 19 Jul 2016 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 surnw_3i2U0l for ; Tue, 19 Jul 2016 08:07:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 BB3E412D8FF for ; Tue, 19 Jul 2016 07:43:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E2DDDA3; Tue, 19 Jul 2016 16:43:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1468939395; bh=Cfmyy4gJippZ36+t1qV4n6A7BP3GL2r0tjG5lldQUlI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uAFS8ZmhHsF//I82s/AehtwwRY3+Jc+ZtUm2gncP0XJrKZlL7eDi2rjxtmxoKX85S jAC0/JVYbdwYmMRFxlYyRlgjkVBFUwhOBIcc0KoWKv8U7WMFemA8/HZDStHkZEYWPD V6EOp7rKIne1IUKYWX/RjMTq7xGU6AfOeKI2xres= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DC93AA2; Tue, 19 Jul 2016 16:43:15 +0200 (CEST) Date: Tue, 19 Jul 2016 16:43:15 +0200 (CEST) From: Mikael Abrahamsson To: "Howard, Lee" In-Reply-To: Message-ID: References: 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: 'IPv6 Operations' Subject: Re: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:07:16 -0000 On Tue, 19 Jul 2016, Howard, Lee wrote: > We're looking for volunteers to take minutes and jabber scribe. > It's a short agenda, so it shouldn't be too hard. > > Any volunteers? I can do jabber scribe. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jul 19 08:58:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89912D7D6 for ; Tue, 19 Jul 2016 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 I13nDmIru6HO for ; Tue, 19 Jul 2016 08:58:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 EEDAB12DC1F for ; Tue, 19 Jul 2016 08:48:42 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6JFlVLu015729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 08:47:41 -0700 (PDT) To: Mark Smith , Alexandre Petrescu References: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> From: Joe Touch Message-ID: <578E4B94.2000507@isi.edu> Date: Tue, 19 Jul 2016 08:47:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: 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] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:58:55 -0000 On 7/18/2016 10:09 PM, Mark Smith wrote: ... > No specific to above, however related. > > I think it is better to avoid using generic "all node" IPv6 addresses > if possible, and instead use a function specific multicast address. > > While I don't really like the layer violation, function specific IPv6 > multicast addresses can more easily facilitate IPv6 packet filtering > at layer 2, because the IPv6 addresses are in a fixed location in the > frame, meaning the layer 2 device doesn't have to do as much > frame/packet parsing to perform IPv6 packet filtering. > > For example, as All_DHCP_Relay_Agents_and_Servers in DHCPv6 has > exclusive use of the FF02::1:2 multicast address, a simple way to > implement DHCPv6 guard would be to prevent any packets to those > multicast addresses being flooded to layer 2 device egress ports that > are not configured as attached to link authorised DHCPv6 servers. > > RA Guard in part can be implemented that way - RSes are sent to the > All Routers (FF01::2) multicast address, so the layer 2 device could > control the flooding of those to only authorised ports attached to > authorised routers. > > However, RAs are sent to the all nodes multicast address that isn't > exclusive to all Router clients. There is already a multicast address for "all routers". > That means it wouldn't be possible to > apply an ingress layer 2 port filter to drop RAs from rogue routers. > Ideally, there would have been an "All router clients" specific > multicast address "all router clients" == "all hosts", which already has a multicast address. > instead that RAs were sent to, that could have > facilitated ingress layer 2 filtering. (DHCPv6 doesn't have this > problem because DHCPv6 servers and relays don't periodically announce > themselves.) > > It is probably wasteful to use function specific multicast addresses > for all functions/applications that somebody might want to filter in a > layer 2 device, as they're in effect encoding upper layer identifiers > such as UDP ports or ICMP types in addresses. Use of functional > multicast addresses could be limited to fundamental IPv6 operations > that might be typical of what people might want to filter in layer 2 > devices. There are already quite a few of these. The key is that they are mapped to *protocols* or *protocol node classes* (host/router). Joe From nobody Tue Jul 19 09:54:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAD012D0F6 for ; Tue, 19 Jul 2016 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 9b4wPlFJElFj for ; Tue, 19 Jul 2016 09:54:44 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A3812D0E8 for ; Tue, 19 Jul 2016 09:54:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6JGsaZl015603; Tue, 19 Jul 2016 18:54:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 53CFE206AA0; Tue, 19 Jul 2016 18:54:36 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 43901202944; Tue, 19 Jul 2016 18:54:36 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGsZV6008589; Tue, 19 Jul 2016 18:54:35 +0200 To: Owen DeLong References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <20160714094952.GA19518@lud.polynome.dn42> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Jul 2016 18:54:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:54:48 -0000 Le 14/07/2016 19:06, Owen DeLong a crit : >>> In terms of reachability, these layer-2 links are generally not >>> transitive (and may not be symmetric either). >> >> YEs. >> >>> There is some previous work: MANET, "mesh-under" vs. >>> "route-over" architecture [1], Babel [2]. >> >> YEs, but it is not satisfactory in vehicular reasons for many other >> reasons. >> >>> Basically, the sanest way is to define the scope of a link as the >>> set of nodes reachable via radio broadcast. You then have to >>> deal with the fact that this set will change over time (see Babel >>> for unicast dynamic routing). >> >> Such scope can make sense, but it is still dependent on the user. > > This is an inevitable consequence of your design decision to use > OCB. It is a wise decision in that OCB eliminates much messages and noise which may provoke interference. Interference is a risk in jams or high relative speeds (e.g. mobile to infra, or mobile crossing another mobile, but not mobile following a mobile). That decision can not be questioned. >> There is a different scope for each user. >> >> On another hand, a link scope in AP-mode or ad-hoc mode is the >> scope covering that ESSID: a link scope is different for each ESSID >> (not different for each user). > > That is a property difference between OCB and ESSID modes of > operation. It has nothing to do with IP or the IP concept of a link. Well. The ND operation is specified with the full expectation that when an NS is sent to the link-scope everybody in that link is supposed to be willing to reply. But in WiFi-adhoc and in 802-11-OCB for that matter, some hosts in link scope will not even hear that NS. This is not normal. And it is unnormal because link scope is for wires, not for 802.11-adhoc nor for 802.11-OCB. >> The fact that within AP-mode or ad-hoc mode link scope some hosts >> can not see each other (non transitivity: A sees B sees C doesnt >> mean A sees C) is commonly understood as a configuration problem: >> one is not supposed to build networks with only one ESSID bigger >> than the WiFi radio range. > > Or if one, does, one is expected to provide transitivity between APs > sharing the same ESSID to overcome this. Such transitivity has never been provided meaningfully, other than duplicating packets in the air, which means to generate more noise back to the emitter. > However, in OCB mode, you dont have those facilities, so your link > is limited to being different for east combination of station, time, > position, and relative position of other stations as well as > propagation factors. Look, not only OCB mode is different than wires, but 802.11-adhoc is also different in this respect. You can not single out OCB mode. >> To solve this non-transitivity problem in AP-mode or ad-hoc mode >> one should define an "ESSID scope" (not a link scope). At that >> point we talk about nodes in ESSID scope are agreed to be >> non-transitive. And routers to forward between link scopes but >> within same ESSID scope. > > This is completely illogical and is not how any Wireless network Ive > worked with is implemented. > > Instead, multiple APs are connected with the same ESSID using > bridging and/or other technologies on the wired side to provide this > transitivity. YEs but in some vehicular networks there is no wired side along the road (although almost often there is a wired side inside each vehicle). One could not imagine bridging a single 'wildcard' ESSID between the outside of vehicles and throughout each distinct inside of vehicles. Whereas yes, this ESSID could be bridged between each vehicle and the wired side along the road (in the rare places where there are linked Road-Side Units along road). > In some cases, there are also wireless protocols that can be used to > extend an ESSID wirelessly between two or more APs, but these are > obviously suboptimal due to spectrum utilization for forwarding > between the APs. I agree. > However, none of this is relevant to your situation because of your > design decision to use OCB. > >> But that is not my problem here. It is an IPv6-over-80211 problem >> in the first place. And we dont have such an RFC. > > Nor do we have an actual need for one as it is a problem which > everyone so far solves at layer 2 using media adapters and bridging. Not in WiFi. >> My problem here is the scope for OCB-mode, which has no ESSID. > > What is the problem? As you have mentioned, each user has a unique > link scope. But in Ethernet the scope is not relative to a particular user - it is the scope of the wire if I can say so. > If you dont like that, dont use OCB or dont use link scope for > your application(s). That's not an option. In some vehicles 802.11-OCB is there built in. >>> I don't see why you would need to change the semantic of >>> multicast addresses, in particular "all-nodes". It represents >>> all nodes on the layer-2 link, and this set can always change >>> over time (even in classical wired links, where nodes can come >>> and go and bridges can fail). >> >> Noted but non implementable. > > Why not? > >> The "all nodes" Group ID is defined to be able to live within link >> scope (ff02::1), site scope (ff0X::1) and more other scopes. > > Sure. Use the scope that best meets your needs. > >> Nodes that come and go from link scopes can indeed be managed but >> _only_ if we have a solid scope. > > What do you mean by solid scope? If nodes are arriving and departing > from the scope, by definition, it lacks solidity from at least one > perspective on the term. I meant a solid scope definition. The scope itself should be more ephemeral. Hosts sending NS to that scope would wait more than on a link scope before continuing. >> In 802.11 there are no bridges (yes there are bridges between >> 802.11 and 802.3 but not between different 802.11 ESSIDs). > > Since you are not using ESSIDs to begin with, Im not sure how that > is relevant. Well in OCB there is one single 'wildcard' ESSID whose value is a string of all 1s (not to be confused with the all 1s MAC broadcast address). So an ESSID bridge would link together all in that 'wildcard' ESSID. Alex > > Owen > >> >> Alex >> >>> >>> Baptiste >>> >>> [1] >>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.188.2437 >>> [2] https://datatracker.ietf.org/wg/babel/documents/ >>> >>>> Le 09/07/2016 05:12, Owen DeLong a crit : >>>>> I fail to see any reason that the mapping would be different >>>>> in OCB vs. any other 802 style networking. >>>>> >>>>> Owen >>>>> >>>>>> On Jul 8, 2016, at 12:38 , Alexandre Petrescu >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> During our discussion of IPv6 and MAC address multicast I >>>>>> laid down a few of comment results of the discussion on >>>>>> this email list, on this Internet Draft referred to below. >>>>>> >>>>>> In my oppinion there is obviously a need to clarify how >>>>>> and what MAC multicast addresses to use below IPv6 in >>>>>> IPv6-over-802.11OCB (Out of the Context of BSSID, aka >>>>>> 802.11p). >>>>>> >>>>>> Alex >>>>>> >>>>>> -------- Message transfr -------- Sujet : [its] Fwd: I-D >>>>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : >>>>>> Fri, 8 Jul 2016 21:33:53 +0200 De : Alexandre Petrescu >>>>>> Pour : its@ietf.org >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have just submitted this Internet Draft I co-author with >>>>>> Thierry Ernst. >>>>>> >>>>>> The distinctive aspect is that it tries to suggest the way >>>>>> MAC and IPv6 multicast is used on an IPv6-over-80211-OCB >>>>>> links. >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> -------- Message transfr -------- Sujet : I-D Action: >>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 >>>>>> Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org >>>>>> Rpondre : internet-drafts@ietf.org Pour : >>>>>> i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts directories. >>>>>> >>>>>> >>>>>> Title : Transmission of IPv6 Packets over IEEE >>>>>> 802.11-OCB Networks Authors : Thierry Ernst >>>>>> Alexandre Petrescu Filename : >>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : >>>>>> 2016-07-08 >>>>>> >>>>>> Abstract: In this document the mapping of multicast IPv6 >>>>>> addresses to MAC addresses of 802.11-OCB is proposed. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >>>>>> >>>>>> >>>>>> >>>> >>>>>> >> >>>>>> >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-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/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> _______________________________________________ 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 Jul 19 10:41:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE34C12D0BA for ; Tue, 19 Jul 2016 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 dCduRYg-F1Bn for ; Tue, 19 Jul 2016 10:41:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 2F0FA12D13A for ; Tue, 19 Jul 2016 10:41:43 -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 u6JHfBZn005209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 10:41:11 -0700 (PDT) To: Alexandre Petrescu , Owen DeLong References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <20160714094952.GA19518@lud.polynome.dn42> From: Joe Touch Message-ID: <1f058f3c-1f5b-16f0-fdb3-85beefd6b089@isi.edu> Date: Tue, 19 Jul 2016 10:41:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6JHfBZn005209 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 17:41:45 -0000 On 7/19/2016 9:54 AM, Alexandre Petrescu wrote: > The ND operation is specified with the full expectation that when an NS > is sent to the link-scope everybody in that link is supposed to be > willing to reply. > > But in WiFi-adhoc and in 802-11-OCB for that matter, some hosts in link > scope will not even hear that NS. > > This is not normal. And it is unnormal because link scope is for wires, > not for 802.11-adhoc nor for 802.11-OCB. Then either: - don't present the entire adhoc/OCB net as a single IPv6 "link" because you're not flooding NS - flood NS and support the requirements of what IPv6 considers a link Joe From nobody Tue Jul 19 11:41:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AA12D143 for ; Tue, 19 Jul 2016 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.387 X-Spam-Level: X-Spam-Status: No, score=-7.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 INjfAkWLd5xu for ; Tue, 19 Jul 2016 11:41:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB112B00C for ; Tue, 19 Jul 2016 11:41:45 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6JIeb2N030959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jul 2016 11:40:38 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_99D4032A-5ADA-4F64-A6E1-997FF079575D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Tue, 19 Jul 2016 11:40:34 -0700 Message-Id: <765ECBEC-89D7-4F5D-BE05-46157FE6DFDA@delong.com> References: <3c86b78e-0f28-21e6-6bbd-23a129f897e9@gmail.com> <6E56624E-AF13-40F3-A429-80612E8A1C42@delong.com> <43725be7-7c8e-ebfd-a1d8-12f755d3d333@gmail.com> <20160714094952.GA19518@lud.polynome.dn42> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 19 Jul 2016 11:40:38 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] [its] Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 18:41:50 -0000 --Apple-Mail=_99D4032A-5ADA-4F64-A6E1-997FF079575D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 19, 2016, at 09:54 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 14/07/2016 =E0 19:06, Owen DeLong a =E9crit : >>>> In terms of reachability, these layer-2 links are generally not >>>> transitive (and may not be symmetric either). >>>=20 >>> YEs. >>>=20 >>>> There is some previous work: MANET, "mesh-under" vs. >>>> "route-over" architecture [1], Babel [2]. >>>=20 >>> YEs, but it is not satisfactory in vehicular reasons for many other >>> reasons. >>>=20 >>>> Basically, the sanest way is to define the scope of a link as the >>>> set of nodes reachable via radio broadcast. You then have to >>>> deal with the fact that this set will change over time (see Babel >>>> for unicast dynamic routing). >>>=20 >>> Such scope can make sense, but it is still dependent on the user. >>=20 >> This is an inevitable consequence of your design decision to use >> OCB. >=20 > It is a wise decision in that OCB eliminates much messages and noise > which may provoke interference. Interference is a risk in jams or = high > relative speeds (e.g. mobile to infra, or mobile crossing another > mobile, but not mobile following a mobile). >=20 > That decision can not be questioned. Fair enough, but like any other decision, it has tradeoffs. Now, you are here complaining about the tradeoffs inherent in that decision as if it is somehow up to the IETF and/or IEEE to contort network standards to address those inherent tradeoffs. You=92ve chosen a networking mechanism with an inherently amorphous = definition of link which is specific to each node. That is what it is and all the=20= continued complaints about this will not change that nature. You must address these issues in your higher level protocols because you have made this choice. >=20 >>> There is a different scope for each user. >>>=20 >>> On another hand, a link scope in AP-mode or ad-hoc mode is the >>> scope covering that ESSID: a link scope is different for each ESSID >>> (not different for each user). >>=20 >> That is a property difference between OCB and ESSID modes of >> operation. It has nothing to do with IP or the IP concept of a link. >=20 > Well. >=20 > The ND operation is specified with the full expectation that when an = NS > is sent to the link-scope everybody in that link is supposed to be > willing to reply. >=20 > But in WiFi-adhoc and in 802-11-OCB for that matter, some hosts in = link > scope will not even hear that NS. >=20 > This is not normal. And it is unnormal because link scope is for = wires, > not for 802.11-adhoc nor for 802.11-OCB. No, the ND is sent with the expectation that everyone reachable (that = is, everyone actually on link) will hear it. Since the ND is sent to the =93All Nodes On Link=94 multicast address, and the definition of =93On = Link=94 is based on the ability to hear that packet, I think it is safe to take that for granted. Your complaint isn=92t that in 802.11-OCB some hosts in link scope won=92t hear it. Your complaint is that the host that was in link scope 200 milliseconds or even 20 milliseconds ago may not be on link now, but may again be on link 20 milliseconds later. Again, this is a tradeoff you have chosen in your decision to use this particular networking mechanism. It does not change the concept, definition, or properties of link-scope. It simply makes it damn inconvenient for you to use it because of the high rate of speed at which the definition of link-scope changes in your particular operating environment. >>> The fact that within AP-mode or ad-hoc mode link scope some hosts >>> can not see each other (non transitivity: A sees B sees C doesnt >>> mean A sees C) is commonly understood as a configuration problem: >>> one is not supposed to build networks with only one ESSID bigger >>> than the WiFi radio range. >>=20 >> Or if one, does, one is expected to provide transitivity between APs >> sharing the same ESSID to overcome this. >=20 > Such transitivity has never been provided meaningfully, other than > duplicating packets in the air, which means to generate more noise = back > to the emitter. Either over the air or over a wire, yes. This is true. Those really are the only two choices available. Nonetheless, it has worked well in enough installations that I feel comfortable saying it is a useful thing for many applications. >> However, in OCB mode, you don=92t have those facilities, so your link >> is limited to being different for east combination of station, time, >> position, and relative position of other stations as well as >> propagation factors. >=20 > Look, not only OCB mode is different than wires, but 802.11-adhoc is > also different in this respect. You can not single out OCB mode. 802.11-adhoc has a somewhat different set of tradeoffs, but it is = generally treated as a point-to-point link or point-to-multipoint link from an IPv6 perspective and this generally works just fine. Most actual deployments of adhoc are done as point to point anyway. >>> To solve this non-transitivity problem in AP-mode or ad-hoc mode >>> one should define an "ESSID scope" (not a link scope). At that >>> point we talk about nodes in ESSID scope are agreed to be >>> non-transitive. And routers to forward between link scopes but >>> within same ESSID scope. >>=20 >> This is completely illogical and is not how any Wireless network I=92ve= >> worked with is implemented. >>=20 >> Instead, multiple APs are connected with the same ESSID using >> bridging and/or other technologies on the wired side to provide this >> transitivity. >=20 > YEs but in some vehicular networks there is no wired side along the = road (although almost often there is a wired side inside each vehicle). >=20 > One could not imagine bridging a single 'wildcard' ESSID between the = outside of vehicles and throughout each distinct inside of vehicles. = Whereas yes, this ESSID could be bridged between each vehicle and the = wired side along the road (in the rare places where there are linked = Road-Side Units along road). Again, this is a tradeoff inherent in your particular design choices. It is yours to deal with and does not require the layer three protocol to make any special adaptation, rather, you must adapt either in your higher layers or in providing adequate compensating facilities in the lower layer network(s). >> In some cases, there are also wireless protocols that can be used to >> extend an ESSID wirelessly between two or more APs, but these are >> obviously suboptimal due to spectrum utilization for forwarding >> between the APs. >=20 > I agree. >=20 >> However, none of this is relevant to your situation because of your >> design decision to use OCB. >>=20 >>> But that is not my problem here. It is an IPv6-over-80211 problem >>> in the first place. And we dont have such an RFC. >>=20 >> Nor do we have an actual need for one as it is a problem which >> everyone so far solves at layer 2 using media adapters and bridging. >=20 > Not in WiFi. Yes, in WiFi=85 Most large ESSIDs are deployed with a lot of WAPs = bridged on to a common wired/fiber infrastructure. >=20 >>> My problem here is the scope for OCB-mode, which has no ESSID. >>=20 >> What is the problem? As you have mentioned, each user has a unique >> link scope. >=20 > But in Ethernet the scope is not relative to a particular user - it is = the scope of the wire if I can say so. Yes, but we are no longer talking about ethernet because you=92ve made a different design decision to not use Ethernet. So, as a result of your design decision, you have a very tenuous and constantly fluctuating definition of =93link=94 that you now have to accept as a tradeoff of = your particular design decision. >=20 >> If you don=92t like that, don=92t use OCB or don=92t use link scope = for >> your application(s). >=20 > That's not an option. In some vehicles 802.11-OCB is there built in. Then accept the tradeoffs of that decision and compensate accordingly or use something other than =93link scope=94 to scope your multicast = packets. >=20 >>>> I don't see why you would need to change the semantic of >>>> multicast addresses, in particular "all-nodes". It represents >>>> all nodes on the layer-2 link, and this set can always change >>>> over time (even in classical wired links, where nodes can come >>>> and go and bridges can fail). >>>=20 >>> Noted but non implementable. >>=20 >> Why not? >>=20 >>> The "all nodes" Group ID is defined to be able to live within link >>> scope (ff02::1), site scope (ff0X::1) and more other scopes. >>=20 >> Sure. Use the scope that best meets your needs. >>=20 >>> Nodes that come and go from link scopes can indeed be managed but >>> _only_ if we have a solid scope. >>=20 >> What do you mean by solid scope? If nodes are arriving and departing >> from the scope, by definition, it lacks solidity from at least one >> perspective on the term. >=20 > I meant a solid scope definition. >=20 > The scope itself should be more ephemeral. Hosts sending NS to that > scope would wait more than on a link scope before continuing. I would think you=92d want the exact opposite in most cases. After all, at 65MPH, assuming a ~500 foot radio range between vehicles, you=92re talking about 95 feet per second for a closure/departure rate of roughly 190 feet per second. Therefore, you have roughly 5 seconds of visibility for two cars approaching head on before they are out of range of each other. I would think that in an environment os such transient nature you would want to reduce delays rather than increase them. >=20 >>> In 802.11 there are no bridges (yes there are bridges between >>> 802.11 and 802.3 but not between different 802.11 ESSIDs). >>=20 >> Since you are not using ESSIDs to begin with, I=92m not sure how that >> is relevant. >=20 > Well in OCB there is one single 'wildcard' ESSID whose value is a = string > of all 1s (not to be confused with the all 1s MAC broadcast address). > So an ESSID bridge would link together all in that 'wildcard' ESSID. Again, I don=92t understand the relevance here. Owen >=20 > Alex >=20 >>=20 >> Owen >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Baptiste >>>>=20 >>>> [1] >>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.188.2437 >>>> [2] https://datatracker.ietf.org/wg/babel/documents/ >>>>=20 >>>>> Le 09/07/2016 =E0 05:12, Owen DeLong a =E9crit : >>>>>> I fail to see any reason that the mapping would be different >>>>>> in OCB vs. any other 802 style networking. >>>>>>=20 >>>>>> Owen >>>>>>=20 >>>>>>> On Jul 8, 2016, at 12:38 , Alexandre Petrescu >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> During our discussion of IPv6 and MAC address multicast I >>>>>>> laid down a few of comment results of the discussion on >>>>>>> this email list, on this Internet Draft referred to below. >>>>>>>=20 >>>>>>> In my oppinion there is obviously a need to clarify how >>>>>>> and what MAC multicast addresses to use below IPv6 in >>>>>>> IPv6-over-802.11OCB (Out of the Context of BSSID, aka >>>>>>> 802.11p). >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>> -------- Message transf=E9r=E9 -------- Sujet : [its] Fwd: I-D >>>>>>> Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : >>>>>>> Fri, 8 Jul 2016 21:33:53 +0200 De : Alexandre Petrescu >>>>>>> Pour : its@ietf.org >>>>>>> >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I have just submitted this Internet Draft I co-author with >>>>>>> Thierry Ernst. >>>>>>>=20 >>>>>>> The distinctive aspect is that it tries to suggest the way >>>>>>> MAC and IPv6 multicast is used on an IPv6-over-80211-OCB >>>>>>> links. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>=20 >>>>>>> -------- Message transf=E9r=E9 -------- Sujet : I-D Action: >>>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 >>>>>>> Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org >>>>>>> R=E9pondre =E0 : internet-drafts@ietf.org Pour : >>>>>>> i-d-announce@ietf.org >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : Transmission of IPv6 Packets over IEEE >>>>>>> 802.11-OCB Networks Authors : Thierry Ernst >>>>>>> Alexandre Petrescu Filename : >>>>>>> draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : >>>>>>> 2016-07-08 >>>>>>>=20 >>>>>>> Abstract: In this document the mapping of multicast IPv6 >>>>>>> addresses to MAC addresses of 802.11-OCB is proposed. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> = https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 > There's also a htmlized version available at: >>>>>>> = https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 >>>>>>>=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 >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>=20 >>>>>>> _______________________________________________ v6ops >>>>>>> mailing list v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>=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 --Apple-Mail=_99D4032A-5ADA-4F64-A6E1-997FF079575D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 19, 2016, at 09:54 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 14/07/2016 =E0 19:06, Owen DeLong a = =E9crit :
In terms = of reachability, these layer-2 links are generally not
transitive (and may not be symmetric either).

YEs.

There is some previous = work: MANET, "mesh-under" vs.
"route-over" architecture = [1], Babel [2].

YEs, but it is = not satisfactory in vehicular reasons for many other
reasons.

Basically, the sanest way is to define the scope of a link = as the
set of nodes reachable via radio broadcast. =  You then have to
deal with the fact that this set = will change over time (see Babel
for unicast dynamic = routing).

Such scope can make = sense, but it is still dependent on the user.

This is an inevitable consequence = of your design decision to use
OCB.

It is a wise decision in that OCB eliminates = much messages and noise
which may provoke interference. =  Interference is a risk in jams or high
relative speeds (e.g. = mobile to infra, or mobile crossing another
mobile, but not mobile = following a mobile).

That decision can not be = questioned.

Fair enough, but = like any other decision, it has tradeoffs. Now, you are
here = complaining about the tradeoffs inherent in that decision as if = it
is somehow up to the IETF and/or IEEE to contort network = standards to
address those inherent tradeoffs.

You=92ve chosen a networking mechanism with an = inherently amorphous definition
of link which is specific to = each node. That is what it is and all the 
continued = complaints about this will not change that nature. You = must
address these issues in your higher level protocols = because you have
made this choice.


There is a different scope for each user.

On another hand, a link scope in AP-mode or = ad-hoc mode is the
scope covering that ESSID: a link scope = is different for each ESSID
(not different for each = user).

That is a property = difference between OCB and ESSID modes of
operation. It = has nothing to do with IP or the IP concept of a link.

Well.

The ND operation is specified with the full = expectation that when an NS
is sent to the link-scope everybody in = that link is supposed to be
willing to reply.

But in WiFi-adhoc and in 802-11-OCB for = that matter, some hosts in link
scope will not even hear that = NS.

This is not normal.  And it is = unnormal because link scope is for wires,
not for 802.11-adhoc nor for = 802.11-OCB.

No, the ND is = sent with the expectation that everyone reachable (that = is,
everyone actually on link) will hear it. Since the ND is = sent to the
=93All Nodes On Link=94 multicast address, and the = definition of =93On Link=94
is based on the ability to hear = that packet, I think it is safe to take
that for = granted.

Your complaint isn=92t that = in 802.11-OCB some hosts in link scope
won=92t hear it. Your = complaint is that the host that was in link
scope 200 = milliseconds or even 20 milliseconds ago may not be on
link = now, but may again be on link 20 milliseconds later.

Again, this is a tradeoff you have chosen in your = decision to use
this particular networking = mechanism.

It does not change the = concept, definition, or properties of link-scope.
It simply = makes it damn inconvenient for you to use it because of = the
high rate of speed at which the definition of link-scope = changes in your
particular operating = environment.

The fact that within = AP-mode or ad-hoc mode link scope some hosts
can not see = each other (non transitivity: A sees B sees C doesnt
mean = A sees C) is commonly understood as a configuration problem:
one is not supposed to build networks with only one ESSID = bigger
than the WiFi radio range.

Or if one, does, one is expected = to provide transitivity between APs
sharing the same ESSID = to overcome this.

Such transitivity has never been provided = meaningfully, other than
duplicating packets in the air, which = means to generate more noise back
to the emitter.

Either over the air or over a wire, yes. This is true. = Those really are
the only two choices available.

Nonetheless, it has worked well in enough = installations that I feel
comfortable saying it is a useful = thing for many applications.

However, in OCB mode, you = don=92t have those facilities, so your link
is limited to = being different for east combination of station, time,
position, and relative position of other stations as well = as
propagation factors.

Look, not only OCB mode is = different than wires, but 802.11-adhoc is
also different in this respect.  You = can not single out OCB mode.

802.11-adhoc has = a somewhat different set of tradeoffs, but it is = generally
treated as a point-to-point link or = point-to-multipoint link from an
IPv6 perspective and this = generally works just fine.

Most = actual deployments of adhoc are done as point to point = anyway.

To solve this = non-transitivity problem in AP-mode or ad-hoc mode
one = should define an "ESSID scope" (not a link scope).  At that
point we talk about nodes in ESSID scope are agreed to be
non-transitive.  And routers to forward between link = scopes but
within same ESSID scope.

This is completely illogical and = is not how any Wireless network I=92ve
worked with is = implemented.

Instead, multiple APs are = connected with the same ESSID using
bridging and/or other = technologies on the wired side to provide this
transitivity.

YEs but in some vehicular = networks there is no wired side along the road (although almost often = there is a wired side inside each vehicle).

One could not imagine bridging a single = 'wildcard' ESSID between the outside of vehicles and throughout each = distinct inside of vehicles. Whereas yes, this ESSID could be bridged = between each vehicle and the wired side along the road (in the rare = places where there are linked Road-Side Units along road).

Again, this is a tradeoff inherent in your particular = design choices.
It is yours to deal with and does not require = the layer three protocol
to make any special adaptation, = rather, you must adapt either in your
higher layers or in = providing adequate compensating facilities in the
lower layer = network(s).

In some cases, there are also wireless protocols that can be = used to
extend an ESSID wirelessly between two or more = APs, but these are
obviously suboptimal due to spectrum = utilization for forwarding
between the APs.

I agree.

However, = none of this is relevant to your situation because of your
design decision to use OCB.

But that is not my = problem here.  It is an IPv6-over-80211 problem
in = the first place.  And we dont have such an RFC.

Nor do we have an actual need for = one as it is a problem which
everyone so far solves at = layer 2 using media adapters and bridging.

Not in WiFi.

Yes, in WiFi=85 Most large ESSIDs are deployed with a = lot of WAPs bridged
on to a common wired/fiber = infrastructure.


My problem here is the = scope for OCB-mode, which has no ESSID.

What is the problem? As you have mentioned, each user has a = unique
link scope.

But in Ethernet the scope = is not relative to a particular user - it is the scope of the wire if I = can say so.

Yes, but we are = no longer talking about ethernet because you=92ve made
a = different design decision to not use Ethernet. So, as a result = of
your design decision, you have a very tenuous and = constantly fluctuating
definition of =93link=94 that you now = have to accept as a tradeoff of your
particular design = decision.


If you don=92t like that, don=92t use OCB or don=92t use link = scope for
your application(s).

That's not an option.  In some vehicles = 802.11-OCB is there built in.

Then accept the = tradeoffs of that decision and compensate accordingly
or use = something other than =93link scope=94 to scope your multicast = packets.


I don't see why you would need to change the semantic of
multicast addresses, in particular "all-nodes".  It = represents
all nodes on the layer-2 link, and this set can = always change
over time (even in classical wired links, = where nodes can come
and go and bridges can fail).

Noted but non implementable.

Why not?

The "all nodes" Group ID = is defined to be able to live within link
scope (ff02::1), = site scope (ff0X::1) and more other scopes.
Sure. Use the scope that best meets your needs.

Nodes = that come and go from link scopes can indeed be managed but
_only_ if we have a solid scope.
What do you mean by solid scope? If nodes are arriving and = departing
from the scope, by definition, it lacks solidity = from at least one
perspective on the term.

I meant a solid scope definition.

The scope itself should be more = ephemeral.  Hosts sending NS to that
scope would wait more than on a link = scope before continuing.

I would think = you=92d want the exact opposite in most cases. After all,
at = 65MPH, assuming a ~500 foot radio range between vehicles, = you=92re
talking about 95 feet per second for a = closure/departure rate of
roughly 190 feet per second. = Therefore, you have roughly 5 seconds
of visibility for two = cars approaching head on before they are out
of range of each = other.

I would think that in an = environment os such transient nature you
would want to reduce = delays rather than increase them.


In 802.11 there are no bridges (yes there are = bridges between
802.11 and 802.3 but not between different = 802.11 ESSIDs).

Since you are = not using ESSIDs to begin with, I=92m not sure how that
is = relevant.

Well in OCB there is one single = 'wildcard' ESSID whose value is a string
of all 1s (not to be confused with the = all 1s MAC broadcast address).
So an ESSID bridge would link together = all in that 'wildcard' ESSID.

Again, I don=92t = understand the relevance here.

Owen


Alex


Owen


Alex


Baptiste

[1]
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.188.2= 437
[2] = https://datatracker.ietf.org/wg/babel/documents/

Le 09/07/2016 =E0 05:12, = Owen DeLong a =E9crit :
I fail to see any reason that the mapping would be = different
in OCB vs. any other 802 style networking.

Owen

On Jul 8, 2016, at 12:38 , Alexandre = Petrescu
<alexandre.petrescu@gmail.com> wrote:

Hi,

During our = discussion of IPv6 and MAC address multicast I
laid down a = few of comment results of the discussion on
this email = list, on this Internet Draft referred to below.

In my oppinion there is obviously a need to clarify how
and what MAC multicast addresses to use below IPv6 in
IPv6-over-802.11OCB (Out of the Context of BSSID, aka
802.11p).

Alex

-------- Message transf=E9r=E9 -------- Sujet : [its] Fwd: = I-D
Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date = :
Fri, 8 Jul 2016 21:33:53 +0200 De : Alexandre = Petrescu
<alexandre.petrescu@gmail.com> Pour : = its@ietf.org
<its@ietf.org>

Hi,

I have just submitted this = Internet Draft I co-author with
Thierry Ernst.

The distinctive aspect is that it tries to = suggest the way
MAC and IPv6 multicast is used on an = IPv6-over-80211-OCB
links.

Alex


-------- = Message transf=E9r=E9 -------- Sujet : I-D Action:
draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8
Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org
R=E9pondre =E0 : internet-drafts@ietf.org Pour :
i-d-announce@ietf.org


A New Internet-Draft is available from the on-line
Internet-Drafts directories.


Title =           : = Transmission of IPv6 Packets over IEEE
802.11-OCB Networks = Authors         : Thierry = Ernst
Alexandre Petrescu Filename =        :
draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date :
2016-07-08

Abstract: In this = document the mapping of multicast IPv6
addresses to MAC = addresses of 802.11-OCB is proposed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-8021= 1ocb/









There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-= 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/

_______________________________________________
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

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

_______________________________________________ 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

= --Apple-Mail=_99D4032A-5ADA-4F64-A6E1-997FF079575D-- From nobody Tue Jul 19 15:26:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A383A12D504 for ; Tue, 19 Jul 2016 15:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bbJmsQ4OdGRB for ; Tue, 19 Jul 2016 15:26:04 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 4C07412D1A5 for ; Tue, 19 Jul 2016 15:26:04 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id x130so45017273vkc.0 for ; Tue, 19 Jul 2016 15:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pSeEXc7yUWNHImgGPk4y3K6vt6U7/JjjlAvNV7vqSwg=; b=Kh/P+wMIsbm7pp7/AMdqJ+0O4G/weYJ4wU/Rt0ZNwHeMD/kYOvv1I57IX9ExOCLc5E r9jEiM+gDx+QViIugpVYgwg7MbRBNXeUj/G3dQUbSLjEqKWhEkPONrArdGGjNhBhOjYV 5BGUeW4cFRSurN8t/G9APrpUbMotI8aomfZkWtw99Nz7kzfboFmJZLs4XSvDsC13n75o kBfD+Tf37NsFbUuRvVklLB1pxTGbmA0KfpG7DJ2ozJHlMGdo9c+mHGS8KaeVtl+AZubd kASQ5adjxihCZZZQyH3PNqH9tjVsus8zRUhnzvkKgUCbiGu9UKYexR1LGxLP8HPmwEqw kAwA== 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:date :message-id:subject:from:to:cc; bh=pSeEXc7yUWNHImgGPk4y3K6vt6U7/JjjlAvNV7vqSwg=; b=bj7RcYfuFDFZKpUq7zMsY39s750OUXW8LAKqTuDMlLiINjW3RbfU1mlksHkS48Hv+d Q41Ldw5jBPdnT6JP4TRzcF429S+XR33SkdUgaluFYa8G7lPKppXOh26JEB8RtvqTvyP1 HFBMhyIT3ebw2jexL4VuhRH6qDaJkf2NQURz130KxWWzng+MbKgV1PXWAhSixZwXluSJ 7J7ASQqDawSfo1S0jjOnYpUzVjTeFN7++wr8Wd/7JldZBtUczrFNP/+u0mVTDQL2qSHB U/w1aa6EDt0BEGMBfJyJa/F/XQxkcgvpK3jcX5VHn4Z23txLDj6d1Nn1IyojsudzV2Lf N5xA== X-Gm-Message-State: ALyK8tIv2LutyftZVi7rLJOlK3tMwOgLHevojYGmbyo5LJMFu0+4s/byZIfYoUaGG+I1r9jcO8LRAIwhPP1ouw== MIME-Version: 1.0 X-Received: by 10.31.154.1 with SMTP id c1mr22466140vke.36.1468967163368; Tue, 19 Jul 2016 15:26:03 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:26:03 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:26:03 -0700 (PDT) In-Reply-To: References: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <578E4B94.2000507@isi.edu> Date: Wed, 20 Jul 2016 08:26:03 +1000 Message-ID: From: Mark Smith To: Joe Touch Content-Type: multipart/alternative; boundary=001a1142336ef5a61b0538049134 Archived-At: Cc: v6ops list Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:26:05 -0000 --001a1142336ef5a61b0538049134 Content-Type: text/plain; charset=UTF-8 On 20 Jul 2016 1:48 AM, "Joe Touch" wrote: > > > > On 7/18/2016 10:09 PM, Mark Smith wrote: > ... > > No specific to above, however related. > > > > I think it is better to avoid using generic "all node" IPv6 addresses > > if possible, and instead use a function specific multicast address. > > > > While I don't really like the layer violation, function specific IPv6 > > multicast addresses can more easily facilitate IPv6 packet filtering > > at layer 2, because the IPv6 addresses are in a fixed location in the > > frame, meaning the layer 2 device doesn't have to do as much > > frame/packet parsing to perform IPv6 packet filtering. > > > > For example, as All_DHCP_Relay_Agents_and_Servers in DHCPv6 has > > exclusive use of the FF02::1:2 multicast address, a simple way to > > implement DHCPv6 guard would be to prevent any packets to those > > multicast addresses being flooded to layer 2 device egress ports that > > are not configured as attached to link authorised DHCPv6 servers. > > > > RA Guard in part can be implemented that way - RSes are sent to the > > All Routers (FF01::2) multicast address, so the layer 2 device could > > control the flooding of those to only authorised ports attached to > > authorised routers. > > > > However, RAs are sent to the all nodes multicast address that isn't > > exclusive to all Router clients. > > There is already a multicast address for "all routers". > RAs from rogue routers are sent to the all nodes IPv6 multicast address. You can't block that address on layer 2 port ingress from non-router ports without breaking anything else that might legitimately use the all nodes IPv6 multicast address (off the top of my head, all nodes ping). However, if RAs were sent to a RA specific multicast group, then dropping on ingress based on that RA specific multicast destination address would only drop rogue RAs and nothing else. The current way to implement RA guard is to have to look deeper into the all nodes packet to see if it is an RA or not. Matching on a RA specific destination multicast address would be much simpler, and something I think that could be done in TCAM because of the exact match on and fixed location of the IPv6 DA in the frame. Regards, Mark. > > That means it wouldn't be possible to > > apply an ingress layer 2 port filter to drop RAs from rogue routers. > > Ideally, there would have been an "All router clients" specific > > multicast address > "all router clients" == "all hosts", which already has a multicast address. > > > instead that RAs were sent to, that could have > > facilitated ingress layer 2 filtering. (DHCPv6 doesn't have this > > problem because DHCPv6 servers and relays don't periodically announce > > themselves.) > > > > It is probably wasteful to use function specific multicast addresses > > for all functions/applications that somebody might want to filter in a > > layer 2 device, as they're in effect encoding upper layer identifiers > > such as UDP ports or ICMP types in addresses. Use of functional > > multicast addresses could be limited to fundamental IPv6 operations > > that might be typical of what people might want to filter in layer 2 > > devices. > > There are already quite a few of these. The key is that they are mapped > to *protocols* or *protocol node classes* (host/router). > > Joe --001a1142336ef5a61b0538049134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 20 Jul 2016 1:48 AM, "Joe Touch" <touch@isi.edu> wrote:
>
>
>
> On 7/18/2016 10:09 PM, Mark Smith wrote:
> ...
> > No specific to above, however related.
> >
> > I think it is better to avoid using generic "all node" = IPv6 addresses
> > if possible, and instead use a function specific multicast addres= s.
> >
> > While I don't really like the layer violation, function speci= fic IPv6
> > multicast addresses can more easily facilitate IPv6 packet filter= ing
> > at layer 2, because the IPv6 addresses are in a fixed location in= the
> > frame, meaning the layer 2 device doesn't have to do as much<= br> > > frame/packet parsing to perform IPv6 packet filtering.
> >
> > For=C2=A0 example, as All_DHCP_Relay_Agents_and_Servers in DHCPv6= has
> > exclusive use of the FF02::1:2 multicast address, a simple way to=
> > implement DHCPv6 guard would be to prevent any packets to those > > multicast addresses being flooded to layer 2 device egress ports = that
> > are not configured as attached to link authorised DHCPv6 servers.=
> >
> > RA Guard in part can be implemented that way - RSes are sent to t= he
> > All Routers (FF01::2) multicast address, so the layer 2 device co= uld
> > control the flooding of those to only authorised ports attached t= o
> > authorised routers.
> >
> > However, RAs are sent to the all nodes multicast address that isn= 't
> > exclusive to all Router clients.
>
> There is already a multicast address for "all routers".
>

RAs from rogue routers are sent to the all nodes IPv6 multic= ast address. You can't block that address on layer 2 port ingress from = non-router ports without breaking anything else that might legitimately use= the all nodes IPv6 multicast address (off the top of my head, all nodes pi= ng).

However, if RAs were sent to a RA specific multicast group, = then dropping on ingress based on that RA specific multicast destination ad= dress would only drop rogue RAs and nothing else.

The current way to implement RA guard is to have to look dee= per into the all nodes packet to see if it is an RA or not. Matching on a R= A specific destination multicast address would be much simpler, and somethi= ng I think that could be done in TCAM because of the exact match on and fix= ed location of the IPv6 DA in the frame.

Regards,
Mark.

> >=C2=A0 That means it wouldn't be possible to > > apply an ingress layer 2 port filter to drop RAs from rogue route= rs.
> > Ideally, there would have been an "All router clients" = specific
> > multicast address
> "all router clients" =3D=3D "all hosts", which alr= eady has a multicast address.
>
> > instead that RAs were sent to, that could have
> > facilitated ingress layer 2 filtering. (DHCPv6 doesn't have t= his
> > problem because DHCPv6 servers and relays don't periodically = announce
> > themselves.)
> >
> > It is probably wasteful to use function specific multicast addres= ses
> > for all functions/applications that somebody might want to filter= in a
> > layer 2 device, as they're in effect encoding upper layer ide= ntifiers
> > such as UDP ports or ICMP types in addresses. Use of functional > > multicast addresses could be limited to fundamental IPv6 operatio= ns
> > that might be typical of what people might want to filter in laye= r 2
> > devices.
>
> There are already quite a few of these. The key is that they are mappe= d
> to *protocols* or *protocol node classes* (host/router).
>
> Joe

--001a1142336ef5a61b0538049134-- From nobody Wed Jul 20 01:58:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAD412B061 for ; Wed, 20 Jul 2016 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 mka_xFkY_kwF for ; Wed, 20 Jul 2016 01:58:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C746112D9D1 for ; Wed, 20 Jul 2016 01:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=880; q=dns/txt; s=iport; t=1469005079; x=1470214679; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FO0sZoV89swprZwhUf4f8hUgP25NUIUJyoxbGxYmWw0=; b=IpvbeP0U2XxI/NYhMciqxWGbveb9qcKyAr4CDnSYhPZhXfFaId7ThvaE t9Wt4+zRZ65X5kdiDqUuOzpB8auJC2auFZxTNJn8InMO6Dyjw+TLN3gur Nrv0bmt3XIdRptcF9e8lqe2Y6TpKxcxbvop8rH6dse2aBjs722Y4kRi1F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAgBxPI9X/4UNJK1dgz9WfAa4aYF6I?= =?us-ascii?q?oV4AhyBGTgUAQEBAQEBAWUnQQ4BhA0BBQEBIRE6CxACAQgOCgICJgICAiULFRA?= =?us-ascii?q?CBA4FiDAOr06NdQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFKYRNhBIRARwXg?= =?us-ascii?q?mqCWgWZJgGOYYFVjWOQHwEeNoNzboJog1M2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="127986062" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 08:57:58 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6K8vwvj022200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 08:57:59 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 04:57:57 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 04:57:58 -0400 From: "Eric Vyncke (evyncke)" To: Mikael Abrahamsson , "Howard, Lee" Thread-Topic: [v6ops] meeting help Thread-Index: AQHR4bT0no9AsIzjnkq3RnkPhtUXxaAgF2eAgAFTeIA= Date: Wed, 20 Jul 2016 08:57:58 +0000 Message-ID: References: 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.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.165.92] Content-Type: text/plain; charset="utf-8" Content-ID: <1EDB17377C8D47428CFBEE0212534EFD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 'IPv6 Operations' Subject: Re: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:58:15 -0000 SSBjb3VsZCBkbyB0aGUgbWludXRlIHRha2VyIChidXQgYW5vdGhlciBtaW51dGUgdGFrZXIgaXMg cHJvYmFibHkgcmVxdWlyZWQNCmFzIHdlbGwpDQoNCi3DqXJpYw0KDQoNCk9uIDE5LzA3LzE2IDE2 OjQzLCAidjZvcHMgb24gYmVoYWxmIG9mIE1pa2FlbCBBYnJhaGFtc3NvbiINCjx2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzd21pa2VAc3dtLnBwLnNlPiB3cm90ZToNCg0KPk9u IFR1ZSwgMTkgSnVsIDIwMTYsIEhvd2FyZCwgTGVlIHdyb3RlOg0KPg0KPj4gV2UncmUgbG9va2lu ZyBmb3Igdm9sdW50ZWVycyB0byB0YWtlIG1pbnV0ZXMgYW5kIGphYmJlciBzY3JpYmUuDQo+PiBJ dCdzIGEgc2hvcnQgYWdlbmRhLCBzbyBpdCBzaG91bGRuJ3QgYmUgdG9vIGhhcmQuDQo+Pg0KPj4g QW55IHZvbHVudGVlcnM/DQo+DQo+SSBjYW4gZG8gamFiYmVyIHNjcmliZS4NCj4NCj4tLSANCj5N aWthZWwgQWJyYWhhbXNzb24gICAgZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcg bGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQo= From nobody Wed Jul 20 02:59:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840DD12B01C for ; Wed, 20 Jul 2016 02:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 L_YGEmVmhmSt for ; Wed, 20 Jul 2016 02:59:23 -0700 (PDT) Received: from atl4mhob18.myregisteredsite.com (atl4mhob18.myregisteredsite.com [209.17.115.111]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2E12D801 for ; Wed, 20 Jul 2016 02:59:23 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob18.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u6K9xK2W024703 for ; Wed, 20 Jul 2016 05:59:20 -0400 Received: (qmail 7731 invoked by uid 0); 20 Jul 2016 09:59:20 -0000 X-TCPREMOTEIP: 31.133.177.200 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.177.200?) (lee@asgard.org@31.133.177.200) by 0 with ESMTPA; 20 Jul 2016 09:59:20 -0000 User-Agent: Microsoft-MacOutlook/0.0.0.150911 Date: Wed, 20 Jul 2016 05:39:09 -0400 From: Time Warner Cable To: "Eric Vyncke (evyncke)" , Mikael Abrahamsson , "Howard, Lee" Message-ID: <567EC48F-2283-4BDF-A372-CBA32B313245@asgard.org> Thread-Topic: [v6ops] meeting help References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: 'IPv6 Operations' Subject: Re: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 09:59:25 -0000 Thank you both! Backup minute taker still sought. Lee On 7/20/16, 4:57 AM, "v6ops on behalf of Eric Vyncke (evyncke)" wrote: >I could do the minute taker (but another minute taker is probably required >as well) > >-=C3=A9ric > > >On 19/07/16 16:43, "v6ops on behalf of Mikael Abrahamsson" > wrote: > >>On Tue, 19 Jul 2016, Howard, Lee wrote: >> >>> We're looking for volunteers to take minutes and jabber scribe. >>> It's a short agenda, so it shouldn't be too hard. >>> >>> Any volunteers? >> >>I can do jabber scribe. >> >>--=20 >>Mikael Abrahamsson email: swmike@swm.pp.se >> >>_______________________________________________ >>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 Wed Jul 20 03:08:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF012D129 for ; Wed, 20 Jul 2016 03:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 33DRfeAF-fxR for ; Wed, 20 Jul 2016 03:08:15 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 6CF1712D12B for ; Wed, 20 Jul 2016 03:08:15 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id n129so16850057vke.3 for ; Wed, 20 Jul 2016 03:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pdr3ybj/lokyEMDSQwoMjM5GRj3ccoNly3nyhog00FU=; b=PcF3JGn2fd90kOWjdB8xtFTwuZi4G+alC/lALv+IOex0ZqYZIZuPU7kFVX3nOv/WPW WtUxy3iwoFKV4UAEhVvguX9IsrsaqlYr77QdUyWUlcywBe2pM4FA1Zr44XZZalobmLhh wVrdAjLhJjykEQZX2h5S3xCufTEadmG/GxOuzFy1WapIYa9uWjk6IPqKc89stiME7WFY fiMZ+lK9w0RbYyYd+h1i0yG/ywYQi60TcfBR+pFQZeW3xoTLBSYZJupCsGyBPSufDfll /iE2B3RwjcbP/yW2sQ2FYJwHiINVEAfNAdcyKSLNPbnlsppY79m8kVtSsQaG/nuC57e1 fVdA== 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; bh=pdr3ybj/lokyEMDSQwoMjM5GRj3ccoNly3nyhog00FU=; b=J+PG0q/FV+rDwOav2m+0cMYbtNY6S9n++8nlKQSuX5VESe/RVZRAtUBsO61VMMMzQX MY9YD5MVxqSLpiy+UKvEgLtb0HF8MyblUqlefIZmfzO4bHaxJV2CyDyDA2PCs2nrHvVH nYfBcDYOSsXYZGkdtHImDMXsPUsus0T4TdG/7ZWoLSjjvr0xxx57saW967EANphQaQgt gfNi21M8lD8c1w6OjrEpmy8w4cOkzlLCY6xTfqqWuR12YozkEVF8jQ4hiEPVEi7SBR0z lxQ9N/dApndMOgL4GPrstPF4sUzSoUCA6Ji13P4CybiOttnd/TJ+9qvV4nplCCEaCMJr Nk6g== X-Gm-Message-State: ALyK8tIMih4E9SygH3OiaKbhHiP8S1cscrA0T9xV97/yjUxjCpTRJTjVYWAx1Z+4d4w03YcmvS6iPduWT1vMoA== X-Received: by 10.31.254.4 with SMTP id l4mr784010vki.34.1469009294554; Wed, 20 Jul 2016 03:08:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.83 with HTTP; Wed, 20 Jul 2016 03:08:14 -0700 (PDT) In-Reply-To: <567EC48F-2283-4BDF-A372-CBA32B313245@asgard.org> References: <567EC48F-2283-4BDF-A372-CBA32B313245@asgard.org> From: Musa Stephen Honlue Date: Wed, 20 Jul 2016 12:08:14 +0200 Message-ID: To: Time Warner Cable Content-Type: multipart/alternative; boundary=94eb2c149e562c7c8b05380e6108 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:08:17 -0000 --94eb2c149e562c7c8b05380e6108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am very bad at minutes but I will provide my support. Regards. 2016-07-20 11:39 GMT+02:00 Time Warner Cable : > Thank you both! > > Backup minute taker still sought. > > Lee > > > > > On 7/20/16, 4:57 AM, "v6ops on behalf of Eric Vyncke (evyncke)" < > v6ops-bounces@ietf.org on behalf of evyncke@cisco.com> wrote: > > >I could do the minute taker (but another minute taker is probably requir= ed > >as well) > > > >-=C3=A9ric > > > > > >On 19/07/16 16:43, "v6ops on behalf of Mikael Abrahamsson" > > wrote: > > > >>On Tue, 19 Jul 2016, Howard, Lee wrote: > >> > >>> We're looking for volunteers to take minutes and jabber scribe. > >>> It's a short agenda, so it shouldn't be too hard. > >>> > >>> Any volunteers? > >> > >>I can do jabber scribe. > >> > >>-- > >>Mikael Abrahamsson email: swmike@swm.pp.se > >> > >>_______________________________________________ > >>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 > --94eb2c149e562c7c8b05380e6108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am very bad at minutes but I will provide my suppor= t.
Regards.

2016-07-20 11:39 GMT+02:00 Time Warner Cable <= ;Lee@asgard.org>= :
Thank you both!

Backup minute taker still sought.

Lee




On 7/20/16, 4:57 AM, "v6ops on behalf of Eric Vyncke (evyncke)" &= lt;v6ops-bounces@ietf.org on = behalf of evyncke@cisco.com> wr= ote:

>I could do the minute taker (but another minute taker is probably requi= red
>as well)
>
>-=C3=A9ric
>
>
>On 19/07/16 16:43, "v6ops on behalf of Mikael Abrahamsson" ><v6ops-bounces@ietf.org on behalf of swmike@swm.pp.se>= wrote:
>
>>On Tue, 19 Jul 2016, Howard, Lee wrote:
>>
>>> We're looking for volunteers to take minutes and jabber sc= ribe.
>>> It's a short agenda, so it shouldn't be too hard.
>>>
>>> Any volunteers?
>>
>>I can do jabber scribe.
>>
>>--
>>Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>>
>>_______________________________________________
>>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

--94eb2c149e562c7c8b05380e6108-- From nobody Wed Jul 20 03:11:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6D412D58E for ; Wed, 20 Jul 2016 03:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 GPCLCB_wQJ4V for ; Wed, 20 Jul 2016 03:10:57 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 61F4412DB30 for ; Wed, 20 Jul 2016 03:10:21 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bPoSI-0007P6-3R; Wed, 20 Jul 2016 12:10:19 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::53]) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bPoSH-0003HW-T1; Wed, 20 Jul 2016 12:10:17 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_825BDF8B-A02B-4CD0-B472-20C768E19C8B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nathalie Trenaman In-Reply-To: Date: Wed, 20 Jul 2016 12:10:17 +0200 Message-Id: <9AAB527B-5502-4A2B-9ABC-7CEECC736888@ripe.net> References: <567EC48F-2283-4BDF-A372-CBA32B313245@asgard.org> To: Musa Stephen Honlue X-Mailer: Apple Mail (2.3112) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a3434c5763a06d86d3647041d0402c22f Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] meeting help X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:10:59 -0000 --Apple-Mail=_825BDF8B-A02B-4CD0-B472-20C768E19C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will also help out in the etherpad.=20 Nathalie=20 > On 20 Jul 2016, at 12:08, Musa Stephen Honlue = wrote: >=20 > I am very bad at minutes but I will provide my support. > Regards. >=20 > 2016-07-20 11:39 GMT+02:00 Time Warner Cable >: > Thank you both! >=20 > Backup minute taker still sought. >=20 > Lee >=20 >=20 >=20 >=20 > On 7/20/16, 4:57 AM, "v6ops on behalf of Eric Vyncke (evyncke)" = on behalf of = evyncke@cisco.com > wrote: >=20 > >I could do the minute taker (but another minute taker is probably = required > >as well) > > > >-=C3=A9ric > > > > > >On 19/07/16 16:43, "v6ops on behalf of Mikael Abrahamsson" > > on behalf of = swmike@swm.pp.se > wrote: > > > >>On Tue, 19 Jul 2016, Howard, Lee wrote: > >> > >>> We're looking for volunteers to take minutes and jabber scribe. > >>> It's a short agenda, so it shouldn't be too hard. > >>> > >>> Any volunteers? > >> > >>I can do jabber scribe. > >> > >>-- > >>Mikael Abrahamsson email: swmike@swm.pp.se = > >> > >>_______________________________________________ > >>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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_825BDF8B-A02B-4CD0-B472-20C768E19C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I will also help out in the = etherpad. 

Nathalie 

On 20 Jul 2016, at 12:08, Musa Stephen Honlue <honlue@gmail.com> = wrote:

I am very bad at minutes but I = will provide my support.
Regards.

2016-07-20= 11:39 GMT+02:00 Time Warner Cable <Lee@asgard.org>:
Thank you both!

Backup minute taker still sought.

Lee




On 7/20/16, 4:57 AM, "v6ops on behalf of Eric Vyncke (evyncke)" <v6ops-bounces@ietf.org on behalf of evyncke@cisco.com> = wrote:

>I could do the minute taker (but another minute taker is probably = required
>as well)
>
>-=C3=A9ric
>
>
>On 19/07/16 16:43, "v6ops on behalf of Mikael Abrahamsson"
><v6ops-bounces@ietf.org on behalf of swmike@swm.pp.se> = wrote:
>
>>On Tue, 19 Jul 2016, Howard, Lee wrote:
>>
>>> We're looking for volunteers to take minutes and jabber = scribe.
>>> It's a short agenda, so it shouldn't be too hard.
>>>
>>> Any volunteers?
>>
>>I can do jabber scribe.
>>
>>--
>>Mikael Abrahamsson    email: swmike@swm.pp.se
>>
>>_______________________________________________
>>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

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

= --Apple-Mail=_825BDF8B-A02B-4CD0-B472-20C768E19C8B-- From nobody Wed Jul 20 04:46:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F8812D1D0 for ; Wed, 20 Jul 2016 04:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 CuiXgGvvu18H for ; Wed, 20 Jul 2016 04:46:20 -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 DDD4A12B01B for ; Wed, 20 Jul 2016 04:46:19 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BA57C6069D for ; Wed, 20 Jul 2016 13:46:16 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8694060278; Wed, 20 Jul 2016 13:46:16 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 75F2633909; Wed, 20 Jul 2016 13:46:16 +0200 (CEST) Date: Wed, 20 Jul 2016 13:46:16 +0200 From: Gert Doering To: Mark Smith Message-ID: <20160720114616.GU79185@Space.Net> References: <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <578E4B94.2000507@isi.edu> 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.6.1 (2016-04-27) Archived-At: Cc: v6ops list Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:46:22 -0000 Hi, On Wed, Jul 20, 2016 at 08:26:03AM +1000, Mark Smith wrote: > RAs from rogue routers are sent to the all nodes IPv6 multicast address. > You can't block that address on layer 2 port ingress from non-router ports > without breaking anything else that might legitimately use the all nodes > IPv6 multicast address (off the top of my head, all nodes ping). > > However, if RAs were sent to a RA specific multicast group, then dropping > on ingress based on that RA specific multicast destination address would > only drop rogue RAs and nothing else. > > The current way to implement RA guard is to have to look deeper into the > all nodes packet to see if it is an RA or not. Matching on a RA specific > destination multicast address would be much simpler, and something I think > that could be done in TCAM because of the exact match on and fixed location > of the IPv6 DA in the frame. While I like that idea, it would also only work if target hosts would refuse to accept a RA that is not destined to this "all-RA-clients" multicast address. How well such assumptions work can be seen with the recent router ND issue where routers happily received and processed ND packets with TTL != 255, in violation of the standards, and the fe80:: issue where routers happily forward fe80::-sourced packets... 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 Jul 20 05:05:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B212B059 for ; Wed, 20 Jul 2016 05:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 utWsnoQHPyK9 for ; Wed, 20 Jul 2016 05:05:29 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 4F74012D596 for ; Wed, 20 Jul 2016 05:05:23 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s189so65543143vkh.1 for ; Wed, 20 Jul 2016 05:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2jhn4pr2u78n0Mvz7fUIDbdCE385HaczdrXw0MuvoBw=; b=rr7hIdNqBASE4YmklKXPqDVcPLQ71S0t747WIRIas0L8DchGrUQcIOT5DMs//h2h+N SAzpH99nnTU6PMcNDl7SwXZ0SzDOHSTOCBHPAmRtMD4+cHn49E9oVw3/E+l1/65J6SC4 VfMxRgK2Z+g6z8cgoD1bW+d4KPWwwshHsJNz7BtM8Mxe0OXnkR5Z4SKE+oKksqBBUqgB NZMM+zTu3w3NBDrpPTgH5dUkKldTbpru4+G9Pvc/9q/YxCa1oEjDLyWsMkYrqYC2DKtI 8Cgmt36IGbw2oRoukVxS7jY0mvktR1Y8rRnWm5xKO0CfqLuqYwEUf0ylUDZ2wag4LQhV sTMQ== 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:date :message-id:subject:from:to:cc; bh=2jhn4pr2u78n0Mvz7fUIDbdCE385HaczdrXw0MuvoBw=; b=deoJi4GoWINJKqQHsUJ1LM857Kh78Zcb8AYlAp5x77D1xe0f7GWgzcN4DGVTLx/ur/ 7ustmV3IT6b8u+t6xzMfXdvh6E53MTgp71GY4v4a7Q5ik3Xy2O9ErH4nYrl+xHbDNaq1 /i2PJCILWITVt7wvBk3lmlu1oMN+0U2yh5lxRm6IfL3XuV1x+oYhq5uh4Knzge5r3Bjf EBmHSGi9rbi5pxJXEHLNihWS+AZEt+5KATnIEYh4gg7vOZhUW3EE0+WWXh4wI7DiEDnU blMPDEiElOvUcZOg2n4gWui8U6pjGAOEGjXchJXYhdchLHX7EsiiHNvvcBA+xBzJtkUX xRUw== X-Gm-Message-State: ALyK8tK7lMW5J83yKoOgY6Z17KlVvz1YAoTcnej1UPCW72TMG18A1pXMgZdugMbwdNvQwvZZjNZN8tzBQQDOVQ== MIME-Version: 1.0 X-Received: by 10.31.220.66 with SMTP id t63mr22571127vkg.113.1469016322403; Wed, 20 Jul 2016 05:05:22 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Wed, 20 Jul 2016 05:05:22 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Wed, 20 Jul 2016 05:05:22 -0700 (PDT) In-Reply-To: <20160720114616.GU79185@Space.Net> References: <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <578E4B94.2000507@isi.edu> <20160720114616.GU79185@Space.Net> Date: Wed, 20 Jul 2016 22:05:22 +1000 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=94eb2c07ad3c10f1cf05381004c7 Archived-At: Cc: v6ops list Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:05:31 -0000 --94eb2c07ad3c10f1cf05381004c7 Content-Type: text/plain; charset=UTF-8 On 20 Jul 2016 9:16 PM, "Gert Doering" wrote: > > Hi, > > On Wed, Jul 20, 2016 at 08:26:03AM +1000, Mark Smith wrote: > > RAs from rogue routers are sent to the all nodes IPv6 multicast address. > > You can't block that address on layer 2 port ingress from non-router ports > > without breaking anything else that might legitimately use the all nodes > > IPv6 multicast address (off the top of my head, all nodes ping). > > > > However, if RAs were sent to a RA specific multicast group, then dropping > > on ingress based on that RA specific multicast destination address would > > only drop rogue RAs and nothing else. > > > > The current way to implement RA guard is to have to look deeper into the > > all nodes packet to see if it is an RA or not. Matching on a RA specific > > destination multicast address would be much simpler, and something I think > > that could be done in TCAM because of the exact match on and fixed location > > of the IPv6 DA in the frame. > > While I like that idea, it would also only work if target hosts would > refuse to accept a RA that is not destined to this "all-RA-clients" > multicast address. > Sure. I'm not saying it is feasible to implement now with RAs, more using it as an example of a limitation of using the all nodes multi address. So if something is being invented where multicasting to all nodes is performed, I think it is worth considering and perhaps preferring a function specific multicast address instead so that specific filtering or classification by just using the destination multicast address can be performed. Regards, Mark. > How well such assumptions work can be seen with the recent router ND issue > where routers happily received and processed ND packets with TTL != 255, in > violation of the standards, and the fe80:: issue where routers happily > forward fe80::-sourced packets... > > 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 --94eb2c07ad3c10f1cf05381004c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 20 Jul 2016 9:16 PM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Wed, Jul 20, 2016 at 08:26:03AM +1000, Mark Smith wrote:
> > RAs from rogue routers are sent to the all nodes IPv6 multicast a= ddress.
> > You can't block that address on layer 2 port ingress from non= -router ports
> > without breaking anything else that might legitimately use the al= l nodes
> > IPv6 multicast address (off the top of my head, all nodes ping).<= br> > >
> > However, if RAs were sent to a RA specific multicast group, then = dropping
> > on ingress based on that RA specific multicast destination addres= s would
> > only drop rogue RAs and nothing else.
> >
> > The current way to implement RA guard is to have to look deeper i= nto the
> > all nodes packet to see if it is an RA or not. Matching on a RA s= pecific
> > destination multicast address would be much simpler, and somethin= g I think
> > that could be done in TCAM because of the exact match on and fixe= d location
> > of the IPv6 DA in the frame.
>
> While I like that idea, it would also only work if target hosts would<= br> > refuse to accept a RA that is not destined to this "all-RA-client= s"
> multicast address.
>

Sure. I'm not saying it is feasible to implement now wit= h RAs, more using it as an example of a limitation of using the all nodes m= ulti address.

So if something is being invented where multicasting to all = nodes is performed, I think it is worth considering and perhaps preferring = a function specific multicast address instead so that specific filtering or= classification by just using the destination multicast address can be perf= ormed.

Regards,
Mark.

> How well such assumptions work can be seen with the rec= ent router ND issue
> where routers happily received and processed ND packets with TTL !=3D = 255, in
> violation of the standards, and the fe80:: issue where routers happily=
> forward fe80::-sourced packets...
>
> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> 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 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279

--94eb2c07ad3c10f1cf05381004c7-- From nobody Wed Jul 20 05:17:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA912DBC5; Wed, 20 Jul 2016 05:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Mksc83a2Ctoj; Wed, 20 Jul 2016 05:17:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F1112D57B; Wed, 20 Jul 2016 05:17:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC0C2B80EDC; Wed, 20 Jul 2016 05:17:07 -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: <20160720121707.CC0C2B80EDC@rfc-editor.org> Date: Wed, 20 Jul 2016 05:17:07 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] BCP 204, RFC 7934 on Host Address Availability Recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:17:09 -0000 A new Request for Comments is now available in online RFC libraries. BCP 204 RFC 7934 Title: Host Address Availability Recommendations Author: L. Colitti, V. Cerf, S. Cheshire, D. Schinazi Status: Best Current Practice Stream: IETF Date: July 2016 Mailbox: lorenzo@google.com, vint@google.com, cheshire@apple.com, dschinazi@apple.com Pages: 15 Characters: 37124 See Also: BCP 204 I-D Tag: draft-ietf-v6ops-host-addr-availability-07.txt URL: https://www.rfc-editor.org/info/rfc7934 DOI: http://dx.doi.org/10.17487/RFC7934 This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so. 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/retrieve/bulk 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 Wed Jul 20 05:55:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168D12D5BD; Wed, 20 Jul 2016 05:55:08 -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 autolearn_force=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 0ZdNgMzVKdt4; Wed, 20 Jul 2016 05:55:04 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 8CBF012D611; Wed, 20 Jul 2016 05:55:04 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bPr1e-000Gou-NJ; Wed, 20 Jul 2016 14:55:00 +0200 Date: Wed, 20 Jul 2016 14:54:58 +0200 From: David Lamparter To: "v6ops@ietf.org" , homenet Message-ID: <20160720125458.GO255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline In-Reply-To: <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Jen Linkova , Chris Bowers Subject: [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:55:08 -0000 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As mentioned on mic during rtgwg, I think the idea of affecting host source address selection through 6724 rule 5.5 is potentially very useful and IMHO should be explored. Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached to this mail. I've been able to gleam a little more detail on the idea: - it's a bit unclear how an address/prefix's "source" next-hop is kept in association. The simplistic approach of adding a "PA source ipv6 address" for each of a host's configured addresses falls flat when more than 1 router advertises the same prefix, so I implemented it as a list -- however, my hack never removes entries off that. It should possibly have a copy of the PA's valid time? (Read as: the "Discussion" note in 6724 is right on the mark - the details are not quite specified.) - in that avenue, I don't think it's possible to store the information in a route-centric way, because RA lifetimes tend to be shorter. If a router goes away and comes back, it seems to me that the prefix's associated origin/nexthop should still be there. - rule 5.5 makes RA preference carry into source address selection. I think this is described in the draft, I just failed to grasp that from the presentation. Very useful for getting source selection right in the face of unequal performance uplinks. - if you want to manage this in an userspace process on Linux, you can simply update the route's preferred source attribute. The attached patchset also has the following caveats that result from me just doing a quick hack: - there is no debugging/user visibility of the value - as mentioned above, tracked source addresses never go away unless the entire address dies. It caps at 4 sources (so you can't exhaust kernel memory by spoofing...) - I should probably pass Linux's "dst" instead of "rt6_info" - I didn't check for locking/concurrentness violations - there's a const warning which I ignored. Either way if anyone wants to tinker with it, here it is. No warranties, YMMV. You touch it, it becomes your responsibility ;) Cheers, -David On Wed, Jul 06, 2016 at 04:33:18PM +0000, Fred Baker (fred) wrote: > At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. > > > Begin forwarded message: > > > > From: > > Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > > Date: July 5, 2016 at 5:58:25 PM PDT > > To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" > > > > > > A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > > has been successfully submitted by Fred Baker and posted to the > > IETF repository. > > > > Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming > > Revision: 00 > > Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution > > Document date: 2016-07-05 > > Group: Individual Submission > > Pages: 44 > > URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > > Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ > > Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 > > > > > > Abstract: > > Connecting an enterprise site to multiple ISPs using provider- > > assigned addresses is difficult without the use of some form of > > Network Address Translation (NAT). Much has been written on this > > topic over the last 10 to 15 years, but it still remains a problem > > without a clearly defined or widely implemented solution. Any > > multihoming solution without NAT requires hosts at the site to have > > addresses from each ISP and to select the egress ISP by selecting a > > source address for outgoing packets. It also requires routers at the > > site to take into account those source addresses when forwarding > > packets out towards the ISPs. > > > > This document attempts to define a complete solution to this problem. > > It covers the behavior of routers to forward traffic taking into > > account source address, and it covers the behavior of host to select > > appropriate source addresses. It also covers any possible role that > > routers might play in providing information to hosts to help them > > select appropriate source addresses. In the process of exploring > > potential solutions, this documents also makes explicit requirements > > for how the solution would be expected to behave from the perspective > > of an enterprise site network administrator . > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --L6iaP+gRLNZHKoI4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-net-ipv6-track-autoconfigured-address-origin.patch" >From 2d1bf126d3e776deabcab4ef8b6f941636b8bc67 Mon Sep 17 00:00:00 2001 From: David Lamparter Date: Wed, 20 Jul 2016 10:37:54 +0200 Subject: [PATCH 1/3] net/ipv6: track autoconfigured address' origin --- include/net/addrconf.h | 3 ++- include/net/if_inet6.h | 11 +++++++++++ net/ipv6/addrconf.c | 15 ++++++++++++++- net/ipv6/ndisc.c | 3 ++- 4 files changed, 29 insertions(+), 3 deletions(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 47f52d3..33f2652 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -226,7 +226,8 @@ static inline bool ipv6_is_mld(struct sk_buff *skb, int nexthdr, int offset) } void addrconf_prefix_rcv(struct net_device *dev, - u8 *opt, int len, bool sllao); + u8 *opt, int len, bool sllao, + const struct in6_addr *source); /* * anycast prototypes (anycast.c) diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h index 1c8b682..f79faa9 100644 --- a/include/net/if_inet6.h +++ b/include/net/if_inet6.h @@ -38,6 +38,14 @@ enum { INET6_IFADDR_STATE_DEAD, }; +/* for RFC6724 rule 5.5, we want to know what router advertised a prefix; + * however, there may be multiple such routers, so it needs to be a list. + * (think redundant default gateways) + * + * to prevent spoofed packets filling memory - and to keep this simple - + * this is a fixed-size list. */ +#define INET6_IFADDR_ORIGINRTR_MAX 4 + struct inet6_ifaddr { struct in6_addr addr; __u32 prefix_len; @@ -75,6 +83,9 @@ struct inet6_ifaddr { struct rcu_head rcu; struct in6_addr peer_addr; + + size_t origin_rtr_count; + struct in6_addr origin_rtr[INET6_IFADDR_ORIGINRTR_MAX]; }; struct ip6_sf_socklist { diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index fd065f2..f148278 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2338,7 +2338,19 @@ static bool is_addr_mode_generate_stable(struct inet6_dev *idev) idev->addr_gen_mode == IN6_ADDR_GEN_MODE_RANDOM; } -void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len, bool sllao) +static void addr_register_origin(struct inet6_ifaddr *addr, + const struct in6_addr *rtr) +{ + if (!rtr) + return; + if (addr->origin_rtr_count == ARRAY_SIZE(addr->origin_rtr)) + return; + addr->origin_rtr[addr->origin_rtr_count] = *rtr; + addr->origin_rtr_count++; +} + +void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len, bool sllao, + const struct in6_addr *source) { struct prefix_info *pinfo; __u32 valid_lft; @@ -2556,6 +2568,7 @@ ok: in6_ifa_put(ifp); addrconf_verify(); } + addr_register_origin(ifp, source); } inet6_prefix_notify(RTM_NEWPREFIX, in6_dev, pinfo); in6_dev_put(in6_dev); diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c index 84afb9a..b298da6 100644 --- a/net/ipv6/ndisc.c +++ b/net/ipv6/ndisc.c @@ -1385,7 +1385,8 @@ skip_routeinfo: p = ndisc_next_option(p, ndopts.nd_opts_pi_end)) { addrconf_prefix_rcv(skb->dev, (u8 *)p, (p->nd_opt_len) << 3, - ndopts.nd_opts_src_lladdr != NULL); + ndopts.nd_opts_src_lladdr != NULL, + &ipv6_hdr(skb)->saddr); } } -- 2.7.3 --L6iaP+gRLNZHKoI4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-net-ipv6-add-ipv6_rt_get_saddr.patch" >From 57c57fdc9ddbfa627660117d4d257e17dc4c6b3f Mon Sep 17 00:00:00 2001 From: David Lamparter Date: Wed, 20 Jul 2016 11:24:46 +0200 Subject: [PATCH 2/3] net/ipv6: add ipv6_rt_get_saddr() --- include/net/addrconf.h | 3 +++ net/ipv6/addrconf.c | 26 +++++++++++++++++++++++--- net/ipv6/fib6_rules.c | 4 +--- net/ipv6/route.c | 3 +-- net/ipv6/xfrm6_policy.c | 3 ++- 5 files changed, 30 insertions(+), 9 deletions(-) diff --git a/include/net/addrconf.h b/include/net/addrconf.h index 33f2652..95cee9a 100644 --- a/include/net/addrconf.h +++ b/include/net/addrconf.h @@ -83,6 +83,9 @@ struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net, int ipv6_dev_get_saddr(struct net *net, const struct net_device *dev, const struct in6_addr *daddr, unsigned int srcprefs, struct in6_addr *saddr); +int ipv6_rt_get_saddr(struct net *net, const struct rt6_info *rt, + const struct in6_addr *daddr, unsigned int srcprefs, + struct in6_addr *saddr); int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr, u32 banned_flags); int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr, diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index f148278..b0aedd3 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -1287,6 +1287,7 @@ struct ipv6_saddr_dst { int scope; int label; unsigned int prefs; + const struct in6_addr *nh; }; static inline int ipv6_saddr_preferred(int type) @@ -1518,9 +1519,11 @@ out: return hiscore_idx; } -int ipv6_dev_get_saddr(struct net *net, const struct net_device *dst_dev, - const struct in6_addr *daddr, unsigned int prefs, - struct in6_addr *saddr) +static int __ipv6_rtdev_get_saddr(struct net *net, const struct rt6_info *rt, + const struct net_device *dst_dev, + const struct in6_addr *daddr, + unsigned int prefs, + struct in6_addr *saddr) { struct ipv6_saddr_score scores[2], *hiscore; struct ipv6_saddr_dst dst; @@ -1537,6 +1540,7 @@ int ipv6_dev_get_saddr(struct net *net, const struct net_device *dst_dev, dst.scope = __ipv6_addr_src_scope(dst_type); dst.label = ipv6_addr_label(net, daddr, dst_type, dst.ifindex); dst.prefs = prefs; + dst.nh = rt ? &rt->rt6i_gateway : NULL; scores[hiscore_idx].rule = -1; scores[hiscore_idx].ifa = NULL; @@ -1599,8 +1603,24 @@ int ipv6_dev_get_saddr(struct net *net, const struct net_device *dst_dev, in6_ifa_put(hiscore->ifa); return 0; } + +int ipv6_dev_get_saddr(struct net *net, const struct net_device *dst_dev, + const struct in6_addr *daddr, unsigned int prefs, + struct in6_addr *saddr) +{ + return __ipv6_rtdev_get_saddr(net, NULL, dst_dev, daddr, prefs, saddr); +} EXPORT_SYMBOL(ipv6_dev_get_saddr); +int ipv6_rt_get_saddr(struct net *net, const struct rt6_info *rt, + const struct in6_addr *daddr, unsigned int prefs, + struct in6_addr *saddr) +{ + const struct net_device *dst_dev = ip6_dst_idev(&rt->dst)->dev; + return __ipv6_rtdev_get_saddr(net, rt, dst_dev, daddr, prefs, saddr); +} +EXPORT_SYMBOL(ipv6_rt_get_saddr); + int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr, u32 banned_flags) { diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index ed33abf..d91b6f5 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -104,9 +104,7 @@ static int fib6_rule_action(struct fib_rule *rule, struct flowi *flp, r->src.plen && !(flags & RT6_LOOKUP_F_HAS_SADDR)) { struct in6_addr saddr; - if (ipv6_dev_get_saddr(net, - ip6_dst_idev(&rt->dst)->dev, - &flp6->daddr, + if (ipv6_rt_get_saddr(net, rt, &flp6->daddr, rt6_flags2srcprefs(flags), &saddr)) goto again; diff --git a/net/ipv6/route.c b/net/ipv6/route.c index ed44663..8e6218d 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2546,8 +2546,7 @@ int ip6_route_get_saddr(struct net *net, if (rt && rt->rt6i_prefsrc.plen) *saddr = rt->rt6i_prefsrc.addr; else - err = ipv6_dev_get_saddr(net, idev ? idev->dev : NULL, - daddr, prefs, saddr); + err = ipv6_rt_get_saddr(net, rt, daddr, prefs, saddr); return err; } diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c index c074771..19005e6 100644 --- a/net/ipv6/xfrm6_policy.c +++ b/net/ipv6/xfrm6_policy.c @@ -64,7 +64,8 @@ static int xfrm6_get_saddr(struct net *net, int oif, return -EHOSTUNREACH; dev = ip6_dst_idev(dst)->dev; - ipv6_dev_get_saddr(dev_net(dev), dev, &daddr->in6, 0, &saddr->in6); + ipv6_rt_get_saddr(dev_net(dev), (struct rt6_info *)dst, + &daddr->in6, 0, &saddr->in6); dst_release(dst); return 0; } -- 2.7.3 --L6iaP+gRLNZHKoI4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0003-net-ipv6-implement-RFC6724-addrconf-rule-5.5.patch" >From f396b90dc6dfd36f282ba574c1add619d7345ad3 Mon Sep 17 00:00:00 2001 From: David Lamparter Date: Wed, 20 Jul 2016 11:25:23 +0200 Subject: [PATCH 3/3] net/ipv6: implement RFC6724 (addrconf) rule 5.5 --- net/ipv6/addrconf.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index b0aedd3..64ea39d 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -1262,6 +1262,7 @@ enum { IPV6_SADDR_RULE_HOA, #endif IPV6_SADDR_RULE_OIF, + IPV6_SADDR_RULE_OIF_RTR, IPV6_SADDR_RULE_LABEL, IPV6_SADDR_RULE_PRIVACY, IPV6_SADDR_RULE_ORCHID, @@ -1312,6 +1313,7 @@ static int ipv6_get_saddr_eval(struct net *net, int i) { int ret; + size_t j; if (i <= score->rule) { switch (i) { @@ -1390,6 +1392,18 @@ static int ipv6_get_saddr_eval(struct net *net, ret = (!dst->ifindex || dst->ifindex == score->ifa->idev->dev->ifindex); break; + case IPV6_SADDR_RULE_OIF_RTR: + /* Rule 5.5: Prefer prefixes announced by nexthop */ + ret = 0; + if (!dst->nh) + break; + for (j = 0; j < score->ifa->origin_rtr_count; j++) + if (ipv6_addr_equal(&score->ifa->origin_rtr[j], + dst->nh)) { + ret = 1; + break; + } + break; case IPV6_SADDR_RULE_LABEL: /* Rule 6: Prefer matching label */ ret = ipv6_addr_label(net, -- 2.7.3 --L6iaP+gRLNZHKoI4-- From nobody Wed Jul 20 05:59:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806E212D5FB; Wed, 20 Jul 2016 05:59:04 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MBcwpunoVrjj; Wed, 20 Jul 2016 05:59:02 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D6A8E12D5D5; Wed, 20 Jul 2016 05:59:01 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id f65so174741282wmi.0; Wed, 20 Jul 2016 05:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OzCd7t8Y0IZmofuJnSKXszFz0oJUMlWWv6XYtgTb6hE=; b=pwFlhGS+XapXrTwRrgpscrU9LGED5ikY76m+VhbGXJHOv92GoqoBp3MG6ZVdSkOuv7 grNqrHf+Eh4iwG7nCuIKfQ5T49nIzWt338BSgR8HcJ3Rk2+EEzFwWaZZiJ0e3ahppoM4 Yg80d9v6Cf9+hFgxNcr2bCbO5kVCVnd09m6TOwY4V+li5FQ6BecmPsBsSf1mwUddSeMT 0rcECtiEXl36xOS/+k5Vbab/QAHSC748gT3VU9gtNFYpmJcaIU9c8YqsDeKWDgWj7uZn BpFWsa5VnlnRZhtbyzOdxK83EbsHVoO06zMFVKdjlcHjataqDMFx8gFlwIZLazo/CPeb Vyhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OzCd7t8Y0IZmofuJnSKXszFz0oJUMlWWv6XYtgTb6hE=; b=Of87buMWY+soCliRhNH92LFIGOg6nUESisz+on49O4fMFmlJmFY44K2NB20yPPBgXX MepCFhEX0iww6bvGjyNSj24QnxTeB3vnax8eBxncXRWtrKCmSnFqP031OP0OGJWAJfMX ETtTm9Y/il5AmDKA6iaXDqBSydZXelq8NFdwZWijcvWkk2LGd+MPaOl8v/n7xutz1qDr 6QkkI0P/nSqNAOEdEdqEqG85BzlVUkZnNHCSbjqDfp3lTTWpH9n6Q6HjoKF60JoVM/0E TdO7/AlvtgbdCXE94Pr3yBkRJ4EzIss4OX/MYJccjdfmYPMiWQS04+vYJspdLCweIsDF eGxg== X-Gm-Message-State: ALyK8tJ8FVQE+1bnsvp/GhZSR8a5IWkPbmkVg0MWcUy3OOdweSRa/BFNOvJG/lOwoA2j5g== X-Received: by 10.28.182.136 with SMTP id g130mr10896707wmf.21.1469019540395; Wed, 20 Jul 2016 05:59:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g184sm31428393wme.15.2016.07.20.05.58.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 05:58:59 -0700 (PDT) To: David Lamparter , "v6ops@ietf.org" , homenet References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6097913e-d9e3-82ae-56ef-0476347af4e9@gmail.com> Date: Thu, 21 Jul 2016 00:59:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720125458.GO255916@eidolon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Jen Linkova , Chris Bowers Subject: Re: [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:59:04 -0000 On 21/07/2016 00:54, David Lamparter wrote: > As mentioned on mic during rtgwg, I think the idea of affecting host > source address selection through 6724 rule 5.5 is potentially very > useful and IMHO should be explored. And please note that draft-ietf-6man-multi-homed-host-07 (in IETF Last Call) recommends hosts to support this, exactly to assist SADR solutions. Brian > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached > to this mail. I've been able to gleam a little more detail on the idea: > > - it's a bit unclear how an address/prefix's "source" next-hop is kept > in association. The simplistic approach of adding a "PA source ipv6 > address" for each of a host's configured addresses falls flat when > more than 1 router advertises the same prefix, so I implemented it as > a list -- however, my hack never removes entries off that. It should > possibly have a copy of the PA's valid time? > > (Read as: the "Discussion" note in 6724 is right on the mark - the > details are not quite specified.) > > - in that avenue, I don't think it's possible to store the information > in a route-centric way, because RA lifetimes tend to be shorter. > If a router goes away and comes back, it seems to me that the prefix's > associated origin/nexthop should still be there. > > - rule 5.5 makes RA preference carry into source address selection. I > think this is described in the draft, I just failed to grasp that from > the presentation. Very useful for getting source selection right in > the face of unequal performance uplinks. > > - if you want to manage this in an userspace process on Linux, you can > simply update the route's preferred source attribute. > > The attached patchset also has the following caveats that result from me > just doing a quick hack: > - there is no debugging/user visibility of the value > - as mentioned above, tracked source addresses never go away unless the > entire address dies. It caps at 4 sources (so you can't exhaust > kernel memory by spoofing...) > - I should probably pass Linux's "dst" instead of "rt6_info" > - I didn't check for locking/concurrentness violations > - there's a const warning which I ignored. > > Either way if anyone wants to tinker with it, here it is. > No warranties, YMMV. You touch it, it becomes your responsibility ;) > > Cheers, > > > -David > > On Wed, Jul 06, 2016 at 04:33:18PM +0000, Fred Baker (fred) wrote: >> At IETF 94, this working group advised the routing ADs and Routing Working Group that PA multihoming would not work without a source/destination routing solution. This draft was developed in response. Routing Working Group requests v6ops review. >> >>> Begin forwarded message: >>> >>> From: >>> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Date: July 5, 2016 at 5:58:25 PM PDT >>> To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" >>> >>> >>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> has been successfully submitted by Fred Baker and posted to the >>> IETF repository. >>> >>> Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming >>> Revision: 00 >>> Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution >>> Document date: 2016-07-05 >>> Group: Individual Submission >>> Pages: 44 >>> URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ >>> Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 >>> >>> >>> Abstract: >>> Connecting an enterprise site to multiple ISPs using provider- >>> assigned addresses is difficult without the use of some form of >>> Network Address Translation (NAT). Much has been written on this >>> topic over the last 10 to 15 years, but it still remains a problem >>> without a clearly defined or widely implemented solution. Any >>> multihoming solution without NAT requires hosts at the site to have >>> addresses from each ISP and to select the egress ISP by selecting a >>> source address for outgoing packets. It also requires routers at the >>> site to take into account those source addresses when forwarding >>> packets out towards the ISPs. >>> >>> This document attempts to define a complete solution to this problem. >>> It covers the behavior of routers to forward traffic taking into >>> account source address, and it covers the behavior of host to select >>> appropriate source addresses. It also covers any possible role that >>> routers might play in providing information to hosts to help them >>> select appropriate source addresses. In the process of exploring >>> potential solutions, this documents also makes explicit requirements >>> for how the solution would be expected to behave from the perspective >>> of an enterprise site network administrator . >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >> > > > >> _______________________________________________ >> 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 Wed Jul 20 06:06:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B012D62F; Wed, 20 Jul 2016 06:06: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_PASS=-0.001] autolearn=ham autolearn_force=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 Ay_3MQEpHRGy; Wed, 20 Jul 2016 06:06:40 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 02DE012D612; Wed, 20 Jul 2016 06:06:40 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bPrCu-000H94-PD; Wed, 20 Jul 2016 15:06:37 +0200 Date: Wed, 20 Jul 2016 15:06:36 +0200 From: David Lamparter To: Brian E Carpenter Message-ID: <20160720130636.GP255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <6097913e-d9e3-82ae-56ef-0476347af4e9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6097913e-d9e3-82ae-56ef-0476347af4e9@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , homenet , Chris Bowers Subject: Re: [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:06:41 -0000 On Thu, Jul 21, 2016 at 12:59:05AM +1200, Brian E Carpenter wrote: > On 21/07/2016 00:54, David Lamparter wrote: > > As mentioned on mic during rtgwg, I think the idea of affecting host > > source address selection through 6724 rule 5.5 is potentially very > > useful and IMHO should be explored. > > And please note that draft-ietf-6man-multi-homed-host-07 (in IETF Last Call) > recommends hosts to support this, exactly to assist SADR solutions. Yay! I'm also happy to add that googling around the topic tells me at least Windows already implements rule 5.5: http://blog.ipspace.net/2016/01/ipv6-address-allocation-is-operating.html -David From nobody Wed Jul 20 06:13:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26A12D586 for ; Wed, 20 Jul 2016 06:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 bMkH4iG_CX9x for ; Wed, 20 Jul 2016 06:13:27 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 7668012D5A1 for ; Wed, 20 Jul 2016 06:13:25 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id u186so115765113ita.0 for ; Wed, 20 Jul 2016 06:13:25 -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; bh=+HyN2MJuf8XNOEs1KCYsm1s9Yv88yEJiwPBpL/x8OyQ=; b=S7oWPZeQrW4A+u6ev8FxH1hU8nrv/efRC7Te9R/a/HZWLCcrO2NZH39/yeb0VqSOJp 0K1Xiv+8e98mj80WUtLDYGBhCwfWaMZSR6PVSSGI02zswCVgxlNtRffEhDyyjyHjUQt9 1PSJ39T/ozMX/6xPH2Fm697pa2fKpRAP+or9xgbAu8pdou347N2o+4S8ur0lr9hOR1Fh M587bXjthzUE8AKG86hMVfCgXL/5vlC4ue0Vs5kNUqhqshN/2wZix9rex/xaGrrjbCTh rZsS6DFS66gFFse2d/EorZiuzR4SpOki7Db0aawhxx36FJrdSMfylxsHRimzi6+V342q 8r8g== 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; bh=+HyN2MJuf8XNOEs1KCYsm1s9Yv88yEJiwPBpL/x8OyQ=; b=WFwy8/lfKUCQ9vuR3Ccm1vsy3q/V25BoOmiz0y9wPDV8B97W9u32QlwojVAiE+6KvG dVuj1VKCpnkySAfW0z69aHtAxUleAfdZjarzXIaBrkXsON4arytMLowXz8mg5eDAGIr7 p3FFiQcq+c0AB+WxO+EKGodmYXC0zaRMCebol5EbxXeY/c6jjnjp51VBVem60eQoaatY HyEyaOScppc3DSxXzKBkfYNJ3nMSA9wGRey4sf+lC5pcT+pTRej4C/XLsWjkZa/O8/GF 0bR0mdyD52InfJ7diJKGn//Y9Obnz0fDnW+oebCrJTczUs9L1nYqBhejD1XKqwzIEuVK co2A== X-Gm-Message-State: ALyK8tJIwr2F1ManOExolOdebuy1RLVclCTj4f0kwBhp2jfFDUJBBRVYMZ5X270xAe7lpR4lWwG+tC4K5SXlPrQx X-Received: by 10.36.103.4 with SMTP id u4mr60046636itc.88.1469020404606; Wed, 20 Jul 2016 06:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.65.15.99 with HTTP; Wed, 20 Jul 2016 06:13:05 -0700 (PDT) In-Reply-To: <20160720125458.GO255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> From: Lorenzo Colitti Date: Wed, 20 Jul 2016 15:13:05 +0200 Message-ID: To: David Lamparter Content-Type: multipart/alternative; boundary=001a114ac8f862d25f053810f711 Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , homenet , Chris Bowers Subject: Re: [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:13:28 -0000 --001a114ac8f862d25f053810f711 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > - it's a bit unclear how an address/prefix's "source" next-hop is kept > in association. The simplistic approach of adding a "PA source ipv6 > address" for each of a host's configured addresses falls flat when > more than 1 router advertises the same prefix, so I implemented it as > a list -- however, my hack never removes entries off that. It should > possibly have a copy of the PA's valid time? > The way I thought of doing this would be to alternatively/additionally keep a pointer from the default router that announced a given prefix (which does have the link-local address of the router) to each address that was configured from that prefix. That way, when an address goes away you can scan the FIB and find another router to associate with that prefix. As for lifetimes expiring, you would need to have somewhere to keep dummy zero-lifetime default routes. It might be possible to do this in the FIB itself by adding a special entry that doesn't ever match anything, or has an infinite metric, or a different type... --001a114ac8f862d25f053810f711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 20, 2016 at 2:54 PM, David Lamparter <equinox@diac24.net>= wrote:
- it's a bit unclear h= ow an address/prefix's "source" next-hop is kept
=C2=A0 in association.=C2=A0 The simplistic approach of adding a "PA s= ource ipv6
=C2=A0 address" for each of a host's configured addresses falls fl= at when
=C2=A0 more than 1 router advertises the same prefix, so I implemented it a= s
=C2=A0 a list -- however, my hack never removes entries off that.=C2=A0 It = should
=C2=A0 possibly have a copy of the PA's valid time?

The way I thought of doing this would be to alternatively/= additionally keep a pointer from the default router that announced a given = prefix (which does have the link-local address of the router) to each addre= ss that was configured from that prefix. That way, when an address goes awa= y you can scan the FIB and find another router to associate with that prefi= x.

As for lifetimes expiring, you would need to ha= ve somewhere to keep dummy zero-lifetime default routes. It might be possib= le to do this in the FIB itself by adding a special entry that doesn't = ever match anything, or has an infinite metric, or a different type...
--001a114ac8f862d25f053810f711-- From nobody Wed Jul 20 06:22:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF112D5D3; Wed, 20 Jul 2016 06:22:14 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JhcAXsuziC6u; Wed, 20 Jul 2016 06:22:12 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 926C312D648; Wed, 20 Jul 2016 06:22:12 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id o80so68892956wme.1; Wed, 20 Jul 2016 06:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xpm3+bC8G6QMirpjSVy0QpFy95OCAlyZnYKWwUkx46w=; b=OvKjENDvUsSolPgxfwZNlbs4708FjjgNWf9gFRkEQH+eEDj7QgcBK1e8QrAbCZMeAN qzw3Vsh+1rdsVLLPCtM7uZSN50pU9CBgR5NpdJScEex7thzUpREbIC9p+EQVTL7ot+Wi hFLoyGvXXr6byPLOV6hG6qs3FB9+2c/QIHyQOrxi1YufD6qmJ7QU1LGGb5EJ24Roa50s okV/htfd2wDT4gQX/cKFsFiI/ql8nY+05zX9x8e2XzbHzM4A0Pr+lL+ce9xNdlurHivH +ZWeALe9qtcmtYsfH0BVftpHduKVm+N59+3eLE50dwQL+Z07VzW3kxggy8NBHoczlrSq BNbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xpm3+bC8G6QMirpjSVy0QpFy95OCAlyZnYKWwUkx46w=; b=acHwK6JXpbB/CKi3+QRweGDe4enZuw1l2Xd/HOVfL0Cct+p4SDHxSnFKkb2HvFpvOs JDiX/qkfY+g5PzVn3X/Y9ZRCPfdLV5jJp35prBz/OuXZ5C0egvRtuwRnBE1oLlZmn8gO wsHeSHNL0mTCIeRo8mokK7sEPxWTB041yPtJjvwFAmoGi3QcKre98iGSrN9G0H6JORkh WHLNcVNFB512S6my0ztwCTSSmTug20BGjsaZsCY4o5t5Y0zwyd+ggvZY+wgVG+9RDyWN So1dhgaKFGqKtvl2kxS8Os+MFyFWn7ViePR/L5Ugv08O45A5Qa0gemhTJDPQG1soxGWc cG+g== X-Gm-Message-State: ALyK8tJ/twwLSLNwnEukKW4hKbvMJ4272fwkqq1yYA3q8hBkRGoHkzHTighS/LtZh9M4SQ== X-Received: by 10.28.134.14 with SMTP id i14mr10927669wmd.59.1469020931057; Wed, 20 Jul 2016 06:22:11 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g5sm1276410wji.37.2016.07.20.06.22.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 06:22:10 -0700 (PDT) To: Lorenzo Colitti , David Lamparter References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> Date: Thu, 21 Jul 2016 01:22:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , homenet , Chris Bowers Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:22:15 -0000 On 21/07/2016 01:13, Lorenzo Colitti wrote: > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > >> - it's a bit unclear how an address/prefix's "source" next-hop is kept >> in association. The simplistic approach of adding a "PA source ipv6 >> address" for each of a host's configured addresses falls flat when >> more than 1 router advertises the same prefix, so I implemented it as >> a list -- however, my hack never removes entries off that. It should >> possibly have a copy of the PA's valid time? >> > > The way I thought of doing this would be to alternatively/additionally keep > a pointer from the default router that announced a given prefix (which does > have the link-local address of the router) to each address that was > configured from that prefix. That way, when an address goes away you can > scan the FIB and find another router to associate with that prefix. > > As for lifetimes expiring, you would need to have somewhere to keep dummy > zero-lifetime default routes. It might be possible to do this in the FIB > itself by adding a special entry that doesn't ever match anything, or has > an infinite metric, or a different type... Please tell us ASAP if there is anything we should add to https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 or thereabouts. Brian From nobody Wed Jul 20 06:38:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8512D695; Wed, 20 Jul 2016 06:38:19 -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 autolearn_force=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 br8PYI_cBeJf; Wed, 20 Jul 2016 06:38:18 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 CA9C812D6AF; Wed, 20 Jul 2016 06:38:10 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bPrhP-000I1s-49; Wed, 20 Jul 2016 15:38:07 +0200 Date: Wed, 20 Jul 2016 15:38:07 +0200 From: David Lamparter To: Lorenzo Colitti Message-ID: <20160720133807.GR255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Chris Bowers , homenet , Jen Linkova Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:38:19 -0000 On Wed, Jul 20, 2016 at 03:13:05PM +0200, Lorenzo Colitti wrote: > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > > > - it's a bit unclear how an address/prefix's "source" next-hop is kept > > in association. The simplistic approach of adding a "PA source ipv6 > > address" for each of a host's configured addresses falls flat when > > more than 1 router advertises the same prefix, so I implemented it as > > a list -- however, my hack never removes entries off that. It should > > possibly have a copy of the PA's valid time? > > > > The way I thought of doing this would be to alternatively/additionally keep > a pointer from the default router that announced a given prefix (which does > have the link-local address of the router) to each address that was > configured from that prefix. That turns nontrivial as soon as you have 4191 RIOs, especially if the router is trying to do walled gardens by sending its RAs with lifetime = 0 (as suggested in section 4.2.2 of pa-multihoming). > That way, when an address goes away you can scan the FIB and find > another router to associate with that prefix. [I assume "address goes away" meant "router goes away"] > As for lifetimes expiring, you would need to have somewhere to keep dummy > zero-lifetime default routes. It might be possible to do this in the FIB > itself by adding a special entry that doesn't ever match anything, or has > an infinite metric, or a different type... That sounds quite a bit more complicated than address-centric handling... we're 1:N for router['s LL address] to routes and also 1:N for router['s LL address] to prefixes, and then 1:N for prefix to derived addresses. I'd rather copy the prefix lifetime (either valid or preferred - probably former?) onto the same list entry where a configured address's RA source LL is also stored; that replicates only the last 1:N step... (So, for each address, in its list of RA sources that the prefix was seen from, there will be a potentially-distinct lifetime.) -David P.S.: Does anyone know the details of how Windows implements this? From nobody Wed Jul 20 06:51:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0D612D74A for ; Wed, 20 Jul 2016 06:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.388 X-Spam-Level: X-Spam-Status: No, score=-7.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3vQYShxoBNxt for ; Wed, 20 Jul 2016 06:51:21 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id AB01012D742 for ; Wed, 20 Jul 2016 06:51:21 -0700 (PDT) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u6KDoJD2019357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jul 2016 06:50:19 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <20160720114616.GU79185@Space.Net> Date: Wed, 20 Jul 2016 06:50:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3F4531-5AAC-4937-B4A3-3CF16CFA1B3C@delong.com> References: <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> <31c0de4a-ecb0-9c11-4e8d-a701c8311a75@gmail.com> <578E4B94.2000507@isi.edu> <20160720114616.GU79185@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Jul 2016 06:50:20 -0700 (PDT) Archived-At: Cc: v6ops list Subject: Re: [v6ops] MAC and IP multicast addresses in vehicular networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:51:23 -0000 > On Jul 20, 2016, at 04:46 , Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Jul 20, 2016 at 08:26:03AM +1000, Mark Smith wrote: >> RAs from rogue routers are sent to the all nodes IPv6 multicast = address. >> You can't block that address on layer 2 port ingress from non-router = ports >> without breaking anything else that might legitimately use the all = nodes >> IPv6 multicast address (off the top of my head, all nodes ping). >>=20 >> However, if RAs were sent to a RA specific multicast group, then = dropping >> on ingress based on that RA specific multicast destination address = would >> only drop rogue RAs and nothing else. >>=20 >> The current way to implement RA guard is to have to look deeper into = the >> all nodes packet to see if it is an RA or not. Matching on a RA = specific >> destination multicast address would be much simpler, and something I = think >> that could be done in TCAM because of the exact match on and fixed = location >> of the IPv6 DA in the frame. >=20 > While I like that idea, it would also only work if target hosts would > refuse to accept a RA that is not destined to this "all-RA-clients" > multicast address. That=E2=80=99s problematic because some legitimate RAs can be unicast to = the targets unicast LL address in response to an RS from the target in = question. >=20 > How well such assumptions work can be seen with the recent router ND = issue=20 > where routers happily received and processed ND packets with TTL !=3D = 255, in > violation of the standards, and the fe80:: issue where routers happily > forward fe80::-sourced packets=E2=80=A6 We definitely should be trying to solve these problems wherever = possible. Owen From nobody Wed Jul 20 07:34:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB2B12D836; Wed, 20 Jul 2016 07:34:21 -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 autolearn_force=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 2_rjRvBqHvTs; Wed, 20 Jul 2016 07:34:17 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 B92C312D82C; Wed, 20 Jul 2016 07:34:17 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bPsZe-000JmN-V1; Wed, 20 Jul 2016 16:34:12 +0200 Date: Wed, 20 Jul 2016 16:34:10 +0200 From: David Lamparter To: Brian E Carpenter Message-ID: <20160720143410.GS255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Chris Bowers , homenet , Jen Linkova Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 14:34:21 -0000 On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: > On 21/07/2016 01:13, Lorenzo Colitti wrote: > > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > > > >> - it's a bit unclear how an address/prefix's "source" next-hop is kept > >> in association. The simplistic approach of adding a "PA source ipv6 > >> address" for each of a host's configured addresses falls flat when > >> more than 1 router advertises the same prefix, so I implemented it as > >> a list -- however, my hack never removes entries off that. It should > >> possibly have a copy of the PA's valid time? > >> > > > > The way I thought of doing this would be to alternatively/additionally keep > > a pointer from the default router that announced a given prefix (which does > > have the link-local address of the router) to each address that was > > configured from that prefix. That way, when an address goes away you can > > scan the FIB and find another router to associate with that prefix. > > > > As for lifetimes expiring, you would need to have somewhere to keep dummy > > zero-lifetime default routes. It might be possible to do this in the FIB > > itself by adding a special entry that doesn't ever match anything, or has > > an infinite metric, or a different type... > > Please tell us ASAP if there is anything we should add to > https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 > or thereabouts. I do see some trouble in use-cases where more than one actual router (actual = not counting extra link-local addresses on the same router) is present on a link, advertising the same prefix to hosts. (This is reasonably likely in homenet scenarios, maybe less in enterprise.) If the host only tracks a maximum of one RA source LL for a prefix/address, but the router with that LL happens to not be the one actually used (e.g. preference, router gone, more specific route from RIO, whatever else) then the functionality is lost. It's particularly bad if the one RA source LL is the one prefix was first seen from (and then, worst-case, never updated). (The neccessary precondition / assumption being broken there is that the test "was prefix X announced by router Y" doesn't report false negatives. I haven't applied brain to false positives yet.) -David From nobody Thu Jul 21 00:25:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0C12DA8D; Thu, 21 Jul 2016 00:25:43 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OBSNGvTpeVSh; Thu, 21 Jul 2016 00:25:41 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 219B612D098; Thu, 21 Jul 2016 00:25:41 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id o80so13028342wme.1; Thu, 21 Jul 2016 00:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N5dzZKkXQMGkRlNWZAx7fgQwsMLV4y2BrGt3QCTBE7I=; b=LUSqixYreR7Di5uFju0xwwu6eEF4RPQkM3uw1x3edJ0JCeWW0OHV7gn9AQotGfBy5l BZ6On+ufMDYzkVX6YwPAjCFeUMMAyOwWpf8XcNmOG5QnaNLEFYdHTuC2s6wioxTbFD/R izoxM+vvO/sTSlcOmjWibGJy1l9DMcpYXitQS99qzLWe072FdwgBGkhIgD0dmTUe+ww6 BVeXzju9saqjVdCPSG7eTWNIDxavZZCijRMMOLK32W1Pd4DfjQAzZoLydbJn1AkI7YpQ rvytHUGIETYxKoXJVuDpgmlQ70eFXBpA6X9p+jpREe4oQu9UzGw3jIkknKA64v/HQlvV eP0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=N5dzZKkXQMGkRlNWZAx7fgQwsMLV4y2BrGt3QCTBE7I=; b=CJT4sJWBgf5A3ZhFykeueOu9imgm1fCcCtSTS7CPDij8M5kaujd8dGs+WhwKcJVwA/ DePcufKi1NDz0xkQK7BILWzaGcQVFCK63cdmuUTFzK1YAq7sL6+ZomJ51dHRRagLHsOz tnTbmsC5wPGREE33K/dGO2fPbFMKX0yhngsixiSyeKX8YpHzOuCikjUO39qAsKUrJteR utEiZcnVtn+ZFAAuPL4v14zhhIkhQVNA55WrYduHkMHgwg4JwieK+Y34t/DA/fzdpE1F IN34P92/Kba32qh9lcJKS6KS6eX6SVy9RuKm1AeE9ljBDGQEBKRkyXQA+MwoI4X/Aqzp fcnw== X-Gm-Message-State: ALyK8tK7ge5Y7vVDwT7mXKAQ2iDoaPdccUAwEx3rF/ENruZPj0ms/yjemW64CpUlALDdUA== X-Received: by 10.28.156.6 with SMTP id f6mr16660199wme.1.1469085939558; Thu, 21 Jul 2016 00:25:39 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:28cc:dc4c:9703:6781? ([2001:67c:370:152:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a194sm1825603wmd.24.2016.07.21.00.25.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 00:25:38 -0700 (PDT) To: David Lamparter References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Jul 2016 19:25:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720143410.GS255916@eidolon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , Chris Bowers , homenet , Jen Linkova Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 07:25:43 -0000 On 21/07/2016 02:34, David Lamparter wrote: > On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: >> On 21/07/2016 01:13, Lorenzo Colitti wrote: >>> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: >>> >>>> - it's a bit unclear how an address/prefix's "source" next-hop is kept >>>> in association. The simplistic approach of adding a "PA source ipv6 >>>> address" for each of a host's configured addresses falls flat when >>>> more than 1 router advertises the same prefix, so I implemented it as >>>> a list -- however, my hack never removes entries off that. It should >>>> possibly have a copy of the PA's valid time? >>>> >>> >>> The way I thought of doing this would be to alternatively/additionally keep >>> a pointer from the default router that announced a given prefix (which does >>> have the link-local address of the router) to each address that was >>> configured from that prefix. That way, when an address goes away you can >>> scan the FIB and find another router to associate with that prefix. >>> >>> As for lifetimes expiring, you would need to have somewhere to keep dummy >>> zero-lifetime default routes. It might be possible to do this in the FIB >>> itself by adding a special entry that doesn't ever match anything, or has >>> an infinite metric, or a different type... >> >> Please tell us ASAP if there is anything we should add to >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 >> or thereabouts. > > I do see some trouble in use-cases where more than one actual router > (actual = not counting extra link-local addresses on the same router) is > present on a link, advertising the same prefix to hosts. (This is > reasonably likely in homenet scenarios, maybe less in enterprise.) > > If the host only tracks a maximum of one RA source LL for a > prefix/address, but the router with that LL happens to not be the one > actually used (e.g. preference, router gone, more specific route from > RIO, whatever else) then the functionality is lost. It's particularly > bad if the one RA source LL is the one prefix was first seen from (and > then, worst-case, never updated). > > (The neccessary precondition / assumption being broken there is that the > test "was prefix X announced by router Y" doesn't report false > negatives. I haven't applied brain to false positives yet.) Is this any worse than if the single default router in a traditional host goes away, which will break all off-link packets until something happens? I'm not saying it isn't a problem, but it doesn't sound like it's a new problem that applies only in the multihomed case. Brian From nobody Thu Jul 21 00:50:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31DF12DB27 for ; Thu, 21 Jul 2016 00:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 No_kNT3WvO0m for ; Thu, 21 Jul 2016 00:50:06 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 ADFAD12DADC for ; Thu, 21 Jul 2016 00:50:06 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so10329076ith.0 for ; Thu, 21 Jul 2016 00:50:06 -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; bh=BXOFuuzJ9TrlPpDdlag+yosRcD9jfOU/HsAMXO9OZ4E=; b=nS6tMP8a9FiBbzkL65lCY90OI94h4X3yPNzNOORCOHYIna8ehXGme0Jg7uJFaXGoSc yX309KQMAmWPO5eNOAAhfmFJBLIzyPoTgqyjVGBG8YG7AHJNDZ48Qy4mrj9WeF38IKRi MKiJTdRpx/MpjTrWNDxQ1z8IC7ptlpHMgXaebtqXyxofamVg1RM2tj8spZtSukhiL3fx 3UdvbXwMlzxg18TFAHb5n12g9Z7R1hn0hqs4wLQRCSmVUvc9Kafy2rnmIZJFWVH7d3QY 4g8le4cK1nm6J5c5Hzwtg1K+LRWQg4v4QMZA9upDVXiyhgmyI3dzGXIs/Zx79HMtnkei haCQ== 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; bh=BXOFuuzJ9TrlPpDdlag+yosRcD9jfOU/HsAMXO9OZ4E=; b=ASwwW80shuxaRC6slNwQbWnzfQskExRdlfPVdK2x6pX01ypkHX03Zb6v7/v+00LyCy Q6Hv2V3RPWUoEcS01em4Qku1EtZYHYOXx8OmHUPCPJhEMFYAWl34brCL3U16N/RmRP/M BJwOsiUB+5KyNOvePfukm1rSECS2e2YBN/Kw/TmKctxCa3gLNuB6V7Nxb89khBwm+P4q gauz/+Eejwa2NirHTpeRusvb04/lLDyZolxxApPYsMOnny4ZdkejI1mwjQlOMpGk109y 956vM84xccyecz/+hyYXtFDIURCPFyWtW6zMVb0Q9V3agNmb4T/sP0ZFMStObIuwbBxF xtIg== X-Gm-Message-State: ALyK8tKc2mngbYPttovnuTb/SbBUrW0nHPF1q8ACamS8UrM/pmPy1XXJrf6fUyscr4I0LCvr4ZesF+bFXclxAyyz X-Received: by 10.36.137.215 with SMTP id s206mr14177462itd.82.1469087405867; Thu, 21 Jul 2016 00:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.65.15.99 with HTTP; Thu, 21 Jul 2016 00:49:46 -0700 (PDT) In-Reply-To: <20160720125458.GO255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> From: Lorenzo Colitti Date: Thu, 21 Jul 2016 09:49:46 +0200 Message-ID: To: David Lamparter Content-Type: multipart/alternative; boundary=94eb2c05e6ecf9495505382090b1 Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , homenet , Chris Bowers Subject: Re: [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 07:50:09 -0000 --94eb2c05e6ecf9495505382090b1 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached > to this mail. I've been able to gleam a little more detail on the idea: > David, do you intend to keep working on the patches? Think you could send them to netdev as an RFC patchset, with proper signoff? Once it's on netdev other people can iterate on them, even if you lose interest :-) --94eb2c05e6ecf9495505382090b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 20, 2016 at 2:54 PM, David Lamparter <equinox@diac24.net>= wrote:
Hence, I hacked it up for = the Linux (4.5.0) kernel; patches are attached
to this mail.=C2=A0 I've been able to gleam a little more detail on the= idea:

David, do you intend to keep wor= king on the patches? Think you could send them to netdev as an RFC patchset= , with proper signoff? Once it's on netdev other people can iterate on = them, even if you lose interest :-)
--94eb2c05e6ecf9495505382090b1-- From nobody Thu Jul 21 03:22:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F5912DCDB for ; Thu, 21 Jul 2016 03:22:17 -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 autolearn_force=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 i6D2tNYV17Hj for ; Thu, 21 Jul 2016 03:22:14 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 56CB012DCB1 for ; Thu, 21 Jul 2016 03:21:57 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bQB73-000ril-Av; Thu, 21 Jul 2016 12:21:54 +0200 Date: Thu, 21 Jul 2016 12:21:53 +0200 From: David Lamparter To: Brian E Carpenter Message-ID: <20160721102153.GU255916@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:22:17 -0000 On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: > On 21/07/2016 02:34, David Lamparter wrote: > > On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: > >> On 21/07/2016 01:13, Lorenzo Colitti wrote: > >>> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > >>> > >>>> - it's a bit unclear how an address/prefix's "source" next-hop is kept > >>>> in association. The simplistic approach of adding a "PA source ipv6 > >>>> address" for each of a host's configured addresses falls flat when > >>>> more than 1 router advertises the same prefix, so I implemented it as > >>>> a list -- however, my hack never removes entries off that. It should > >>>> possibly have a copy of the PA's valid time? > >>>> > >>> > >>> The way I thought of doing this would be to alternatively/additionally keep > >>> a pointer from the default router that announced a given prefix (which does > >>> have the link-local address of the router) to each address that was > >>> configured from that prefix. That way, when an address goes away you can > >>> scan the FIB and find another router to associate with that prefix. > >>> > >>> As for lifetimes expiring, you would need to have somewhere to keep dummy > >>> zero-lifetime default routes. It might be possible to do this in the FIB > >>> itself by adding a special entry that doesn't ever match anything, or has > >>> an infinite metric, or a different type... > >> > >> Please tell us ASAP if there is anything we should add to > >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 > >> or thereabouts. > > > > I do see some trouble in use-cases where more than one actual router > > (actual = not counting extra link-local addresses on the same router) is > > present on a link, advertising the same prefix to hosts. (This is > > reasonably likely in homenet scenarios, maybe less in enterprise.) > > > > If the host only tracks a maximum of one RA source LL for a > > prefix/address, but the router with that LL happens to not be the one > > actually used (e.g. preference, router gone, more specific route from > > RIO, whatever else) then the functionality is lost. It's particularly > > bad if the one RA source LL is the one prefix was first seen from (and > > then, worst-case, never updated). > > > > (The neccessary precondition / assumption being broken there is that the > > test "was prefix X announced by router Y" doesn't report false > > negatives. I haven't applied brain to false positives yet.) > > Is this any worse than if the single default router in a traditional host > goes away, which will break all off-link packets until something happens? Yes -- this breaks the application of 6724 5.5 for the specific goal of preferring the correct source address for a particular uplink, if there is more than one router advertising the same prefix and the host can only remember one router. I.e., a scenario like this: # +--- R1 ------- ISP_A # | # Host --+--- R2 ---+ # | +--- ISP_B # +--- R3 ---+ Where R1 advertises Prefix A (ISP A) and R2 and R3 advertise Prefix B (ISP B). If R2 goes away and the Host only associated Prefix B with R2 (because it only saves a single LL address), then it can end up using R3 but with source prefix A. Meanwhile there is enough information floating on the link for it to know that it shouldn't. I'm not completely convinced this needs to be in the draft explicitly; if so this is a sentence or two along the lines of "a host SHOULD remember all/multiple routers that have advertised a particular prefix", or maybe "for full capability, the host needs to be capable of correctly tracking N:M prefix to router relations", or something similar. The question is whether that needs to be spelled out or not. I don't have a strong opinion. Windows managed to implement it without RFC guidance -- can anyone find out if it tracks N:M? -David From nobody Thu Jul 21 06:36:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C935312D0B1 for ; Thu, 21 Jul 2016 06:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0nWaIVnRTc8b for ; Thu, 21 Jul 2016 06:36:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A32112D53C for ; Thu, 21 Jul 2016 06:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1062; q=dns/txt; s=iport; t=1469108179; x=1470317779; h=from:to:subject:date:message-id:mime-version; bh=r9pnHL67IDoZpCOu7x/Bc+yM+CdRnAv/T6za2vjjbGo=; b=Qw/kRLMnYkK5gj5D1TQiAikf9+0hK7cxOMGudx0BMzaDWHNmty/iqCKt /fUnv2XP6Ub1KfdoLcngyfAxZpkI5odvpMW1JLJpcI/k/V/JdieyhMPBS 4Qb/bdtLkNv31hSRfvoOPwy9Z5ymzwVj3ZMfPF8Jb0NodkKspkqkrUZOX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAwDkzpBX/5xdJa1dgnFOgVizXIUEg?= =?us-ascii?q?XuGOIEROBQBAQEBAQEBZRwLQRABhBEjaAELAQI8AgQwJwSIQ59Lj2ONbwEBCAE?= =?us-ascii?q?BAQEjhiqMDoJaBZkmAY5qjzqQIAEeNoNzgW2FUH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208,217";a="131966044" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 13:36:18 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6LDaIoc007918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Jul 2016 13:36:18 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 09:36:17 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 09:36:17 -0400 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: unique-ipv6-prefix-per-host purpose of Neighbourship Discovery Best Practices Thread-Index: AQHR41Tbj5ebi91dC0Sz+8speHZRgQ== Date: Thu, 21 Jul 2016 13:36:17 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.216.53] Content-Type: multipart/alternative; boundary="_000_D3B69C8478A4Aevynckeciscocom_" MIME-Version: 1.0 Archived-At: Subject: [v6ops] unique-ipv6-prefix-per-host purpose of Neighbourship Discovery Best Practices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:36:27 -0000 --_000_D3B69C8478A4Aevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b25kZXIgd2hhdCBpcyB0aGUgcHVycG9zZSBvZiBzZWN0aW9uIDUgaW4gYW4gSS1EIHdoaWNo IGlzIGFib3V0IG9uZSBwcmVmaXggcGVyIGhvc3Q/DQoNCi3DqXJpYw0K --_000_D3B69C8478A4Aevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <294C61A6B0093B47B94F2DD72DF82317@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHdvbmRlciB3 aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNlY3Rpb24gNSBpbiBhbiBJLUQgd2hpY2ggaXMgYWJvdXQg b25lIHByZWZpeCBwZXIgaG9zdD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi3DqXJp YzwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3B69C8478A4Aevynckeciscocom_-- From nobody Thu Jul 21 06:45:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568E012D533 for ; Thu, 21 Jul 2016 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 I5gCocne5c0n for ; Thu, 21 Jul 2016 06:45:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 5503812B02B for ; Thu, 21 Jul 2016 06:45:21 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DD83EC1F3FF08; Thu, 21 Jul 2016 13:45:16 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6LDjINI014821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2016 13:45:19 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6LDjIXu009284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jul 2016 15:45:18 +0200 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.53]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 21 Jul 2016 15:45:18 +0200 From: "Van De Velde, Gunter (Nokia - BE)" To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" Thread-Topic: [v6ops] unique-ipv6-prefix-per-host purpose of Neighbourship Discovery Best Practices Thread-Index: AQHR41YdfCPnglZBPEK7KezKuOREqw== Date: Thu, 21 Jul 2016 13:45:16 +0000 Message-ID: <40BB2F6D-1F6E-4EA3-950B-F9C0B69A5A6A@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_40BB2F6D1F6E4EA3950BF9C0B69A5A6Aalcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] unique-ipv6-prefix-per-host purpose of Neighbourship Discovery Best Practices X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:45:23 -0000 --_000_40BB2F6D1F6E4EA3950BF9C0B69A5A6Aalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KR29vZCBjYXRjaC4gVGhhdCBzZWN0aW9uIGlzIG9uZSBvZiB0aGluZ3MgdGhh dCBlZGl0b3JzIHdlcmUgd29uZGVyaW5nIGFib3V0IHRvIGhvdyB0byBoYW5kbGUgdGhpcy4NCg0K VGhlIGludGVuZCB3YXMgdG8gc3BsaXQgdGhlIOKAkzAwIGRyYWZ0IGluIHR3byBkb2N1bWVudHMg YmFzZWQgdXBvbiBXRyBmZWVkYmFjayBhYm91dCDigJMwMCB2ZXJzaW9uLiBPbmUgZHJhZnQgdG8g c3BlYWsgYWJvdXQgdGhlIGFkZHJlc3MgYWxsb2NhdGlvbiAoQkNQIHR5cGUgZG9jKSwgYW5kIG9u ZSBpbmZvcm1hdGlvbmFsIGFib3V0IGluZm9ybWF0aW9uIGhvdyBwYXJhbWV0ZXJzIGNhbiBiZSBz ZXQgZm9yIGNvbW11bml0eSBuZXR3b3Jrcy4gVGhpcyBzZWN0aW9uIGlzIHNvbWV0aGluZyB0aGF0 IG5lZWRzIHRvIGJlIGNsZWFuZWQgdXAgaW4gdGhlIOKAkzAzIHZlcnNpb24gd2Ugd2lsbCBjcmVh dGUsIGFuZCBpIGJlbGlldmUgc29tZSBjb250ZW50IHdpbGwgYmUgaW4gdGhlIG90aGVyIGRvY3Vt ZW50IHRoYXQgd2UgaW50ZW5kIHRvIGNyZWF0ZSB0byBkb2N1bWVudCB0aG9zZSBzZXR0aW5ncy4N Cg0KSG9wZSBpdCBwcm92aWRlcyBzb21lIGNvbnRleHQgYWJvdXQgdGhpcyBzZWN0aW9uLCBhbmQg dGhlIGZ1dHVyZSBvZiB0aGUgdGV4dC4NCg0KDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJF cmljIFZ5bmNrZSAoZXZ5bmNrZSkiIDxldnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBj aXNjby5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMjEgSnVseSAyMDE2IGF0IDE1OjM2DQpUbzogInY2 b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4iIDx2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3Y2b3BzXSB1bmlxdWUtaXB2Ni1wcmVmaXgt cGVyLWhvc3QgcHVycG9zZSBvZiBOZWlnaGJvdXJzaGlwIERpc2NvdmVyeSBCZXN0IFByYWN0aWNl cw0KDQpJIHdvbmRlciB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHNlY3Rpb24gNSBpbiBhbiBJLUQg d2hpY2ggaXMgYWJvdXQgb25lIHByZWZpeCBwZXIgaG9zdD8NCg0KLcOpcmljDQo= --_000_40BB2F6D1F6E4EA3950BF9C0B69A5A6Aalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SGkg RXJpYyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkdvb2QgY2F0Y2guIFRoYXQgc2Vj dGlvbiBpcyBvbmUgb2YgdGhpbmdzIHRoYXQgZWRpdG9ycyB3ZXJlIHdvbmRlcmluZyBhYm91dCB0 byBob3cgdG8gaGFuZGxlIHRoaXMuJm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09V VExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGUgaW50ZW5kIHdhcyB0byBzcGxpdCB0aGUg4oCTMDAgZHJhZnQgaW4gdHdvIGRv Y3VtZW50cyBiYXNlZCB1cG9uIFdHIGZlZWRiYWNrIGFib3V0IOKAkzAwIHZlcnNpb24uIE9uZSBk cmFmdCB0byBzcGVhayBhYm91dCB0aGUgYWRkcmVzcyBhbGxvY2F0aW9uIChCQ1AgdHlwZSBkb2Mp LCBhbmQgb25lIGluZm9ybWF0aW9uYWwgYWJvdXQgaW5mb3JtYXRpb24gaG93IHBhcmFtZXRlcnMg Y2FuIGJlIHNldCBmb3IgY29tbXVuaXR5IG5ldHdvcmtzLiBUaGlzDQogc2VjdGlvbiBpcyBzb21l dGhpbmcgdGhhdCBuZWVkcyB0byBiZSBjbGVhbmVkIHVwIGluIHRoZSDigJMwMyB2ZXJzaW9uIHdl IHdpbGwgY3JlYXRlLCBhbmQgaSBiZWxpZXZlIHNvbWUgY29udGVudCB3aWxsIGJlIGluIHRoZSBv dGhlciBkb2N1bWVudCB0aGF0IHdlIGludGVuZCB0byBjcmVhdGUgdG8gZG9jdW1lbnQgdGhvc2Ug c2V0dGluZ3MuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIGl0IHByb3ZpZGVz IHNvbWUgY29udGV4dCBhYm91dCB0aGlzIHNlY3Rpb24sIGFuZCB0aGUgZnV0dXJlIG9mIHRoZSB0 ZXh0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNv bG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1 bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1S SUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbTogPC9zcGFuPnY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAm cXVvdDtFcmljIFZ5bmNrZSAoZXZ5bmNrZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpldnlu Y2tlQGNpc2NvLmNvbSI+ZXZ5bmNrZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXkgMjEgSnVseSAyMDE2IGF0 IDE1OjM2PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ W3Y2b3BzXSB1bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QgcHVycG9zZSBvZiBOZWlnaGJvdXJz aGlwIERpc2NvdmVyeSBCZXN0IFByYWN0aWNlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KPGRpdj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyI+DQo8ZGl2Pkkgd29uZGVyIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc2VjdGlvbiA1IGluIGFu IEktRCB3aGljaCBpcyBhYm91dCBvbmUgcHJlZml4IHBlciBob3N0PzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+LcOpcmljPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bh bj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_40BB2F6D1F6E4EA3950BF9C0B69A5A6Aalcatellucentcom_-- From nobody Thu Jul 21 07:07:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89BE12D5F4 for ; Thu, 21 Jul 2016 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 kJTEZ8SgoWpm for ; Thu, 21 Jul 2016 07:06:59 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 37A2312D5C9 for ; Thu, 21 Jul 2016 07:06:59 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6LE4HXv034936 for ; Thu, 21 Jul 2016 10:06:59 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 24aytt84m9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jul 2016 10:06:58 -0400 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 u6LE6vZd015898 for ; Thu, 21 Jul 2016 10:06:57 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6LE6rZE015859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 21 Jul 2016 10:06:55 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor) for ; Thu, 21 Jul 2016 14:06:49 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.74]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 10:06:48 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: Letting apps select outbound path Thread-Index: AdHjWR8CKDBsUWgfQhCSr0A2o4GFUQ== Date: Thu, 21 Jul 2016 14:06:48 +0000 Message-ID: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607210156 Archived-At: Subject: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:07:05 -0000 In response to the comment about operators not wanting to let hosts determi= ne path... That's not relevant to the discussion of letting hosts or apps on hosts sel= ect the outbound link to use for their traffic in a multi homed environment= . The selection is already under the host / app control through source addr= ess selection. The question is how to allow the host/app to make an informe= d decision.=20 Barbara From nobody Thu Jul 21 08:24:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2812D6AB for ; Thu, 21 Jul 2016 08:24:38 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ORaTD1QNqPbw for ; Thu, 21 Jul 2016 08:24:35 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 5718712D69A for ; Thu, 21 Jul 2016 08:24:33 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id i5so29730802wmg.0 for ; Thu, 21 Jul 2016 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=a8YCQ+RnAZ+//kbGjKo/a+JV7joV1Hn+1pBs1HIkaTg=; b=yE1PQ8rOkjk+8LR75ScNcatT7R5UBU+OFGvXg6PgPF5aY3s8EvGIRnyKzLG6u3hQt4 79url5AjptvjeywpiHe2yvmro4VBD+x4Yb0/yr+sK8fCTYuHo8dYc+Y3SvuVNmn1Wgi5 b0Lk32sJxk1BsP09FcQav7tGZ1jaMFxPsGlbm1BDuv3tK2u8ihL7+RIkqGkzPiwTQdtP JcPUk15NAm5aZm7dVzr+9I2ZRFPV4M25iS6Hp4CA5vY9W7z103bZUIS8RUZTYqEKf5lI mxAVXfF1anmPVLiol2vNUR1Mk2iazE2pYY9+7/dmLfuEaKvlblZACIa7Z1mQxHeUlUtI MVKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=a8YCQ+RnAZ+//kbGjKo/a+JV7joV1Hn+1pBs1HIkaTg=; b=hNqZOiIDUvRQle2RiXS9eUlQBZdkTnEmcRboYW7iWShGbYNSOd5UEy6IdjP1phCSdQ 8TQDWfdn1s+ZFsszInScOf3iz3M56J92g5W2dujHSpGeGVqVuKlwcv1FaG6iyqJFOw70 n1fWLLnZvmbUjMnKG3hhkxTLXe0MoQGQjcgL866rgq35ZUHjdei5B8rSIP4SKpULb805 F6lYrv1elGEcMZ14IwehVkP4z7I4HTA/ppHOllHznczZM7+I+CCphNxXDvckTeVSloHu 0wbwbsnOXRMPxz24zxuLBm/A4fAaz7dJhyNtYYKcNbKC1hwI6TjhppuG0RIf9noAlS6i 3x4w== X-Gm-Message-State: ALyK8tLSkItbYRsN4aamQZGUh3our259fVP7FjBuou5vWCdCRJoNBbcBz31x9TNFS1sPBA== X-Received: by 10.28.96.11 with SMTP id u11mr19299431wmb.5.1469114671664; Thu, 21 Jul 2016 08:24:31 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:28cc:dc4c:9703:6781? ([2001:67c:370:160:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g184sm4843332wme.15.2016.07.21.08.24.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:24:31 -0700 (PDT) To: v6ops@ietf.org References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> Date: Fri, 22 Jul 2016 03:24:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:24:38 -0000 On 22/07/2016 02:06, STARK, BARBARA H wrote: > In response to the comment about operators not wanting to let hosts determine path... > That's not relevant to the discussion of letting hosts or apps on hosts select the outbound link to use for their traffic in a multi homed environment. The selection is already under the host / app control through source address selection. The question is how to allow the host/app to make an informed decision. And that is where the path probing performed by shim6 came in, and the effective probing done by MPTCP comes in. I never really understood why the operators hated shim6 with such a passion, but that's another story. They don't seem to hate MPTCP the same way. Brian From nobody Thu Jul 21 08:40:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D4B12D78D for ; Thu, 21 Jul 2016 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 Ph9azYXbSJZ9 for ; Thu, 21 Jul 2016 08:39:58 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A796A12D774 for ; Thu, 21 Jul 2016 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oFZvwJsVAdCfUUFu5l3W0q79q2A2Q562FTuh0U9nam4=; b=IJ8J4ORxAVoVTh7mZCdJUcOjsJij8TU4sf2xyXPcMw5Yo+EHWm+O6P70eaE+floWBLQSLzwFNNYmMRJnzsFQRhFH03kKJEKOPf1rgz9jtMgmozuYcbv7vbBKMBSx55/eb46/th0328jxnaYjQlCCMh3xt4C7iBaxfhU7HMHYi98= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0116.outbound.protection.outlook.com [213.199.154.116]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-28-xFI6Z5XoPM-YfjGR0tZiiA-1; Thu, 21 Jul 2016 16:39:50 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Thu, 21 Jul 2016 15:39:48 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.021; Thu, 21 Jul 2016 15:39:48 +0000 From: Tim Chown To: Brian E Carpenter Thread-Topic: [v6ops] Letting apps select outbound path Thread-Index: AdHjWR8CKDBsUWgfQhCSr0A2o4GFUQACt/+AAACSoYA= Date: Thu, 21 Jul 2016 15:39:48 +0000 Message-ID: References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> In-Reply-To: <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.155.0] x-ms-office365-filtering-correlation-id: 64ed0080-5bc1-4e52-f929-08d3b17d3f80 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:aWcVtopZ9hkWW89bH0D16t3AFXJ+Qjo4jlXRzTHllE9DBiZ2StmKGEcdgFFN4OkYexz7k9pdWs4sN9Q6WcWILpMZi9+x8IIM4TIhZHTX3wUIOcNrxV1bw6Z37If+59pOB1EP88ucnsXeHSeRInNLEH7dMjox00h4Uf4OOIX03gU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(60444003)(24454002)(102836003)(11100500001)(2950100001)(6116002)(2900100001)(586003)(3846002)(7736002)(7846002)(305945005)(8676002)(10400500002)(36756003)(122556002)(19580405001)(105586002)(19580395003)(5002640100001)(3660700001)(77096005)(3280700002)(97736004)(68736007)(50226002)(82746002)(110136002)(81156014)(81166006)(2906002)(4326007)(8936002)(189998001)(74482002)(101416001)(57306001)(83716003)(66066001)(106356001)(76176999)(50986999)(92566002)(87936001)(33656002)(86362001)(7756004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <4D89887459708E46B6EE9C2F2AF1C559@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 15:39:48.2876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: xFI6Z5XoPM-YfjGR0tZiiA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:40:08 -0000 > On 21 Jul 2016, at 16:24, Brian E Carpenter = wrote: >=20 > On 22/07/2016 02:06, STARK, BARBARA H wrote: >> In response to the comment about operators not wanting to let hosts dete= rmine path... >> That's not relevant to the discussion of letting hosts or apps on hosts = select the outbound link to use for their traffic in a multi homed environm= ent. The selection is already under the host / app control through source a= ddress selection. The question is how to allow the host/app to make an info= rmed decision.=20 >=20 > And that is where the path probing performed by shim6 came in, and the ef= fective > probing done by MPTCP comes in. I never really understood why the operato= rs hated > shim6 with such a passion, but that's another story. They don't seem to h= ate MPTCP > the same way. But was that really the issue, or was it simply crappy handling of (especia= lly =93unknown") IPv6 Extension Headers? Regardless, choice of path from a home or an enterprise shouldn=92t be of i= nterest to an ISP, should it? In the IPv6 multi-addressed multihoming model= , they shouldn=92t even need to know if you have one or more other ISPs con= nected to your network. All you=92d expect is that they BCP38 what they tak= e from you. Tim From nobody Thu Jul 21 08:43:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBBE12D640 for ; Thu, 21 Jul 2016 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 RrWTHMi1j-tb for ; Thu, 21 Jul 2016 08:43:30 -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 93D3C12D66A for ; Thu, 21 Jul 2016 08:43:30 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B6EC660249 for ; Thu, 21 Jul 2016 17:43:28 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 663AF60248; Thu, 21 Jul 2016 17:43:28 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 550AC26BC8; Thu, 21 Jul 2016 17:43:28 +0200 (CEST) Date: Thu, 21 Jul 2016 17:43:28 +0200 From: Gert Doering To: "STARK, BARBARA H" Message-ID: <20160721154328.GG79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:43:32 -0000 Hi, On Thu, Jul 21, 2016 at 02:06:48PM +0000, STARK, BARBARA H wrote: > In response to the comment about operators not wanting to let hosts determine path... > That's not relevant to the discussion of letting hosts or apps on hosts select the outbound link to use for their traffic in a multi homed environment. The selection is already under the host / app control through source address selection. The question is how to allow the host/app to make an informed decision. I haven't followed the discussion, but I assume it's the usual misunderstanding that not all networks are borne equal. In a fully managed, administrator controlled enterprise environment, having hosts decide routing policy is a no-go area. In a homenet / SOHO environment, there is no administrator, and nobody will install policies in "WAN devices" - so the host *MUST* make the decision, because nobody else is around. As Barbara said: giving the host data to make this an *informed* decision is good. 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 Thu Jul 21 08:52:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D06B12D69C for ; Thu, 21 Jul 2016 08:52:45 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7GbDFEHENGmV for ; Thu, 21 Jul 2016 08:52:42 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 2B92612D75F for ; Thu, 21 Jul 2016 08:52:42 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id f93so65755853lfi.2 for ; Thu, 21 Jul 2016 08:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ljKLOQVu2cwVlikCN9YdXuzGWW97uTvRACgvJo/4zf8=; b=vV8XwvPJmY9Uuj4E+q6T28obEsPvIoGj4uCZXpNt/bQ5qaNeis5uw8s+5W0mrVMcEB O/WNebpZXv7uOY63QPirDTebvNeJUcXc6YB0LoUTcnBE5nVOqV4RAidq263xxHK3lkdE A1G0E8z/xNSo7tdBTZLCsdwgiyslTbk5ZxE6jGqC5/6QFkHuDScv1vRLjGgjB3qemrP6 7qkJlJAK9SK+gd0DhKLtK4DMiZzAGA5w/iHRvdsn1dWAa7nEn1tXzbjqSDHpQKPbxYGs HfzDqptToEjiq2/jeOuhGhozJ9mN61tRnDF5wFvxgvaHkx3MVjklaIoxw+y87pDXkrPw KCdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ljKLOQVu2cwVlikCN9YdXuzGWW97uTvRACgvJo/4zf8=; b=E7WtDArmeA7iQ1K+9qhm4eGogsBXfm3CXdCEZL8Syt1jRKc75kXxGU0vRkWRpGiqnS bpsKoDY0kOLhDtdwX3eKR5LId7gstnm5gIUj9+Rp4+l73XqOQH6DgLxYWTAVYf+stGfu TK5V0nTBAt8LmYocpRgjUw2UtzceWONAeT4txPglp3N6fad+02l8APzPP/iUtTaxwFEc tn4N3ShQCEbq0jkDnvKdqsT++wZuW8JQMh+n1Snd+IAaZRRrVcXjOpkln6NPkzGNWCp+ DWoGvdBIuXcPQKgTn1HmHveYxV0MWxIWJQ94pNh9/X7es4sZXJoxsUt+39MyHcKdmMx+ pq6A== X-Gm-Message-State: ALyK8tJMVIoRgEGdZxUa89PIsfZtI0bbw//cWDg9fUi+oSiH2XRjW8PTiSgtRi4/1bPChQ== X-Received: by 10.25.133.138 with SMTP id h132mr22774255lfd.210.1469116360353; Thu, 21 Jul 2016 08:52:40 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:28cc:dc4c:9703:6781? ([2001:67c:370:160:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f4sm2000096lji.41.2016.07.21.08.52.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:52:39 -0700 (PDT) To: Gert Doering , "STARK, BARBARA H" References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> Date: Fri, 22 Jul 2016 03:52:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160721154328.GG79185@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:52:45 -0000 On 22/07/2016 03:43, Gert Doering wrote: > Hi, > > On Thu, Jul 21, 2016 at 02:06:48PM +0000, STARK, BARBARA H wrote: >> In response to the comment about operators not wanting to let hosts determine path... >> That's not relevant to the discussion of letting hosts or apps on hosts select the outbound link to use for their traffic in a multi homed environment. The selection is already under the host / app control through source address selection. The question is how to allow the host/app to make an informed decision. > > I haven't followed the discussion, but I assume it's the usual > misunderstanding that not all networks are borne equal. > > In a fully managed, administrator controlled enterprise environment, having > hosts decide routing policy is a no-go area. Sure. But nobody ever proposed that - all the host can do is select a source/destination address pair. That impacts where the packets flow but doesn't touch routing policy itself. Brian > In a homenet / SOHO environment, there is no administrator, and nobody > will install policies in "WAN devices" - so the host *MUST* make the > decision, because nobody else is around. As Barbara said: giving the > host data to make this an *informed* decision is good. > > Gert Doering > -- NetMaster > From nobody Thu Jul 21 08:54:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79812D767 for ; Thu, 21 Jul 2016 08:54:04 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VbSh1gq304Cd for ; Thu, 21 Jul 2016 08:54:01 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 C7C3312D777 for ; Thu, 21 Jul 2016 08:53:59 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id q128so26561173wma.1 for ; Thu, 21 Jul 2016 08:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=e3OzgNtGKf6h+/PYxQjEndhLaAJXJBn5up+xkizcRkg=; b=GCNxNqpSBv6irertyvipOdRwPNUAFv5KjjV4miwCue4KuThT6UdS6wxlkLHtOEtIQL ImF3x2IEMioxkhtOyYRiA8HoXrpkv7I8sQ1AEvU8Fmi2vlfq2Er+G+iC2wUVVpij2G1B D40D8Pfcn+dCyOsXeKhrVIm8UeiFEvq4F1/cqXXIfCc3QJwZB3lxq8Eg3vkDugkJVaVT i9B2+PwNU6Aqu+UO029S6nmMsP/spmm6Y0hhCDlBQo0HDM1A8fz/4KqdJSc0VwKC26+1 wjyyhcxupkYH3F9U+pCU3y/axULWppmWOgG0/mQxOa3O40zHnPbU6dOzUmjTElG0wRWk LJGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=e3OzgNtGKf6h+/PYxQjEndhLaAJXJBn5up+xkizcRkg=; b=Ek2CBcZO/0b5pUDTtYmZ+GEvvgB2MXEn/8ZMXmjvsYyy7MK7PQZWRKyIG6NxoHL40o rrcQ3sti/G/kBUrh+DNp5IYKPORp8NobNbte72kVdpsSahf+sneNB37XcJuHYujqnEJx r0Dn9PDCo043yyB/ybhCpqkjk9iLqxyj0UcIL8Xr3EwDrOMfCRdBkFc8Mz7VsaSI2Xku +oWWHo6dgtvNdf9Fs1olAQ7H3jxFho3JmTdapturnbLeDmSEWTdyHIuXMYiW/TLjS1DC wCIObHhzFwfK5g8+LbOlkoD3USHFwdfvBECBoeYB5ahkP813xC2nble0Iv395te82S08 dAcA== X-Gm-Message-State: ALyK8tKMZVakhAQRA9s7wksMOvXHvTFImFPQrJ28Dti5BD4xjbKbsh2XCXipJXV7csctEw== X-Received: by 10.28.92.71 with SMTP id q68mr2224626wmb.85.1469116438304; Thu, 21 Jul 2016 08:53:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:28cc:dc4c:9703:6781? ([2001:67c:370:160:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w129sm5052350wmd.9.2016.07.21.08.53.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 08:53:57 -0700 (PDT) To: Tim Chown References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1abb23f5-5364-3e79-1c7f-652737ffa695@gmail.com> Date: Fri, 22 Jul 2016 03:54:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:54:05 -0000 On 22/07/2016 03:39, Tim Chown wrote: >> On 21 Jul 2016, at 16:24, Brian E Carpenter wrote: >> >> On 22/07/2016 02:06, STARK, BARBARA H wrote: >>> In response to the comment about operators not wanting to let hosts d= etermine path... >>> That's not relevant to the discussion of letting hosts or apps on hos= ts select the outbound link to use for their traffic in a multi homed env= ironment. The selection is already under the host / app control through s= ource address selection. The question is how to allow the host/app to mak= e an informed decision.=20 >> >> And that is where the path probing performed by shim6 came in, and the= effective >> probing done by MPTCP comes in. I never really understood why the oper= ators hated >> shim6 with such a passion, but that's another story. They don't seem t= o hate MPTCP >> the same way. >=20 > But was that really the issue, or was it simply crappy handling of (esp= ecially =E2=80=9Cunknown") IPv6 Extension Headers? That came later, the NANOG abreaction was long before we discovered how b= ad that problem was. Brian > Regardless, choice of path from a home or an enterprise shouldn=E2=80=99= t be of interest to an ISP, should it? In the IPv6 multi-addressed multih= oming model, they shouldn=E2=80=99t even need to know if you have one or = more other ISPs connected to your network. All you=E2=80=99d expect is th= at they BCP38 what they take from you. >=20 > Tim >=20 >=20 From nobody Thu Jul 21 10:20:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F2D12D104 for ; Thu, 21 Jul 2016 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 koihnbqwZXcU for ; Thu, 21 Jul 2016 10:20:37 -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 91D4D12D0D1 for ; Thu, 21 Jul 2016 10:20:36 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D68F96093A for ; Thu, 21 Jul 2016 19:20:33 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 9435D60248; Thu, 21 Jul 2016 19:20:33 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 83468250BE; Thu, 21 Jul 2016 19:20:33 +0200 (CEST) Date: Thu, 21 Jul 2016 19:20:33 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20160721172033.GI79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NG8Hw1stB4iVQNG4" Content-Disposition: inline In-Reply-To: <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:20:43 -0000 --NG8Hw1stB4iVQNG4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2016 at 03:52:47AM +1200, Brian E Carpenter wrote: > > I haven't followed the discussion, but I assume it's the usual=20 > > misunderstanding that not all networks are borne equal. > >=20 > > In a fully managed, administrator controlled enterprise environment, ha= ving > > hosts decide routing policy is a no-go area. >=20 > Sure. But nobody ever proposed that - all the host can do is select > a source/destination address pair. That impacts where the packets flow > but doesn't touch routing policy itself. In a fully controlled environment, you don't want the hosts to make decisions (unless directed by configured policy). I just wanted to=20 point out that "enterprise" and "SOHO" are really totally different problem spaces regarding multihoming and "who makes decisions?". 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 --NG8Hw1stB4iVQNG4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXkQReAAoJEN9WwGXkzn/F6o8P/3Cfj4lw1nCqP7u6vVKLRzyZ jg+0vv/vM3k/ZbURkNHdCsH7Q2Fc75p/c14DFkaI9ZcWb3ncgcparLpOejy8YMjb M9E9sYDYvSJ27rtZsP+4Bdav2ngV+bmhIMBjFZqrDX3FI8zX2uX6kqV0gfFKiI3y TKfvkKAd80p+eRmXuz7S5mkxxmGEwXEYYqQ9BNPPdPDyAmAk+p+rlfuVbFyfSgvj 38gowsnaliz991wVagPhn+h+Sl4TdtZ9TtKqv5JMbKS3iDReUgPjZpULFp11JgTU hb8SNusN+Rpyh9mK8c3GJsYYeAJc7DkNeRAd+oTkF1pqQyz1Rhlj9hTd/ozdU5Xg 285hwn9SId34ifZnN4RAHfo9Vy/vWx0M+0RAZjpsH1oi+kITWe6y93dtbOqsNhOb nYGGpvCjrq6m+DOaooVwHp4rkH3H4Tmx/3B2twb78SldKLIR8h7sS30WsQQAOV9w 3mer4Ci1SBMzUpP1Hi7csY3WvVphMd85NmkW10m0Nnhyy7UgSTdck4EWgsJDmxvB yQUv5qAG2IemsFUpGaI4UCNSL0tA8zpzF13t+IxW9UJRfLzTeyVTYDpFzZ2lY0Lz pjMIYpD3W5l63O8DEk60QTP2mxewFW/e0ROys/5h51tnnjJWzFMLnUfuNtgvQBvJ p8kVy6LXcSo92NwhBRKi =ztyg -----END PGP SIGNATURE----- --NG8Hw1stB4iVQNG4-- From nobody Thu Jul 21 10:22:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED33812D61A for ; Thu, 21 Jul 2016 10:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 QsuK4ZAKR2-q for ; Thu, 21 Jul 2016 10:22:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 C330712D619 for ; Thu, 21 Jul 2016 10:22:52 -0700 (PDT) Received: from [128.9.184.116] ([128.9.184.116]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6LHMDhM025515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2016 10:22:13 -0700 (PDT) To: v6ops@ietf.org References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> From: Joe Touch Message-ID: <579104C5.2020109@isi.edu> Date: Thu, 21 Jul 2016 10:22:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.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: Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:22:55 -0000 On 22/07/2016 02:06, STARK, BARBARA H wrote: > In response to the comment about operators not wanting to let hosts determine path... > That's not relevant to the discussion of letting hosts or apps on hosts select the outbound link to use for their traffic in a multi homed environment. The selection is already under the host / app control through source address selection. A source address might be bound to multiple interfaces. Existing requirements account for the application having control over the source and destination L3 *address*, nothing more. They do NOT control interface selection except as a *side effect* of controlling those addresses. Joe From nobody Thu Jul 21 10:30:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A2E12D7B6 for ; Thu, 21 Jul 2016 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 XJ4RDEE7YkxJ for ; Thu, 21 Jul 2016 10:30:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 733BE12D7D4 for ; Thu, 21 Jul 2016 10:30:25 -0700 (PDT) Received: from [128.9.184.116] ([128.9.184.116]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6LHTKmH027709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2016 10:29:21 -0700 (PDT) To: v6ops@ietf.org References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <3c5a37a2-6c42-5236-98a4-780709694ede@gmail.com> <579104C5.2020109@isi.edu> From: Joe Touch Message-ID: <57910671.7090802@isi.edu> Date: Thu, 21 Jul 2016 10:29:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <579104C5.2020109@isi.edu> 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: Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:30:27 -0000 On 7/21/2016 10:22 AM, Joe Touch wrote: > On 22/07/2016 02:06, STARK, BARBARA H wrote: > >> In response to the comment about operators not wanting to let hosts determine path... >> That's not relevant to the discussion of letting hosts or apps on hosts select the outbound link to use for their traffic in a multi homed environment. The selection is already under the host / app control through source address selection. > A source address might be bound to multiple interfaces. > > Existing requirements account for the application having control over > the source and destination L3 *address*, nothing more. They do NOT > control interface selection except as a *side effect* of controlling > those addresses. > > Joe PS - to see the confusion that ensues when you release control from the forwarding plane to anyone else, see RFC 3884. I.e., let's not let apps create the kind of problems that came out of IPsec tunnel mode when it tried to embed forwarding control outside the IP data plane. Joe From nobody Thu Jul 21 13:00:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA79812D8D8 for ; Thu, 21 Jul 2016 13:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 066gtRl7dBvC for ; Thu, 21 Jul 2016 13:00:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E01712D567 for ; Thu, 21 Jul 2016 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4446; q=dns/txt; s=iport; t=1469131217; x=1470340817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ti9JfppjbZkjiL0GQVYs6yX0cynw3LatGH/hh6Yd8zg=; b=UP5dzWVrsrEcU3Dxj85R5Ne/F10KPNuHgWmo0PCuj91FFYePbiYKI6P+ gskS/9uRR6bZhXp9tu0cpSlvRH05PwRzN/EqTR6Tb4adG/h8ovKJco9cr 8fIfACKYLuO01pD2ll/hcCfAixPBJ/PvAyqD833K3Y43sjrt7FXabUTiS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAwAvKZFX/5FdJa1dgnFOgVKzWoUEg?= =?us-ascii?q?XuGGgKBMDgUAQEBAQEBAWUnQQ4BhA0BBS1MEAIBCAQULjIlAQEEDgUIiCi9agE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARyKd4obBZkmAY5jj0GQIAEeNoIGgW1ughCFb?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,400,1464652800"; d="scan'208,217";a="131363418" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 20:00:16 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6LK0GwI022234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 20:00:16 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 15:00:16 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 15:00:16 -0500 From: "Toerless Eckert (eckert)" To: Gert Doering Thread-Topic: [v6ops] Letting apps select outbound path Thread-Index: AdHjWR8CKDBsUWgfQhCSr0A2o4GFUQAN2nEAAABTTIAAAxCygP//2M7l Date: Thu, 21 Jul 2016 20:00:16 +0000 Message-ID: <6b564ea8ae884ca09b8f575bb9bd60c5@XCH-RCD-003.cisco.com> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com>, <20160721172033.GI79185@Space.Net> In-Reply-To: <20160721172033.GI79185@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_6b564ea8ae884ca09b8f575bb9bd60c5XCHRCD003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 20:00:22 -0000 --_000_6b564ea8ae884ca09b8f575bb9bd60c5XCHRCD003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Host has 2 addresses =3D=3D configured policy. If your where an enterprise and your SP recommended you to set dscp for tra= ffic according to the app requirements to get best results. How would you d= o that ? typos =3D smartphone On Jul 21, 2016 7:21 PM, Gert Doering wrote: Hi, On Fri, Jul 22, 2016 at 03:52:47AM +1200, Brian E Carpenter wrote: > > I haven't followed the discussion, but I assume it's the usual > > misunderstanding that not all networks are borne equal. > > > > In a fully managed, administrator controlled enterprise environment, ha= ving > > hosts decide routing policy is a no-go area. > > Sure. But nobody ever proposed that - all the host can do is select > a source/destination address pair. That impacts where the packets flow > but doesn't touch routing policy itself. In a fully controlled environment, you don't want the hosts to make decisions (unless directed by configured policy). I just wanted to point out that "enterprise" and "SOHO" are really totally different problem spaces regarding multihoming and "who makes decisions?". 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 --_000_6b564ea8ae884ca09b8f575bb9bd60c5XCHRCD003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Host has 2 addresses =3D=3D configured policy.

If your where an enterprise and your SP recommended you to s= et dscp for traffic according to the app requirements to get best results. = How would you do that ?

typos =3D smartphone

On Jul 21, 2016 7:21 PM, Gert Doering <gert@space= .net> wrote:
Hi,

On Fri, Jul 22, 2016 at 03:52:47AM +1200, Brian E Carpenter wrote:
> > I haven't followed the discussion, but I assume it's the usual > > misunderstanding that not all networks are borne equal.
> >
> > In a fully managed, administrator controlled enterprise environme= nt, having
> > hosts decide routing policy is a no-go area.
>
> Sure. But nobody ever proposed that - all the host can do is select > a source/destination address pair. That impacts where the packets flow=
> but doesn't touch routing policy itself.

In a fully controlled environment, you don't want the hosts to make
decisions (unless directed by configured policy).  I just wanted to point out that "enterprise" and "SOHO" are really total= ly different
problem spaces regarding multihoming and "who makes decisions?".<= br>
Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG          &nbs= p;             = Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14        &n= bsp; Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen          = ;         HRB: 136055 (AG Muenchen)=
Tel: +49 (0)89/32356-444        = ;   USt-IdNr.: DE813185279
 --_000_6b564ea8ae884ca09b8f575bb9bd60c5XCHRCD003ciscocom_-- From nobody Thu Jul 21 13:15:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8C912B04B for ; Thu, 21 Jul 2016 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 e0bHb3iEPJn2 for ; Thu, 21 Jul 2016 13:15:00 -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 B904E12B027 for ; Thu, 21 Jul 2016 13:14:59 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1B4A36093A for ; Thu, 21 Jul 2016 22:14:58 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id DEE4260249; Thu, 21 Jul 2016 22:14:57 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id DB79E25625; Thu, 21 Jul 2016 22:14:57 +0200 (CEST) Date: Thu, 21 Jul 2016 22:14:57 +0200 From: Gert Doering To: "Toerless Eckert (eckert)" Message-ID: <20160721201457.GR79185@Space.Net> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <6b564ea8ae884ca09b8f575bb9bd60c5@XCH-RCD-003.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RzeXDTTMi1+808ej" Content-Disposition: inline In-Reply-To: <6b564ea8ae884ca09b8f575bb9bd60c5@XCH-RCD-003.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 20:15:03 -0000 --RzeXDTTMi1+808ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 21, 2016 at 08:00:16PM +0000, Toerless Eckert (eckert) wrote: > Host has 2 addresses =3D=3D configured policy. >=20 > If your where an enterprise and your SP recommended you to set dscp for t= raffic according to the app requirements to get best results. How would you= do that ? Please do not mix in arbitrary complications. This was about address selection, and address selection influencing ISP selection. 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 --RzeXDTTMi1+808ej Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXkS0+AAoJEN9WwGXkzn/FkLcQAIxiit4AfFiGs/t4pDIR8Ar/ 0MS6Zhyfqk6dZY3S+SxbiWN7R5kstWBzFbiRItR/ZfPSNA6jNVNE3jsdMzudO7jK FAoAVejhODgwPe7LiIgu54AdGDVx8kJTsr+m0EPtYPyuR6n1VCOX49P/tuSFWX1j ImTwYNMosI8dZxWeMtAmt4WMnXY2BN0IAM4NVFT9odHpkBwpH/hBDJ4YKy677RYk chDRrlWWH2qxL3c8qLkkmw2L9q2q41Sh2OAsgpKtjvKs1EU2OG1N9V5nG85XhHeV SiPLyew/OzGN5gS0R15TlVWrVvxL1NThrGTCyQqgYbXoQYqPX3PUghtcw985m10I NMgojENpzQVLsZEFUVY5K1VXQH5wEXZnG1FQ9iFRKvk/L3VeyxNE3r5gO2iCUGzu 6PfxnUtWI7/y6glsue26YqtonXSauiL4CXquUnelb12vPE0ekAvisK1eu0DrDvtV hfRwQk5lqIX6GUjqZIS27Jvm8jmiRbEr32qbvBis6D/wWkh8WHpZSZyDjei2z9qP xzAhe40ffAPFMZlnUkDHMoQoEoAKvKh4Mqf/M09CYM4Cdx5mzRWYT9xDk6a2c91G YQT086HcFQ3XkKx4wPbWcmnLTXN3DqqM3ZZLXwSdS8O98L7cG1dQvjprkXqWpq0G +7D0UkS+7J0wRt2UEN2U =b9H9 -----END PGP SIGNATURE----- --RzeXDTTMi1+808ej-- From nobody Fri Jul 22 00:04:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A107E12D699 for ; Fri, 22 Jul 2016 00:04:41 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 efPV93cyO9pr for ; Fri, 22 Jul 2016 00:04:40 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 E3FD512D67A for ; Fri, 22 Jul 2016 00:04:39 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o80so52219054wme.1 for ; Fri, 22 Jul 2016 00:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xz1cAdaeZHjibd67GW46PLndM8RpTmYOvo7ja/WH53g=; b=vALKpfIXn3TuVeqlug34ugLN6yWHE5v3va3PxKBfCLQz2X/d+maKcRzKAxYyPP92I9 nb8Y4eNgcWd795zY4XS+4EH9lCOj9+66iEfNolaw6x2zkAKJOr2B/87NJOsHObeOjls5 9Hamae7Y2C/Ap4u8Yk6YY+859zw1oWvKzl1lQ0ztSPh9nJOfmD+bF0Soq3SQc/hcHAaK VjTZbWNdgGTphxyDG+SZb/AIWWKz+7JsKc9QgyCXC/T8Uu7106koc/L3FgbhDgle/oiw MlKtXDtzGEq0xjF5vIELeZWHfUaZ+NOhzgEfG7LRiMdcHhF7bfSG6WWuDRxA7Tw0gf0R Gjig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xz1cAdaeZHjibd67GW46PLndM8RpTmYOvo7ja/WH53g=; b=YFyiUfVOCzwE+JoQRPEQU4Viu0JTwluTVm78FyBBLPV3rvIFror4Ol0NLEy+KZjy8j 1mmBFD1/lBbNvi6sGRWIosy5nBzSuXZZIdIw2Pdd0bOXomkKMr2+0JTkpIHMTDBoW0BZ ychsq7AjBbFA3td8tnRthQz0dAc/g9HH1hAg1HV04XSn6oXB8mojyDh2oe4NzNQn5CUO /NgG779ZQx44yi6tIe9TCoK2de3qSu8gQg+RhJfJseb+KGQdfPsM942fsOzf03+UfKkT kIu3rCEIqOPzX+cXpLdJccPtPOCylolaoQRUznd5l0J1K3soggWZjhtc0KkAjFMMKdVj hKEg== X-Gm-Message-State: AEkoout/w4yADc4/5nyFTckONa+P0mS3dDazwL/eU/56e2fn9Z/imGA2q8en3dmOfQrKwg== X-Received: by 10.28.47.199 with SMTP id v190mr3497843wmv.28.1469171078492; Fri, 22 Jul 2016 00:04:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c16sm10725463wme.4.2016.07.22.00.04.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 00:04:37 -0700 (PDT) To: Gert Doering , "Toerless Eckert (eckert)" References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <6b564ea8ae884ca09b8f575bb9bd60c5@XCH-RCD-003.cisco.com> <20160721201457.GR79185@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <30fb725e-4926-f7b0-ef2c-d76f2561d960@gmail.com> Date: Fri, 22 Jul 2016 19:04:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160721201457.GR79185@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:04:41 -0000 On 22/07/2016 08:14, Gert Doering wrote: > Hi, > > On Thu, Jul 21, 2016 at 08:00:16PM +0000, Toerless Eckert (eckert) wrote: >> Host has 2 addresses == configured policy. >> >> If your where an enterprise and your SP recommended you to set dscp for traffic according to the app requirements to get best results. How would you do that ? > > Please do not mix in arbitrary complications. This was about address > selection, and address selection influencing ISP selection. Yes, I think we can't add that layer of complexity here. Possibly this is covered by the MIF provisioning domain concept? (If you believe in that particular kind of magic, that is.) Or by a connection manager. Brian From nobody Fri Jul 22 09:47:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE96A12DE4D for ; Fri, 22 Jul 2016 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 gFTzRmJfENfd for ; Fri, 22 Jul 2016 09:47:32 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A081012DE46 for ; Fri, 22 Jul 2016 09:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1969; q=dns/txt; s=iport; t=1469206052; x=1470415652; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=vwqVas5sJb7NVcftzujvwtY4tAExBhyqPB9O/xNX4I0=; b=VtEaMLjTNGuH0wxSAgtKgCOBwLRWj+gOiyjn9mdBWv+ugypFw19Dhx2t /46WSqlbS4saz0lYB+G2O4U7GQO26d8H7Gsm0/cTP5+HHbW6lLeoabGt1 s67kKew3IH3gmXKmGAzlhofXIMsORspZqafEI4mokA55UVal/ThU/phV3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AwAMTZJX/4wNJK1egz+6MoF7hhwCg?= =?us-ascii?q?TA4FAEBAQEBAQFdJ0EOAYQNAQU6PxALGAklDwVJLogVu08BAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEcineHbIIvBY8BiiUBjmMKgWyEWYh1kCEeNoQTHIVxgzQBAQE?= X-IronPort-AV: E=Sophos;i="5.28,405,1464652800"; d="scan'208";a="301079864" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2016 16:47:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6MGlVJu013479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 16:47:31 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6MGlVpE026996; Fri, 22 Jul 2016 09:47:31 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6MGlUgl026995; Fri, 22 Jul 2016 09:47:30 -0700 Date: Fri, 22 Jul 2016 09:47:30 -0700 From: "Toerless Eckert (eckert)" To: Brian E Carpenter Message-ID: <20160722164730.GA26081@cisco.com> References: <4067F8A1-2720-42B7-927F-A7341D3AB7EE@att.com> <20160721154328.GG79185@Space.Net> <32c3859f-ba58-ca5a-ddcc-836a52a92f7c@gmail.com> <20160721172033.GI79185@Space.Net> <6b564ea8ae884ca09b8f575bb9bd60c5@XCH-RCD-003.cisco.com> <20160721201457.GR79185@Space.Net> <30fb725e-4926-f7b0-ef2c-d76f2561d960@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30fb725e-4926-f7b0-ef2c-d76f2561d960@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Letting apps select outbound path X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 16:47:34 -0000 *sigh* I brought that up to help me understand what the term "fully controlled" would mean in other similar contexts. Its just not very helpful to say "can't do MultiPrefix because fully conrolled network" when you're not willing to explain what "Fully controlled" is supposed to mean. I didn't mean at all to say that we should bother about DSCP design in this discussion. Enterprises should definitely have the ability to define/control source address selection through enterprise operator defined policy. But we'd need to start collecting what those policies should be to design the right solution. And yes, if hosts / apps override the target policy we need security to prohibit this. Thats not differrent from any other security policy (DSCP comes to mind, or if thats a red flag any other firewall / security functions). And lets also understand that there will be fewer and fewer enterprise specific apps, so we'd definitely be well advised to come up with a host model where apps can develop against the expectation to support whats desired in the home, and then also work well in an enterprise. Cheers Toerless On Fri, Jul 22, 2016 at 07:04:46PM +1200, Brian E Carpenter wrote: > On 22/07/2016 08:14, Gert Doering wrote: > > Hi, > > > > On Thu, Jul 21, 2016 at 08:00:16PM +0000, Toerless Eckert (eckert) wrote: > >> Host has 2 addresses == configured policy. > >> > >> If your where an enterprise and your SP recommended you to set dscp for traffic according to the app requirements to get best results. How would you do that ? > > > > Please do not mix in arbitrary complications. This was about address > > selection, and address selection influencing ISP selection. > > Yes, I think we can't add that layer of complexity here. Possibly this > is covered by the MIF provisioning domain concept? (If you believe in that > particular kind of magic, that is.) Or by a connection manager. > > Brian From nobody Sat Jul 23 21:15:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2212D08D for ; Sat, 23 Jul 2016 21:15:35 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YibCrUAcNM-G for ; Sat, 23 Jul 2016 21:15:34 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 40AD812B014 for ; Sat, 23 Jul 2016 21:15:34 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6so79107362ith.0 for ; Sat, 23 Jul 2016 21:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=QE5GB7z2ZOV+2x5EQkAwLqIqG/P7wHsXvPprXJyr1Es=; b=y+pDteU7Kp74AaMnUZrcqfN6seSNkU5M2Qak9L7JMQ+3AHfqTxVtRqctU8c6kXMFRR HEW8CjJbJXoFMMVjqc+8PHXSb/xQwLkUceSRnknQu+l+3dAFkejZyt4P7+8dTO2irJF7 qYnNHPBND44xHqjsR8I7ck9V9rs2tF0kCDuve1BAnMr+IlJJn06Ah4rkNTyf4N5CySqk xH/Lw1jZABSkeSaaVA+0H4k0kbcuAJmsdyd9qlLqMSLZRWEufN8b4YzmKYh1XB/4otcJ Mm9oBUElQnLM35Xu01cdwCQbh7w5yW6+bq8tqUvpvEqdlPi0zwVX0ThDkg9l8F2JMUTn JuXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QE5GB7z2ZOV+2x5EQkAwLqIqG/P7wHsXvPprXJyr1Es=; b=VEpyficybFUuTR2xz5OD4COQGEihAV/QBwInjdKtGjIp0u7kRqZ58EMqerZNI4FbZT x+K2P8tCeEjawrQ4CFzBCrfog3aQc+2XO7FlqE3byfUGaGI1wbFslQiH/DnEZapMjQCJ 9/EuBuO8SmHPpzW3BvN/C+cHhwbGLX4tfVuuIjgZ/L/YlvSUFfFU6JsyoW0Ef6lst/Rk X5ORaHa63eK0tGL7VQAtjO0E66xmLuoT2ls9+BL9tKx0xOrGf49fB1QFP64WVGaw1Sby Tsk5yngSMsNX4+DkJuKbi0zkrf+bmAlzCbUGwUfEx9zjAgVaa8tNVOe6yD9b+JcY+nJv AzFA== X-Gm-Message-State: AEkoous6zIU9qz7qDRaS6Dqths8VckQFx3Bl/4pg58nN8xyo1+0t8iC/VJSIKJTyijHwjFZD7PUqPx/ICsAaxA== X-Received: by 10.36.144.68 with SMTP id x65mr10441596itd.70.1469333733211; Sat, 23 Jul 2016 21:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.165.67 with HTTP; Sat, 23 Jul 2016 21:14:53 -0700 (PDT) From: "Mukom Akong T." Date: Sun, 24 Jul 2016 06:14:53 +0200 Message-ID: To: IPv6 Operations Content-Type: multipart/alternative; boundary=94eb2c07e80639b872053859eb40 Archived-At: Subject: [v6ops] Completeness of DNS Parameter Provisioning in draft-jjmb-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 04:15:36 -0000 --94eb2c07e80639b872053859eb40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 Section 4 says [snip] The architected result of designing the RA as documented above is that each UE/subscriber gets its own unique /64 IPv6 prefix for which it can use SLAAC or any other method to select its /128 unique address. In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address. If the UE/ subscriber desires to send anything external including other UE/ subscriber devices (assuming device to device communications is enabled and supported), then due to the L-bit set it SHOULD send this traffic to the First Hop Provider Router. [/snip] Question #1 Any reason for silence about the possibility of passing DNS parameters within the RAs as per RFC 6106? Perhaps the statement " In addition, it will use stateless DHCPv6 to get the IPv6 address of the DNS server ..." may be replaced with "The UE depending upon its capabilities should get DNS information either from the RA as per RFC6106 or via stateless DHCPv6" --=20 Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --94eb2c07e80639b872053859eb40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Section 4 says

[snip]

The architected result of designing t=
he RA as documented above is
   that each UE/subscriber gets its own unique /64 IPv6 prefix for which
   it can use SLAAC or any other method to select its /128 unique
   address.  In addition it will use stateless DHCPv6 to get the IPv6
   address of the DNS server, however it SHOULD NOT use stateful DHCPv6
   to receive a service provider managed IPv6 address.  If the UE/
   subscriber desires to send anything external including other UE/
   subscriber devices (assuming device to device communications is
   enabled and supported), then due to the L-bit set it SHOULD send this
   traffic to the First Hop Provider Router.

[/snip]

Question #1


=
Any reason for silence about the =C2=A0possibility of passing DN= S parameters within the RAs as per RFC 6106?

Perha= ps the statement=C2=A0

" In addition, it will= use stateless DHCPv6 to get the IPv6 address of the DNS server ..."

may be replaced with

"= ;The UE depending upon its capabilities should get DNS information either f= rom the RA as per RFC6106 or via stateless DHCPv6"


--

Mukom Akong T.

LinkedIn:Mukom=C2=A0=C2=A0| =C2=A0twitter: @p= erfexcellent =C2=A0
    -------= ---------------------------------------------------------------------------= --------------------------------------------------------
    =E2=80=9CWhen y= ou work, you are the FLUTE through whose lungs the whispering of the hours = turns to MUSIC" - Kahlil Gibran
    -----------------------------------= ---------------------------------------------------------------------------= -----------------------------
    --94eb2c07e80639b872053859eb40-- From nobody Sat Jul 23 23:41:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5958A12D7BE; Sat, 23 Jul 2016 23:41:10 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Js20yKDzL9LH; Sat, 23 Jul 2016 23:41:08 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 0CD3712D17A; Sat, 23 Jul 2016 23:41:08 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id j124so81119840ith.1; Sat, 23 Jul 2016 23:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DC7pK9xbaAiQ9K4cRJhg63v1wnAj2SYYRJ011w0qUM8=; b=TTPz48BfymnWvkshNAAzCkL8TtVMY1RnBC/fI4PkXtWQJiWBEsfHdG/XRxboPqMI3i 1pqz4ulmo2xZJmg5m/bQC7YOPLT+2upEbw/Jp/k/9E6842VUUte9isF2eY9/v+cRXmpu xrByQlqcVLc0Qa+PCWWMR1pohWmbmozOeZdQJyery0v3oZP87ElvDKRw/BQn3Y8NdD77 LMo7Ilo1bTl47qxEeX4i0u0gCklqrnLXDWWQ/EVFPdx5xCl0AVC04DBhh9/Q5ByP3jah xrYxgxKkMHMcHJot2Bs/vY5EQuadRPLWFQR+i5VAq90Uh5Gio12n0Fe24tYsERZx+fz0 tDCA== 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; bh=DC7pK9xbaAiQ9K4cRJhg63v1wnAj2SYYRJ011w0qUM8=; b=b/VMD7DXpkHMp657NYdzYy2LkQIRKYapmBF+Xw0DPulqhxz79MskjMKrezXfNA9skc zLmr+fa0IJqihbcwaEOHo0LKcABTKgbq9cYsYP6k/2xtgxj68SBP+0rMKMKP5ytkuvES dN97rQRNex85+3cBBdfnE/G+OJj1oqyzkhsFH+F+9wEpghmq7PK105AN0zwuUwHmEvbr uT1SJpdxwDR5HQRMhzxaiFreDTeN5PoZZZDXR/r8OzKwZONCIdLf66Z+8l8CcfwKAvCM KDm2EEeX4Kvlb8iGpXwEqfqhCvtx3pmLQlzI7yHFXqxfXdcvMht9A+KGsWDgQwCXd5SI 2yPA== X-Gm-Message-State: AEkoouv+xc19ijuo6LOlydQ9w1Ayvlxxx2M5ilY6wt12/5xv2J7EFv0UnCt6g/Qt/wSfuSy+5h1P3tuI1Ut+hg== X-Received: by 10.36.22.195 with SMTP id a186mr14766610ita.37.1469342467085; Sat, 23 Jul 2016 23:41:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.165.67 with HTTP; Sat, 23 Jul 2016 23:40:27 -0700 (PDT) In-Reply-To: <77EB26C9-5B6A-496A-93D1-38621B4DD257@alcatel-lucent.com> References: <413035d09b9f424a8e6a741234ae1dbf@XCH-ALN-003.cisco.com> <77EB26C9-5B6A-496A-93D1-38621B4DD257@alcatel-lucent.com> From: "Mukom Akong T." Date: Sun, 24 Jul 2016 08:40:27 +0200 Message-ID: To: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary=001a1144590ccde18e05385bf370 Archived-At: Cc: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 06:41:11 -0000 --001a1144590ccde18e05385bf370 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (I'm reposting this under this thread so ask to keep the conversation about this draft in a single place. apologies for the duplicate) Section 4 says [snip] The architected result of designing the RA as documented above is that each UE/subscriber gets its own unique /64 IPv6 prefix for which it can use SLAAC or any other method to select its /128 unique address. In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address. If the UE/ subscriber desires to send anything external including other UE/ subscriber devices (assuming device to device communications is enabled and supported), then due to the L-bit set it SHOULD send this traffic to the First Hop Provider Router. [/snip] Question #1 Any reason for silence about the possibility of passing DNS parameters within the RAs as per RFC 6106? Perhaps the statement " In addition, it will use stateless DHCPv6 to get the IPv6 address of the DNS server ..." may be replaced with "The UE depending upon its capabilities should get DNS information either from the RA as per RFC6106 or via stateless DHCPv6" On 18 July 2016 at 11:23, Van De Velde, Gunter (Nokia - BE) < gunter.van_de_velde@nokia.com> wrote: > Yep, good catch. I indeed missed these when doing the edit on this latest > version to split out the /64 assignment per host. > > > > Next version I=E2=80=99ll take this comment into account. > > > > Many thanks, > > G/ > > > > > > > > *From: *"Bernie Volz (volz)" > *Date: *Saturday 9 July 2016 at 17:27 > *To: *"draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" < > draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org> > *Cc: *"v6ops@ietf.org" > *Subject: *draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 > *Resent-From: * > *Resent-To: *, < > gunter.van_de_velde@nokia.com> > *Resent-Date: *Saturday 9 July 2016 at 17:27 > > > > Hi: > > > > Did you perhaps miss some edits late in the document (Section 5): > > > > An operational consideration when using IPv6 address assignment using > > IPv6 SLAAC is that after the onboarding procedure the UE/subscriber > > will have a prefix with certain preferred and valid lifetimes. The > > First Hop Provider Router extends these lifetimes by sending an > > unsolicited RA, the applicable MaxRtrAdvInterval on the WLAN-GW MUST > > therefore be lower than the preferred lifetime. As a consequence of > > this process is that the First Hop Router never knows when a UE/ > > subscriber stops using addresses from a prefix and additional > > procedures are required to help the First Hop Router to gain this > > information. When using stateful DHCPv6 IA_NA for IPv6 UE/subscriber > > address assignment this uncertainty on the First Hop Router is not of > > impact due to the stateful nature of DHCPv6 IA_NA address assignment. > > > > And I=E2=80=99m not really sure how the stateful nature of DHCP helps > significantly with this issue. The RA=E2=80=99s preferred/valid lifetime = are really > no different than DHCPv6=E2=80=99s preferred/valid lifetimes and could ea= sily be > made the same. (While a DHCPv6 client would normally renew at =C2=BD the > preferred lifetime, that is not a hard requirement and therefore a DHCPv6 > server must still assume that the address is in use until the > valid-lifetime has expired.) Sure, a DHCPv6 client COULD send a Release > message to give up its address, but that is rarely done in practice. > > > > And a bit later (RFC4941): > > > > When employing stateless IPv6 address assignment a number of widely > > deployed operating systems will attempt to utilize RFC 4941 RFC4941 > > [RFC4941] temporary 'private' addresses. This can lead to the > > > > And is there much benefit is including: > > > > 6. Future work > > > > o Informational draft regarding WLAN IPv6 Deployment technology > > experiences roll-out > > > > It would perhaps be useful if you had a draft to reference, but otherwise > not so much? > > > > - Bernie > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Mukom Akong T. LinkedIn:Mukom | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --001a1144590ccde18e05385bf370 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    (I'm reposting this under this thread so ask to k= eep the conversation about this draft in a single place. apologies for the = duplicate)

    Section 4 says
    =

    [snip= ]

    The architected result of designing the RA as documented above=
 is
   that each UE/subscriber gets its own unique /64 IPv6 prefix for which
   it can use SLAAC or any other method to select its /128 unique
   address.  In addition it will use stateless DHCPv6 to get the IPv6
   address of the DNS server, however it SHOULD NOT use stateful DHCPv6
   to receive a service provider managed IPv6 address.  If the UE/
   subscriber desires to send anything external including other UE/
   subscriber devices (assuming device to device communications is
   enabled and supported), then due to the L-bit set it SHOULD send this
   traffic to the First Hop Provider Router.

    [/snip]

    Question #1

    Any reason for silence about the =C2= =A0possibility of passing DNS parameters within the RAs as per RFC 6106?

    Pe= rhaps the statement=C2=A0

    " In addition, it will use stateless DHCPv6 = to get the IPv6 address of the DNS server ..."

    may be replaced with

    &q= uot;The UE depending upon its capabilities should get DNS information eithe= r from the RA as per RFC6106 or via stateless DHCPv6"

    On 18 July 2016 = at 11:23, Van De Velde, Gunter (Nokia - BE) <gunter.van_de_v= elde@nokia.com> wrote:

    Yep, good catch. I indeed missed these when doing th= e edit on this latest version to split out the /64 assignment per host.<= /u>

    =C2=A0

    Next version I=E2=80=99ll take this comment into acc= ount.

    =C2=A0

    Many thanks,

    G/

    =C2=A0

    =C2=A0

    =C2=A0

    From: "Bernie Volz (volz)" <volz@cisco.com>
    Date: Saturday 9 July 2016 at 17:27
    To: "draft-ietf-v6ops-unique-ipv6-prefix-per-ho= st@ietf.org" <draft-ietf-v6ops-unique-ipv6-pref= ix-per-host@ietf.org>
    Cc: "v6ops@= ietf.org" <= v6ops@ietf.org>
    Subject: draft-ietf-v6ops-unique-ipv6-prefix-per-host-01
    Resent-From: <alias-bounces@ietf.org>
    Resent-To: <john_brzozowski@cable.comcast.com>, <gunter.van_de_veld= e@nokia.com>
    Resent-Date: Saturday 9 July 2016 at 17:27

    =C2=A0

    Hi:

    =C2=A0

    Did you perhaps miss some edits late in the document= (Section 5):

    =C2=A0

    = =C2=A0=C2=A0 An operational consideration when using IPv6 address assignmen= t using

    = =C2=A0=C2=A0 IPv6 SLAAC is that after the onboarding procedure the UE/subsc= riber

    = =C2=A0=C2=A0 will have a prefix with certain preferred and valid lifetimes.= =C2=A0 The

    = =C2=A0=C2=A0 First Hop Provider Router extends these lifetimes by sending a= n

    = =C2=A0=C2=A0 unsolicited RA, the applicable MaxRtrAdvInterval on the WLAN-GW MUST<= /p>

    = =C2=A0=C2=A0 therefore be lower than the preferred lifetime.=C2=A0 As a con= sequence of

    = =C2=A0=C2=A0 this process is that the First Hop Router never knows when a U= E/

    = =C2=A0=C2=A0 subscriber stops using addresses from a prefix and additional<= /span>

    = =C2=A0=C2=A0 procedures are required to help the First Hop Router to gain t= his

    = =C2=A0=C2=A0 information.=C2=A0 When using stateful DHCPv6 IA_NA for IPv6 U= E/subscriber

    = =C2=A0=C2=A0 address assignment this uncertainty on the First Hop Router is= not of

    = =C2=A0=C2=A0 impact due to the stateful nature of DHCPv6 IA_NA address assi= gnment.

    =C2=A0

    And I=E2=80=99m not really sure how the stateful nat= ure of DHCP helps significantly with this issue. The RA=E2=80=99s preferred= /valid lifetime are really no different than DHCPv6=E2=80=99s preferred/val= id lifetimes and could easily be made the same. (While a DHCPv6 client would normally renew at =C2=BD the preferred lifetime, that is not = a hard requirement and therefore a DHCPv6 server must still assume that the= address is in use until the valid-lifetime has expired.) Sure, a DHCPv6 cl= ient COULD send a Release message to give up its address, but that is rarely done in practice.

    =C2=A0

    And a bit later (RFC4941):

    =C2=A0

    = =C2=A0=C2=A0 When employing stateless IPv6 address assignment a number of w= idely

    = =C2=A0=C2=A0 deployed operating systems will attempt to utilize RFC 4941 RF= C4941

    = =C2=A0=C2=A0 [RFC4941] temporary 'private' addresses.=C2=A0 This ca= n lead to the

    =C2=A0

    And is there much benefit is including:

    =C2=A0

    = 6.=C2=A0 Future work

    = =C2=A0

    = =C2=A0=C2=A0 o=C2=A0 Informational draft regarding WLAN IPv6 Deployment tec= hnology

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 experiences roll-out

    =C2=A0

    It would perhaps be useful if you had a draft to ref= erence, but otherwise not so much?

    =C2=A0

    -=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bernie


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




    --
    =

    Mukom Akong T.

    LinkedIn:Mukom=C2=A0= =C2=A0| =C2=A0twitter: @perfexcellent =C2=A0
      -------------------------------------------------------------------------= -----------------------------------------------------------------
      =E2=80= =9CWhen you work, you are the FLUTE through whose lungs the whispering of t= he hours turns to MUSIC" - Kahlil Gibran
      --------------------------= ---------------------------------------------------------------------------= --------------------------------------
      --001a1144590ccde18e05385bf370-- From nobody Wed Jul 27 11:39:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9712D50A; Wed, 27 Jul 2016 11:39:18 -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 autolearn_force=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 LqPAi1oAwDqn; Wed, 27 Jul 2016 11:39:16 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 EEAF312D12D; Wed, 27 Jul 2016 11:39:14 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bSTja-000Dq3-UT; Wed, 27 Jul 2016 20:39:11 +0200 Date: Wed, 27 Jul 2016 20:39:10 +0200 From: David Lamparter To: Lorenzo Colitti Message-ID: <20160727183910.GF996866@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Dave Taht , "v6ops@ietf.org" , Jen Linkova , homenet Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 18:39:19 -0000 On Thu, Jul 21, 2016 at 09:49:46AM +0200, Lorenzo Colitti wrote: > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote: > > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached > > to this mail. I've been able to gleam a little more detail on the idea: > > > > David, do you intend to keep working on the patches? Think you could send > them to netdev as an RFC patchset, with proper signoff? Once it's on netdev > other people can iterate on them, even if you lose interest :-) I've uploaded the patches (with signoffs) to: https://aurora.nox.tf/tmp/rule55/ NB: patch 2 of 3 is slightly different from the version I mailed, I accidentally lost a NULL check in ipv6_rt_get_saddr(). I do _not_ intend to continue working on these since I now believe the functionality should be put on neighbor cache entries. This requires some (minor IMHO) rework to make these neighbor entries stay alive until their prefix information times out. By putting it there, it can support addresses that are configured from dhcpv6 or static/admin. The code linked above only works for SLAAC. => the patches are intended purely for testing, for example if someone hacks on the router side and wants to use Linux VMs to test the full picture. Cheers, -David From nobody Wed Jul 27 12:49:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C112D534; Wed, 27 Jul 2016 12:49:31 -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 autolearn_force=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 3Ot0XcsssmpX; Wed, 27 Jul 2016 12:49:29 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 0EA3512D0C2; Wed, 27 Jul 2016 12:49:29 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bSUpX-000Fvv-QF; Wed, 27 Jul 2016 21:49:25 +0200 Date: Wed, 27 Jul 2016 21:49:23 +0200 From: David Lamparter To: 6man <6man@ietf.org> Message-ID: <20160727194923.GG996866@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Praveen Balasubramanian , Jen Linkova Subject: [v6ops] RFC 6724 rule 5.5 implementation guidance (was: Linux 6724 rule 5.5, ...enterprise-pa-multihoming) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 19:49:31 -0000 On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: > On 21/07/2016 02:34, David Lamparter wrote: > > On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: > >> Please tell us ASAP if there is anything we should add to > >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 > >> or thereabouts. I believe we need to ship the following text (or something similar) /somewhere/: (Some points - particularly 7, 8 & 10 - might need some arguing about. Text below is what I /believe/ to be reasonable, but I may of course have overlooked some scenarios...) Cheers / hoping for feedback, -David P.S.: Praveen - this is what I was wondering about when I asked you @ Bits'n'Bytes in Berlin. Can you provide some insight into how Windows implements this? --- section: Rule 5.5 implementation considerations Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember which next-hops advertised which prefixes" [RFC 6724], these are listed here: 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for SLAAC-derived addresses but needs to be considered for DHCPv6 and admin-configured addresses. If a router advertises a particular prefix, addresses in that prefix SHOULD be preferred regardless of the mechanism used to configure them. 2. Neither L nor A bit in the Prefix Information Option (PIO) are specified anywhere to have an impact on source address selection. Hosts SHOULD consider all PIOs regardless of L/A bit values for the purposes of source address selection. 3. When using non-default routes learned from Route Information Options, hosts SHOULD apply the rules in the same manner, preferring source addresses inside prefixes advertised by the nexthop of the specific route used. 4. Routers MAY advertise more than one prefix (e.g. during renumbering), which hosts SHOULD honor up to a limit imposed by security considerations. 5. More than one router MAY advertise the same prefix. In particular, homenet routers implementing RFCs 7695 and 7788 will exhibit this behaviour by default and in normal operation. Hosts SHOULD be able to correctly retain identical prefixes for multiple routers, up to a limit imposed by security considerations. 6. A router MAY choose to include prefix information only in some of its RAs, for example when the sum of RA options exceeds the link's MTU. A host MUST NOT rely on all RAs including all information. This also means a host MUST NOT implement rule 5.5 by keeping a copy of the last RA packet, as that packet may not have all information. 7. Entries on a router's list of advertised prefixes need to be expired using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD apply the same rules regarding lifetimes as if they were configuring an address from that prefix. 8. A host MAY dismiss a router's list of advertised prefixes if all routes via that router expire. If a host does so, it MUST ensure that additional routes learned from Route Information Options cause it to retain the list even if the default route expires (i.e. had a lower lifetime), or is not added to begin with. 9. Hosts MUST NOT use link-layer addresses to identify routers. Not only is this information unreliable on some media (e.g. 802.11 with aggressive controller-based optimizations), but it also conflicts with (future) approaches to exploit rule 5.5 for multihoming scenarios. Hosts MUST use IPv6 link-local addresses to identify routers for this purpose. 10. Hosts SHOULD retain prefix information even if they have no address inside that prefix. Not doing so delays the application of improved source address selection for DHCPv6 and admin-configured addresses until the next receipt of a RA packet. This can be visible to the user as a temporary period of failed service, or, if RAs are infrequent, be interpreted as entirely broken connectivity. section: Security Considerations Retaining additional information from router advertisements opens hosts to another avenue of memory exhaustion attacks by malicious on-link hosts. Implementations MUST cap the amount of data retained. section: Privacy Considerations If hosts incorrectly mix prefix information across multiple interfaces, it becomes possible for malicious on-link hosts (or routers) to enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep this information strictly scoped to the respective interface. Routers generally gain a method of insight into a host's addresses. This extends existing considerations applying to rogue RAs. The problem is particularly relevant on link layers where the broadcast domain is shattered into non-transitive subdomains (e.g. Private VLANs [RFC 5517]). Even if RAs are secured in some way, privacy is not provided between multiple routers on the same link. section: Acknowledgements This text/section/... was added by David Lamparter based on implementation observations and discussions with Lorenzo Colitti and Jen Linkova. From nobody Wed Jul 27 13:19:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46A12D580; Wed, 27 Jul 2016 13:19:06 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 z6adB7mRZcVA; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 A0EAA12D57B; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id y134so14052685pfg.0; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZR2xNoawQ9Lh18uaZKMsyPcmxL4k6izo2AFCLzfG4RA=; b=sGb6tJlOCMGIcnZ5/fDD7X9Y9koYLgGnfJQGNZY98cTSmZNiUHervJUwRLB3jdaz5o ikwXr8gq6gbjv1AllXm2TFmsvQ+obd+CE+umXNzVlBMmTzXemguwZQvbavlAqDTzocmh QqT2N7TJRk8L5Qnjwt31EYdDsHJKFlai0Yb87rap6ISSXPgdkME5hwmcnocLUgXkQKNU 5XWcLPnOTrp+IcqUM2RX8edYpf4wLS+12XgjEyHUO05fz8c3MfCmZN4w3EFu8DEn1Rmy rAdmH782+iPSP+CSVPXm5DLBFuLL2fRV18miA79B92LSP523MWOnE2V6C2rSBszPbNeY GGsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZR2xNoawQ9Lh18uaZKMsyPcmxL4k6izo2AFCLzfG4RA=; b=GoRHYx2D7WlK0wA7CCbxrE9sNzFbfaSboUpkp5ykhJ8IQOAbqJxosG7aS0XWr3eWnw G122YhnUnFqClvCbjOe9zLXXm+jXjivQ25IP1xo68T+5krRn2mav5FiLtfYEkz8RttGO TU9F5M3IgyJp2nxOWwiX7Bgb83ms0mPFgpXlf53IccIPh+HIkO0OPIUlvrNooKj9sidY 65bCQMHjmyp3miaPn1f7h6HP8483kHUbuArNJ/nRE2N5R/mtZEqYvhY7PE2zMDKSHyCZ ELp0xjoYm/lC1weShOXzUnVzn4j9aXOkFdy6nXZy5/4k1cvA3wSTQ5AvouH8dXH8+5Xy ybzg== X-Gm-Message-State: AEkoouttSjnRmArt8yfHIUHjnfy1sNLpTBO8BlfKgH30tq7Yc04vs48jqqm+9CaiKYaEfQ== X-Received: by 10.98.59.70 with SMTP id i67mr52344793pfa.45.1469650744212; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: from ?IPv6:2406:e007:5502:1:28cc:dc4c:9703:6781? ([2406:e007:5502:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c82sm11205281pfb.72.2016.07.27.13.19.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 13:19:03 -0700 (PDT) To: David Lamparter , 6man <6man@ietf.org>, Suresh Krishnan References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> From: Brian E Carpenter Organization: University of Auckland Message-ID: <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> Date: Thu, 28 Jul 2016 08:19:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160727194923.GG996866@eidolon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , Jen Linkova Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 20:19:06 -0000 David, On 28/07/2016 07:49, David Lamparter wrote: > On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: >> On 21/07/2016 02:34, David Lamparter wrote: >>> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: >>>> Please tell us ASAP if there is anything we should add to >>>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 >>>> or thereabouts. > > I believe we need to ship the following text (or something similar) > /somewhere/: I like what you wrote. I don't think such eminently practical information fits very well into IETF documents but I'd be interested in other opionions. draft-ietf-6man-multi-homed-host is in IETF LC and already on the IESG agenda, so if we should add this sort of material Suresh had better tell us to do so rather soon. One specific comment below... > > (Some points - particularly 7, 8 & 10 - might need some arguing about. > Text below is what I /believe/ to be reasonable, but I may of course > have overlooked some scenarios...) > > Cheers / hoping for feedback, > > -David > > > P.S.: Praveen - this is what I was wondering about when I asked you @ > Bits'n'Bytes in Berlin. Can you provide some insight into how Windows > implements this? > > --- > section: Rule 5.5 implementation considerations > > Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember > which next-hops advertised which prefixes" [RFC 6724], these are listed > here: > > 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for > SLAAC-derived addresses but needs to be considered for DHCPv6 and > admin-configured addresses. If a router advertises a particular > prefix, addresses in that prefix SHOULD be preferred regardless of > the mechanism used to configure them. > > 2. Neither L nor A bit in the Prefix Information Option (PIO) are > specified anywhere to have an impact on source address selection. > Hosts SHOULD consider all PIOs regardless of L/A bit values for the > purposes of source address selection. Yes, including L=0 and A=0, as explicitly called out at the end of https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-07#section-2.1 Brian > > 3. When using non-default routes learned from Route Information Options, > hosts SHOULD apply the rules in the same manner, preferring source > addresses inside prefixes advertised by the nexthop of the specific > route used. > > 4. Routers MAY advertise more than one prefix (e.g. during renumbering), > which hosts SHOULD honor up to a limit imposed by security > considerations. > > 5. More than one router MAY advertise the same prefix. In particular, > homenet routers implementing RFCs 7695 and 7788 will exhibit this > behaviour by default and in normal operation. Hosts SHOULD be able > to correctly retain identical prefixes for multiple routers, up to a > limit imposed by security considerations. > > 6. A router MAY choose to include prefix information only in some of its > RAs, for example when the sum of RA options exceeds the link's MTU. > A host MUST NOT rely on all RAs including all information. This also > means a host MUST NOT implement rule 5.5 by keeping a copy of the > last RA packet, as that packet may not have all information. > > 7. Entries on a router's list of advertised prefixes need to be expired > using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD > apply the same rules regarding lifetimes as if they were configuring > an address from that prefix. > > 8. A host MAY dismiss a router's list of advertised prefixes if all > routes via that router expire. If a host does so, it MUST ensure > that additional routes learned from Route Information Options cause > it to retain the list even if the default route expires (i.e. had a > lower lifetime), or is not added to begin with. > > 9. Hosts MUST NOT use link-layer addresses to identify routers. Not > only is this information unreliable on some media (e.g. 802.11 with > aggressive controller-based optimizations), but it also conflicts > with (future) approaches to exploit rule 5.5 for multihoming > scenarios. Hosts MUST use IPv6 link-local addresses to identify > routers for this purpose. > > 10. Hosts SHOULD retain prefix information even if they have no address > inside that prefix. Not doing so delays the application of improved > source address selection for DHCPv6 and admin-configured addresses > until the next receipt of a RA packet. This can be visible to the > user as a temporary period of failed service, or, if RAs are > infrequent, be interpreted as entirely broken connectivity. > > > section: Security Considerations > > Retaining additional information from router advertisements opens hosts > to another avenue of memory exhaustion attacks by malicious on-link > hosts. Implementations MUST cap the amount of data retained. > > > section: Privacy Considerations > > If hosts incorrectly mix prefix information across multiple interfaces, > it becomes possible for malicious on-link hosts (or routers) to > enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep > this information strictly scoped to the respective interface. > > Routers generally gain a method of insight into a host's addresses. > This extends existing considerations applying to rogue RAs. The problem > is particularly relevant on link layers where the broadcast domain is > shattered into non-transitive subdomains (e.g. Private VLANs [RFC > 5517]). Even if RAs are secured in some way, privacy is not provided > between multiple routers on the same link. > > > section: Acknowledgements > > This text/section/... was added by David Lamparter based on > implementation observations and discussions with Lorenzo Colitti and Jen > Linkova. > From nobody Wed Jul 27 17:47:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014B12DB6A; Wed, 27 Jul 2016 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ke-3aE0GOC8n; Wed, 27 Jul 2016 17:47:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 CD17912DA20; Wed, 27 Jul 2016 17:47:30 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w18so41930814oiw.3; Wed, 27 Jul 2016 17:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e8OuPnjkLXrvoiGM1I1qNriPkbjAJ46IcDtzIYk+Qxc=; b=xGmXCoqITA462rzfSm8jAkZXn0Zi1GEwrQuip2H92hz7NmPgz9l9ttaCuwUVyEajAn Cm4634ozkDqm22pqwCpbZsVlDKUgnoRMue3K8laoTpZnnoHzW/ma5C1HAEwZiLhvXKLE 5nE8lsNCs9We14KyDAtTa2QDd49/flRAtoztrwPfvEXkVd7NKKEzX2F3RjRYvx5vtkUz HYaXR/DIneMhW7a9AHmjgR4SmEvVrJoR3afncQRhtGFT9nwuv1+7X5swQvI7+BLOJ4rH gWIMEFY5DOQlc5bl5gKD+eaXZXXXfNhLsaqfYvvv0VBG9nTomGL4ZsoMgXQ3kiIRIKGB WEBg== 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; bh=e8OuPnjkLXrvoiGM1I1qNriPkbjAJ46IcDtzIYk+Qxc=; b=guWSs1PPHbzl5kcE4wiuxw/siccWsZpUkMiFEYpcHljJJnaugJFfAT2eq6Ii0plZDS ezH1XNk6Jvv4Iz073xxyMOIuflNpOUHPKN5BwVi1AMoFOYBAb/tIs/Pf8G4AmRXr9ybm 0pgwkBIicCB3mzR8eAXATOpGjeDXsTEgIilBZAdQ9QkJBEctblEU+duTeUgHGvh9MGYU O0IVGjU23jfO9nVWE8ll2A6uCxAVLoKtipIv40Y+XnElIQXeITAgZ50CY8E8odPzSblp tDCqC4Kcq62r98W9dWCI9QCccjFBmfBwqhMpzX9Pw4do/yu1ZgQD8mCq8gRHtbj3ztzr pkuw== X-Gm-Message-State: AEkoousUBBtQ/fF0l+BQS5b3GU3l87m/2/IaakyDHXcruVn6BsiSuY1A+NP+q4+Va5EqcYbZAI9U+h3O7DffhQ== X-Received: by 10.202.171.80 with SMTP id u77mr19001492oie.29.1469666850177; Wed, 27 Jul 2016 17:47:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Wed, 27 Jul 2016 17:47:29 -0700 (PDT) In-Reply-To: <20160727194923.GG996866@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> From: Hemant Singh Date: Wed, 27 Jul 2016 20:47:29 -0400 Message-ID: To: David Lamparter Content-Type: multipart/alternative; boundary=001a113cc7dc8b09820538a77a17 Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org>, Jen Linkova Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance (was: Linux 6724 rule 5.5, ...enterprise-pa-multihoming) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 00:47:32 -0000 --001a113cc7dc8b09820538a77a17 Content-Type: text/plain; charset=UTF-8 First, if the doc is in the IESG, so much text does not make sense to add to the doc at this juncture. Second, I agree with Brian that it is mostly practical information that does not belong in an IETF RFC. Third, it is too much text and the text has to be thoroughly reviewed by a wide audience. I reviewed the proposed text and see most items are not necessary. I have my review comments in line below preceded by "". On Wed, Jul 27, 2016 at 3:49 PM, David Lamparter wrote: > On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: > > > --- > section: Rule 5.5 implementation considerations > > Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember > which next-hops advertised which prefixes" [RFC 6724], these are listed > here: > It is deliberate. If a host tracks prefixes advertised by a specific router, RFC 4861 and RFC 4191 require a change which needs to be discussed. > > 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for > SLAAC-derived addresses Not quite. Also, a renumbering takes place and Prefix A is advertised with reduced lifetime which eventually goes to zero. Now each destination that matches Prefix A is off-link. Router A advertised SA Prefix A and router B advertised SA Prefix B. Now router selection is needed at the host. What SLAAC address is used for SA requires more work that a redundant "on-link" for any SLAAC prefix. but needs to be considered for DHCPv6 and > admin-configured addresses. If a router advertises a particular > prefix, addresses in that prefix SHOULD be preferred regardless of > the mechanism used to configure them. > RFC4861 already covers a union of information from RA and DHCPv6 for use by the host. See section 6.3.4 in RFC4861 and this text: "Hosts accept the union of all received information;" > > 2. Neither L nor A bit in the Prefix Information Option (PIO) are > specified anywhere to have an impact on source address selection. > Hosts SHOULD consider all PIOs regardless of L/A bit values for the > purposes of source address selection. > No. If the lifetime in the PIO is zero, more work is needed to pick a source address. > > 3. When using non-default routes learned from Route Information Options, > hosts SHOULD apply the rules in the same manner, preferring source > addresses inside prefixes advertised by the nexthop of the specific > route used. > Minor comment first. IPv6 ND has no concept of a default route. ND specifies a default router for the link. The text in this item 3 is not needed. When a packet is to be sent out, the host performs a longest prefix match of the packet destination with prefixes in the Prefix List. If a match is found, the next-hop is the packet destination. If not, the packet is forwarded to the default router. If the host supports RFC 4191, the rules are already specified in RFC 4191 for routing table. > > 4. Routers MAY advertise more than one prefix (e.g. during renumbering), > which hosts SHOULD honor up to a limit imposed by security > considerations. > Already covered in RFC 4861 and RFC 4862. See section 5.5.4 in RFC 4862 and sections 6.3.5 and 12 in RFC 4861. > > 5. More than one router MAY advertise the same prefix. In particular, > homenet routers implementing RFCs 7695 and 7788 will exhibit this > behaviour by default and in normal operation. Hosts SHOULD be able > to correctly retain identical prefixes for multiple routers, up to a > limit imposed by security considerations. > > Could you please provide specific text and sections from the homenet RFCs to show why multiple routers advertise the same prefix and what is the reason for doing so. A topology diagram would help - maybe the diagram exists in a homenet doc. Then we can discuss. 6. A router MAY choose to include prefix information only in some of its > RAs, for example when the sum of RA options exceeds the link's MTU. > A host MUST NOT rely on all RAs including all information. This also > means a host MUST NOT implement rule 5.5 by keeping a copy of the > last RA packet, as that packet may not have all information. > Section 6.3.4 of RFC 4861 already covers such details and thus Rule 5.5 of RFC 6724 is fine. > > 7. Entries on a router's list of advertised prefixes need to be expired > using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD > apply the same rules regarding lifetimes as if they were configuring > an address from that prefix. > It is the Preferred Lifetime. RFC 4862 already includes the behavior you describe above for SLAAC addresses. DHCPv6 has address renew mechanisms to refresh address before the address expires. I don't see a need to text in item 7 above. > > 8. A host MAY dismiss a router's list of advertised prefixes if all > routes via that router expire. If a host does so, it MUST ensure that additional routes learned from Route Information Options cause > it to retain the list even if the default route expires (i.e. had a > lower lifetime), or is not added to begin with. > Text is not needed. Section 6.3.5 clears specifies how to timeout entries in the Prefix List and the Default Router List. > > 9. Hosts MUST NOT use link-layer addresses to identify routers. Not > only is this information unreliable on some media (e.g. 802.11 with > aggressive controller-based optimizations), but it also conflicts > with (future) approaches to exploit rule 5.5 for multihoming > scenarios. Hosts MUST use IPv6 link-local addresses to identify > routers for this purpose. > > If the RA includes a Source Link-layer address via the Source Link-layer address Option (SLAO), the host is legal to use the link-layer address. If a link does not use Source Link-layer address, then no SLAO is included in the RA. How is a packet forwarded by the host to the default router if the host does not know the link-layer address of the default router? More details on 802.11 optimizations are needed before the text in item 9 is considered. > 10. Hosts SHOULD retain prefix information even if they have no address > inside that prefix. Not doing so delays the application of improved > source address selection for DHCPv6 and admin-configured addresses > until the next receipt of a RA packet. This can be visible to the > user as a temporary period of failed service, or, if RAs are > infrequent, be interpreted as entirely broken connectivity. > > A better model exists if the hosts only use DHCPv6. The router sends an RA with no PIO with the M and O bits set, Thus hosts have all non-link-local destinations as off-link. > > section: Security Considerations > > Retaining additional information from router advertisements opens hosts > to another avenue of memory exhaustion attacks by malicious on-link > hosts. Implementations MUST cap the amount of data retained. > > RFC 4861, in section 5.3 already says "However, a node may garbage-collect entries prematurely if it is low on memory." > > section: Privacy Considerations > > If hosts incorrectly mix prefix information across multiple interfaces, > it becomes possible for malicious on-link hosts (or routers) to > enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep > this information strictly scoped to the respective interface. > IPv6 ND and SLAAC are protocols that work for a specific interface. Thus this information is blatantly clear. If host mix information, it's a bug in the host implementation to fix. No new text to IETF RFCs is needed. > > Routers generally gain a method of insight into a host's addresses. > This extends existing considerations applying to rogue RAs. The problem > is particularly relevant on link layers where the broadcast domain is > shattered into non-transitive subdomains (e.g. Private VLANs [RFC > 5517]). Even if RAs are secured in some way, privacy is not provided > between multiple routers on the same link. > > Again, the RA is promiscuous for a specific private VLAN domain. It > is clear and obvious information. > Hemant > > --001a113cc7dc8b09820538a77a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      First, if the doc is in the IESG, so much text does not ma= ke sense to add to the doc at this juncture.=C2=A0
      Second, I agree with= Brian that it is mostly practical information that does not belong in an I= ETF RFC.=C2=A0
      Third, it is too much text and the text has to be = thoroughly reviewed by a wide audience.=C2=A0 I reviewed the proposed text = and see most items are not necessary. =C2=A0=C2=A0

      I have my review comments in line below preceded by "<hs>"= .


      O= n Wed, Jul 27, 2016 at 3:49 PM, David Lamparter <equinox@diac24.net&g= t; wrote:
      On Thu, Jul 21, 2016 at 07:25:45PM +12= 00, Brian E Carpenter wrote:


      ---
      section: Rule 5.5 implementation considerations

      Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember=
      which next-hops advertised which prefixes" [RFC 6724], these are liste= d
      here:

      <hs> It is deliberate.=C2= =A0 If a host tracks prefixes advertised by a specific router, RFC 4861 and= RFC 4191 require a change which needs to be discussed.

      1. Note RFC 6724 mentions "SA or SA's prefix".=C2=A0 This is = redundant for
      =C2=A0 =C2=A0SLAAC-derived addresses

      <hs= > Not quite.=C2=A0 Also, a renumbering takes place and Prefix A is adver= tised with reduced lifetime which eventually goes to zero.=C2=A0 Now each d= estination that matches Prefix A is off-link. =C2=A0=C2=A0Router A advertis= ed SA Prefix A and router B advertised SA Prefix B.=C2=A0 Now router select= ion is needed at the host.=C2=A0 What SLAAC address is used for SA requires= more work that a redundant "on-link" for any SLAAC prefix.=C2=A0=

      but needs to be considered for DHCPv= 6 and
      =C2=A0 =C2=A0admin-configured addresses.=C2=A0 If a router advertises a par= ticular
      =C2=A0 =C2=A0prefix, addresses in that prefix SHOULD be preferred regardles= s of
      =C2=A0 =C2=A0the mechanism used to configure them.
      <hs>RFC4861 already covers a union of information from RA= and DHCPv6 for use by the host.=C2=A0 See section 6.3.4 in RFC4861 and thi= s text: "Hosts accept the union of all received information;"
      =C2=A0

      2. Neither L nor A bit in the Prefix Information Option (PIO) are
      =C2=A0 =C2=A0specified anywhere to have an impact on source address selecti= on.
      =C2=A0 =C2=A0Hosts SHOULD consider all PIOs regardless of L/A bit values fo= r the
      =C2=A0 =C2=A0purposes of source address selection.
      <hs> No. If the lifetime in the PIO is zero, more work is= needed to pick a source address.=C2=A0

      3. When using non-default routes learned from Route Information Options, =C2=A0 =C2=A0hosts SHOULD apply the rules in the same manner, preferring so= urce
      =C2=A0 =C2=A0addresses inside prefixes advertised by the nexthop of the spe= cific
      =C2=A0 =C2=A0route used.

      <hs>Mino= r comment first.=C2=A0 IPv6 ND has no concept of a default route.=C2=A0 ND = specifies a default router for the link. =C2=A0 The text in this item 3 is = not needed.=C2=A0 When a packet is to be sent out, the host performs a long= est prefix match of the packet destination with prefixes in the Prefix List= .=C2=A0 If a match is found, the next-hop is the packet destination.=C2=A0 = If not, the packet is forwarded to the default router. =C2=A0 If the host s= upports RFC 4191, the rules are already specified in RFC 4191 for routing t= able.

      4. Routers MAY advertise more than one prefix (e.g. during renumbering), =C2=A0 =C2=A0which hosts SHOULD honor up to a limit imposed by security
      =C2=A0 =C2=A0considerations.

      <hs>= Already covered in RFC 4861 and RFC 4862.=C2=A0 See section 5.5.4 in RFC 4= 862 and sections 6.3.5 and 12 in RFC 4861.=C2=A0

      5. More than one router MAY advertise the same prefix.=C2=A0 In particular,=
      =C2=A0 =C2=A0homenet routers implementing RFCs 7695 and 7788 will exhibit t= his
      =C2=A0 =C2=A0behaviour by default and in normal operation.=C2=A0 Hosts SHOU= LD be able
      =C2=A0 =C2=A0to correctly retain identical prefixes for multiple routers, u= p to a
      =C2=A0 =C2=A0limit imposed by security considerations.

      <hs> Could you please provide specific text and= sections from the homenet RFCs to show why multiple routers advertise the = same prefix and what is the reason for doing so.=C2=A0 A topology diagram w= ould help - maybe the diagram exists in a homenet doc. =C2=A0 Then we can d= iscuss.=C2=A0

      6. A router MAY choose to include prefix information only in some of its =C2=A0 =C2=A0RAs, for example when the sum of RA options exceeds the link&#= 39;s MTU.
      =C2=A0 =C2=A0A host MUST NOT rely on all RAs including all information.=C2= =A0 This also
      =C2=A0 =C2=A0means a host MUST NOT implement rule 5.5 by keeping a copy of = the
      =C2=A0 =C2=A0last RA packet, as that packet may not have all information.

      <hs> Section 6.3.4 of RFC 4861 alr= eady covers such details and thus Rule 5.5 of RFC 6724 is fine. =C2=A0

      7. Entries on a router's list of advertised prefixes need to be expired=
      =C2=A0 =C2=A0using the prefix's (TBD: valid or preferred?) lifetime.=C2= =A0 Hosts SHOULD
      =C2=A0 =C2=A0apply the same rules regarding lifetimes as if they were confi= guring
      =C2=A0 =C2=A0an address from that prefix.

      <hs> It is the Preferred Lifetime.=C2=A0 RFC 4862 already includes= the behavior you describe above for SLAAC addresses.=C2=A0 DHCPv6 has addr= ess renew mechanisms to refresh address before the address expires. =C2=A0 = I don't see a need to text in item 7 above. =C2=A0

      8. A host MAY dismiss a router's list of advertised prefixes if all
      =C2=A0 =C2=A0routes via that router expire. If a host does so, it MUST ensu= re
      =C2=A0 =C2=A0that additional routes learned from Route Information Options = cause
      =C2=A0 =C2=A0it to retain the list even if the default route expires (i.e. = had a
      =C2=A0 =C2=A0lower lifetime), or is not added to begin with.

      <hs> Text is not needed.=C2=A0 Section 6.3.5 cl= ears specifies how to timeout entries in the Prefix List and the Default Ro= uter List.=C2=A0

      9. Hosts MUST NOT use link-layer addresses to identify routers.=C2=A0 Not =C2=A0 =C2=A0only is this information unreliable on some media (e.g. 802.11= with
      =C2=A0 =C2=A0aggressive controller-based optimizations), but it also confli= cts
      =C2=A0 =C2=A0with (future) approaches to exploit rule 5.5 for multihoming =C2=A0 =C2=A0scenarios.=C2=A0 Hosts MUST use IPv6 link-local addresses to i= dentify
      =C2=A0 =C2=A0routers for this purpose.

      <hs> If the RA includes a Source Link-layer add= ress via the Source Link-layer address Option (SLAO), the host is legal to = use the link-layer address.=C2=A0 If a link does not use Source Link-layer = address, then no SLAO is included in the RA. =C2=A0 How is a packet forward= ed by the host to the default router if the host does not know the link-lay= er address of the default router? =C2=A0 =C2=A0More details on 802.11 optim= izations are needed before the text in item 9 is considered. =C2=A0
      =C2=A0
      10. Hosts SHOULD retain prefix information even if they have no address
      =C2=A0 =C2=A0 inside that prefix.=C2=A0 Not doing so delays the application= of improved
      =C2=A0 =C2=A0 source address selection for DHCPv6 and admin-configured addr= esses
      =C2=A0 =C2=A0 until the next receipt of a RA packet.=C2=A0 This can be visi= ble to the
      =C2=A0 =C2=A0 user as a temporary period of failed service, or, if RAs are<= br> =C2=A0 =C2=A0 infrequent, be interpreted as entirely broken connectivity.
      <hs> A better model exists if the hosts only us= e DHCPv6.=C2=A0 The router sends an RA with no PIO with the M and O bits se= t, =C2=A0Thus hosts have all non-link-local destinations as off-link. =C2= =A0=C2=A0

      section: Security Considerations

      Retaining additional information from router advertisements opens hosts
      to another avenue of memory exhaustion attacks by malicious on-link
      hosts.=C2=A0 Implementations MUST cap the amount of data retained.

      <hs> RFC 4861, in section 5.3 already says &quo= t;However, a node may<= /span>=C2=A0garbage-co= llect entries prematurely if it is low on memory." =C2=A0
      =

      section: Privacy Considerations

      If hosts incorrectly mix prefix information across multiple interfaces,
      it becomes possible for malicious on-link hosts (or routers) to
      enumerate all of a host's IPv6 addresses.=C2=A0 Hosts therefore MUST ke= ep
      this information strictly scoped to the respective interface.

      <hs> IPv6 ND and SLAAC are protocols that work= for a specific interface.=C2=A0 Thus this information is blatantly clear.= =C2=A0 If host mix information, it's a bug in the host implementation t= o fix.=C2=A0 No new text to IETF RFCs is needed. =C2=A0

      Routers generally gain a method of insight into a host's addresses.
      This extends existing considerations applying to rogue RAs.=C2=A0 The probl= em
      is particularly relevant on link layers where the broadcast domain is
      shattered into non-transitive subdomains (e.g. Private VLANs [RFC
      5517]).=C2=A0 Even if RAs are secured in some way, privacy is not provided<= br> between multiple routers on the same link.

      <hs>Again, the RA is promiscuous for a specific private VLAN domain.= =C2=A0 It is clear and obvious information.=C2=A0

      =
      Hemant=C2=A0
      =C2=A0

      --001a113cc7dc8b09820538a77a17-- From nobody Wed Jul 27 21:38:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F7412D54F; Wed, 27 Jul 2016 21:38:31 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AN7hqbpFdHs0; Wed, 27 Jul 2016 21:38:29 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 7134112B047; Wed, 27 Jul 2016 21:38:29 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id g86so6845717ioj.1; Wed, 27 Jul 2016 21:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=AEBdorNld1/Q0C4ElnpjLQWTJu2MJCCgYHiOenhZ8kI=; b=MIhHwf1vVTKGY78VtaXhDchTh+xHeI35Lxo4ij4MF04ujWx4nyYUPWQeQ0bttWuf9N cOad8NlcGwxvXCjK9B5+P/u6UErBAUP4/hBvU6+qu/AWVY+mFttMEDhBGQwVa0g5tNtf UjT7XlS6oQxHwEowy7YEr5lH8Otf27H45rnfu2cupUrt8kBBEFeQSdbnHlGPnCmPfw+L XOVnvdfBwSL6f1vOCMYIenf3I9WgsJ8A52gtS832M0SGY913YDtti4S2p3Be7OanLwxq gJQYPPhvRXZrMHw8OkOqukLvIUIAS1Kdh4T7dCRJ5NntvrGY6/dL4HGNZ+tPu/uCpLCD cDDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=AEBdorNld1/Q0C4ElnpjLQWTJu2MJCCgYHiOenhZ8kI=; b=G//DjGLnazq2VHvUTSVDCVd4dkZisiCkWmrLRVRsGMz0w+H+PU72VArRbi+NjmRufJ fddgVfZft5rnQcG7Z6AcBsE2d0Fuyj1CqjWE+dvzzREIk+v06I+VlaB4EhRXc1C0RTKy LjmIlosKesGjw1JOcaclJPkJuYD8VYd/F5oqEsZdhMFucko0twsfoBg5TyYaD59OVeg3 WEnKZhlpJkqVaODZwrqaWboLIXVZEbcrLUH58uQ9FZZl3ZKkIvjgU3IagC+smU32jc9V K8rRJo9uYqfSZapNTHJtWs11QLMWAR4sJa85qspKS+aFiuApk6JM56vc7/vsEtiiTMLB V3CQ== X-Gm-Message-State: AEkoouuOcF1ncQ5ZdAatKHoJ6oJrrnfL9Rft1dedcgUqd343Aim/3Szq9hW9/prvZSKjOv4EwOprhV4LCM9z+Q== X-Received: by 10.107.8.140 with SMTP id h12mr37646722ioi.95.1469680708730; Wed, 27 Jul 2016 21:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.14.17 with HTTP; Wed, 27 Jul 2016 21:38:28 -0700 (PDT) From: Dave Taht Date: Thu, 28 Jul 2016 06:38:28 +0200 Message-ID: To: David Lamparter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" , Jen Linkova , homenet Subject: Re: [v6ops] [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 04:38:31 -0000 On Wed, Jul 27, 2016 at 8:39 PM, David Lamparter wrote= : > On Thu, Jul 21, 2016 at 09:49:46AM +0200, Lorenzo Colitti wrote: >> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wr= ote: >> > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attach= ed >> > to this mail. I've been able to gleam a little more detail on the ide= a: >> > >> >> David, do you intend to keep working on the patches? Think you could sen= d >> them to netdev as an RFC patchset, with proper signoff? Once it's on net= dev >> other people can iterate on them, even if you lose interest :-) > > I've uploaded the patches (with signoffs) to: > https://aurora.nox.tf/tmp/rule55/ Thank you for posting the patches. I will try them out the next time I get = time. I think I object to landing IPV6_SADDR_RULE_OIF_RTR in the middle of the existing enum rather than at the end, but will twiddle further. > NB: patch 2 of 3 is slightly different from the version I mailed, I > accidentally lost a NULL check in ipv6_rt_get_saddr(). > > I do _not_ intend to continue working on these since I now believe the > functionality should be put on neighbor cache entries. This requires > some (minor IMHO) rework to make these neighbor entries stay alive until > their prefix information times out. By putting it there, it can support > addresses that are configured from dhcpv6 or static/admin. I think I agree, but looking over the existing patches is a goodness. I was only just made aware that getting source specific routing to work well in other base ipv6 protocols had entered ietf consideration in this past ietf, and have some catching up to do. Has there been any work on improving how the std APIs might work on choosing a better source address for a given destination? I see some work has happened in mptcp.... > The code > linked above only works for SLAAC. One thing that has bothered me of late has been the lack of symmetry regarding address assignment's sources, vs how routes are handled. ip -6 route add fd01::1 via fe80::1 dev whatever proto static # rip/babel/dhcp/etc vs ip -6 addr add fd01::2/64 dev whatever # with no means to specify that it came from slaac/dhcpv6/static/hncp/background radiation. The existing bits for things like tmpaddr, mgmt_tmpaddr and scope seems to be breaking down in the representability... > > =3D> the patches are intended purely for testing, for example if someone > hacks on the router side and wants to use Linux VMs to test the full > picture. > > Cheers, > > > -David --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Thu Jul 28 05:25:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F212D875; Thu, 28 Jul 2016 05:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RfnhRCyvdKom; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 CE17812D828; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l72so60364562oig.2; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q4XlxQScRg7SMa0rJPuqpVLXDyGyKkJc9z+PFbXfaLo=; b=Fb+ihLhUED+yw4aOfLrxX+9FXb/5ajiCXIYoP3JAcT5aVPkA6jF4sQUR4IXhRiClnW LbHhWqbWdmyBU/Pgg4smQBuOIwH7EQ6kT8fP7lYO7kURxY8W4mThylkcGxRtxbK3IzbG 9Wrml0PprxF9pWMgcZYZCU3RptMahBGN0ycbqqP91Bud7d1cSQ//V5ICRZA4oIAgmR1P gAXHRitRx80TZfnyQGSGjmNH587MdxG7f5FWpoTKb6ug15VFmPXIykoiG2NPS2MN6+mJ b0ygG3DcP0vAN2YuVhZhMKqZGXFXP/OCYhiBwEcekAMl30EPjUKVJU9/HMVGtqpYNKjc khPw== 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; bh=Q4XlxQScRg7SMa0rJPuqpVLXDyGyKkJc9z+PFbXfaLo=; b=F+Q7BmK14/d3D6d7Npyan8whNnERIdui9l9DJp5YAsvqqVs5xsUJB+Fpa4kncSNr8b H1MOBR8AQHnsktVEvz+Bh3fvGVSd6ekhdghCapsiLwr1acId7khcP4+X6aw8Ulsh6+SO IImR8P/Zs/1CjWGyFKvLPN7IpkswBeRFhSE1TiuOQL6geeWB8XPbHfbhRHC4CEU6dLwC GB/Uh3t2pCTOJt9q6rJfb0mM2kAcZA+o0DfeF4KgoxbgbpRcbpP2LCT36kun5a28gFQS /zQKQxikMJLUg7Tr0u70qyFZDl+xOwvMSfeU2MfjDjRPCfEmAxXLK+4HAnr5/JdUgZmQ GlIA== X-Gm-Message-State: AEkooutH8kyRzP2fkz3HK4/adAY+lgrRMO2R+F/zEFkPhhgFi75+07zttdh3wWCrw7sNkY0QKfOlnx2CI23blA== X-Received: by 10.202.253.149 with SMTP id b143mr20948539oii.34.1469708728292; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Thu, 28 Jul 2016 05:25:27 -0700 (PDT) In-Reply-To: <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Hemant Singh Date: Thu, 28 Jul 2016 08:25:27 -0400 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113de8d2ac75380538b13aef Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org> Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 12:25:30 -0000 --001a113de8d2ac75380538b13aef Content-Type: text/plain; charset=UTF-8 Brian/Fred, Does it make sense to add a new section towards the end of the draft below. The new section is titled "Changes to RFC 4861" and lists specific changes in the new section. Thanks, Hemant On Wed, Jul 27, 2016 at 4:19 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > David, > > > https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03 > > > --001a113de8d2ac75380538b13aef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
      Brian/Fred,

      Does it make sense to add a= new section towards the end of the draft below.=C2=A0 The new section is t= itled "Changes to RFC 4861" and lists specific changes in the new= section.=C2=A0

      Thanks,

      H= emant

      On Wed, = Jul 27, 2016 at 4:19 PM, Brian E Carpenter <brian.e.carpenter@gm= ail.com> wrote:
      David,


      https://tools.iet= f.org/html/draft-ietf-6man-multi-homed-host-03

      --001a113de8d2ac75380538b13aef-- From nobody Thu Jul 28 16:24:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00A12D989; Thu, 28 Jul 2016 16:24:18 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zrtNaosCnGsS; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 AE8AE12D091; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id y134so26295030pfg.0; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VwfX8PmzTL8hdsLabwjjSbVgHp1pnZUi7EXlsK1CiXo=; b=dU3JiaBL/MZeamkZM+VUh5jFC64DZvIUN+7vGKfWCsHfh80c0jKbJJf98W7YiXUOMX zGmchiyvXOvBTz7cQw2Y9zGIkDK3wWZx8NM/Cpsi9CUYGvSHKI0UfPSZNAy+u90nJwoT MtnVxVz/WacRo8UcH6fgzLCuXdNiRLWETlhAKOJB6W+rVB8K0hqHgjiUMOCMkulllIc1 BX/PFPzMOhRFXWsTAqlzbtOmwapTJBEUhXfbyGGjcXEudsSZSpVHcSS1QazObc+SoMZK EiuUrpJMrFVu1EMax/TFQH6JXIqjGmeyFAgEhLBKmzjNQjPUZBZaUk71mV4Jg54N42eG LjPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=VwfX8PmzTL8hdsLabwjjSbVgHp1pnZUi7EXlsK1CiXo=; b=csx8TVZVbiQNZlsAEQWGeM/PlElRrTrraoGqQ+ySPbZ0ejLyEDUA3QJ4+6PSbpYMhr 7FThQS71yCVRJ6tt/7r2uX4AIiBtVNGQtBcFmfTDmC11aVjnMAwp06TiNHGbQjDG/sLF DOfXMNFnpPz+O2ANuQbQzJJD7O4EBH+OlGbSx7LY+3k9TbwaQmmiv6we0uP/sdlvOC5m oTK6fqI2oZktvaQS1z5zcZuwDLwl6Jtdwd2znr7sKoYnhAXvSeVdrE42cln2oF/yqxvY NIy2VdUFSCKrEpZX7STgX7d3RXQc/JHU+SRRZJn5PyOdsxdNAFKcKa3I+tA6RE3a0Ups GWIw== X-Gm-Message-State: AEkooutbphLm1Q+VofJubvQx5A0hBBYgWQ1O8C0Iju8vkD3lILQJFSJpn2y8p0He3lnK0w== X-Received: by 10.98.129.5 with SMTP id t5mr63314745pfd.32.1469748256299; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) Received: from ?IPv6:2406:e007:5061:1:28cc:dc4c:9703:6781? ([2406:e007:5061:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q1sm19641845pfd.48.2016.07.28.16.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jul 2016 16:24:15 -0700 (PDT) To: Hemant Singh References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 29 Jul 2016 11:24:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org> Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 23:24:18 -0000 Hemant, On 29/07/2016 00:25, Hemant Singh wrote: > Brian/Fred, > > Does it make sense to add a new section towards the end of the draft > below. The new section is titled "Changes to RFC 4861" and lists specific > changes in the new section. We do say this in the Introduction: "Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 4861 will need to extend their implementations accordingly." Is that specific enough? I think it's very hard to say more without making assumptions about individual implementations. (Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires 2016-08-04.) Regards Brian > > Thanks, > > Hemant > > On Wed, Jul 27, 2016 at 4:19 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> David, >> >> >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03 >> >> >> > From nobody Thu Jul 28 16:31:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513512D99A; Thu, 28 Jul 2016 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5qEu9iwuYddu; Thu, 28 Jul 2016 16:31:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 D22E312D98E; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id w18so84804804oiw.3; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ciH32M/CClTinkQ0k6jNhVhoOv1kmKcyivsWpEg3eDA=; b=Nsz/tMejAc8cgqicfHUrrQhIbnfTv8DEig5gYrS8HxmmqpOBRiuc7idwPWKdf/EJeX bixMA1IXXOLiWVpQRf/tvIWUtT+tvylbxGlc13L62b2Re2H7SIM0RT5yZzNERlUi4Gyb tLyW3LL2oOixArWYWZZxzJ7xZufeTpT6/0JF9CRH+OTMfbSiXCyChWX/sjrXj0ufOPQc Xqn2OwHfvDDnVWOdSkdc0znrhpJhOizOBjR4bm6FrrPFEPui9G29SwC46YTUS3vHexsQ Kyo8CImNizF4OqxV/YSET1cAMNOvjcWYQEI/utY2V2wjdjtZRvCaHWQCup5VGvnkkrGj 6c+g== 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; bh=ciH32M/CClTinkQ0k6jNhVhoOv1kmKcyivsWpEg3eDA=; b=cR4+VryF+R5WAKDkPFprDHnyuUYY5UWB+oNLxrpTDYQXil2Ct5XJJ8vDANn+AiIL2u mwxzxsm4Iy02MTyN6n+Bw2ojGyFd1/UL+hKwc6M8NT7/uIEdPaVuDcZVFkLl4ogi+Vne rlmdPDFjpJpGyM992s6fI4p96IZ/DCFoA43t9FuFIYcVPTkj4oF8WcIuT4pZZGCnlKyb 44FbtH/bQt57gbXe+vbTkO/m59A4Wz6p5KDETVx7k0bLygP1/5EhElneHZWBqNAEMbmH KMOumyuRNsFpMAhtwvxcG9S4igRAsCPxbhShnzKV6qem+u1g4bK2y32xzjViV1Y7jijg VtPw== X-Gm-Message-State: AEkooutQESuI5PjHNiu+Vt1Z8pk57/AQ03fGIQ4YhiMNbS+GJShZkNM0r29rGMUoeWkXKXwsOuc9pwuaAaRS1g== X-Received: by 10.157.34.201 with SMTP id y67mr22279210ota.138.1469748713306; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Thu, 28 Jul 2016 16:31:52 -0700 (PDT) In-Reply-To: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Hemant Singh Date: Thu, 28 Jul 2016 19:31:52 -0400 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c0332a6f745e20538ba894d Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org> Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 23:31:55 -0000 --94eb2c0332a6f745e20538ba894d Content-Type: text/plain; charset=UTF-8 Brian, Ok, works for me - we can skip adding the new section. Thanks to you and Fred for working on this doc. Hemant On Thu, Jul 28, 2016 at 7:24 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hemant, > > > We do say this in the Introduction: > "Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC > 4861 will need to extend their implementations accordingly." > Is that specific enough? I think it's very hard to say more without > making assumptions about individual implementations. > > (Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires > 2016-08-04.) > > Regards > Brian > > --94eb2c0332a6f745e20538ba894d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

      Brian,

      Ok, works for me - we can = skip adding the new section.=C2=A0 Thanks to you and Fred for working on th= is doc.

      Hemant


      On Thu, Jul 28, 2016 at 7:24 PM, Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
      =
      Hemant,


      We do say this in the Introduction:
      "Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC=
      4861 will need to extend their implementations accordingly."
      Is that specific enough? I think it's very hard to say more without
      making assumptions about individual implementations.

      (Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires 2= 016-08-04.)

      Regards
      =C2=A0 =C2=A0 Brian

      --94eb2c0332a6f745e20538ba894d-- From nobody Thu Jul 28 20:36:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837C912D7E7; Thu, 28 Jul 2016 20:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PxDH3E3Jd4-4; Thu, 28 Jul 2016 20:36:38 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 1790112D5E7; Thu, 28 Jul 2016 20:36:38 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-21-579acf70604b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 4B.15.02568.07FCA975; Fri, 29 Jul 2016 05:37:20 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 23:30:19 -0400 From: Suresh Krishnan To: Brian E Carpenter , David Lamparter , 6man <6man@ietf.org> Thread-Topic: RFC 6724 rule 5.5 implementation guidance Thread-Index: AQHR6EQfqWT8cYqVCk+WGMHdBIsRjg== Date: Fri, 29 Jul 2016 03:30:18 +0000 Message-ID: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPlG7B+VnhBgv2S1isXHGXyaLt4j4m izWNG5gt3q87w2Zx8vAcJov1p98xWrzuecxocfrYXmYHDo8pvzeyenzZK+Wxc9Zddo8Fm0o9 liz5yeTRuuMvewBbFJdNSmpOZllqkb5dAlfGlDNzGQu6eSou73zE1sD4lrOLkZNDQsBE4vmk J2xdjFwcQgIbGCVW/nvEBOEsZ5S4+Oc8K0gVG1DVhp2fmUBsEYFCiUf/JoLZzALHGCV+7IsG sYUFzCQaF+xngagxl7jf9QHI5gCy9SSmvuMDCbMIqEpM2/aRHcTmFfCVaP04gxFi1wFmiRNv 17OBJBgFxCS+n1oDNV9c4taT+UwQlwpILNlznhnCFpV4+fgfK4StJDHn9TVmiHodiQW7P7FB 2NoSyxa+ZoZYJihxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtjECIyrYxJs ujsY70/3PMQowMGoxMOr4DErXIg1say4MvcQowQHs5IIr+pZoBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFesUeK4UIC6YklqdmpqQWpRTBZJg5OqQZGsakCG9RbGbccd173W0tTe63Z210rffcf 04/OiMiXYOBPvvX4d1b89mOlVscWRYTd6hS+NynlYlufmf73feU7Tj9JYuXt+JJ7P/rplcn1 k4zP39zramyyoG1iwH39M3tDVxks337+R2Pdqesrjx9d0Rzvsmibl+f7JTPSC9arnXe/P2XC 8V8n9yqxFGckGmoxFxUnAgAYT2V5pwIAAA== Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , Jen Linkova Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 03:36:39 -0000 Hi Brian,=0A= =0A= On 07/27/2016 04:19 PM, Brian E Carpenter wrote:=0A= > David,=0A= >=0A= > On 28/07/2016 07:49, David Lamparter wrote:=0A= >> On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote:=0A= >>> On 21/07/2016 02:34, David Lamparter wrote:=0A= >>>> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:=0A= >>>>> Please tell us ASAP if there is anything we should add to=0A= >>>>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#secti= on-3.2=0A= >>>>> or thereabouts.=0A= >>=0A= >> I believe we need to ship the following text (or something similar)=0A= >> /somewhere/:=0A= >=0A= > I like what you wrote. I don't think such eminently practical information= =0A= > fits very well into IETF documents but I'd be interested in other opionio= ns.=0A= > draft-ietf-6man-multi-homed-host is in IETF LC and already on the IESG ag= enda,=0A= > so if we should add this sort of material Suresh had better tell us to=0A= > do so rather soon. One specific comment below...=0A= =0A= I agree with your assessment that this is closely tied to implementation = =0A= details and does not belong here, but I am also fine if you would like to a= dd =0A= some form of generic explanatory text in this regard. Feel free to discuss = =0A= text proposals until the IETF Last Call completes. If there are no other La= st =0A= Call comments we can handle this text addition along with any that are =0A= necessitated by IESG evaluation.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A=