From nobody Wed Jun 1 05:40: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 6586F12D1BF for ; Wed, 1 Jun 2016 05:40:30 -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 7x_2Pl5nhxgW for ; Wed, 1 Jun 2016 05:40:21 -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 190D912D1B8 for ; Wed, 1 Jun 2016 05:40:20 -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 u51CeJQS003732; Wed, 1 Jun 2016 14:40:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B13A203664; Wed, 1 Jun 2016 14:40:40 +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 3E2692031C3; Wed, 1 Jun 2016 14:40:40 +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 u51CeJs7026993; Wed, 1 Jun 2016 14:40:19 +0200 References: <20160211191203.4120F180472@rfc-editor.org> To: v6ops@ietf.org From: Alexandre Petrescu Message-ID: <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> Date: Wed, 1 Jun 2016 14:40:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160211191203.4120F180472@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) (was: BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements) 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, 01 Jun 2016 12:40:30 -0000 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 > > From nobody Wed Jun 1 05:52:13 2016 Return-Path: <11beeasadiq@seecs.edu.pk> 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 5DA3312B007 for ; Wed, 1 Jun 2016 05:52:12 -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, 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 (1024-bit key) header.d=seecs.edu.pk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QSQbxir_UEi for ; Wed, 1 Jun 2016 05:52:09 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 373B312D111 for ; Wed, 1 Jun 2016 05:52:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id c127so16987485ywb.1 for ; Wed, 01 Jun 2016 05:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seecs.edu.pk; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IusVzVGwFdkxwaa51efa4AIlwMbOZHbH+nou/NDz3iU=; b=aRLtdOGIcAogYh02UPtoBL40Q8dBTEL95MAVG3CCsAfbDfDHbQvfF6y+DOpaO7KArQ CdzhERJ8FpjMZRoH0pBWDxZd54zKRICMfNzN1T86KbWvPeQPApFNoqo0/5fcCPv9Ngay ziDca3qr/b5wn+0msq2y7BzeZUNdUPdGgveW4= 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=IusVzVGwFdkxwaa51efa4AIlwMbOZHbH+nou/NDz3iU=; b=FbYzPdBn1b0Wpb3cFfqgN6YfEDmY2TlOhaeGjZMEhvWyYZt3QNjz0x9kJeOy5NS0ew Ti8v3/BagFTjxJmdk+5SY5B78bSM8D4W5Yf3Otpxw5benuYeRlkzGrJDXFsHvZChJp3w ot6QF3gSJmjULu91ToIdqPi2eeQVKYC4T+5xj3Xv3Ta/fxa87bwx4MfmEoiIK0ALs9E2 8JUX/i4kVcanpX4HuFY4lVIUTS6Vpye3/5bZsm4UWWt2ZhFvAQelfjwJxFHynI57lq6d IHfrs7qGu2Pxxyxf5kt4yG91U/UQlJIaRzzjxzYlSXgeFLbCAq4PhF81V9OrxHC+bimQ Y35A== X-Gm-Message-State: ALyK8tLoUHDX4lQEbUeye93ICEXttfhkfXrN63anmnGAAIKNt7zBq+l1ym7dgG2Bf720m0aiJF1EUk//ymBZiCRV X-Received: by 10.13.217.6 with SMTP id b6mr2072906ywe.307.1464785528423; Wed, 01 Jun 2016 05:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.46.18 with HTTP; Wed, 1 Jun 2016 05:51:49 -0700 (PDT) In-Reply-To: <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> From: Adeel Sadiq <11beeasadiq@seecs.edu.pk> Date: Wed, 1 Jun 2016 17:51:49 +0500 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114fc6f8182acf053436f5ac Archived-At: Cc: IPv6 Ops WG Subject: Re: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) (was: BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements) 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, 01 Jun 2016 12:52:12 -0000 --001a114fc6f8182acf053436f5ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Alexandre Thank you for your concern. I think we'll have to look into it by making different test scenarios, both with IPv4 and IPv6. Like maybe we need less/more RAs when an IPv6-only network needs to connect to IPv4-only network, or vice versa, or any possible combination of the two. Regards Adeel Sadiq On Wed, Jun 1, 2016 at 5:40 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit : > >> 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.t= xt >> >> 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 > --001a114fc6f8182acf053436f5ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Alexandre

Thank you for your conce= rn.

I think we'll have to look into it by maki= ng different test scenarios, both with IPv4 and IPv6. Like maybe we need le= ss/more RAs when an IPv6-only network needs to connect to IPv4-only network= , or vice versa, or any possible combination of the two.

Regards

Adeel Sadiq

On Wed, Jun 1, 2016 at 5:40= PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit :
A new Request for Comments is now available in online RFC libraries.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BCP 202
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7772

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Reducing Energy Cons= umption of Router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adver= tisements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0A. Yourtchenko,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Co= litti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Best Current Practic= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0February 2016 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 ayourtch@cisco.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lorenzo@google.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 12555
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See Also:=C2=A0 =C2=A0BCP 202

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-v6ops-reducing= -ra-energy-consumption-03.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc7772

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /dx.doi.org/10.17487/RFC7772

Frequent Router Advertisement messages can severely impact host power
consumption.=C2=A0 This document recommends operational practices to avoid<= br> 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
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/retriev= e/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 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

--001a114fc6f8182acf053436f5ac-- From nobody Wed Jun 1 06:00: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 DCFC612D111 for ; Wed, 1 Jun 2016 06:00:28 -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 Jqxd6jf3YgnE for ; Wed, 1 Jun 2016 06:00:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A787512D1BE for ; Wed, 1 Jun 2016 06:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=774; q=dns/txt; s=iport; t=1464786022; x=1465995622; h=date:from:message-id:to:subject; bh=dJ/0ohN9QPPqrQKssKR11AMQz2thanHvEsk2iYfv6BA=; b=XD/nUghXPoXSohEjYlPeEq7UmU+xmCJ3tOyrkvtIBnwybVGu4HZCKuNJ mSIeEsd2HrKZ3Au5GnadNGFA0h5qIVKoQhKzFHol52m0QFzCjjut7ihmT rlMBo4YWXeCE4lZzAdk5wb529TxllYBWgZtS0/lJE6QlWEwZPkVsNlv3Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgDi205X/5JdJa1bgz2rFAGQUgENg?= =?us-ascii?q?XqHQTgUAQEBAQEBAWUnhgE0iQ8Bn06hPgEBAQEGAQEBAQEBASCQAIJggi4Fjlm?= =?us-ascii?q?JXoEvnA2PTB4BAUKEDYsFAQEB?= X-IronPort-AV: E=Sophos;i="5.26,401,1459814400"; d="scan'208";a="280386951" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2016 13:00:21 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u51D0LLD006923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2016 13:00:21 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 u51D0LuG009979 for ; Wed, 1 Jun 2016 06:00:21 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u51D0LAD009978 for v6ops@ietf.org; Wed, 1 Jun 2016 06:00:21 -0700 Date: Wed, 1 Jun 2016 06:00:21 -0700 From: fred@cisco.com Message-Id: <201606011300.u51D0LAD009978@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: Wed, 01 Jun 2016 13:00:29 -0000 RFC Editor: AUTH48 2016-04-13 draft-ietf-v6ops-ipv6-ehs-in-real-world RFC Editor: EDIT 2016-05-27 draft-ietf-v6ops-host-addr-availability RFC Editor: RFC-EDITOR 2016-05-10 draft-bao-v6ops-rfc6145bis 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-05 draft-templin-v6ops-pdhost 2016-01-03 draft-xcf-v6ops-chinatelecom-deployment 2016-01-03 draft-xli-v6ops-cernet-deployment Individual Submission: Updated 2016-05-01 draft-anderson-v6ops-v4v6-xlat-prefix From nobody Wed Jun 1 06:05: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 2D7D912D1BE for ; Wed, 1 Jun 2016 06:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, 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 N_9lxQ6kjCtG for ; Wed, 1 Jun 2016 06:05:39 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 B156F12D1B8 for ; Wed, 1 Jun 2016 06:05:38 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a20so26203122wma.1 for ; Wed, 01 Jun 2016 06:05:38 -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=wj6N8lh2FLGMbRNB87TkajEdOv2aMOUHnKPdrDRsGow=; b=x9Kf/kngbaEmHi1r8Iqo/3DrL5xiqXy71XpAjXO7DszcNSEVfrBQFF9QdJRSi5iODA iolFRScHA1mnJEcZfiQA8RwzzGlivlF9n+AiS07AqO9d5S/gk9C4sUwE0grjLTPjThbX rgi3H8ijtitdgLVgXuJZH0EZRDHZa0LjvRURpSsuI4WQabeWXGJldjD3ugleZX4LOTQR ZBsDXn7m2jwke1olMoWQlOvUYpK0JK/LDiy3+MPbZDfQFvMZV6F2IjPnBWk9v2ZX8XVJ S45SJCpC7nLa4We3HR4spER18QVIq9emnBXdf0X7gfPEedYUMA/arbwJSZpUK2Vw5/CQ /4wg== 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=wj6N8lh2FLGMbRNB87TkajEdOv2aMOUHnKPdrDRsGow=; b=RNZkEqQYrm22xjZ+AbZOSyYJeiapTVu9UeFQ5RxqLIwn9xbAHzPl9gc7qtAWmfo6Mo QoMdBzlJX9Ro2jiYQwRQ+fXFcGh/mlN9TGotRKWzdTF99GKzLth1ANS3ky4qBQg71X4a 4bAoIwKe+asNWGwyEbxTLIquEoEk8s9WlRriyIb/UT+K/+3aDJg2xZOACCWpvkgBShuf wyhEPzQkQEdiStno8SkPo/tkxTe0TavqOfC1ZjFcbMqQJQi6H9FhVdqmSpFAmc3nYUsi lM1a9d1m10HsgyeQg8wJy6+RFDxYuNw9RigmPq1vaER84/5/giJ8CKVN0CzOCArTp1+K TeDw== X-Gm-Message-State: ALyK8tIFcCkj8HjqC9L5o0epNyBsXEx1ZoYBiaxTH5ghKpPCG5i3X+85xvlQBlCLMfYIgetQ4D0kDJELyjE1sw== MIME-Version: 1.0 X-Received: by 10.28.98.138 with SMTP id w132mr3696497wmb.7.1464786337062; Wed, 01 Jun 2016 06:05:37 -0700 (PDT) Received: by 10.28.13.77 with HTTP; Wed, 1 Jun 2016 06:05:37 -0700 (PDT) In-Reply-To: <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> Date: Wed, 1 Jun 2016 14:05:37 +0100 Message-ID: From: Nabil Benamar To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1148e9564aeae00534372566 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) (was: BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements) 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, 01 Jun 2016 13:05:41 -0000 --001a1148e9564aeae00534372566 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Thank you for rising this issue. I'm interested in working on the energy consumption in IPv6 and compare it with IPv4. Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Wed, Jun 1, 2016 at 1:40 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit : > >> 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.t= xt >> >> 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 >> >> >> --001a1148e9564aeae00534372566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex,

Thank you for rising this issue. I= 'm interested in working on the energy consumption in IPv6 and compare = it with IPv4.

=
Best regar= ds
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8= =B1=D9=88


On Wed, Jun 1, 2016 at 1:40 PM, Alexandre Pe= trescu <alexandre.petrescu@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit :
A new Request for Comments is now available in online RFC libraries.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BCP 202
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7772

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Reducing Energy Cons= umption of Router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adver= tisements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0A. Yourtchenko,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Co= litti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Best Current Practic= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0February 2016 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 ayourtch@cisco.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lorenzo@google.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 12555
=C2=A0 =C2=A0 =C2=A0 =C2=A0 See Also:=C2=A0 =C2=A0BCP 202

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-v6ops-reducing= -ra-energy-consumption-03.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc7772

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /dx.doi.org/10.17487/RFC7772

Frequent Router Advertisement messages can severely impact host power
consumption.=C2=A0 This document recommends operational practices to avoid<= br> 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
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/retriev= e/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



--001a1148e9564aeae00534372566-- From nobody Wed Jun 1 09:13: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 25C9012D52B for ; Wed, 1 Jun 2016 09:13:55 -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 lYEpvkZE1v6d for ; Wed, 1 Jun 2016 09:13:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CC112B042 for ; Wed, 1 Jun 2016 09:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4637; q=dns/txt; s=iport; t=1464797632; x=1466007232; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6nWUOq1al2XKoXGNLc0M/RU/yIqvJYQK/+P0AhdybLU=; b=SFbaZrWICSjdVojYzpyXvDlvfwShIrEDworD/ut6pP+ccmc/pTl/0JeL LEH3Y5NtYbNuZsQXeLADmHTITTomkElaKqmW9TfeUp83QlsyUacwfuE2k my//o97IpYst1QNjKsuKfaxzX2a6VVyoemF+PCT8ASUs1zosI2xWlQVzV I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgBuCE9X/4YNJK1dgz1WfQauIYtvD?= =?us-ascii?q?oF6FwuFbwKBMTgUAQEBAQEBAWUnhEUBAQEDAQEBAUsgAgkFCwIBCBQEDBcLIQY?= =?us-ascii?q?KASUCBA4FDgYHAgSHdAMPCA69Aw2EHwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Oi?= =?us-ascii?q?B6CVoE5gQqBSRUFOoMMgi4FmAQzAYMqgWhthieBeY8ch2SHZwEeAUOCEyWBNW4?= =?us-ascii?q?BiQE2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,401,1459814400"; d="asc'?scan'208";a="280292806" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2016 16:13:50 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u51GDnGO022859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2016 16:13:50 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 11:13:49 -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.1104.009; Wed, 1 Jun 2016 11:13:49 -0500 From: "Fred Baker (fred)" To: Alexandre Petrescu Thread-Topic: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) (was: BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements) Thread-Index: AQHRvCCUAx/yRP/3iUuOvKaYDHQCTA== Date: Wed, 1 Jun 2016 16:13:49 +0000 Message-ID: <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> In-Reply-To: <5099e169-696d-54ec-a4a7-8cc773e358c5@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=_014F509C-4422-402A-ABAE-B7F79A628157"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) (was: BCP 202, RFC 7772 on Reducing Energy Consumption of Router Advertisements) 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, 01 Jun 2016 16:13:55 -0000 --Apple-Mail=_014F509C-4422-402A-ABAE-B7F79A628157 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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: >=20 > Hi v6ops, >=20 > I wonder whether there may be interest in evaluating the energy = consumption of an IPv6 application on smartphones, compared to its IPv4 = counterpart. >=20 > I suspect the difference may be negligible but I am not sure. >=20 > It would be good to avoid a situation in which the end user prefers = IPv4 on the smartphone because IPv6 empties the battery. >=20 > Alex >=20 > Le 11/02/2016 =E0 20:12, rfc-editor@rfc-editor.org a =E9crit : >> A new Request for Comments is now available in online RFC libraries. >>=20 >> BCP 202 >> RFC 7772 >>=20 >> 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 >>=20 >> I-D Tag: = draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt >>=20 >> URL: https://www.rfc-editor.org/info/rfc7772 >>=20 >> DOI: http://dx.doi.org/10.17487/RFC7772 >>=20 >> Frequent Router Advertisement messages can severely impact host power >> consumption. This document recommends operational practices to avoid >> such impact. >>=20 >> This document is a product of the IPv6 Operations Working Group of = the IETF. >>=20 >>=20 >> 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. >>=20 >> 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 >>=20 >> For searching the RFC series, see https://www.rfc-editor.org/search >> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >>=20 >> 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. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_014F509C-4422-402A-ABAE-B7F79A628157 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 iQIVAwUBV08JvEayAOS/EQ8MAQJvhg/7BcrZ4hfg0es32oczcyj1+rmsSirs+Wjg vswDqqHTBW9zN5+w85s/MKQak07x/Gp7nY5pw/vZfAF78ETnOmBAptKDuMEKWCiD /Wdaf95lcOizRf7CeI2YWjcO75X6tfJ30XT5jjoFn3DAku2YqkIAJrgud9DhhJv4 776S8X+FUuB3DRBLipbvgaFc3dZxBu017xbr5dWuYWrkmaYfP4bZcY6+6bT6Q9Ib M6KyBeeU1Rp3kYIXt3olQSVwT21IK7kDuj3+bqA5d+FzMVk9Ns7NPw72ujal4ns6 3mGBfg/ESe9c2oMHZzAMVRZ2N2g247jLq8asFGtIcBLGjJ38njVBuvpIdC1rAtM6 Dm31/Q6GuWQPrkpuw5E4jrZt5tGSHkI6Xqtic6ryBKvGwlnmhnCI1lZtKLvxYpl1 frne1p4eM1s9zdko0/ycVK5XTxrI8DRHRwyqjpg3GA2M8lzbsZQKGWFxhaeyVREc nttV6debjyFO1u2kBdklszzHgeNa/AjZ8ZueCo57u5mLtBJEW72uXOmHCnerI22B 1YrB8pc1xM6S60bCElWWDaBHb6FkrI+de0JLSU9FluAA7Mv0BUFu4c0uyxohyp3N /tTisOm5Kq4QoTT0jSc3fceKFM8EY8rMw2HaFSbhF/AkvehFMzlQfIG3Sz6uqzmb Co2kf1/IHSM= =6EBy -----END PGP SIGNATURE----- --Apple-Mail=_014F509C-4422-402A-ABAE-B7F79A628157-- From nobody Wed Jun 1 10:02: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 3A5EF12B04D for ; Wed, 1 Jun 2016 10:02:29 -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 wwlSdCkv331s for ; Wed, 1 Jun 2016 10:02:27 -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 1376612B034 for ; Wed, 1 Jun 2016 10:02:27 -0700 (PDT) Received: from mb-2.local ([IPv6:2620:11a:c081:20:a967:c8a:8ddf:4da7]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u51H2Mp3022844 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 1 Jun 2016 17:02:22 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:a967:c8a:8ddf:4da7] claimed to be mb-2.local To: "Fred Baker (fred)" , Alexandre Petrescu References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> From: joel jaeggli Message-ID: <29333516-5eda-a15c-3cb2-6a58b7e264db@bogus.com> Date: Wed, 1 Jun 2016 10:02:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrmO4qqQTODdC5XD1b1RmfCIQEvC6E9LK" 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: Wed, 01 Jun 2016 17:02:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nrmO4qqQTODdC5XD1b1RmfCIQEvC6E9LK Content-Type: multipart/mixed; boundary="NERXtUhlseA4KmtTV2QjegXk2D4FRiQlj" From: joel jaeggli To: "Fred Baker (fred)" , Alexandre Petrescu Cc: "v6ops@ietf.org" Message-ID: <29333516-5eda-a15c-3cb2-6a58b7e264db@bogus.com> Subject: Re: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) References: <20160211191203.4120F180472@rfc-editor.org> <5099e169-696d-54ec-a4a7-8cc773e358c5@gmail.com> <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> In-Reply-To: <4B8679AA-6FA4-4D9F-A7DD-C8DD6F525EC6@cisco.com> --NERXtUhlseA4KmtTV2QjegXk2D4FRiQlj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/16 9:13 AM, Fred Baker (fred) wrote: > 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? Energy management is a widely distributed problem. there are a number of areas where IETF participants have been peripherally or directly involved= =2E Building or network level power management was an activity of the operations and management area. Scheduling on air interfaces would tend to fall to other SDO's though as fred notes, multicast contention and protocol chattiness are considerations for protocols that fall within the IETF scope, there is also scope for transport or IRTF related exploration probably. joel > Do you have something to share? >=20 >> On Jun 1, 2016, at 5:40 AM, Alexandre Petrescu >> wrote: >>=20 >> Hi v6ops, >>=20 >> I wonder whether there may be interest in evaluating the energy >> consumption of an IPv6 application on smartphones, compared to its >> IPv4 counterpart. >>=20 >> I suspect the difference may be negligible but I am not sure. >>=20 >> It would be good to avoid a situation in which the end user prefers >> IPv4 on the smartphone because IPv6 empties the battery. >>=20 >> Alex >>=20 >> Le 11/02/2016 =E0 20:12, rfc-editor@rfc-editor.org a =E9crit : >>> A new Request for Comments is now available in online RFC >>> libraries. >>>=20 >>> BCP 202 RFC 7772 >>>=20 >>> Title: Reducing Energy Consumption of Router Advertisements=20 >>> 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 >>>=20 >>> I-D Tag: >>> draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt >>>=20 >>> URL: https://www.rfc-editor.org/info/rfc7772 >>>=20 >>> DOI: http://dx.doi.org/10.17487/RFC7772 >>>=20 >>> Frequent Router Advertisement messages can severely impact host >>> power consumption. This document recommends operational >>> practices to avoid such impact. >>>=20 >>> This document is a product of the IPv6 Operations Working Group >>> of the IETF. >>>=20 >>>=20 >>> 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. >>>=20 >>> This announcement is sent to the IETF-Announce and rfc-dist >>> lists. To subscribe or unsubscribe, see=20 >>> https://www.ietf.org/mailman/listinfo/ietf-announce=20 >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>=20 >>> For searching the RFC series, see >>> https://www.rfc-editor.org/search For downloading RFCs, see >>> https://www.rfc-editor.org/retrieve/bulk >>>=20 >>> 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. >>>=20 >>>=20 >>> The RFC Editor Team Association Management Solutions, LLC >>>=20 >>>=20 >>=20 >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --NERXtUhlseA4KmtTV2QjegXk2D4FRiQlj-- --nrmO4qqQTODdC5XD1b1RmfCIQEvC6E9LK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAldPFSAACgkQ8AA1q7Z/VrKPYQCeLQYxYfxPqj/fmIw3k+PdIisV gnMAnjqZg9XNe39Zde9YH8S+3LciloK8 =u4gd -----END PGP SIGNATURE----- --nrmO4qqQTODdC5XD1b1RmfCIQEvC6E9LK-- From nobody Thu Jun 2 01:33: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 120D212B04A for ; Thu, 2 Jun 2016 01:33:53 -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 b4SINX0iDGtQ for ; Thu, 2 Jun 2016 01:33:50 -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 B480612B038 for ; Thu, 2 Jun 2016 01:33:49 -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 u528XjX8025366; Thu, 2 Jun 2016 10:33:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E217E205AD2; Thu, 2 Jun 2016 10:34:07 +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 D535F205AD1; Thu, 2 Jun 2016 10:34:07 +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 u528Xjmp003962; Thu, 2 Jun 2016 10:33:45 +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: <5fcbf830-fc25-7394-5c8a-55dc9189b462@gmail.com> Date: Thu, 2 Jun 2016 10:33:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 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 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: Thu, 02 Jun 2016 08:33:53 -0000 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? It would be interesting to look at how IPv6 link and network protocol behaviour may consume more or less energy. ND efficiency, energy-efficient IP paths in access and core networks, path-energy discovery: are topics very interesting to explore. Other operational question may be whether the full use of IPv6 on a smartphone (disable IPv4) draws its battery more, less, or just as when only IPv4 is used. It may need some measurement of application behaviour. Recently energy-specific APIs became available on smartphone OSs, supposing they're working ok on IPv6. > Do you have something to share? Well not at this time. We are currently exploring the application-specific measurement part with a few people. Maybe that can lead to an Internet Draft. Alex > >> 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 Thu Jun 2 02:37: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 1521612D160 for ; Thu, 2 Jun 2016 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, 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 dkXxURUus0Y6 for ; Thu, 2 Jun 2016 02:37:16 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 70C0212D67A for ; Thu, 2 Jun 2016 02:37:16 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a20so59574858wma.1 for ; Thu, 02 Jun 2016 02:37:16 -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=P6p32sq1ZY0T88nxnUSlOllFJNhoqR/r0eFoONQU+YI=; b=sl5ZFbBMo6Pp3llRn7rjdyYMTYSd6LLrxamFBk4KVIVAQB4iLCwi0NH4DnmwreL71+ XXhvTli15SAvYyTmXmXNWHh7ZfNSDQk+wgay2I4PUE/rzR7YXV1/vRfaIrAD7LmIgry5 Sd1PSxInFnVirMluM9LPviUZlc97SI1VQrb+Yrwf4R4KCvgheHAsDqZvJYLtgYQ0PhUu TThk1Vo5uaneaW9LJk078NuAT1MOwc+MiIvM+y6w2Fdw6yzG1uMt2HGxlxT1xrLfKhyB yGFfwnasoVGMYUunvWUp6sLlZ953JIeRLbOZnlkdDrtbyChhkZkvEUaaJL+9JE76LVKI CUbw== 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=P6p32sq1ZY0T88nxnUSlOllFJNhoqR/r0eFoONQU+YI=; b=OFyIKy10LUckIdzNyyrq8ZqZeISZkumD1evdWphXu/UrAyJKFNk63ycueqUxUg3ccx ePgdNp1NRhRZArl5BF5+hpkKcKI4BDUydweXLrfJoYGMzKTe2UFrD6O+DbqGeDxC2NYi gPJtZmh1nuvGgmAWfLYmqhB8UMVNHtRroXTu0eL65UUYlvDV76SQpJiJksqM7lzJrJj7 a7kL8qe28k4rz5eUVXsMYvA4dBP+4hastjbq2D6qmMsbguctftsdRTQ41mznkARJ7PPw AyaAnwoQaoyOiz7MjIHoa6R96YTQhwGK7h5tl5x7zxnxVYC2v0xXz6CQwET9xyFf7OZP +sug== X-Gm-Message-State: ALyK8tJ8xWcsOTPZh5/nZvUqlxaQ5uUSDf9rZSBywtkbXsKxS/H9WVx9GKv1CAXXFdS02uFM7rmcJSqP0L2oSg== MIME-Version: 1.0 X-Received: by 10.28.46.83 with SMTP id u80mr24717623wmu.35.1464860234853; Thu, 02 Jun 2016 02:37:14 -0700 (PDT) Received: by 10.28.13.77 with HTTP; Thu, 2 Jun 2016 02:37:14 -0700 (PDT) In-Reply-To: <5fcbf830-fc25-7394-5c8a-55dc9189b462@gmail.com> 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> Date: Thu, 2 Jun 2016 10:37:14 +0100 Message-ID: From: Nabil Benamar To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114240e8f1b6100534485932 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: Thu, 02 Jun 2016 09:37:19 -0000 --001a114240e8f1b6100534485932 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, Since there is no dual stack on 3g/4g in my side, I can only test with wifi. Create a tunnel with HE.net for example and then connect a smartphone on IPv6 only..make the measurements and then switch to IPv4 only repeat the steps.....energy measurements are application specific! I would like to ask the members of the list which is the best application to use for energy consumption on Android ? It would also be interesting to measure with different mobile OS ! Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 http://nabilbenamar.ipv6-lab.net/ On Thu, Jun 2, 2016 at 9:33 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Le 01/06/2016 =C3=A0 18:13, Fred Baker (fred) a =C3=A9crit : > >> 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? >> > > It would be interesting to look at how IPv6 link and network protocol > behaviour may consume more or less energy. ND efficiency, > energy-efficient IP paths in access and core networks, path-energy > discovery: are topics very interesting to explore. > > Other operational question may be whether the full use of IPv6 on a > smartphone (disable IPv4) draws its battery more, less, or just as when > only IPv4 is used. It may need some measurement of application > behaviour. Recently energy-specific APIs became available on smartphone > OSs, supposing they're working ok on IPv6. > > Do you have something to share? >> > > Well not at this time. We are currently exploring the > application-specific measurement part with a few people. Maybe that can > lead to an Internet Draft. > > Alex > > > > >> 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit : >>> >>>> 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 >>> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114240e8f1b6100534485932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Since there is no dual stack on 3g/= 4g in my side, I can only test with wifi. Create a tunnel with HE.net for e= xample and then connect a smartphone on IPv6 only..make the measurements an= d then switch to IPv4 only repeat the steps.....energy measurements are app= lication specific!

I would like to ask the members of the list which is the best appl= ication to use for energy consumption on Android ?

It would also be interesting to me= asure with different mobile OS !

Best regards
Nabil Benamar
-------------------
=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9= =86=D8=B9=D9=85=D8=B1=D9=88


On Thu, Jun 2, 2016 at 9:33 AM, Alexandre Pe= trescu <alexandre.petrescu@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Le 01/06/2016 =C3=A0 18:13, = Fred Baker (fred) a =C3=A9crit :
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?

 It would be interesting to look at how IPv6 link and network protocol
behaviour may consume more or less energy.=C2=A0 ND efficiency,
energy-efficient IP paths in access and core networks, path-energy
discovery: are topics very interesting to explore.

Other operational question may be whether the full use of IPv6 on a
smartphone (disable IPv4) draws its battery more, less, or just as when
only IPv4 is used.=C2=A0 It may need some measurement of application
behaviour.=C2=A0 Recently energy-specific APIs became available on smartpho= ne
OSs, supposing they're working ok on IPv6.

Do you have something to share?

 Well not at this time.=C2=A0 We are currently exploring the
application-specific measurement part with a few people.=C2=A0 Maybe that c= an
lead to an Internet Draft.

Alex




On Jun 1, 2016, at 5:40 AM, Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com> 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit :
A new Request for Comments is now available in online RFC
libraries.

BCP 202 RFC 7772

Title:=C2=A0 =C2=A0 =C2=A0 Reducing Energy Consumption of Router Advertisem= ents
=C2=A0Author:=C2=A0 =C2=A0 =C2=A0A. Yourtchenko, L. Colitti Status:=C2=A0 = =C2=A0 =C2=A0Best Current
Practice Stream:=C2=A0 =C2=A0 =C2=A0IETF Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0Fe= bruary 2016 Mailbox:
ayourtch@cisco.com<= /a>, lorenzo@google= .com Pages:=C2=A0 =C2=A0 =C2=A0 6 Characters:
12555 See Also:=C2=A0 =C2=A0BCP 202

I-D Tag: draft-ietf-v6ops-reducing-ra-energy-consumption-03.txt

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.rfc-editor.org/in= fo/rfc7772

DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dx.doi.org/10.17487/RFC7772=

Frequent Router Advertisement messages can severely impact host
power consumption.=C2=A0 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-announ= ce
https://mailman.rfc-editor.org/mailman/listi= nfo/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@r= fc-editor.org.=C2=A0 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
=C2=A0v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


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

--001a114240e8f1b6100534485932-- From nobody Thu Jun 2 03:22: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 ACACF12D6E2 for ; Thu, 2 Jun 2016 03:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gih.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEuqd3eGdCI2 for ; Thu, 2 Jun 2016 03:22:25 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [194.33.63.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE6112D6E4 for ; Thu, 2 Jun 2016 03:22:19 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 3098E32060F; Thu, 2 Jun 2016 11:22:18 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=gih.co.uk; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type; s=mahalo1; bh=EKU+M4han+bMQE8UnXDM2nOrbI8=; b=Exp GpbJCWuhpKSR5La26HiLn/6Nwdf73EX030vbmJED8UK3Gsah+ibOQ3j3O3gN/X/8 QpjGl9OiY3gfJB6/1bcDnxvRvRx6oHwoYmemaGviCdxm/xPjcgxgP5pXWt0DV9d1 VP5NtlNLR5h23TcFD4j1Y7WTRgTp71j/mnQjPTc4= Received: from [192.168.1.33] (ANice-651-1-312-79.w83-201.abo.wanadoo.fr [83.201.164.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 31FB7320590; Thu, 2 Jun 2016 11:22:17 +0100 (BST) To: Nabil Benamar , Alexandre Petrescu 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> From: Olivier MJ Crepin-Leblond Message-ID: <093d3a00-a2cc-c6d9-8939-56114eb4a461@gih.com> Date: Thu, 2 Jun 2016 12:22:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------23159D240CE88FE901126EC8" 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: Thu, 02 Jun 2016 10:22:29 -0000 This is a multi-part message in MIME format. --------------23159D240CE88FE901126EC8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, it is also worth noting that 3G & 4G in particular appears to drain battery more than 2G. Results could be flawed because due to novelty, in most places 4G signal strength is not yet at the level of 2G or 3G signal strength. A study under controlled environment would be somehow interesting indeed although I fail to see the end goal for performing such a study? Do we want to prove that longer addresses mean more power requirements? I would have thought the end point really relates to chipset architecture, not bits transmitted. Kindest regards, Olivier On 02/06/2016 11:37, Nabil Benamar wrote: > Hi All, > > Since there is no dual stack on 3g/4g in my side, I can only test with > wifi. Create a tunnel with HE.net for example and then connect a > smartphone on IPv6 only..make the measurements and then switch to IPv4 > only repeat the steps.....energy measurements are application specific! > > I would like to ask the members of the list which is the best > application to use for energy consumption on Android ? > > It would also be interesting to measure with different mobile OS ! > > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 > > http://nabilbenamar.ipv6-lab.net/ > > On Thu, Jun 2, 2016 at 9:33 AM, Alexandre Petrescu > > > wrote: > > Le 01/06/2016 =C3=A0 18:13, Fred Baker (fred) a =C3=A9crit : > > I personally would find that interesting. As you note, we recen= tly > 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? > > > It would be interesting to look at how IPv6 link and network protoc= ol > behaviour may consume more or less energy. ND efficiency, > energy-efficient IP paths in access and core networks, path-energy > discovery: are topics very interesting to explore. > > Other operational question may be whether the full use of IPv6 on a > smartphone (disable IPv4) draws its battery more, less, or just as > when > only IPv4 is used. It may need some measurement of application > behaviour. Recently energy-specific APIs became available on > smartphone > OSs, supposing they're working ok on IPv6. > > Do you have something to share? > > > Well not at this time. We are currently exploring the > application-specific measurement part with a few people. Maybe > that can > lead to an Internet Draft. > > Alex > > > > > 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 sur= e. > > 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 =C3=A0 20:12, rfc-editor@rfc-editor.org > a =C3=A9crit : > > A new Request for Comments is now available in online R= FC > libraries. > > BCP 202 RFC 7772 > > Title: Reducing Energy Consumption of Router > Advertisements > Author: A. Yourtchenko, L. Colitti Status: =20 > Best Current > Practice Stream: IETF Date: February 2016 > Mailbox: > ayourtch@cisco.com , > lorenzo@google.com Pages:=20 > 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 operationa= l > 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-dis= t > > 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, L= LC > > > > _______________________________________________ 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 --=20 Olivier MJ Cr=C3=A9pin-Leblond, PhD http://www.gih.com/ocl.html --------------23159D240CE88FE901126EC8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all,

it is also worth noting that 3G & 4G in particular appears to drain battery more than 2G. Results could be flawed because due to novelty, in most places 4G signal strength is not yet at the level of 2G or 3G signal strength. A study under controlled environment would be somehow interesting indeed although I fail to see the end goal for performing such a study? Do we want to prove that longer addresses mean more power requirements? I would have thought the end point really relates to chipset architecture, not bits transmitted. Kindest regards,

Olivier

On 02/06/2016 11:37, Nabil Benamar wrote:
Hi All,

Since there is no dual stack on 3g/4g in my side, I can only test with wifi. Create a tunnel with HE.net for example and then connect a smartphone on IPv6 only..make the measurements and then switch to IPv4 only repeat the steps.....energy measurements are application specific!

I would like to ask the members of the list which is the best application to use for energy consumption on Android ?

It would also be interesting to measure with different mobile OS !

Best regards
Nabil Benamar
----------= ---------
=D9=86=D8= =A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88


On Thu, Jun 2, 2016 at 9:33 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 01/06/2016 =C3=A0 18:13, Fred Baker (fred) a = =C3=A9crit :
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?

 It would be interesting to look at how IPv6 link and network protocol
behaviour may consume more or less energy.=C2=A0 ND efficienc= y,
energy-efficient IP paths in access and core networks, path-energy
discovery: are topics very interesting to explore.

Other operational question may be whether the full use of IPv6 on a
smartphone (disable IPv4) draws its battery more, less, or just as when
only IPv4 is used.=C2=A0 It may need some measurement of application
behaviour.=C2=A0 Recently energy-specific APIs became availab= le on smartphone
OSs, supposing they're working ok on IPv6.
Do you have something to share?

 Well not at this time.=C2=A0 We are currently exploring the application-specific measurement part with a few people.=C2=A0 Maybe that can
lead to an Internet Draft.

Alex




On Jun 1, 2016, at 5:40 AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com&= gt; 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 =C3=A0 20:12, rfc-editor@rfc-editor.org a =C3=A9crit :
A new Request for Comments is now available in online RFC
libraries.

BCP 202 RFC 7772

Title:=C2=A0 =C2=A0 =C2=A0 Reducing Energy Consumpt= ion of Router Advertisements
=C2=A0Author:=C2=A0 =C2=A0 =C2=A0A. Yourtchenko, L.= Colitti Status:=C2=A0 =C2=A0 =C2=A0Best Current
Practice Stream:=C2=A0 =C2=A0 =C2=A0IETF Date:=C2=A0= =C2=A0 =C2=A0 =C2=A0February 2016 Mailbox:
ayourtch@cisco.com, lorenzo@google.com Pages:=C2=A0 =C2=A0 =C2=A0 6 Characters:
12555 See Also:=C2=A0 =C2=A0BCP 202

I-D Tag: draft-ietf-v6ops-reducing-ra-energy-consumption-03.= txt

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.= rfc-editor.org/info/rfc7772

DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dx.do= i.org/10.17487/RFC7772

Frequent Router Advertisement messages can severely impact host
power consumption.=C2=A0 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://mail= man.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.=C2= =A0 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
=C2=A0v6= ops@ietf.org https://www.ie= tf.org/mailman/listinfo/v6ops


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



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


--=20
Olivier MJ Cr=C3=A9pin-Leblond, PhD
h=
ttp://www.gih.com/ocl.html
--------------23159D240CE88FE901126EC8-- From nobody Thu Jun 2 04:02: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 9AAF712D68C for ; Thu, 2 Jun 2016 04:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] 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 UG3D9Nxywmfy for ; Thu, 2 Jun 2016 04:02:29 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) (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 6934712D153 for ; Thu, 2 Jun 2016 04:02:08 -0700 (PDT) Received: from [85.158.137.67] by server-12.bemta-3.messagelabs.com id CD/D8-21858-E2210575; Thu, 02 Jun 2016 11:02:06 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRWlGSWpSXmKPExsUy9d9HH11doYB wg6mbzSxOnnnCZvF+ViOrxc3/01gsTh/by+zA4nFt0w9mj52z7rJ7LFnykymAOYo1My8pvyKB NeP9gTtsBXdeMVY8n/6UuYHxxHPGLkYuDiGBTYwS33csYYJwDjBKzHixHCpzklFi8Z5lQA4nB 5uArkT7rFXMIAkRgRZGiZNbl7N1MXJwMAuoSsz+ww9SIywQLPGv6xo7iC0iECIx69JkRgjbSW LLo5ksIOUsAioSuxfJg4R5BUIl1nXfYIHYdZhJ4v7OSWC9nALWEtvXfWUFsRkFZCW+NK5mBrG ZBcQlbj2ZzwRiSwgISCzZc54ZwhaVePn4HyuErSBxaVEXK0R9nsSDF9vYIZYJSpyc+YRlAqPI LCSjZiEpm4WkbBbYZ5oS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjRnFqUVlqka6hiV5SU WZ6RkluYmaOrqGBsV5uanFxYnpqTmJSsV5yfu4mRmBcMgDBDsYV2z0PMUpyMCmJ8q4s8w8X4k vKT6nMSCzOiC8qzUktPsQow8GhJMErJhgQLiRYlJqeWpGWmQNMEDBpCQ4eJRHeqQJAad7igsT c4sx0iNQpRl2OHx331zIJseTl56VKifOqgMwQACnKKM2DGwFLVpcYZaWEeRmBjhLiKUgtys0s QZV/xSjOwagkzGsAMoUnM68EbtMroCOYgI4oeOQPckRJIkJKqoFxX8isiwvifq2NdrinqeSw9 bbQ3RptuX+/zNrui3PbXrtaey5TRDLl/rSJLlFBB76cY1WeEjAxvnrGJ83tqSH/ml+fj2y3P/ ib/9Cp2RnzH0xXnc7Aknii7+u59yrNnMWv5gncrQr/IDl538tzpR/fCD7J6L1oyFn0UHtvUL7 Ggelt5/nPvr7QoMRSnJFoqMVcVJwIAC2SKrVRAwAA X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-139.messagelabs.com!1464865324!22030264!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9258 invoked from network); 2 Jun 2016 11:02:05 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-8.tower-139.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jun 2016 11:02:05 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Thu, 02 Jun 2016 12:01:57 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Thu, 02 Jun 2016 12:02:01 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Thu, 2 Jun 2016 12:01:43 +0100 From: "Heatley, Nick" To: Olivier MJ Crepin-Leblond , Nabil Benamar , Alexandre Petrescu Thread-Topic: [v6ops] Interest in energy consumption of IPv6 smartphones (vs. IPv4) Thread-Index: AQHRvKmNmZCWV24cdEKeI3apVfQaQp/V2pkAgAAMj4CAABoVQA== Date: Thu, 2 Jun 2016 11:01:42 +0000 Message-ID: <6536E263028723489CCD5B6821D4B2131714501A@UK30S005EXS06.EEAD.EEINT.CO.UK> 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> In-Reply-To: <093d3a00-a2cc-c6d9-8939-56114eb4a461@gih.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B2131714501AUK30S005EXS06EE_" MIME-Version: 1.0 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: Thu, 02 Jun 2016 11:02:33 -0000 --_000_6536E263028723489CCD5B6821D4B2131714501AUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIChvdGhlciB0aGFuIGF2b2lkaW5nIFJBIHRpbWUgaXNzdWVzKSBkbyB0aGUgcmVhbCBiZW5l Zml0cyBjb21lIHdoZW4gYXBwcyBhcmUgY2hhbmdlZCwgbGVzcyBzZXNzaW9uIGtlZXBhbGl2ZXMg aW4gYSBuYXQtZnJlZSBlbnZpcm9ubWVudD8NCkl0IGlzIGFsbCBhYm91dCB0aGUgYXBwcyBvcHBv cnR1bml0eS4gVGhleSBuZWVkIHRvIGJlaGF2ZSBkaWZmZXJlbnRseSB3aGVuIElQdjYtb25seS4N Ck5pY2sNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgT2xpdmllciBNSiBDcmVwaW4tTGVibG9uZA0KU2VudDogMDIgSnVuZSAyMDE2IDEx OjIyDQpUbzogTmFiaWwgQmVuYW1hcjsgQWxleGFuZHJlIFBldHJlc2N1DQpDYzogdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEludGVyZXN0IGluIGVuZXJneSBjb25zdW1wdGlv biBvZiBJUHY2IHNtYXJ0cGhvbmVzICh2cy4gSVB2NCkNCg0KSGVsbG8gYWxsLA0KDQppdCBpcyBh bHNvIHdvcnRoIG5vdGluZyB0aGF0IDNHICYgNEcgaW4gcGFydGljdWxhciBhcHBlYXJzIHRvIGRy YWluIGJhdHRlcnkgbW9yZSB0aGFuIDJHLiBSZXN1bHRzIGNvdWxkIGJlIGZsYXdlZCBiZWNhdXNl IGR1ZSB0byBub3ZlbHR5LCBpbiBtb3N0IHBsYWNlcyA0RyBzaWduYWwgc3RyZW5ndGggaXMgbm90 IHlldCBhdCB0aGUgbGV2ZWwgb2YgMkcgb3IgM0cgc2lnbmFsIHN0cmVuZ3RoLiBBIHN0dWR5IHVu ZGVyIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQgd291bGQgYmUgc29tZWhvdyBpbnRlcmVzdGluZyBp bmRlZWQgYWx0aG91Z2ggSSBmYWlsIHRvIHNlZSB0aGUgZW5kIGdvYWwgZm9yIHBlcmZvcm1pbmcg c3VjaCBhIHN0dWR5PyBEbyB3ZSB3YW50IHRvIHByb3ZlIHRoYXQgbG9uZ2VyIGFkZHJlc3NlcyBt ZWFuIG1vcmUgcG93ZXIgcmVxdWlyZW1lbnRzPyBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGUgZW5k IHBvaW50IHJlYWxseSByZWxhdGVzIHRvIGNoaXBzZXQgYXJjaGl0ZWN0dXJlLCBub3QgYml0cyB0 cmFuc21pdHRlZC4NCktpbmRlc3QgcmVnYXJkcywNCg0KT2xpdmllcg0KT24gMDIvMDYvMjAxNiAx MTozNywgTmFiaWwgQmVuYW1hciB3cm90ZToNCkhpIEFsbCwNCg0KU2luY2UgdGhlcmUgaXMgbm8g ZHVhbCBzdGFjayBvbiAzZy80ZyBpbiBteSBzaWRlLCBJIGNhbiBvbmx5IHRlc3Qgd2l0aCB3aWZp LiBDcmVhdGUgYSB0dW5uZWwgd2l0aCBIRS5uZXQgZm9yIGV4YW1wbGUgYW5kIHRoZW4gY29ubmVj dCBhIHNtYXJ0cGhvbmUgb24gSVB2NiBvbmx5Li5tYWtlIHRoZSBtZWFzdXJlbWVudHMgYW5kIHRo ZW4gc3dpdGNoIHRvIElQdjQgb25seSByZXBlYXQgdGhlIHN0ZXBzLi4uLi5lbmVyZ3kgbWVhc3Vy ZW1lbnRzIGFyZSBhcHBsaWNhdGlvbiBzcGVjaWZpYyENCg0KSSB3b3VsZCBsaWtlIHRvIGFzayB0 aGUgbWVtYmVycyBvZiB0aGUgbGlzdCB3aGljaCBpcyB0aGUgYmVzdCBhcHBsaWNhdGlvbiB0byB1 c2UgZm9yIGVuZXJneSBjb25zdW1wdGlvbiBvbiBBbmRyb2lkID8NCg0KSXQgd291bGQgYWxzbyBi ZSBpbnRlcmVzdGluZyB0byBtZWFzdXJlIHdpdGggZGlmZmVyZW50IG1vYmlsZSBPUyAhDQoNCkJl c3QgcmVnYXJkcw0KTmFiaWwgQmVuYW1hcg0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0K2YbYqNmK2YQg 2KjZhti52YXYsdmIDQoNCmh0dHA6Ly9uYWJpbGJlbmFtYXIuaXB2Ni1sYWIubmV0Lw0KDQpPbiBU aHUsIEp1biAyLCAyMDE2IGF0IDk6MzMgQU0sIEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJl LnBldHJlc2N1QGdtYWlsLmNvbTxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4+ IHdyb3RlOg0KTGUgMDEvMDYvMjAxNiDDoCAxODoxMywgRnJlZCBCYWtlciAoZnJlZCkgYSDDqWNy aXQgOg0KSSBwZXJzb25hbGx5IHdvdWxkIGZpbmQgdGhhdCBpbnRlcmVzdGluZy4gQXMgeW91IG5v dGUsIHdlIHJlY2VudGx5DQpwb3N0ZWQgYW4gUkZDIGFib3V0IG1hbmFnaW5nIHBvd2VyIGJ5IG1h bmFnaW5nIGFjdGl2aXR5LiBBbmRyZXcNCllvdXJ0Y2hlbmtvIGhhcyBiZWVuIGludGVyZXN0ZWQg aW4gdGhlIGNoYXR0aW5lc3Mgb2YgSVB2Ng0KaW1wbGVtZW50YXRpb25zIGluIFdpRmksIHRoZSBp c3N1ZSBiZWluZyB0aGF0IGl0IGlzIGEgc2hhcmVkIG1lZGl1bQ0KKG5vdCB1bmxpa2UgYW4gQW5j aWVudCB5ZWxsb3cgRXRoZXJuZXQgY2FibGUsIGFuZCB2ZXJ5IHVubGlrZSBhDQpzd2l0Y2hlZCBu ZXR3b3JrKSwgc28gZXZlcnkgaGljY3VwIHJldmVyYmVyYXRlcyB0aHJvdWdob3V0IHRoZQ0KbmV0 d29yay4gSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgaXNzdWUgYWZmZWN0cyBtb2JpbGUgd2lyZWxl c3MgaW4NCmludGVyZXN0aW5nIHdheXMuIEhvdyBjaGF0dHkgYXJlIHdlLCBhbmQgd2hhdCBuZWVk cyB0byBiZSBhZGp1c3RlZD8NCg0KSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gbG9vayBhdCBo b3cgSVB2NiBsaW5rIGFuZCBuZXR3b3JrIHByb3RvY29sDQpiZWhhdmlvdXIgbWF5IGNvbnN1bWUg bW9yZSBvciBsZXNzIGVuZXJneS4gIE5EIGVmZmljaWVuY3ksDQplbmVyZ3ktZWZmaWNpZW50IElQ IHBhdGhzIGluIGFjY2VzcyBhbmQgY29yZSBuZXR3b3JrcywgcGF0aC1lbmVyZ3kNCmRpc2NvdmVy eTogYXJlIHRvcGljcyB2ZXJ5IGludGVyZXN0aW5nIHRvIGV4cGxvcmUuDQoNCk90aGVyIG9wZXJh dGlvbmFsIHF1ZXN0aW9uIG1heSBiZSB3aGV0aGVyIHRoZSBmdWxsIHVzZSBvZiBJUHY2IG9uIGEN CnNtYXJ0cGhvbmUgKGRpc2FibGUgSVB2NCkgZHJhd3MgaXRzIGJhdHRlcnkgbW9yZSwgbGVzcywg b3IganVzdCBhcyB3aGVuDQpvbmx5IElQdjQgaXMgdXNlZC4gIEl0IG1heSBuZWVkIHNvbWUgbWVh c3VyZW1lbnQgb2YgYXBwbGljYXRpb24NCmJlaGF2aW91ci4gIFJlY2VudGx5IGVuZXJneS1zcGVj aWZpYyBBUElzIGJlY2FtZSBhdmFpbGFibGUgb24gc21hcnRwaG9uZQ0KT1NzLCBzdXBwb3Npbmcg dGhleSdyZSB3b3JraW5nIG9rIG9uIElQdjYuDQpEbyB5b3UgaGF2ZSBzb21ldGhpbmcgdG8gc2hh cmU/DQoNCldlbGwgbm90IGF0IHRoaXMgdGltZS4gIFdlIGFyZSBjdXJyZW50bHkgZXhwbG9yaW5n IHRoZQ0KYXBwbGljYXRpb24tc3BlY2lmaWMgbWVhc3VyZW1lbnQgcGFydCB3aXRoIGEgZmV3IHBl b3BsZS4gIE1heWJlIHRoYXQgY2FuDQpsZWFkIHRvIGFuIEludGVybmV0IERyYWZ0Lg0KDQpBbGV4 DQoNCg0KDQpPbiBKdW4gMSwgMjAxNiwgYXQgNTo0MCBBTSwgQWxleGFuZHJlIFBldHJlc2N1DQo8 YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbTxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpIaSB2Nm9wcywNCg0KSSB3b25kZXIgd2hldGhlciB0aGVyZSBt YXkgYmUgaW50ZXJlc3QgaW4gZXZhbHVhdGluZyB0aGUgZW5lcmd5DQpjb25zdW1wdGlvbiBvZiBh biBJUHY2IGFwcGxpY2F0aW9uIG9uIHNtYXJ0cGhvbmVzLCBjb21wYXJlZCB0byBpdHMNCklQdjQg Y291bnRlcnBhcnQuDQoNCkkgc3VzcGVjdCB0aGUgZGlmZmVyZW5jZSBtYXkgYmUgbmVnbGlnaWJs ZSBidXQgSSBhbSBub3Qgc3VyZS4NCg0KSXQgd291bGQgYmUgZ29vZCB0byBhdm9pZCBhIHNpdHVh dGlvbiBpbiB3aGljaCB0aGUgZW5kIHVzZXINCnByZWZlcnMgSVB2NCBvbiB0aGUgc21hcnRwaG9u ZSBiZWNhdXNlIElQdjYgZW1wdGllcyB0aGUgYmF0dGVyeS4NCg0KQWxleA0KDQpMZSAxMS8wMi8y MDE2IMOgIDIwOjEyLCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPiBhIMOpY3JpdCA6DQpBIG5ldyBSZXF1ZXN0IGZvciBDb21tZW50cyBp cyBub3cgYXZhaWxhYmxlIGluIG9ubGluZSBSRkMNCmxpYnJhcmllcy4NCg0KQkNQIDIwMiBSRkMg Nzc3Mg0KDQpUaXRsZTogICAgICBSZWR1Y2luZyBFbmVyZ3kgQ29uc3VtcHRpb24gb2YgUm91dGVy IEFkdmVydGlzZW1lbnRzDQogQXV0aG9yOiAgICAgQS4gWW91cnRjaGVua28sIEwuIENvbGl0dGkg U3RhdHVzOiAgICAgQmVzdCBDdXJyZW50DQpQcmFjdGljZSBTdHJlYW06ICAgICBJRVRGIERhdGU6 ICAgICAgIEZlYnJ1YXJ5IDIwMTYgTWFpbGJveDoNCmF5b3VydGNoQGNpc2NvLmNvbTxtYWlsdG86 YXlvdXJ0Y2hAY2lzY28uY29tPiwgbG9yZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdv b2dsZS5jb20+IFBhZ2VzOiAgICAgIDYgQ2hhcmFjdGVyczoNCjEyNTU1IFNlZSBBbHNvOiAgIEJD UCAyMDINCg0KSS1EIFRhZzogZHJhZnQtaWV0Zi12Nm9wcy1yZWR1Y2luZy1yYS1lbmVyZ3ktY29u c3VtcHRpb24tMDMudHh0DQoNClVSTDogICAgICAgIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjNzc3Mg0KDQpET0k6ICAgICAgICBodHRwOi8vZHguZG9pLm9yZy8xMC4xNzQ4Ny9S RkM3NzcyDQoNCkZyZXF1ZW50IFJvdXRlciBBZHZlcnRpc2VtZW50IG1lc3NhZ2VzIGNhbiBzZXZl cmVseSBpbXBhY3QgaG9zdA0KcG93ZXIgY29uc3VtcHRpb24uICBUaGlzIGRvY3VtZW50IHJlY29t bWVuZHMgb3BlcmF0aW9uYWwNCnByYWN0aWNlcyB0byBhdm9pZCBzdWNoIGltcGFjdC4NCg0KVGhp cyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdy b3VwDQpvZiB0aGUgSUVURi4NCg0KDQpCQ1A6IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIElu dGVybmV0IEJlc3QgQ3VycmVudCBQcmFjdGljZXMNCmZvciB0aGUgSW50ZXJuZXQgQ29tbXVuaXR5 LCBhbmQgcmVxdWVzdHMgZGlzY3Vzc2lvbiBhbmQNCnN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVu dHMuIERpc3RyaWJ1dGlvbiBvZiB0aGlzIG1lbW8gaXMNCnVubGltaXRlZC4NCg0KVGhpcyBhbm5v dW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURi1Bbm5vdW5jZSBhbmQgcmZjLWRpc3QNCmxpc3Rz LiBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNlZQ0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQpodHRwczovL21haWxtYW4ucmZjLWVkaXRv ci5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmMtZGlzdA0KDQpGb3Igc2VhcmNoaW5nIHRoZSBSRkMg c2VyaWVzLCBzZWUNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3NlYXJjaCBGb3IgZG93bmxv YWRpbmcgUkZDcywgc2VlDQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZXRyaWV2ZS9idWxr DQoNClJlcXVlc3RzIGZvciBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUgYWRkcmVzc2Vk IHRvIGVpdGhlcg0KdGhlIGF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0aW9uLCBvciB0bw0KcmZj LWVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4u ICBVbmxlc3Mgc3BlY2lmaWNhbGx5IG5vdGVkIG90aGVyd2lzZQ0Kb24gdGhlIFJGQyBpdHNlbGYs IGFsbCBSRkNzIGFyZSBmb3IgdW5saW1pdGVkIGRpc3RyaWJ1dGlvbi4NCg0KDQpUaGUgUkZDIEVk aXRvciBUZWFtIEFzc29jaWF0aW9uIE1hbmFnZW1lbnQgU29sdXRpb25zLCBMTEMNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9wcyBtYWlsaW5n IGxpc3QNCiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0Bp ZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KdjZvcHMgbWFpbGluZyBsaXN0DQoNCnY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KDQoNCg0KLS0NCg0KT2xpdmllciBNSiBDcsOpcGluLUxlYmxvbmQs IFBoRA0KDQpodHRwOi8vd3d3LmdpaC5jb20vb2NsLmh0bWwNCg0KTk9USUNFIEFORCBESVNDTEFJ TUVSDQpUaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJp dmlsZWdlZCBvciBjb25maWRlbnRpYWwuIEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1 YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiANCklmIHlvdSdyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBv ciB1c2luZyB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIA0KSWYgeW91J3ZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBv biB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91Lg0KDQpXZSBtb25pdG9yIG91ciBl bWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KDQpFRSBMaW1pdGVkIA0K UmVnaXN0ZXJlZCBvZmZpY2U6VHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwg SGVydGZvcmRzaGlyZSwgQUwxMCA5QlcNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMDIzODIx NjENCg0KRUUgTGltaXRlZCBpcyBhIHdob2xseSBvd25lZCBzdWJzaWRpYXJ5IG9mOg0KDQpCcml0 aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNClJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRl IFN0cmVldCBMb25kb24gRUMxQSA3QUoNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAw MA0K --_000_6536E263028723489CCD5B6821D4B2131714501AUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29s YXMiLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIChvdGhlciB0 aGFuIGF2b2lkaW5nIFJBIHRpbWUgaXNzdWVzKSBkbyB0aGUgcmVhbCBiZW5lZml0cyBjb21lIHdo ZW4gYXBwcyBhcmUgY2hhbmdlZCwgbGVzcyBzZXNzaW9uIGtlZXBhbGl2ZXMgaW4gYSBuYXQtZnJl ZSBlbnZpcm9ubWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgYWxsIGFi b3V0IHRoZSBhcHBzIG9wcG9ydHVuaXR5LiBUaGV5IG5lZWQgdG8gYmVoYXZlIGRpZmZlcmVudGx5 IHdoZW4gSVB2Ni1vbmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWNrPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5PbGl2aWVyIE1KIENyZXBpbi1MZWJsb25kPGJyPg0KPGI+U2Vu dDo8L2I+IDAyIEp1bmUgMjAxNiAxMToyMjxicj4NCjxiPlRvOjwvYj4gTmFiaWwgQmVuYW1hcjsg QWxleGFuZHJlIFBldHJlc2N1PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBJbnRlcmVzdCBpbiBlbmVyZ3kgY29uc3VtcHRpb24g b2YgSVB2NiBzbWFydHBob25lcyAodnMuIElQdjQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IZWxsbyBh bGwsPGJyPg0KPGJyPg0KaXQgaXMgYWxzbyB3b3J0aCBub3RpbmcgdGhhdCAzRyAmYW1wOyA0RyBp biBwYXJ0aWN1bGFyIGFwcGVhcnMgdG8gZHJhaW4gYmF0dGVyeSBtb3JlIHRoYW4gMkcuIFJlc3Vs dHMgY291bGQgYmUgZmxhd2VkIGJlY2F1c2UgZHVlIHRvIG5vdmVsdHksIGluIG1vc3QgcGxhY2Vz IDRHIHNpZ25hbCBzdHJlbmd0aCBpcyBub3QgeWV0IGF0IHRoZSBsZXZlbCBvZiAyRyBvciAzRyBz aWduYWwgc3RyZW5ndGguIEEgc3R1ZHkgdW5kZXIgY29udHJvbGxlZCBlbnZpcm9ubWVudA0KIHdv dWxkIGJlIHNvbWVob3cgaW50ZXJlc3RpbmcgaW5kZWVkIGFsdGhvdWdoIEkgZmFpbCB0byBzZWUg dGhlIGVuZCBnb2FsIGZvciBwZXJmb3JtaW5nIHN1Y2ggYSBzdHVkeT8gRG8gd2Ugd2FudCB0byBw cm92ZSB0aGF0IGxvbmdlciBhZGRyZXNzZXMgbWVhbiBtb3JlIHBvd2VyIHJlcXVpcmVtZW50cz8g SSB3b3VsZCBoYXZlIHRob3VnaHQgdGhlIGVuZCBwb2ludCByZWFsbHkgcmVsYXRlcyB0byBjaGlw c2V0IGFyY2hpdGVjdHVyZSwgbm90IGJpdHMNCiB0cmFuc21pdHRlZC48YnI+DQpLaW5kZXN0IHJl Z2FyZHMsPGJyPg0KPGJyPg0KT2xpdmllcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDAyLzA2LzIwMTYgMTE6MzcsIE5hYmlsIEJlbmFtYXIgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwQjUzOTQiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw QjUzOTQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzBCNTM5NCI+U2luY2UgdGhlcmUgaXMg bm8gZHVhbCBzdGFjayBvbiAzZy80ZyBpbiBteSBzaWRlLCBJIGNhbiBvbmx5IHRlc3Qgd2l0aCB3 aWZpLiBDcmVhdGUgYSB0dW5uZWwgd2l0aCBIRS5uZXQgZm9yIGV4YW1wbGUgYW5kIHRoZW4gY29u bmVjdCBhIHNtYXJ0cGhvbmUgb24gSVB2NiBvbmx5Li5tYWtlIHRoZSBtZWFzdXJlbWVudHMNCiBh bmQgdGhlbiBzd2l0Y2ggdG8gSVB2NCBvbmx5IHJlcGVhdCB0aGUgc3RlcHMuLi4uLmVuZXJneSBt ZWFzdXJlbWVudHMgYXJlIGFwcGxpY2F0aW9uIHNwZWNpZmljITxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzBCNTM5NCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMEI1Mzk0Ij5JIHdvdWxkIGxpa2Ug dG8gYXNrIHRoZSBtZW1iZXJzIG9mIHRoZSBsaXN0IHdoaWNoIGlzIHRoZSBiZXN0IGFwcGxpY2F0 aW9uIHRvIHVzZSBmb3IgZW5lcmd5IGNvbnN1bXB0aW9uIG9uIEFuZHJvaWQgPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzBCNTM5NCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMEI1Mzk0Ij5JdCB3 b3VsZCBhbHNvIGJlIGludGVyZXN0aW5nIHRvIG1lYXN1cmUgd2l0aCBkaWZmZXJlbnQgbW9iaWxl IE9TICE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TmFiaWwgQmVuYW1hcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIGRpcj0iUlRMIiBzdHlsZT0idGV4dC1hbGln bjpsZWZ0O2RpcmVjdGlvbjpydGw7dW5pY29kZS1iaWRpOmVtYmVkIj4NCjxzcGFuIGRpcj0iUlRM Ij48L3NwYW4+PHNwYW4gbGFuZz0iQVItU0EiPjxzcGFuIGRpcj0iUlRMIj48L3NwYW4+LS0tLS0t LS0tLS0tLS0tLS0tLTwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgZGlyPSJSVEwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmxlZnQ7ZGlyZWN0aW9uOnJ0bDt1bmljb2RlLWJpZGk6ZW1iZWQiPg0K PHNwYW4gbGFuZz0iQVItU0EiPtmG2KjZitmEINio2YbYudmF2LHZiDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJBUi1TQSIgZGly PSJSVEwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly9uYWJpbGJlbmFtYXIuaXB2Ni1sYWIubmV0 LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYWJpbGJlbmFtYXIuaXB2Ni1sYWIubmV0LzwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAyLCAyMDE2 IGF0IDk6MzMgQU0sIEFsZXhhbmRyZSBQZXRyZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhh bmRyZS5wZXRyZXNjdUBnbWFpbC5jb20iPmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDAxLzA2 LzIwMTYgw6AgMTg6MTMsIEZyZWQgQmFrZXIgKGZyZWQpIGEgw6ljcml0IDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSB3b3VsZCBmaW5kIHRoYXQgaW50 ZXJlc3RpbmcuIEFzIHlvdSBub3RlLCB3ZSByZWNlbnRseTxicj4NCnBvc3RlZCBhbiBSRkMgYWJv dXQgbWFuYWdpbmcgcG93ZXIgYnkgbWFuYWdpbmcgYWN0aXZpdHkuIEFuZHJldzxicj4NCllvdXJ0 Y2hlbmtvIGhhcyBiZWVuIGludGVyZXN0ZWQgaW4gdGhlIGNoYXR0aW5lc3Mgb2YgSVB2Njxicj4N CmltcGxlbWVudGF0aW9ucyBpbiBXaUZpLCB0aGUgaXNzdWUgYmVpbmcgdGhhdCBpdCBpcyBhIHNo YXJlZCBtZWRpdW08YnI+DQoobm90IHVubGlrZSBhbiBBbmNpZW50IHllbGxvdyBFdGhlcm5ldCBj YWJsZSwgYW5kIHZlcnkgdW5saWtlIGE8YnI+DQpzd2l0Y2hlZCBuZXR3b3JrKSwgc28gZXZlcnkg aGljY3VwIHJldmVyYmVyYXRlcyB0aHJvdWdob3V0IHRoZTxicj4NCm5ldHdvcmsuIEkgd291bGQg ZXhwZWN0IHRoYXQgdGhlIGlzc3VlIGFmZmVjdHMgbW9iaWxlIHdpcmVsZXNzIGluPGJyPg0KaW50 ZXJlc3Rpbmcgd2F5cy4gSG93IGNoYXR0eSBhcmUgd2UsIGFuZCB3aGF0IG5lZWRzIHRvIGJlIGFk anVzdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBsb29rIGF0 IGhvdyBJUHY2IGxpbmsgYW5kIG5ldHdvcmsgcHJvdG9jb2w8YnI+DQpiZWhhdmlvdXIgbWF5IGNv bnN1bWUgbW9yZSBvciBsZXNzIGVuZXJneS4mbmJzcDsgTkQgZWZmaWNpZW5jeSw8YnI+DQplbmVy Z3ktZWZmaWNpZW50IElQIHBhdGhzIGluIGFjY2VzcyBhbmQgY29yZSBuZXR3b3JrcywgcGF0aC1l bmVyZ3k8YnI+DQpkaXNjb3Zlcnk6IGFyZSB0b3BpY3MgdmVyeSBpbnRlcmVzdGluZyB0byBleHBs b3JlLjxicj4NCjxicj4NCk90aGVyIG9wZXJhdGlvbmFsIHF1ZXN0aW9uIG1heSBiZSB3aGV0aGVy IHRoZSBmdWxsIHVzZSBvZiBJUHY2IG9uIGE8YnI+DQpzbWFydHBob25lIChkaXNhYmxlIElQdjQp IGRyYXdzIGl0cyBiYXR0ZXJ5IG1vcmUsIGxlc3MsIG9yIGp1c3QgYXMgd2hlbjxicj4NCm9ubHkg SVB2NCBpcyB1c2VkLiZuYnNwOyBJdCBtYXkgbmVlZCBzb21lIG1lYXN1cmVtZW50IG9mIGFwcGxp Y2F0aW9uPGJyPg0KYmVoYXZpb3VyLiZuYnNwOyBSZWNlbnRseSBlbmVyZ3ktc3BlY2lmaWMgQVBJ cyBiZWNhbWUgYXZhaWxhYmxlIG9uIHNtYXJ0cGhvbmU8YnI+DQpPU3MsIHN1cHBvc2luZyB0aGV5 J3JlIHdvcmtpbmcgb2sgb24gSVB2Ni48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRvIHlvdSBoYXZlIHNvbWV0aGluZyB0byBzaGFyZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCldlbGwgbm90IGF0IHRoaXMgdGltZS4mbmJzcDsgV2UgYXJl IGN1cnJlbnRseSBleHBsb3JpbmcgdGhlPGJyPg0KYXBwbGljYXRpb24tc3BlY2lmaWMgbWVhc3Vy ZW1lbnQgcGFydCB3aXRoIGEgZmV3IHBlb3BsZS4mbmJzcDsgTWF5YmUgdGhhdCBjYW48YnI+DQps ZWFkIHRvIGFuIEludGVybmV0IERyYWZ0Ljxicj4NCjxicj4NCkFsZXggPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBKdW4gMSwgMjAxNiwgYXQgNTo0MCBBTSwgQWxleGFuZHJlIFBldHJlc2N1PGJyPg0KJmx0 OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxi cj4NCkhpIHY2b3BzLDxicj4NCjxicj4NCkkgd29uZGVyIHdoZXRoZXIgdGhlcmUgbWF5IGJlIGlu dGVyZXN0IGluIGV2YWx1YXRpbmcgdGhlIGVuZXJneTxicj4NCmNvbnN1bXB0aW9uIG9mIGFuIElQ djYgYXBwbGljYXRpb24gb24gc21hcnRwaG9uZXMsIGNvbXBhcmVkIHRvIGl0czxicj4NCklQdjQg Y291bnRlcnBhcnQuPGJyPg0KPGJyPg0KSSBzdXNwZWN0IHRoZSBkaWZmZXJlbmNlIG1heSBiZSBu ZWdsaWdpYmxlIGJ1dCBJIGFtIG5vdCBzdXJlLjxicj4NCjxicj4NCkl0IHdvdWxkIGJlIGdvb2Qg dG8gYXZvaWQgYSBzaXR1YXRpb24gaW4gd2hpY2ggdGhlIGVuZCB1c2VyPGJyPg0KcHJlZmVycyBJ UHY0IG9uIHRoZSBzbWFydHBob25lIGJlY2F1c2UgSVB2NiBlbXB0aWVzIHRoZSBiYXR0ZXJ5Ljxi cj4NCjxicj4NCkFsZXg8YnI+DQo8YnI+DQpMZSAxMS8wMi8yMDE2IMOgIDIwOjEyLCA8YSBocmVm PSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcmZj LWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4gYSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BIG5ldyBSZXF1 ZXN0IGZvciBDb21tZW50cyBpcyBub3cgYXZhaWxhYmxlIGluIG9ubGluZSBSRkM8YnI+DQpsaWJy YXJpZXMuPGJyPg0KPGJyPg0KQkNQIDIwMiBSRkMgNzc3Mjxicj4NCjxicj4NClRpdGxlOiZuYnNw OyAmbmJzcDsgJm5ic3A7IFJlZHVjaW5nIEVuZXJneSBDb25zdW1wdGlvbiBvZiBSb3V0ZXIgQWR2 ZXJ0aXNlbWVudHM8YnI+DQombmJzcDtBdXRob3I6Jm5ic3A7ICZuYnNwOyAmbmJzcDtBLiBZb3Vy dGNoZW5rbywgTC4gQ29saXR0aSBTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDtCZXN0IEN1cnJl bnQ8YnI+DQpQcmFjdGljZSBTdHJlYW06Jm5ic3A7ICZuYnNwOyAmbmJzcDtJRVRGIERhdGU6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmVicnVhcnkgMjAxNiBNYWlsYm94Ojxicj4NCjxhIGhy ZWY9Im1haWx0bzpheW91cnRjaEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5heW91cnRjaEBj aXNjby5jb208L2E+LCA8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+DQpsb3JlbnpvQGdvb2dsZS5jb208L2E+IFBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5i c3A7IDYgQ2hhcmFjdGVyczo8YnI+DQoxMjU1NSBTZWUgQWxzbzombmJzcDsgJm5ic3A7QkNQIDIw Mjxicj4NCjxicj4NCkktRCBUYWc6IGRyYWZ0LWlldGYtdjZvcHMtcmVkdWNpbmctcmEtZW5lcmd5 LWNvbnN1bXB0aW9uLTAzLnR4dDxicj4NCjxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NzcyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NzcyPC9h Pjxicj4NCjxicj4NCkRPSTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0 cDovL2R4LmRvaS5vcmcvMTAuMTc0ODcvUkZDNzc3MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9k eC5kb2kub3JnLzEwLjE3NDg3L1JGQzc3NzI8L2E+PGJyPg0KPGJyPg0KRnJlcXVlbnQgUm91dGVy IEFkdmVydGlzZW1lbnQgbWVzc2FnZXMgY2FuIHNldmVyZWx5IGltcGFjdCBob3N0PGJyPg0KcG93 ZXIgY29uc3VtcHRpb24uJm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVjb21tZW5kcyBvcGVyYXRpb25h bDxicj4NCnByYWN0aWNlcyB0byBhdm9pZCBzdWNoIGltcGFjdC48YnI+DQo8YnI+DQpUaGlzIGRv Y3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdvcmtpbmcgR3JvdXA8 YnI+DQpvZiB0aGUgSUVURi48YnI+DQo8YnI+DQo8YnI+DQpCQ1A6IFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGFuIEludGVybmV0IEJlc3QgQ3VycmVudCBQcmFjdGljZXM8YnI+DQpmb3IgdGhlIElu dGVybmV0IENvbW11bml0eSwgYW5kIHJlcXVlc3RzIGRpc2N1c3Npb24gYW5kPGJyPg0Kc3VnZ2Vz dGlvbnMgZm9yIGltcHJvdmVtZW50cy4gRGlzdHJpYnV0aW9uIG9mIHRoaXMgbWVtbyBpczxicj4N CnVubGltaXRlZC48YnI+DQo8YnI+DQpUaGlzIGFubm91bmNlbWVudCBpcyBzZW50IHRvIHRoZSBJ RVRGLUFubm91bmNlIGFuZCByZmMtZGlzdDxicj4NCmxpc3RzLiBUbyBzdWJzY3JpYmUgb3IgdW5z dWJzY3JpYmUsIHNlZTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWV0Zi1hbm5vdW5jZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZTwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmMtZGlzdCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JmYy1kaXN0PC9hPjxicj4NCjxicj4NCkZvciBzZWFyY2hpbmcgdGhlIFJGQyBzZXJpZXMs IHNlZTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3NlYXJjaCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3NlYXJjaDwvYT4gRm9yIGRv d25sb2FkaW5nIFJGQ3MsIHNlZTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JldHJpZXZlL2J1bGsiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9yZXRyaWV2ZS9idWxrPC9hPjxicj4NCjxicj4NClJlcXVlc3RzIGZvciBzcGVjaWFsIGRp c3RyaWJ1dGlvbiBzaG91bGQgYmUgYWRkcmVzc2VkIHRvIGVpdGhlcjxicj4NCnRoZSBhdXRob3Ig b2YgdGhlIFJGQyBpbiBxdWVzdGlvbiwgb3IgdG88YnI+DQo8YSBocmVmPSJtYWlsdG86cmZjLWVk aXRvckByZmMtZWRpdG9yLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJmYy1lZGl0b3JAcmZjLWVkaXRv ci5vcmc8L2E+LiZuYnNwOyBVbmxlc3Mgc3BlY2lmaWNhbGx5IG5vdGVkIG90aGVyd2lzZTxicj4N Cm9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmUgZm9yIHVubGltaXRlZCBkaXN0cmlidXRp b24uPGJyPg0KPGJyPg0KPGJyPg0KVGhlIFJGQyBFZGl0b3IgVGVhbSBBc3NvY2lhdGlvbiBNYW5h Z2VtZW50IFNvbHV0aW9ucywgTExDPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDs8YSBocmVmPSJtYWlsdG86 djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT52Nm9wcyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHM8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5PbGl2aWVyIE1KIENyw6lwaW4tTGVibG9uZCwgUGhEPG86cD48L286cD48 L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL3d3dy5naWguY29tL29jbC5odG1sIj5odHRwOi8v d3d3LmdpaC5jb20vb2NsLmh0bWw8L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KDQo8UD5O T1RJQ0UgQU5EIERJU0NMQUlNRVI8QlI+VGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlv biwgd2hpY2ggbWF5IGJlIA0KcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIEl0J3MgbWVhbnQg b25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IA0KbmFtZWQgYWJvdmUuIDxCUj5J ZiB5b3UncmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5n LCANCmNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9uIGlzIHBy b2hpYml0ZWQuIDxCUj5JZiB5b3UndmUgDQpyZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIA0KYWRkcmVzcyBhYm92 ZS4gVGhhbmsgeW91LjwvUD4NCjxQPldlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1h eSByZWNvcmQgeW91ciBlbWFpbHMuPC9QPg0KPFA+RUUgTGltaXRlZCA8QlI+UmVnaXN0ZXJlZCBv ZmZpY2U6VHJpZGVudCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgDQpIZXJ0Zm9yZHNo aXJlLCBBTDEwIDlCVzxCUj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDAyMzgyMTYxPC9QPg0K PFA+RUUgTGltaXRlZCBpcyBhIHdob2xseSBvd25lZCBzdWJzaWRpYXJ5IG9mOjwvUD4NCjxQPkJy aXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzxCUj5SZWdpc3RlcmVkIG9mZmljZTogODEgTmV3 Z2F0ZSBTdHJlZXQgTG9uZG9uIA0KRUMxQSA3QUo8QlI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIG5v OiAxODAwMDAwPC9QPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6536E263028723489CCD5B6821D4B2131714501AUK30S005EXS06EE_-- From nobody Thu Jun 2 19:17: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 8DE2212D163 for ; Thu, 2 Jun 2016 19:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tz5yhdsnURgE for ; Thu, 2 Jun 2016 19:17:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 4BA85127058 for ; Thu, 2 Jun 2016 19:17:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 8C162349420; Fri, 3 Jun 2016 02:17:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 79A7616004A; Fri, 3 Jun 2016 02:17:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 60552160054; Fri, 3 Jun 2016 02:17:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X9OGQVTeitIs; Fri, 3 Jun 2016 02:17:23 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 0FF1C16004A; Fri, 3 Jun 2016 02:17:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 15D9E4AA4453; Fri, 3 Jun 2016 12:17:20 +1000 (EST) To: "Heatley, Nick" From: Mark Andrews 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> In-reply-to: Your message of "Thu, 02 Jun 2016 11:01:42 +0000." <6536E263028723489CCD5B6821D4B2131714501A@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Fri, 03 Jun 2016 12:17:20 +1000 Message-Id: <20160603021720.15D9E4AA4453@rock.dv.isc.org> 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, 03 Jun 2016 02:17:27 -0000 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jun 2 23:12: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 6D4A512D1A0 for ; Thu, 2 Jun 2016 23:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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.426, 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 dtqX-23PcuqH for ; Thu, 2 Jun 2016 23:11:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 225B412D0DE for ; Thu, 2 Jun 2016 23:11:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 81F7FA2; Fri, 3 Jun 2016 08:11:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1464934311; bh=ivyh7DINQw/JVi5ZA0Og/TH6p4By8F70TEqwjxW3dcY=; h=Date:From:To:Subject:From; b=XUMLVF1HbiTA1qIdMacPpgIA6P2QwPCUr/rHvDniBp1bv66LnmC8Yd7fQVzaKzGL3 WZCk9F+q29EUbB4s89QrwpY6E9taA4jjzcSu8SMftB+jGjOKCTfN0OOiywA9CdASRn AYORf+AdAIBPyu28zh1nX5dSZrsgOCENdoOdjKLA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7D75FA1 for ; Fri, 3 Jun 2016 08:11:51 +0200 (CEST) Date: Fri, 3 Jun 2016 08:11:51 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 06:12:00 -0000 Hi, I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 ? Is there some other RFC somewhere that contradicts this or should we all start opening bug cases with our vendors if we see these types of packets forwarded to us from outside the link? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jun 2 23:19: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 675F012D59B for ; Thu, 2 Jun 2016 23:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.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 zzdEJVb55Pte for ; Thu, 2 Jun 2016 23:19:06 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 374EE12D63C for ; Thu, 2 Jun 2016 23:19:06 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c127so71699873ywb.1 for ; Thu, 02 Jun 2016 23:19: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=yiItZtFXNJf+lDYQcMR6CdtKdBUqRCOwUgK+jug3wfg=; b=WzEOvfveiUsNwFREALuZ9cSjbSqyL2BauK7QYSpL+sLQNccllNUBXms5c1Sppp/aZy VwBg10ZltOH+FG/YXueheHK1EK3+fikJgUN+4DnwFyHXtATntXLnqtjjrT2xzGdiVf5C gWUNWzKuXInl1v8TxjrIvSxxzd14+rLtK0wapgeLWxv6HILQu8KhXtvz9kmx0yj6+AYT hS6TatLuFiB8zkDErQF/R6GaBZ02ywBWrOkz9hUkYqbpcEhn8BmvzmG7YVzFnY+RSsy/ ptS3jnpwWltD+olPgPxLqt8sgpqn4BZ2Hqq1lehmWDTEbK2Z99Jn1n/7wle25s4xGamX cWxg== 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=yiItZtFXNJf+lDYQcMR6CdtKdBUqRCOwUgK+jug3wfg=; b=i2QWgRXFMNYa9vGIQnanGsZQD0XVolIyhMlG2Sb+aR0isqfsa+OMq+97qyhh8cjfjB lugoFyl7xfAZFYVOBfD+ZsfuG0wy9NS1AKRhxcoqdfrCFlEoScmRPP9lukYiHej+wZAH XbUEvFcTvrI3S7ukzG2QuafFxWyzheOoDcIJogMH+6ZCLPccxZqu5tfK6pmroyuacxFc jpa7jtBAS0st0/6oDRwOQ6rGByHpXWF6UZwUuRbfd/2ytwf8sfsM1kyFC6LnRvaQQ4b/ 55mG3e4N9hMVUfSt5ZtjOFSb5Oi2WB9sNKZIhDWCCroL+CVv4TErFfnA4+GIVbchzBcH q1Xw== X-Gm-Message-State: ALyK8tL2T+W9/VnY2EpWZ/qu7SVaGF3Ka32CWRCJCODFqFR0DHka0f2qBSTYCDL+OsCJARoUGexdSP31O9SR7hPR X-Received: by 10.13.220.69 with SMTP id f66mr1420567ywe.132.1464934745449; Thu, 02 Jun 2016 23:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Thu, 2 Jun 2016 23:18:45 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 3 Jun 2016 15:18:45 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=94eb2c0815c81fa992053459b322 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 06:19:09 -0000 --94eb2c0815c81fa992053459b322 Content-Type: text/plain; charset=UTF-8 IIRC it's invalid behaviour. That said, I wouldn't be surprised if some vendor said "we can do this but on these platforms it will cut IPv6 peak performance by 2x because it requires 2x the TCAM lookups" :-) On Fri, Jun 3, 2016 at 3:11 PM, Mikael Abrahamsson wrote: > > Hi, > > I'm getting reports of people getting packets "over the Internet" with LL > source address and GUA dst address. This seems to be a direct violation of > https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > > Is there some other RFC somewhere that contradicts this or should we all > start opening bug cases with our vendors if we see these types of packets > forwarded to us from outside the link? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0815c81fa992053459b322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IIRC it's invalid behaviour. That said, I wouldn't= be surprised if some vendor said "we can do this but on these platfor= ms it will cut IPv6 peak performance by 2x because it requires 2x the TCAM = lookups" :-)

On Fri, Jun 3, 2016 at 3:11 PM, Mikael Abrahamsson = <swmike@swm.pp.se<= /a>> wrote:

Hi,

I'm getting reports of people getting packets "over the Internet&q= uot; with LL source address and GUA dst address. This seems to be a direct = violation of https://tools.ietf.org/html/rfc4291#se= ction-2.5.6 ?

Is there some other RFC somewhere that contradicts this or should we all st= art opening bug cases with our vendors if we see these types of packets for= warded to us from outside the link?

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

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

--94eb2c0815c81fa992053459b322-- From nobody Thu Jun 2 23:30: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 E63AC12B020 for ; Thu, 2 Jun 2016 23:30:48 -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=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 ymRcHpHTZlGZ for ; Thu, 2 Jun 2016 23:30:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551E312D0DE for ; Thu, 2 Jun 2016 23:30:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4302B6013A for ; Fri, 3 Jun 2016 08:30:44 +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 0259E60133; Fri, 3 Jun 2016 08:30:43 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id DDA3C23E7C; Fri, 3 Jun 2016 08:30:43 +0200 (CEST) Date: Fri, 3 Jun 2016 08:30:43 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20160603063043.GD52179@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 Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 06:30:49 -0000 Hi, On Fri, Jun 03, 2016 at 08:11:51AM +0200, Mikael Abrahamsson wrote: > I'm getting reports of people getting packets "over the Internet" with LL > source address and GUA dst address. This seems to be a direct violation of > https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > > Is there some other RFC somewhere that contradicts this or should we all > start opening bug cases with our vendors if we see these types of packets > forwarded to us from outside the link? I'm one of those seeing the packets... (as a consequence of filtering stuff that "should not be there anyway" on my uplinks, and logging to see what might be there nevertheless) Jun 3 07:53:15 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGP : access-list internet-ipv6-in (140) deny tcp fe80::baac:6fff:fe98:c24a(51114) (TenGigE0/0/2/3)-> 2001:608:2:84::130(25), 4 packets Jun 3 07:58:38 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGP : access-list internet-ipv6-in (260) deny udp fe80::7a2b:cbff:fe6a:85d4(46437) (TenGigE0/0/1/3)-> 2001:608:e02:487::4(53), 1 packet Jun 3 08:00:13 ipv6_acl_daemon[289]: %ACL-IPV6_ACL-6-IPACCESSLOGNP : access-list internet-ipv6-in (260) deny 58 fe80::21c:42ff:feb4:846d (TenGigE0/0/1/2.406)-> 2001:608:1:151::17, 3 packets one is an IXP link, the two others are uplinks to two of our ISPs - one is using Juniper gear, the other one I'm not sure. Trying to reproduce this by sending packets across one of our 6500/sup720, I can't make it happen - so at least the sup720 properly drops LLA->off-link packets (though it has other warts, like its netflow never mentioning LLA sourced at all). 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 Jun 2 23:39: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 38C4612D5D8 for ; Thu, 2 Jun 2016 23:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.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 BHIiyQYfDHev for ; Thu, 2 Jun 2016 23:39:45 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3846812D0D8 for ; Thu, 2 Jun 2016 23:39:45 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id c127so72024481ywb.1 for ; Thu, 02 Jun 2016 23:39:45 -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=LLuaJ2q46hnnsUaUEKpukN0u28bxRx10brrgKpwU/fA=; b=X/Aa2pMvHHUZCnMsnW0E6ZhHPF6oQx3/WWN5Ukg7TLxyaMbzHLsqnDxkAMz8+Aj4Vd tMLxiWRmfBtktBV1GSoF3D42Imca3P+MsKY+VaaCkoE5jHn+S2zWYiyPOh0MpKJWCtmk yyQtKM7ZT0Ovkby4JE5YE2QbcHlHEL/JRipUucbStq9AxxeaywgzavCDR6epLIKtWOO7 eC2szTbeGiSxvdg+3wUTdYHViS1rwFkBriijWI+JekJH9GhaA5WaAWT9FPp45AGDKXVs GJ9MVjXOqiRHso8j3xFXYZlExJUOvwYzsbhLuV1+yt3UPUnH6jTn2AKs3G4s9Y80tG7d 74eA== 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=LLuaJ2q46hnnsUaUEKpukN0u28bxRx10brrgKpwU/fA=; b=knUEAxktlbAQ7De5JPGBmwLMnY3xo1HrGwsP6eN/78jtf4iD5iLTDIuzQN41SJx0kU ajSDvrrUi7HdFkN1zSkskPGS9r/cI4Y2MA7H0CVzjsS+pqhq5J8NTRJOoP5PxKZ6+z1T BKtpMyROHO2exYr/i+qNaQ3sq4IBWs/haFzeNDdvZBG1g/fD7rLxR2aui27ht5nb0PJW g+H7DQa22INh6CV82HPLKXUZjJLbi64eBF/X06jJ6otAFfTK2gYZ1Ukc4C6auB0cRb7a AHboTPKpNZmjRxwVXq3Fe8jTimy9CHIOppp1Y8dNnpdmdjD/usAdQHFQ0reTwyjnIjge a3BQ== X-Gm-Message-State: ALyK8tLUR+7P79jE0HRMFM0rZI2oJsy0JaFxpiKHYBMpp0nTTwGBjC2joKH9lMkBa05261kmJpq7fMgfEQuLeBRY X-Received: by 10.37.79.87 with SMTP id d84mr1308921ybb.49.1464935984250; Thu, 02 Jun 2016 23:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Thu, 2 Jun 2016 23:39:24 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 3 Jun 2016 15:39:24 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a113f5cd0f65f44053459fca2 Archived-At: Cc: "v6ops@ietf.org WG" , Jen Linkova Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 06:39:47 -0000 --001a113f5cd0f65f44053459fca2 Content-Type: text/plain; charset=UTF-8 Also see Jen's stats here: https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf On Fri, Jun 3, 2016 at 3:11 PM, Mikael Abrahamsson wrote: > > Hi, > > I'm getting reports of people getting packets "over the Internet" with LL > source address and GUA dst address. This seems to be a direct violation of > https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > > Is there some other RFC somewhere that contradicts this or should we all > start opening bug cases with our vendors if we see these types of packets > forwarded to us from outside the link? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113f5cd0f65f44053459fca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 3, 2016 at 3:11 PM, Mikael Abrahamsson <sw= mike@swm.pp.se> wrote:

Hi,

I'm getting reports of people getting packets "over the Internet&q= uot; with LL source address and GUA dst address. This seems to be a direct = violation of https://tools.ietf.org/html/rfc4291#se= ction-2.5.6 ?

Is there some other RFC somewhere that contradicts this or should we all st= art opening bug cases with our vendors if we see these types of packets for= warded to us from outside the link?

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

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

--001a113f5cd0f65f44053459fca2-- From nobody Fri Jun 3 01:31: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 2DE9612D1E2 for ; Fri, 3 Jun 2016 01:31:46 -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 YkL7h2uWi-6A for ; Fri, 3 Jun 2016 01:31:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B812D50D for ; Fri, 3 Jun 2016 01:31:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1b8kW2-0000CqC; Fri, 3 Jun 2016 10:31:38 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com In-reply-to: Your message of "Fri, 3 Jun 2016 08:11:51 +0200 (CEST) ." Date: Fri, 03 Jun 2016 10:31:37 +0200 Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 08:31:46 -0000 In your letter dated Fri, 3 Jun 2016 08:11:51 +0200 (CEST) you wrote: >I'm getting reports of people getting packets "over the Internet" with LL >source address and GUA dst address. This seems to be a direct violation of >https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > >Is there some other RFC somewhere that contradicts this or should we all >start opening bug cases with our vendors if we see these types of packets >forwarded to us from outside the link? A couple of years ago I looked into this and then it was Juniper forwarding such packets. It is really weird if you have such an address in a traceroute many hops away from the source. Of course, the only way to see such packets at a host is if your own router has this bug. I guess that on other routers it is just a statistic among all other dropped traffic. From nobody Fri Jun 3 03:11: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 812A912D659 for ; Fri, 3 Jun 2016 03:11:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gr_Rt28WbvHO for ; Fri, 3 Jun 2016 03:11:52 -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 CA70212D1E5 for ; Fri, 3 Jun 2016 03:11:52 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id i127so75532623ita.1 for ; Fri, 03 Jun 2016 03:11:52 -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=WFdHsTJ7m7bi6jy6Jy5rj9mhWbqKwXwSN7AtbFF0v7M=; b=kyfCHNPxRu1aELKaCaMtfyVzre/joIF4HFgN2M7KBhQrzT9+w7rUhoER7Kz6jBuUrp Q5qhdsnVil09LjtVGsge9SlKejI/Daba5U3OuvMtJ+es+aqjcN9gNwaFNImACLi9SgC7 egtCFUfLtLdRmcgjUsXY9euRgfVI27mBlPBkuAM/StHJ/i8lGz0EI/mEJRFGMGY0sGIP 9O1ceYv3TRd+NJBqDuvn1kzssUtvQ2BUkpe3CDiYk06E9H9vG+HKZQLUZSWaPFkAlrZO 8SWLhjld47+dKVwZrtsTna0ZldDpXjAVYqabsCUfBvJ35xpG50kf1e6bnoHQ2H9Asslh ieoA== 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=WFdHsTJ7m7bi6jy6Jy5rj9mhWbqKwXwSN7AtbFF0v7M=; b=FDwCVQD5bAp0em1/xgsaid0OdiB4HjZgq9ysbYvcJgKJ8g+Z9CJB8dH5MRIyb3om7C MVEB/il964OcoETd4CIn6wghvfdpAyTtntW3Nl3xZ0dcBCYvkRWXsrK51WLbW7L2yZNA ejXBoOIICwB7+nGtwyL15kE8+eQyR0s/g5eFHs7F5y7UU8NqstpysAB/Xanoj4pduNVi nqH33XDmyZp57tXxcPSZCztg1TB4DoBnutS+NOpPT49ctUjiZZXW6jNi4G8YzIUa8Sw+ NfC44LlrL2ulS33ntH3OwdtGPKXc9uziJuC/LhJ7bNay9yHrd6dUIjX5k6+8QsEBXkgS H8qg== X-Gm-Message-State: ALyK8tLRypKcwvVry9ykfrv5aDosqGlRKzbTlITCIjvBId4/ij4fksegZqgEeDgpGsQTSVdI1Sdc7UuUN5v37Q== X-Received: by 10.36.51.15 with SMTP id k15mr8108715itk.80.1464948712124; Fri, 03 Jun 2016 03:11:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Fri, 3 Jun 2016 03:11:32 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Fri, 3 Jun 2016 12:11:32 +0200 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" , Jen Linkova Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 10:11:54 -0000 On Fri, Jun 3, 2016 at 8:39 AM, Lorenzo Colitti wrote: > Also see Jen's stats here: > https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf >> I'm getting reports of people getting packets "over the Internet" with LL >> source address and GUA dst address. This seems to be a direct violation of >> https://tools.ietf.org/html/rfc4291#section-2.5.6 ? Yes, I believe it is. >> Is there some other RFC somewhere that contradicts this I'm not aware of any such RFC. I think vendors just do not care. There are 3 problems there: 1) hosts (router) send packets for global offlink destination using LLA. Unless the sender does not have any GUA, it looks like badly broken default address selection 2) routers forward those packets, violating https://tools.ietf.org/html/rfc4007#section-9 and https://tools.ietf.org/html/rfc4291#section-2.5.6 3) people do not filter them > or should we all >> start opening bug cases with our vendors if we see these types of packets >> forwarded to us from outside the link? We should indeed. (The problem usually is that it all depends on the kindness of strangers: when I see ICMPv6 Packet Too Big coming to my network with LLA source from somewhere in the Internet, I can only kindly ask my peer to check why their router forwards such packet....) -- SY, Jen Linkova aka Furry From nobody Fri Jun 3 03:30: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 04A7812D154 for ; Fri, 3 Jun 2016 03:30:30 -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_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 QkIw7jQH2ksX for ; Fri, 3 Jun 2016 03:30:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE7B12B065 for ; Fri, 3 Jun 2016 03:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1464949828; x=1466159428; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=u4tyGxoiJTFhDR+V92GAJgvPyvmUqQ91DJLPVQinjNE=; b=W8Ajpd5njGXcVCN5rqsCGriJTVvyO+KC1uJ2rc5+qtjdWdpJG0ghJ93x fXPf//3GzSfCSb3sSjeLqMpYO3Hx0l4GEu0Tkr7p2Myr2iNZcUmiVFxd2 RTdjwlCBUPys0fxEQ+6rf0AKw0vQL/vAER8cPnirHyoWaEQ2OHDZsoYEt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCJW1FX/4oNJK1cgzpWfQa6UoF5F?= =?us-ascii?q?wuEYIEQAoEzOBQBAQEBAQEBZSeERQEBAQQBAQE3NBcEAgEIDgMEAQEfCQcnCxQ?= =?us-ascii?q?JCAIEARIIiCcOwk8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0hBIRAYV2BZhFA?= =?us-ascii?q?YYCiBqPI49RAR42g25uAQGIWzZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,411,1459814400"; d="scan'208";a="111153271" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jun 2016 10:30:26 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u53AUQL9023250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Jun 2016 10:30:26 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 3 Jun 2016 06:30:25 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Fri, 3 Jun 2016 06:30:25 -0400 From: "Hemant Singh (shemant)" To: Mikael Abrahamsson , "v6ops@ietf.org" Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRvV7h3JUBAm5PyUKZsK7A26JgC5/XiRNQ Date: Fri, 3 Jun 2016 10:30:25 +0000 Message-ID: References: In-Reply-To: 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.82.248.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 10:30:30 -0000 Quote one of the basic rules in IPv6 SAS (Source Address Selection) - see R= FC 6724. Specifically, see section 5, Rule 2 included below. =20 Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Friday, June 03, 2016 2:12 AM To: v6ops@ietf.org Subject: [v6ops] Packets with LL src and GUA dst Hi, I'm getting reports of people getting packets "over the Internet" with LL s= ource address and GUA dst address. This seems to be a direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 ? Is there some other RFC somewhere that contradicts this or should we all st= art opening bug cases with our vendors if we see these types of packets for= warded to us from outside the link? --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 3 04:23: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 5B66512D0D3 for ; Fri, 3 Jun 2016 04:23:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BvfvfGLE78SD for ; Fri, 3 Jun 2016 04:23:50 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 B9A6512D0BE for ; Fri, 3 Jun 2016 04:23:50 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id z123so76867938itg.0 for ; Fri, 03 Jun 2016 04:23:50 -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=XHVhB0aEZK35l7OMucPLfCUvw1NXvdK51tuI5v5HGz4=; b=ZIpSil1ipK/v9gACRaX9C5SppK70THjBJnms31LYj9vE+QS2blIqn7mg1rH99In2db ig9TbkmXT8CwBIPGQ4HCpJqdA8uS/7C1QrfFmk3aJcfbV21X6uYGMYR/ByTnYyoC6pLh 0sE3Pl0lChUJrfmXyT4/DK38eGtmSDq3h+qSo/HVQZOM4hxHGS+nxWYHDZW5p3ypbA/X JFTueA6jVoiOhLtyawSTdiLzC8IN4d/zFwLlj2aMRDpli+U1BTqNxbiWC++YAdLRV1f6 cX9Mnh/LAOPAyq5A59FD5mrk7tQ+Sj5bWumlbbvRgj5/+0CYAqaCdAIpscsSLYhYTBCS kk5w== 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=XHVhB0aEZK35l7OMucPLfCUvw1NXvdK51tuI5v5HGz4=; b=HKmCaReLHQnjC0nokGlEPJJicB9xL0/ygStfhOaH0eSiz1V+cokO9coOWPIo7fbRY9 DFl8IziYt8keGAUM4IejtRS3Oq8uRu06axaXsOkvTXhRDmMG5A5XYNjEc/pnmG45MsRs 7ty4w2LCcuzeJkhexoqn37BbAgpjFbDg7u3RqfeaXGAEFAvPQ2U9yCn1Z24FSTSeS0aG 3tH7wV+aZ+P2yMU7hAoMnpBANOf/AxdQ2I7TUpFrAnCduM2n9mzMUoEZjKDFOs1i8Jg0 h9etjqFhKooRJJpSVgk/79oILPRHufrlMqg76dWEpZaluT414iu3s3CBGS4vq9kn0J7H QgXA== X-Gm-Message-State: ALyK8tLm7Jp6ttBTHuTGEuerBEQXqfn+v/SO7REObchZh1Rwl8O4DxYcr1HhxlaXiIA1FS3cGVrioOLvAAwE/Q== X-Received: by 10.36.14.134 with SMTP id 128mr3995173ite.70.1464953030098; Fri, 03 Jun 2016 04:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Fri, 3 Jun 2016 04:23:30 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Fri, 3 Jun 2016 13:23:30 +0200 Message-ID: To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 11:23:52 -0000 On Fri, Jun 3, 2016 at 12:30 PM, Hemant Singh (shemant) wrote: > Quote one of the basic rules in IPv6 SAS (Source Address Selection) - see RFC 6724. Specifically, see section 5, Rule 2 included below. > > Rule 2: Prefer appropriate scope. > If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and > otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If > Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. One of the case when it might happen w/o violating RFC6724 is when the outgoing interface has LLA only and the particular implementation does not include loopback address or GUA assigned to any other interfaces (Section 4 says 'MAY'). > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson > Sent: Friday, June 03, 2016 2:12 AM > To: v6ops@ietf.org > Subject: [v6ops] Packets with LL src and GUA dst > > > Hi, > > I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of > https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > > Is there some other RFC somewhere that contradicts this or should we all start opening bug cases with our vendors if we see these types of packets forwarded to us from outside the link? > > -- > 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 -- SY, Jen Linkova aka Furry From nobody Fri Jun 3 04:24: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 DBADC12D0D3 for ; Fri, 3 Jun 2016 04:24: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 d4l21AcSc8Rs for ; Fri, 3 Jun 2016 04:24:56 -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 AEC7412B008 for ; Fri, 3 Jun 2016 04:24:55 -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 u53BOrTI008560 for ; Fri, 3 Jun 2016 13:24:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6EBD206A07 for ; Fri, 3 Jun 2016 13:25:16 +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 AE012206977 for ; Fri, 3 Jun 2016 13:25:16 +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 u53BOqMj015215 for ; Fri, 3 Jun 2016 13:24:52 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> Date: Fri, 3 Jun 2016 13:24:52 +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: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 11:24:58 -0000 Hi, Le 03/06/2016 à 08:11, Mikael Abrahamsson a écrit : > > Hi, > > I'm getting reports of people getting packets "over the Internet" > with LL source address and GUA dst address. This seems to be a > direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 > ? Yes, but. A message of best-effort "beacon" semantics is sent by a device to members of a global multicast group address. Due to peer-to-peer absence of authority it may be hard for the device to configure and keep a GUA, and hard to inject a GUA in the routing system too - hence it would use its LL as src. I dont think there is any other IP mechanism for such a device to beacon its message across subnets, but to src==LL and dst==global-mcast. Given that, while I would agree to a common practice of same-scoped src and dst fields in same IPv6 header I would consider the exceptions too. (if there were something to definitely prohibit, it would be a src field to contain a multicast address - it makes little sense). > Is there some other RFC somewhere that contradicts this The Code 2 ICMPv6 Parameter Problem is defined in RFC4443 pp. 9 3rd par https://tools.ietf.org/html/rfc4443#page-9 reads: > If the reason for the failure to deliver is that the destination is > beyond the scope of the source address, the Code field is set to 2. > This condition can occur only when the scope of the source address > is smaller than the scope of the destination address (e.g., when a > packet has a link-local source address and a global-scope > destination address) and the packet cannot be delivered to the > destination without leaving the scope of the source address. Mikael said: > or should we all start opening bug cases with our vendors if we see > these types of packets forwarded to us from outside the link? For the router vendor: does the router implement Code ICMPv6 Parameter Problem? Does it send it? For the OS vendor: what does a Host when it receives a Code 2 ICMP Parameter Problem? Does it print on screen, or does it change the scopes? Alex From nobody Fri Jun 3 05:27: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 B385C12D161 for ; Fri, 3 Jun 2016 05:27:05 -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 q-mEnVqjdUq5 for ; Fri, 3 Jun 2016 05:27:02 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (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 AE78A12D126 for ; Fri, 3 Jun 2016 05:27:01 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id DDD9015EC45 for ; Fri, 3 Jun 2016 14:26:59 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id C0D291D15B for ; Fri, 3 Jun 2016 14:26:59 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 9C9579C0E; Fri, 3 Jun 2016 14:26:59 +0200 (CEST) Date: Fri, 3 Jun 2016 14:26:59 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160603122659.GD89557@ernw.de> References: 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: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 12:27:06 -0000 Hi, I'm aware that this is not rly a productive contribution to the thread, but I'd like to point out that my belief (based on observations in the field) is that less than 50% of IPv6 implementations "mostly follow RFC 3484 or 6724". They do sth else, with "sth" being close to "sth random". best Enno On Fri, Jun 03, 2016 at 10:30:25AM +0000, Hemant Singh (shemant) wrote: > Quote one of the basic rules in IPv6 SAS (Source Address Selection) - see RFC 6724. Specifically, see section 5, Rule 2 included below. > > Rule 2: Prefer appropriate scope. > If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and > otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If > Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. > > Hemant > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson > Sent: Friday, June 03, 2016 2:12 AM > To: v6ops@ietf.org > Subject: [v6ops] Packets with LL src and GUA dst > > > Hi, > > I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of > https://tools.ietf.org/html/rfc4291#section-2.5.6 ? > > Is there some other RFC somewhere that contradicts this or should we all start opening bug cases with our vendors if we see these types of packets forwarded to us from outside the link? > > -- > 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 -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Fri Jun 3 07:07: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 BB60A12D694 for ; Fri, 3 Jun 2016 07:07:33 -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 s0lynBMnUnxs for ; Fri, 3 Jun 2016 07:07:32 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 4CF9F12D191 for ; Fri, 3 Jun 2016 07:07:32 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id k19so62094488ioi.3 for ; Fri, 03 Jun 2016 07:07:32 -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=Ch81GSOzW/rEkYCGxwvXW5V+DoUqh9tr/gnMdoK/xKA=; b=eRWj8SkB+pfXddSSS7B4rKKwkmi8OqAseADdjxcD/MqJ5eopNK2Jn1blxv9f4izYzj yVNKoLxCoVrXhSdIUVX+nBeR7/DxM6AFl6gCeEPpu90X0i8vjjnypMInMs0B+X1xP70S +7lqnY9UV/bNKJFlABxDFW/YCaYSBPVQneRVUlBeOY2o4shJcBnk+969loKidTWTIND3 cl5RJwZgibr5aboih+TcKkrranecCSYFJkEHCEP2JUNdIO8q6Nt45ZPjMBayXbDmj/gg 6ejxA79X5mIBrXrG6VThxefXUrhv87+u46QqHdqhutKdcBMge3w5zLm4B/RpGkoXJb9A rdtw== 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=Ch81GSOzW/rEkYCGxwvXW5V+DoUqh9tr/gnMdoK/xKA=; b=gvscLnG6TmYHfyh8Jk/uPQKQ/OUf0ZiAjKN08z0VY1jYG2R2sTQekUvug7tZo/CfnH EJalufKJ+nsOFklgZ4/wwkibGLrZQr8DO2fmgW2pNXjbo3BIplYu4iYhVXx1REKuM1ro g/Y8k+RoPu+hazNMeOJ3I4aNXduffhDka8H4qKsYDu7GejSA3k0cJfaUNP/9mml3+o6G 5PMFlpqA4MwibcnYVEJt6l2eaKFEGt2tshp9Can/cIX4S73PPvMTc96IIiHzspFslYKi MgSFWeK20PhrNVvQgCJV58QiQUT85Yso92vFjHXBjsKNu2vyi/D9BJmre8XSHO+k9Ndf Uy8Q== X-Gm-Message-State: ALyK8tKSI1NSGBIFabuVOFkYEBU79+dJ0v4MCiuvjFZpu3c19xp9bEzKtjrZ5hvg6LJpB4ZX4y7JH15PVU0B+E4b X-Received: by 10.107.142.137 with SMTP id q131mr5574113iod.47.1464962851530; Fri, 03 Jun 2016 07:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.57.2 with HTTP; Fri, 3 Jun 2016 07:07:11 -0700 (PDT) In-Reply-To: <20160603122659.GD89557@ernw.de> References: <20160603122659.GD89557@ernw.de> From: Erik Kline Date: Fri, 3 Jun 2016 23:07:11 +0900 Message-ID: To: Enno Rey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 14:07:34 -0000 I wonder what the distribution of the hoplimits in the receive LL src'd packets is. If it looks like a count down from 255 that's a protocol violation. If they look more like count down from, say, 64, then that sounds more like a corner case bug. From nobody Fri Jun 3 07:38: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 5851212D1F0 for ; Fri, 3 Jun 2016 07:38:07 -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=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 JHRBtjFPBT6x for ; Fri, 3 Jun 2016 07:38:05 -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 471AE12D1D4 for ; Fri, 3 Jun 2016 07:38:04 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BD33C6048E for ; Fri, 3 Jun 2016 16:38:02 +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 5C4036011A; Fri, 3 Jun 2016 16:38:02 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 4C2042CF79; Fri, 3 Jun 2016 16:38:02 +0200 (CEST) Date: Fri, 3 Jun 2016 16:38:02 +0200 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160603143802.GG52179@Space.Net> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@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] Packets with LL src and GUA dst 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, 03 Jun 2016 14:38:07 -0000 Hi, On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu wrote: > Yes, but. > > A message of best-effort "beacon" semantics is sent by a device to > members of a global multicast group address. Due to peer-to-peer > absence of authority it may be hard for the device to configure and keep > a GUA, and hard to inject a GUA in the routing system too - hence it > would use its LL as src. We're not talking multicast and convoluted configurations. The packets I've seen are bog standard unicast ping or UDP 53 (DNS request) 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 Fri Jun 3 08:29: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 53EA912D1BD for ; Fri, 3 Jun 2016 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.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 V9cqv-aNpaUB for ; Fri, 3 Jun 2016 08:28:28 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EAA12D6D7 for ; Fri, 3 Jun 2016 08:28:27 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id c127so83372348ywb.1 for ; Fri, 03 Jun 2016 08:28:27 -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=EuhxlIT+iaNG1w8AOk4Q+SYKMHdZw8HHWCgPRLhaxHE=; b=VlzXpcGB5nWTb/Yqr1fhrhbBu4QrM+d4jnzc2cMBt4nk+W3vtyx2WBmQIgXQZJfcNJ 3P3gJnM4EGy5gt5YvAIu/ED5Y+zF7VqmKZwct+g/HIpXz4+CYsc1OmnDZAS3yNo7Zovu IpMfafCsX0DZwAdLXv6D4ffTdl9XCC9JaIWB90RbiVpVX1ourcV9gidMFOFmjBVQl6YG PygCkrNyBPpHb29I8ljNNP6otKuB32UfRdryNIOxPAdP7+cUzZOR6Qf74ApYOD2gVMv/ Nq/5oSjG9cbqjeeE3f3vEGSlK1WzL6vfm7uWnvrd2JN4CE63qfbkfnO3vT1dYEYV20Q9 Bf8A== 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=EuhxlIT+iaNG1w8AOk4Q+SYKMHdZw8HHWCgPRLhaxHE=; b=OeDF0fLT9JLur1T9AQT3Q26pTKw5L0yMVnmb/2+EgHV2t7lwTILXzz7LrtSV9G8yBp VMlNPW1JpDIHK467RS6xU846Tsi0odhEJ9U8CqDUfXWAbrMyDie917WuC2DdsGnHcOv9 f6GcgLj53pDtDBP0p0C1O4PUPYRA6MpfCet36ZSEpuKJXAE0vjeQLhykQqZjl9otkyxJ VONt6wGFxy0dsmhdeSVX791cJdX3CtfV7Iov9qNDcbPkWS5bnf/Q5PuvusnmVF1xzgdh w9NB0rKN0Jl6oxad5FIEG9+UIT4aF93iGniuVhu6ygOyFo4eyFEAW0Zx5i53bYa2qqTU 1owg== X-Gm-Message-State: ALyK8tJTG0kV+OcBZylVA02db2CsSN/oMfOLY4ozVB1ocSxNHyZwVJ3KPK6OOk8kiTX8RCYEdELDuESRV+vSYC3c X-Received: by 10.129.80.139 with SMTP id e133mr2923830ywb.197.1464967706369; Fri, 03 Jun 2016 08:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.198.210 with HTTP; Fri, 3 Jun 2016 08:28:06 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 4 Jun 2016 00:28:06 +0900 Message-ID: To: Jen Linkova Content-Type: multipart/alternative; boundary=001a1147e532bf68180534615fc5 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 15:28:38 -0000 --001a1147e532bf68180534615fc5 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 3, 2016 at 8:23 PM, Jen Linkova wrote: > One of the case when it might happen w/o violating RFC6724 is when the > outgoing interface has LLA only and the particular implementation does > not include loopback address or GUA assigned to any other interfaces > (Section 4 says 'MAY'). > There are plenty of home gateways that announce a default route but don't assign global addresses, or that only assign addresses via DHCPv6 and have clients behind them that don't support DHCPv6. --001a1147e532bf68180534615fc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 3, 2016 at 8:23 PM, Jen Linkova <furry13@gmail.com> = wrote:
One of the case when it might happ= en w/o violating RFC6724 is when the
outgoing interface has LLA only and the particular implementation does
not include loopback address or GUA assigned to any other interfaces
(Section 4 says 'MAY').

There a= re plenty of home gateways that announce a default route but don't assi= gn global addresses, or that only assign addresses via DHCPv6 and have clie= nts behind them that don't support DHCPv6.=C2=A0
--001a1147e532bf68180534615fc5-- From nobody Fri Jun 3 09:13:58 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 EAB3A12D6FE for ; Fri, 3 Jun 2016 09:13:56 -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 NHAlg6E3J2ko for ; Fri, 3 Jun 2016 09:13:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4612D6F5 for ; Fri, 3 Jun 2016 09:13:48 -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 u53GCkAC016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jun 2016 09:12:47 -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: Date: Fri, 3 Jun 2016 09:12:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson 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, 03 Jun 2016 09:12:47 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 16:13:57 -0000 Open bugs. A device should not forward a packet with LL source or destination = address to any port other than the port on which it arrived. Owen > On Jun 2, 2016, at 23:11 , Mikael Abrahamsson = wrote: >=20 >=20 > Hi, >=20 > I'm getting reports of people getting packets "over the Internet" with = LL source address and GUA dst address. This seems to be a direct = violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 ? >=20 > Is there some other RFC somewhere that contradicts this or should we = all start opening bug cases with our vendors if we see these types of = packets forwarded to us from outside the link? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jun 3 09:36: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 6329012D590 for ; Fri, 3 Jun 2016 09:36:28 -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 BQO7lRnmD9sJ for ; Fri, 3 Jun 2016 09:36:26 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F012D52C for ; Fri, 3 Jun 2016 09:36:25 -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 u53GZNqw018184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jun 2016 09:35:23 -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: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> Date: Fri, 3 Jun 2016 09:35:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@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, 03 Jun 2016 09:35:23 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 16:36:28 -0000 > On Jun 3, 2016, at 04:24 , Alexandre Petrescu = wrote: >=20 > Hi, >=20 > Le 03/06/2016 =E0 08:11, Mikael Abrahamsson a =E9crit : >>=20 >> Hi, >>=20 >> I'm getting reports of people getting packets "over the Internet" >> with LL source address and GUA dst address. This seems to be a >> direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 >> ? >=20 > Yes, but. >=20 > A message of best-effort "beacon" semantics is sent by a device to > members of a global multicast group address. Due to peer-to-peer > absence of authority it may be hard for the device to configure and = keep > a GUA, and hard to inject a GUA in the routing system too - hence it > would use its LL as src. This is unacceptable behavior. It would be better for such a device to cobble together its own ULA for this purpose than to use its LL as = source. (And you know how much I hate ULA). No multicast packet with a scope greater than LINK should be sourced = from an LL address. I don=92t know if the RFCs clearly state that, but I would argue that if = they don=92t say that yet, they certainly should. > I dont think there is any other IP mechanism for such a device to = beacon > its message across subnets, but to src=3D=3DLL and dst=3D=3Dglobal-mcast= . >=20 > Given that, while I would agree to a common practice of same-scoped = src > and dst fields in same IPv6 header I would consider the exceptions = too. Making an exception here is silly. It invites mischief and the use case you describe is better handled using other mechanisms. ULA is a really bad choice too, but it=92s still slightly better than LL. >> Is there some other RFC somewhere that contradicts this >=20 > The Code 2 ICMPv6 Parameter Problem is defined in RFC4443 pp. 9 3rd = par > https://tools.ietf.org/html/rfc4443#page-9 reads: >> If the reason for the failure to deliver is that the destination is >> beyond the scope of the source address, the Code field is set to 2. >> This condition can occur only when the scope of the source address >> is smaller than the scope of the destination address (e.g., when a >> packet has a link-local source address and a global-scope >> destination address) and the packet cannot be delivered to the >> destination without leaving the scope of the source address. >=20 > Mikael said: >> or should we all start opening bug cases with our vendors if we see >> these types of packets forwarded to us from outside the link? >=20 > For the router vendor: does the router implement Code ICMPv6 Parameter > Problem? Does it send it? While it is ideal that the router does this, even if it does not, it = should at least drop the LL sourced packet rather than forward it to an = interface other than the arrival interface. Any router which fails to drop these packets is misbehaving and a bug should be filed when the behavior is detected. > For the OS vendor: what does a Host when it receives a Code 2 ICMP > Parameter Problem? Does it print on screen, or does it change the = scopes? Presumably if changing scopes was an option, it would have selected more compatible scopes in the first place. I see three possibilities: 1. The user/application specifically selected the = incomaptible scopes in which case reporting an error back to the user is appropriate behavior. 2. Automatic source address selection is not working = correctly on the host in which case reporting an error back to the = user is appropriate behavior. (The user should then file a = bug). 3. The system (or possibly just the outbound interface, = depending on implementation) doesn=92t have a valid source address = with a compatible scope in which case reporting an error back = to the user is appropriate behavior. Therefore, once it gets to this point, I believe reporting an error back to the user is correct behavior in all three scenarios. If you can think of a scenario not covered by those three possibilities, then it may = require separate analysis with a different conclusion. Owen From nobody Fri Jun 3 09:57: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 8EDB912D737 for ; Fri, 3 Jun 2016 09:57:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 svSQXjoCWnAA for ; Fri, 3 Jun 2016 09:57:46 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0353912B006 for ; Fri, 3 Jun 2016 09:57:46 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id z123so3267059itg.0 for ; Fri, 03 Jun 2016 09:57:45 -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=UBSLyoTfwFFy2it5Hd12MLnDRl5xYtTZYGePZQp0TQI=; b=kZW4Ht+BlySGRZ5JgvTizo73VsLtjbo7w0uGPnFOH0Y9+XVTWfgnfIgFdz7Fd2M5lk ZeF9zMH9kj2xxAc0u0/U3PCdlPZ51kUQKYq1vCzEQ9hcZ96AGqWpZDhEzqZ7AWpQTZ5J TTd5OWxHdubU/eZEJAHq1r2+PaFTowY2lFgW8tWjjVKRgrqWjnMn/d5l1CpW0dP9ywrr npr9BTQF2qOwHLJBxOtt3q68iqenfqNTtXKedxjJnPfugpi2t66tnVF32Bqhm7Ekx4yK tkqjqdGtO1DpGXMLDCTeoI2iMbOiszXPOAhTRUW+MZJuEkRJD5XhOjc7vY10dk5VD2X0 w13A== 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=UBSLyoTfwFFy2it5Hd12MLnDRl5xYtTZYGePZQp0TQI=; b=cid6hyjTPCOO9fen99auFIrgnirAsMx+MwAoBkveVqGLJpM1H6asUyEThiffTcsN5K p75VQc9oi0DFQhx05h3dx1XS8j/OpxnSBB6S2DTNd4LYiXh3/5KLV+eFOEe2TEP9PfHz dGui3rmx0GIug6j0hgfDnRx6z9aAlvT20r8mIZ2YYJipfZAI6m15qlcWp6LgzR953Am4 FC9tfWq3iv+XGW+y9J8jTlZEpGZ7VGZ3CgvebmJIpN+c9C02xGMWd7Bc1YWjS0PCtIa2 uErVnVSFugQBdZ8ZZr3uhJrh4+L1a+2HgJhsmmbyyJfCYzKmhn9IKHDBqtM61ROofylc EkNg== X-Gm-Message-State: ALyK8tKR9jPDyFOUJYfvTpKFUypYbxT9mH5jOltg0iBe1NS7CjNXJiOOV2lSyWl4kGmDcq7TSsrft3rZA3tZDQ== X-Received: by 10.36.76.148 with SMTP id a142mr905699itb.54.1464973065292; Fri, 03 Jun 2016 09:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Fri, 3 Jun 2016 09:57:25 -0700 (PDT) In-Reply-To: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> From: Jen Linkova Date: Fri, 3 Jun 2016 18:57:25 +0200 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 16:57:47 -0000 On Fri, Jun 3, 2016 at 1:24 PM, Alexandre Petrescu wrote: >> I'm getting reports of people getting packets "over the Internet" >> with LL source address and GUA dst address. This seems to be a >> direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 >> ? > > > Yes, but. > > A message of best-effort "beacon" semantics is sent by a device to > members of a global multicast group address. Due to peer-to-peer > absence of authority it may be hard for the device to configure and keep > a GUA, and hard to inject a GUA in the routing system too - hence it > would use its LL as src. Sending a packet with LLA src means 'sending a packet with source address which is meaningless outside of that link'. Basically it is more or less the same (or even worse) than sending a packet with source address set to '::'. > I dont think there is any other IP mechanism for such a device to beacon > its message across subnets, but to src==LL and dst==global-mcast. Is it OK to send a packet with undefined address to Internet? Shall routers route it between interfaces? -- SY, Jen Linkova aka Furry From nobody Fri Jun 3 11:50: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 0AD2E12D901 for ; Fri, 3 Jun 2016 11:50:30 -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 XtG6V7hoB-Dj for ; Fri, 3 Jun 2016 11:50:26 -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 8F98212D79E for ; Fri, 3 Jun 2016 11:50:26 -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 u53IoOSo013440; Fri, 3 Jun 2016 20:50:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89C7F20708F; Fri, 3 Jun 2016 20:50:48 +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 724F9201D3C; Fri, 3 Jun 2016 20:50:48 +0200 (CEST) Received: from [132.166.84.41] ([132.166.84.41]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u53IoNWw008871; Fri, 3 Jun 2016 20:50:23 +0200 To: Gert Doering References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> From: Alexandre Petrescu Message-ID: <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> Date: Fri, 3 Jun 2016 20:50:23 +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: <20160603143802.GG52179@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 18:50:30 -0000 Le 03/06/2016 à 16:38, Gert Doering a écrit : > Hi, > > On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu wrote: >> Yes, but. >> >> A message of best-effort "beacon" semantics is sent by a device to >> members of a global multicast group address. Due to peer-to-peer >> absence of authority it may be hard for the device to configure and >> keep a GUA, and hard to inject a GUA in the routing system too - >> hence it would use its LL as src. > > We're not talking multicast and convoluted configurations. Ok but please dont call that convoluted. There is a strong use-case for it and that's the potential solution. If you can think of other solution in which a "beacon" is sent to many receivers away from the subnet, and which cant configure a GUA for itself, then I am interested to hear. > The packets I've seen are bog standard unicast ping or UDP 53 (DNS > request) packets. Ok, so that makes wonder what DNS client is it, and what router was its first hop. Alex > > Gert Doering -- NetMaster > From nobody Fri Jun 3 13:27: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 A0DE712D983 for ; Fri, 3 Jun 2016 13:27:45 -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=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 GIDVbjhm_xvG for ; Fri, 3 Jun 2016 13:27:43 -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 47F6A12D87F for ; Fri, 3 Jun 2016 13:27:42 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 223C760498 for ; Fri, 3 Jun 2016 22:27:39 +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 B9B456011A; Fri, 3 Jun 2016 22:27:38 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id A8D8F2C4F8; Fri, 3 Jun 2016 22:27:38 +0200 (CEST) Date: Fri, 3 Jun 2016 22:27:38 +0200 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160603202738.GL52179@Space.Net> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MGmrTRZxVujQoXMz" Content-Disposition: inline In-Reply-To: <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@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] Packets with LL src and GUA dst 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, 03 Jun 2016 20:27:46 -0000 --MGmrTRZxVujQoXMz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jun 03, 2016 at 08:50:23PM +0200, Alexandre Petrescu wrote: > Le 03/06/2016 =E0 16:38, Gert Doering a =E9crit : > > On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu wrote: > >> Yes, but. > >> > >> A message of best-effort "beacon" semantics is sent by a device to > >> members of a global multicast group address. Due to peer-to-peer > >> absence of authority it may be hard for the device to configure and > >> keep a GUA, and hard to inject a GUA in the routing system too - > >> hence it would use its LL as src. > > > > We're not talking multicast and convoluted configurations. >=20 > Ok but please dont call that convoluted. There is a strong use-case for > it and that's the potential solution. If you can think of other=20 > solution in which a "beacon" is sent to many receivers away from the=20 > subnet, and which cant configure a GUA for itself, then I am interested= =20 > to hear. If you want to communicate with off-net machines and have no GUA, that situation *is* convoluted. Or one could say I would be surprised if it works at all, given that multicast routing usually relies on=20 reverse-path-trees which totally break for LLA sources. > > The packets I've seen are bog standard unicast ping or UDP 53 (DNS > > request) packets. >=20 > Ok, so that makes wonder what DNS client is it, and what router was its= =20 > first hop. Hard to say, since I only have a link-local address as a source... 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 --MGmrTRZxVujQoXMz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXUeg2AAoJEN9WwGXkzn/FtlwP/0e1/Pznnxl3j3zj50mhKOu7 NkV+S682i4k7KRvrPkjzgK30akn1RXkVB1orzJjZIzLKZFMDp2awzp8ksMlztnmn 3Cp1dAA/76gcKaxr1WH57sO8VfsZB3lcwqIlqqWfIlNMTLH7c2MjPcDZsZmt4V1Q M9aEkgF/pg/k3j52Le57D0IkE2qiIRKkyjW/i7EpsQYuN+UqDGYdcryX8ZuSbOa8 UCHbPx7kM6IVb1uc+UUIXmswlLTeUNYwd0jLOGYx3Hrmi1+ucIEtSRnx3ilIlAWS ASVZSOdiY52X7Hflpi6envg2MhHFooM3BzJ+x5W0DgGxV5AlZ6Zx0j7lw1WaBP/T VVutvC2NRoT5XMufF3Y1IkrTpZ/yo0Vyi8FA5xbmGTeSY5boMyezHvjE/Fa+2E1M e84o0x0VXDzxKSi+s3k0/HsKHKxWbfCD6hbn9mznKLOxLJ7u3k4VDBEMLvTh7yPo zQutss32evfnSmR0l2Zw+1KUa8zklvNDnK5TkfiAf2DKrdAwlRoC54JMzjnRRzYm 0UH8/UvfSCYtoQNZCwr9bXpVXLwYXiCXcgEjpIt0DIpt7+4kv3OV5kxKX14LeKEk ZR3CR2N64W3WbedtUz8xjTw8TCvrjdvYySxkWBdWvbjHyraBaGVOOFiUUEvflodY PJdLBiaPQuhF7C7FPFiZ =NJlU -----END PGP SIGNATURE----- --MGmrTRZxVujQoXMz-- From nobody Fri Jun 3 13:55:58 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 8B5A712D520 for ; Fri, 3 Jun 2016 13:55:57 -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 zJDJ-dC3dnjc for ; Fri, 3 Jun 2016 13:55:55 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7488012B011 for ; Fri, 3 Jun 2016 13:55:55 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id xk1so17426564pac.2 for ; Fri, 03 Jun 2016 13:55:55 -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=t4fSPAH1xLKTDcnIvEzD6XP6lERL4neU77a+z83UF9c=; b=qieX2aMTTn8rhE/00ZI8ZrHKodLE53qhasgxyc/E64C9QIJIgPiJwNMdsUgLmmse2P V32FmzraVI4Ajs7hbKIaTN1BhQNba4bbYIVd80DZ/DosP4gtD+QqYGqHNSA96m14C3DR QRtOX3Gwqydk5ESGZTZbiuP9ankTREBRo0PAbBtb9wJBQbbdIr1dbxXwzfa0Kujyya4z a11LK0U0hNjtTsSYMyuPmOLUzBLQyGsnsA5KH7luXVm5MKlhHsm7AQTLXZvmeUtr13l1 pt9gXPtOATDeExXlS5TNhEhbYYTCoAFtYLfd5Pr4Zw2/Yx3z5FBK+uC7OfjjPKhk3G6D /U3w== 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=t4fSPAH1xLKTDcnIvEzD6XP6lERL4neU77a+z83UF9c=; b=E1qUdyHm6vNTiyz98olPt6gIoGvvg2jutcGw/ZbBpZVPrpGAuNcVklOEu+Q4OaZ+YL 62JP1g3tJ2SoPR7mhjLx7Ro28AYhRfy315BSHyhDXOuCbirgzOkycQ0gV1rIEmWNagmB +SzB2Xb+lzDVb7BKw84e+xba2QYfkQiCFcDMIJlvUkPHry0BiIdVdccEvnmMjsaMKunR t0iArRi4Fwz/af+wxQ11/KmJH9ImR8M+wG+vNscq8bUM7cZ0ctMRC295tRDDvdjmUM4g l3cOhzq4wG0Rb1HdD5OGnUwczL8fBi/sgiYN3EfwWaxjS+VM4892gxw6A5yM0YX/7aCw PNhQ== X-Gm-Message-State: ALyK8tK2FjRXLfPczgLu0RJLgjxwomQPcQiPSlnP1vn1CV93e10ThV9Dz6K+5k5giu4F1Q== X-Received: by 10.66.158.98 with SMTP id wt2mr7336223pab.53.1464987354928; Fri, 03 Jun 2016 13:55:54 -0700 (PDT) Received: from ?IPv6:2406:e007:5197:1:149c:5050:229f:37c1? ([2406:e007:5197:1:149c:5050:229f:37c1]) by smtp.gmail.com with ESMTPSA id m81sm10409037pfi.51.2016.06.03.13.55.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 13:55:54 -0700 (PDT) To: Enno Rey , v6ops@ietf.org References: <20160603122659.GD89557@ernw.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0c5d3a64-4c00-3621-4b79-6e96bf15fedf@gmail.com> Date: Sat, 4 Jun 2016 08:56:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160603122659.GD89557@ernw.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 03 Jun 2016 20:55:57 -0000 On 04/06/2016 00:26, Enno Rey wrote: > Hi, > > I'm aware that this is not rly a productive contribution to the thread, but I'd like to point out that my belief (based on observations in the field) is that less than 50% of IPv6 implementations "mostly follow RFC 3484 or 6724". They do sth else, with "sth" being close to "sth random". It seems clear to me that whatever we write in RFCs, there will sometimes be situations, possibly transitory, where a host will not have any GUA but will decide to send a packet to a GUA. So it will send it with a LL source address. That cannot be excluded, so the rule that forwarding nodes MUST NOT forward such a packet off link needs to be enforced. We don't have an IPv6 Router Requirements RFC, so I can understand how vendors can miss it in RFC4291. But it's a bug. Brian > best > > Enno > > On Fri, Jun 03, 2016 at 10:30:25AM +0000, Hemant Singh (shemant) wrote: >> Quote one of the basic rules in IPv6 SAS (Source Address Selection) - see RFC 6724. Specifically, see section 5, Rule 2 included below. >> >> Rule 2: Prefer appropriate scope. >> If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and >> otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If >> Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. >> >> Hemant >> >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mikael Abrahamsson >> Sent: Friday, June 03, 2016 2:12 AM >> To: v6ops@ietf.org >> Subject: [v6ops] Packets with LL src and GUA dst >> >> >> Hi, >> >> I'm getting reports of people getting packets "over the Internet" with LL source address and GUA dst address. This seems to be a direct violation of >> https://tools.ietf.org/html/rfc4291#section-2.5.6 ? >> >> Is there some other RFC somewhere that contradicts this or should we all start opening bug cases with our vendors if we see these types of packets forwarded to us from outside the link? >> >> -- >> 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 Fri Jun 3 17:12:55 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 A7B1412D09B for ; Fri, 3 Jun 2016 17:12:53 -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 jq2YE0AaCGgp for ; Fri, 3 Jun 2016 17:12:52 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 18BFA12D151 for ; Fri, 3 Jun 2016 17:12:51 -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 u540BlX7017088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jun 2016 17:11:48 -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: <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> Date: Fri, 3 Jun 2016 17:11:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@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, 03 Jun 2016 17:11:48 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 04 Jun 2016 00:12:54 -0000 > On Jun 3, 2016, at 11:50 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 03/06/2016 =E0 16:38, Gert Doering a =E9crit : >> Hi, >>=20 >> On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu wrote: >>> Yes, but. >>>=20 >>> A message of best-effort "beacon" semantics is sent by a device to >>> members of a global multicast group address. Due to peer-to-peer >>> absence of authority it may be hard for the device to configure and >>> keep a GUA, and hard to inject a GUA in the routing system too - >>> hence it would use its LL as src. >>=20 >> We're not talking multicast and convoluted configurations. >=20 > Ok but please dont call that convoluted. There is a strong use-case = for > it and that's the potential solution. If you can think of other = solution in which a "beacon" is sent to many receivers away from the = subnet, and which cant configure a GUA for itself, then I am interested = to hear. I would argue that in that case, it is better to send with source of :: = (Unknown) than with LL. It=92s ugly, it will probably get dropped, but at least the RFC=92s = don=92t require it to get dropped as they do with LL. Frankly, I=92m trying to understand the use case for such a beacon and = how/why you have a device that can=92t get a global address but has = internet connectivity and it is escaping me. Perhaps with more detail = about the nature of the thing that is beaconing and/or the environment = in which it operates, other solutions could be proposed. >=20 >> The packets I've seen are bog standard unicast ping or UDP 53 (DNS >> request) packets. >=20 > Ok, so that makes wonder what DNS client is it, and what router was = its first hop. Every router between the source and point where the packet was dropped = is wrong (as well as the origin host). Not just the first hop, though if the first hop was right, the rest = being wrong would be undetectable in this scenario. Owen From nobody Mon Jun 6 06:56: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 221D412D7A2 for ; Mon, 6 Jun 2016 06:56: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 OCTghDnhTvU2 for ; Mon, 6 Jun 2016 06:56: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 EB21D12D5AA for ; Mon, 6 Jun 2016 06:56: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 u56DtsDj003041; Mon, 6 Jun 2016 15:55:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93FC5208661; Mon, 6 Jun 2016 15:56:22 +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 868CA20867F; Mon, 6 Jun 2016 15:56:22 +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 u56DtsvD021174; Mon, 6 Jun 2016 15:55:54 +0200 To: Owen DeLong References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 6 Jun 2016 15:55:54 +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: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 13:56:07 -0000 Le 03/06/2016 à 18:35, Owen DeLong a écrit : > >> On Jun 3, 2016, at 04:24 , Alexandre Petrescu >> wrote: >> >> Hi, >> >> Le 03/06/2016 à 08:11, Mikael Abrahamsson a écrit : >>> >>> Hi, >>> >>> I'm getting reports of people getting packets "over the >>> Internet" with LL source address and GUA dst address. This seems >>> to be a direct violation of >>> https://tools.ietf.org/html/rfc4291#section-2.5.6 ? >> >> Yes, but. >> >> A message of best-effort "beacon" semantics is sent by a device to >> members of a global multicast group address. Due to peer-to-peer >> absence of authority it may be hard for the device to configure and >> keep a GUA, and hard to inject a GUA in the routing system too - >> hence it would use its LL as src. > > This is unacceptable behavior. It would be better for such a device > to cobble together its own ULA for this purpose than to use its LL as > source. But that would create a packet with src ULA and dst GUA. Would that be more acceptable than src LL and dst GUA? > (And you know how much I hate ULA). > > No multicast packet with a scope greater than LINK should be sourced > from an LL address. > > I don’t know if the RFCs clearly state that, but I would argue that > if they don’t say that yet, they certainly should. I would argue they shouldn't. There should be a possibility for a device which can't configure a GUA or a ULA to still send packets to a group of interested parties. > >> I dont think there is any other IP mechanism for such a device to >> beacon its message across subnets, but to src==LL and >> dst==global-mcast. >> >> Given that, while I would agree to a common practice of same-scoped >> src and dst fields in same IPv6 header I would consider the >> exceptions too. > > Making an exception here is silly. It invites mischief and the use > case you describe is better handled using other mechanisms. Which ones? [...] > Presumably if changing scopes was an option, it would have selected > more compatible scopes in the first place. I see three > possibilities: > > 1. The user/application specifically selected the incomaptible scopes > in which case reporting an error back to the user is appropriate > behavior. > > 2. Automatic source address selection is not working correctly on the > host in which case reporting an error back to the user is appropriate > behavior. (The user should then file a bug). > > 3. The system (or possibly just the outbound interface, depending on > implementation) doesn’t have a valid source address with a compatible > scope in which case reporting an error back to the user is > appropriate behavior. > > Therefore, once it gets to this point, I believe reporting an error > back to the user is correct behavior in all three scenarios. If you > can think of a scenario not covered by those three possibilities, > then it may require separate analysis with a different conclusion. I think it can be a sensible option: report to the user. But I also think the different-scoped packets should not be qualified as an error in all cases. Because we talk multiple cases: - src LL dst GUA - src LL dsr mcast-global - src ULA dst GUA Alex > > Owen > > > From nobody Mon Jun 6 06:58: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 5716012D7B6 for ; Mon, 6 Jun 2016 06:58:02 -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 CQeUUnyxCDbG for ; Mon, 6 Jun 2016 06:58:00 -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 8EA9112D5AA for ; Mon, 6 Jun 2016 06:58:00 -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 u56DvvM0021040; Mon, 6 Jun 2016 15:57:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EB3002071A3; Mon, 6 Jun 2016 15:58: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 DD06D20443E; Mon, 6 Jun 2016 15:58: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 u56DvvE8022405; Mon, 6 Jun 2016 15:57:57 +0200 To: Jen Linkova References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 6 Jun 2016 15:57: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 13:58:02 -0000 Le 03/06/2016 à 18:57, Jen Linkova a écrit : > On Fri, Jun 3, 2016 at 1:24 PM, Alexandre Petrescu > wrote: >>> I'm getting reports of people getting packets "over the Internet" >>> with LL source address and GUA dst address. This seems to be a >>> direct violation of https://tools.ietf.org/html/rfc4291#section-2.5.6 >>> ? >> >> >> Yes, but. >> >> A message of best-effort "beacon" semantics is sent by a device to >> members of a global multicast group address. Due to peer-to-peer >> absence of authority it may be hard for the device to configure and keep >> a GUA, and hard to inject a GUA in the routing system too - hence it >> would use its LL as src. > > > Sending a packet with LLA src means 'sending a packet with source > address which is meaningless outside of that link'. > Basically it is more or less the same (or even worse) than sending a > packet with source address set to '::'. Well thank you for your interpretation. I can live with it, but my interpretation is a bit different: packets with src :: should be allowed to traverse the Internet, if some admins so decide. It would have some privacy advantages. >> I dont think there is any other IP mechanism for such a device to beacon >> its message across subnets, but to src==LL and dst==global-mcast. > > Is it OK to send a packet with undefined address to Internet? Shall > routers route it between interfaces? It should not be forbidden. Alex > From nobody Mon Jun 6 07:06: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 A633212D7B0 for ; Mon, 6 Jun 2016 07:06:48 -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 87ph9nTOZLST for ; Mon, 6 Jun 2016 07:06:47 -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 1D70312D7AE for ; Mon, 6 Jun 2016 07:06:46 -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 u56E6jph007730; Mon, 6 Jun 2016 16:06:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B6AF2086DC; Mon, 6 Jun 2016 16:07:13 +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 1C9722071AB; Mon, 6 Jun 2016 16:07:13 +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 u56E6isN028598; Mon, 6 Jun 2016 16:06:44 +0200 To: Gert Doering References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <20160603202738.GL52179@Space.Net> From: Alexandre Petrescu Message-ID: <389689c2-9014-b09f-8bac-35b9a6973f3d@gmail.com> Date: Mon, 6 Jun 2016 16:06:44 +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: <20160603202738.GL52179@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 14:06:49 -0000 Le 03/06/2016 à 22:27, Gert Doering a écrit : > Hi, > > On Fri, Jun 03, 2016 at 08:50:23PM +0200, Alexandre Petrescu wrote: >> Le 03/06/2016 à 16:38, Gert Doering a écrit : >>> On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu wrote: >>>> Yes, but. >>>> >>>> A message of best-effort "beacon" semantics is sent by a device to >>>> members of a global multicast group address. Due to peer-to-peer >>>> absence of authority it may be hard for the device to configure and >>>> keep a GUA, and hard to inject a GUA in the routing system too - >>>> hence it would use its LL as src. >>> >>> We're not talking multicast and convoluted configurations. >> >> Ok but please dont call that convoluted. There is a strong use-case for >> it and that's the potential solution. If you can think of other >> solution in which a "beacon" is sent to many receivers away from the >> subnet, and which cant configure a GUA for itself, then I am interested >> to hear. > > If you want to communicate with off-net machines and have no GUA, that > situation *is* convoluted. Or one could say I would be surprised if > it works at all, given that multicast routing usually relies on > reverse-path-trees which totally break for LLA sources. I think the reverse-path-trees are guided by the GUAs of the routers not of the end-user consumer of the content. So yes, it should work. >>> The packets I've seen are bog standard unicast ping or UDP 53 (DNS >>> request) packets. >> >> Ok, so that makes wonder what DNS client is it, and what router was its >> first hop. > > Hard to say, since I only have a link-local address as a source... I see. I can understand the wory. But if there are too many of them you can set a firewall rule to block them, right? Alex > > Gert Doering > -- NetMaster > From nobody Mon Jun 6 07:12: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 D638F12D7C6 for ; Mon, 6 Jun 2016 07:12: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 Oq77ynfdjdGT for ; Mon, 6 Jun 2016 07:12:36 -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 0217212D7C5 for ; Mon, 6 Jun 2016 07:12:35 -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 u56ECRXQ011774; Mon, 6 Jun 2016 16:12:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 341C02086C0; Mon, 6 Jun 2016 16:12:55 +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 22D5720867F; Mon, 6 Jun 2016 16:12:55 +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 u56ECQI3032514; Mon, 6 Jun 2016 16:12:26 +0200 To: Owen DeLong References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> From: Alexandre Petrescu Message-ID: <9a19b42c-b374-eef8-2335-619adebe81ba@gmail.com> Date: Mon, 6 Jun 2016 16:12:26 +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: <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 14:12:38 -0000 Le 04/06/2016 à 02:11, Owen DeLong a écrit : > >> On Jun 3, 2016, at 11:50 , Alexandre Petrescu >> wrote: >> >> >> >> Le 03/06/2016 à 16:38, Gert Doering a écrit : >>> Hi, >>> >>> On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu >>> wrote: >>>> Yes, but. >>>> >>>> A message of best-effort "beacon" semantics is sent by a device >>>> to members of a global multicast group address. Due to >>>> peer-to-peer absence of authority it may be hard for the device >>>> to configure and keep a GUA, and hard to inject a GUA in the >>>> routing system too - hence it would use its LL as src. >>> >>> We're not talking multicast and convoluted configurations. >> >> Ok but please dont call that convoluted. There is a strong >> use-case for it and that's the potential solution. If you can >> think of other solution in which a "beacon" is sent to many >> receivers away from the subnet, and which cant configure a GUA for >> itself, then I am interested to hear. > > I would argue that in that case, it is better to send with source of > :: (Unknown) than with LL. > > It’s ugly, it will probably get dropped, but at least the RFC’s don’t > require it to get dropped as they do with LL. > > Frankly, I’m trying to understand the use case for such a beacon and > how/why you have a device that can’t get a global address but has > internet connectivity and it is escaping me. Perhaps with more detail > about the nature of the thing that is beaconing and/or the > environment in which it operates, other solutions could be proposed. I guess yes. The idea is for moving objects like cars approaching to other cars or moving together for a while. They need to signal their presence somehow, and in some cases setting up networking first can take too much time. Currently there are WSMP messages on top of a vehicle-specific WiFi (i.e. w/o IP) which achieve that: they broadcast their position everybody to everybody else. It has some advantages but some inconvenients in terms of too much noise, scalability. My idea would be to have IP Router Advertisements source with LL or :: and delivered to an IP multicast group with any scope. >>> The packets I've seen are bog standard unicast ping or UDP 53 >>> (DNS request) packets. >> >> Ok, so that makes wonder what DNS client is it, and what router was >> its first hop. > > Every router between the source and point where the packet was > dropped is wrong (as well as the origin host). > > Not just the first hop, though if the first hop was right, the rest > being wrong would be undetectable in this scenario. Read. Alex > > Owen > > From nobody Mon Jun 6 08:00: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 E8AD712D7E7 for ; Mon, 6 Jun 2016 08:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.048 X-Spam-Level: X-Spam-Status: No, score=-114.048 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 5WZM4DuCnXK7 for ; Mon, 6 Jun 2016 08:00:12 -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 1970A12D7E2 for ; Mon, 6 Jun 2016 08:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=495; q=dns/txt; s=iport; t=1465225212; x=1466434812; h=date:from:message-id:to:subject; bh=z12IQodultFFaBFsAXzHY6DYoDHTT4oJUkL080D9Ji4=; b=E4IfV2m/wBv05t4Xmq8VsCR3bezWaXc2hTp3CudptPPTDSNJEn7DI+xD bsV0nc7GsL8IRx4ETjHvBpGFwSNqTMTriWcgWd6bx95p2y714nQKOHXKK rV4kYp5B+F64dphAYb6tN0krAyFFz5VWCbh7lCgkXuOtVlxcknmATQPCO 0=; X-IronPort-AV: E=Sophos;i="5.26,427,1459814400"; d="scan'208";a="281435022" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 15:00:11 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u56F0AUM001393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2016 15:00:11 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 u56F0AZe025535; Mon, 6 Jun 2016 08:00:10 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u56F0Aib025531; Mon, 6 Jun 2016 08:00:10 -0700 Date: Mon, 6 Jun 2016 08:00:10 -0700 From: fred@cisco.com Message-Id: <201606061500.u56F0Aib025531@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] Call to action: post your drafts! 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, 06 Jun 2016 15:00:14 -0000 The Internet Draft repository will close for IETF 96 on July 8. As I find myself reminding people each meeting, the guideline the working group has given the chairs is that they want Internet Drafts posted, and vetted on the list - no supporting commentary, no face time. So, if you have a mind to write a draft for discussion in six weeks, the time to write and post the draft is now - and then forward your posting notification to the list explaining the issue and inviting discussion. From nobody Mon Jun 6 08:03: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 EBBF412D7D4 for ; Mon, 6 Jun 2016 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Cahb48PjGjRE for ; Mon, 6 Jun 2016 08:03:05 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 1DAEB12D7D5 for ; Mon, 6 Jun 2016 08:03:02 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 37so9170617qtc.3 for ; Mon, 06 Jun 2016 08:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=1w20i45/fgSq2/wAbv5jUM/gU7hrWVw4sqtqgQ9viyg=; b=SExE6ilKSLMs/zX4J+W5hXhiuPGYqLv8l5rX9NZ1TLGEx3vQEzSMxFn3b+5nVXtpuZ 1GRMyK00SEBg36dYMmSKGbx8OaCpFH17EkpsO6wGcYbuznk7vdJxCrUh0l7wMCZTMhLJ OOkLbOkGLtTUqjlG7E9Ac6MvJJ3tqWGmypLnOIRnbTl1QYgO8QTWJdLj4kWczQg4E4/6 9QRYB/uYTBmu/qOF/GtxFCr+wj0zEOXlD+jkcIw2/KYP++B8uKUm+s6P46qmywpdCVsB gFvXptNnIstg0jWWa+7Jmcj6GpPb1ihUtaB4nGzTYnWcD7DLS854mMZIcWhucfzo43P9 cGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=1w20i45/fgSq2/wAbv5jUM/gU7hrWVw4sqtqgQ9viyg=; b=gPvSrkM6cB6AuxYbFtd73twPGJCz5i+frJQA1pOWSV1cC5+UYWdVAFG4KU6hRWK+x3 iLNOtArblWI/vhgRZDlMxEcKPuTiDQtDiuEruIwfzm6mbvnkkDriHIDtqM1httlrDgWV 5jQZ0KPhrvZExJqT3aMp9Cxcq1E3EY6A5nEceQoZjBixDOORaERz0bOp8lHnt6PIhRkU GuHHwlyrAkrtlPEmMFLKxU/w9vKPghWN/G2rvAetWnb8K27ioKQvO4Tx0c4IV1V/cWOP HPDXp2RXm9Gt4sBDyAJsjn+XWmWKi4vD/dOYPoutXkWlq+gM1+DqvgK+laHGiPBxsjoE KE4g== X-Gm-Message-State: ALyK8tKsDs+3qyJKBG04hhfDKg/fF3WVe1TiRMUdBFsXzn5GyziguU0rHr2h0nfEM1je59x3QEYHQFd61w7+Kw== X-Received: by 10.237.35.59 with SMTP id h56mr6006912qtc.60.1465225381138; Mon, 06 Jun 2016 08:03:01 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Mon, 6 Jun 2016 08:03:00 -0700 (PDT) In-Reply-To: <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 6 Jun 2016 08:03:00 -0700 X-Google-Sender-Auth: awKH0JlR-0ypsnNeJXYcFb2OkYA Message-ID: To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 15:03:08 -0000 At Fri, 3 Jun 2016 17:11:47 -0700, Owen DeLong wrote: > > Ok but please dont call that convoluted. There is a strong use-case fo= r > > it and that's the potential solution. If you can think of other soluti= on in which a "beacon" is sent to many receivers away from the subnet, and = which cant configure a GUA for itself, then I am interested to hear. > > I would argue that in that case, it is better to send with source of :: (= Unknown) than with LL. > > It=E2=80=99s ugly, it will probably get dropped, but at least the RFC=E2= =80=99s don=E2=80=99t require it to get dropped as they do with LL. (in case no one has pointed this out) I'd interpret the following text of RFC4291 (or rfc4291bis for that matter) as "drop": An IPv6 packet with a source address of unspecified must never be forwarded by an IPv6 router. -- JINMEI, Tatuya From nobody Mon Jun 6 09:47: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 B44DC12D181 for ; Mon, 6 Jun 2016 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.526 X-Spam-Level: X-Spam-Status: No, score=-7.526 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.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 wrPjAzF3OCqS for ; Mon, 6 Jun 2016 09:47:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5951B12D140 for ; Mon, 6 Jun 2016 09:47: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 u56GkEUm022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Jun 2016 09:46:15 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_4E73ED05-A513-4494-8B2B-7F32737F4553" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Mon, 6 Jun 2016 09:46:15 -0700 Message-Id: References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@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]); Mon, 06 Jun 2016 09:46:15 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 16:47:21 -0000 --Apple-Mail=_4E73ED05-A513-4494-8B2B-7F32737F4553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 6, 2016, at 06:55 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 03/06/2016 =E0 18:35, Owen DeLong a =E9crit : >>=20 >>> On Jun 3, 2016, at 04:24 , Alexandre Petrescu >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Le 03/06/2016 =E0 08:11, Mikael Abrahamsson a =E9crit : >>>>=20 >>>> Hi, >>>>=20 >>>> I'm getting reports of people getting packets "over the >>>> Internet" with LL source address and GUA dst address. This seems >>>> to be a direct violation of >>>> https://tools.ietf.org/html/rfc4291#section-2.5.6 ? >>>=20 >>> Yes, but. >>>=20 >>> A message of best-effort "beacon" semantics is sent by a device to >>> members of a global multicast group address. Due to peer-to-peer >>> absence of authority it may be hard for the device to configure and >>> keep a GUA, and hard to inject a GUA in the routing system too - >>> hence it would use its LL as src. >>=20 >> This is unacceptable behavior. It would be better for such a device >> to cobble together its own ULA for this purpose than to use its LL as >> source. >=20 > But that would create a packet with src ULA and dst GUA. Would that = be > more acceptable than src LL and dst GUA? Much more acceptable. ULA can be routed among consenting parties. LL can = not. I=92d still drop it at all my borders, so your packet wouldn=92t see the = light of day if it tried to transit my network either way, but at least the ULA = isn=92t a clear RFC violation and some people might forward it. >> (And you know how much I hate ULA). >>=20 >> No multicast packet with a scope greater than LINK should be sourced >> from an LL address. >>=20 >> I don=92t know if the RFCs clearly state that, but I would argue that >> if they don=92t say that yet, they certainly should. >=20 > I would argue they shouldn't. >=20 > There should be a possibility for a device which can't configure a GUA > or a ULA to still send packets to a group of interested parties. There=92s no such thing as a device which can=92t configure a ULA. A device which has only an LL address should, by definition, only be = able to communicate on-link and therefore should not generate a packet with a scope greater than link. >=20 >>=20 >>> I dont think there is any other IP mechanism for such a device to >>> beacon its message across subnets, but to src=3D=3DLL and >>> dst=3D=3Dglobal-mcast. >>>=20 >>> Given that, while I would agree to a common practice of same-scoped >>> src and dst fields in same IPv6 header I would consider the >>> exceptions too. >>=20 >> Making an exception here is silly. It invites mischief and the use >> case you describe is better handled using other mechanisms. >=20 > Which ones? ULA, Fixing whatever is wrong with the device that it can=92t get an = address, etc. >=20 > [...] >> Presumably if changing scopes was an option, it would have selected >> more compatible scopes in the first place. I see three >> possibilities: >>=20 >> 1. The user/application specifically selected the incomaptible = scopes >> in which case reporting an error back to the user is appropriate >> behavior. >>=20 >> 2. Automatic source address selection is not working correctly on = the >> host in which case reporting an error back to the user is appropriate >> behavior. (The user should then file a bug). >>=20 >> 3. The system (or possibly just the outbound interface, depending = on >> implementation) doesn=92t have a valid source address with a = compatible >> scope in which case reporting an error back to the user is >> appropriate behavior. >>=20 >> Therefore, once it gets to this point, I believe reporting an error >> back to the user is correct behavior in all three scenarios. If you >> can think of a scenario not covered by those three possibilities, >> then it may require separate analysis with a different conclusion. >=20 > I think it can be a sensible option: report to the user. >=20 > But I also think the different-scoped packets should not be qualified = as an error in all cases. >=20 > Because we talk multiple cases: > - src LL dst GUA This is valid so long as the packet is not forwarded by = a router to an interface other than the one on which it was received. Any attempt to leave the confines of the link is, in = fact, an error. > - src LL dsr mcast-global This packet should not be forwarded off link. Any = attempt to do so is an error. > - src ULA dst GUA There=92s no real semantic difference between ULA and = GUA other than some theoretical idea that most people should (and may well) block ULA by = default at their borders. This is one of the reasons I really think ULA was a = horrible idea from the start. Owen --Apple-Mail=_4E73ED05-A513-4494-8B2B-7F32737F4553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 6, 2016, at 06:55 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 03/06/2016 =E0 18:35, Owen DeLong a = =E9crit :

On Jun 3, 2016, at 04:24 = , Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:

Hi,

Le 03/06/2016 =E0 08:11, = Mikael Abrahamsson a =E9crit :

Hi,

I'm getting = reports of people getting packets "over the
Internet" with = LL source address and GUA dst address. This seems
to be a = direct violation of
https://tools.ietf.org/html/rfc4291#section-2.5.6 ?

Yes, but.

A message of best-effort "beacon" semantics is sent by a = device to
members of a global multicast group address. =  Due to peer-to-peer
absence of authority it may be = hard for the device to configure and
keep a GUA, and hard = to inject a GUA in the routing system too -
hence it would = use its LL as src.

This is = unacceptable behavior. It would be better for such a device
to cobble together its own ULA for this purpose than to use = its LL as
source.

But that would create a = packet with src ULA and dst GUA.  Would that be
more acceptable than src = LL and dst GUA?

Much more = acceptable. ULA can be routed among consenting parties. LL can = not.

I=92d still drop it at all my = borders, so your packet wouldn=92t see the light of
day if it = tried to transit my network either way, but at least the ULA = isn=92t
a clear RFC violation and some people might forward = it.

(And you know how much I hate ULA).

No multicast packet with a scope greater than LINK should be = sourced
from an LL address.

I = don=92t know if the RFCs clearly state that, but I would argue that
if they don=92t say that yet, they certainly should.

I would argue they shouldn't.

There should be a possibility for a = device which can't configure a GUA
or a ULA to still send packets to a group = of interested parties.

There=92s no = such thing as a device which can=92t configure a ULA.

A device which has only an LL address should, by = definition, only be able
to communicate on-link and therefore = should not generate a packet with a
scope greater than = link.



I dont think there is = any other IP mechanism for such a device to
beacon its = message across subnets, but to src=3D=3DLL and
dst=3D=3Dglobal-mcast.

Given = that, while I would agree to a common practice of same-scoped
src and dst fields in same IPv6 header I would consider = the
exceptions too.

Making an exception here is silly. It invites mischief and = the use
case you describe is better handled using other = mechanisms.

Which ones?

ULA, Fixing = whatever is wrong with the device that it can=92t get an = address,
etc.


[...]
Presumably if changing scopes was an option, it would have = selected
more compatible scopes in the first place. I see = three
possibilities:

1. The = user/application specifically selected the incomaptible scopes
in which case reporting an error back to the user is = appropriate
behavior.

2. Automatic = source address selection is not working correctly on the
host in which case reporting an error back to the user is = appropriate
behavior. (The user should then file a = bug).

3. The system (or possibly just the = outbound interface, depending on
implementation) doesn=92t = have a valid source address with a compatible
scope in = which case reporting an error back to the user is
appropriate behavior.

Therefore, = once it gets to this point, I believe reporting an error
back to the user is correct behavior in all three scenarios. = If you
can think of a scenario not covered by those three = possibilities,
then it may require separate analysis with = a different conclusion.

I think it can be a = sensible option: report to the user.

But I also think the different-scoped packets = should not be qualified as an error in all cases.

Because we talk multiple cases:
- src LL dst GUA
= This is valid so long as the packet is not forwarded by a router = to an interface
other than the one on = which it was received.

= Any attempt to leave the confines of the link is, in fact, an = error.

- src LL dsr mcast-global

= This packet should not be forwarded off link. Any = attempt to do so is an error.

- src ULA dst = GUA

= There=92s no real semantic difference between ULA and GUA other = than some theoretical
idea that most people = should (and may well) block ULA by default at their = borders.

= This is one of the reasons I really think ULA was a horrible idea = from the start.

Owen


= --Apple-Mail=_4E73ED05-A513-4494-8B2B-7F32737F4553-- From nobody Mon Jun 6 09:54: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 DEA1812D853 for ; Mon, 6 Jun 2016 09:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.526 X-Spam-Level: X-Spam-Status: No, score=-7.526 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.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 z_pfFhR7wjQa for ; Mon, 6 Jun 2016 09:54:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1292612D75B for ; Mon, 6 Jun 2016 09:54:49 -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 u56GrlYr023593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Jun 2016 09:53:47 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECEDDAF-5BA3-4535-92B2-F9E92146FED3" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <9a19b42c-b374-eef8-2335-619adebe81ba@gmail.com> Date: Mon, 6 Jun 2016 09:53:48 -0700 Message-Id: <4063541B-4CF0-49B4-9A54-E7A775BAE769@delong.com> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> <9a19b42c-b374-eef8-2335-619adebe81ba@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]); Mon, 06 Jun 2016 09:53:48 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 06 Jun 2016 16:54:52 -0000 --Apple-Mail=_9ECEDDAF-5BA3-4535-92B2-F9E92146FED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 6, 2016, at 07:12 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 04/06/2016 =E0 02:11, Owen DeLong a =E9crit : >>=20 >>> On Jun 3, 2016, at 11:50 , Alexandre Petrescu >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 03/06/2016 =E0 16:38, Gert Doering a =E9crit : >>>> Hi, >>>>=20 >>>> On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu >>>> wrote: >>>>> Yes, but. >>>>>=20 >>>>> A message of best-effort "beacon" semantics is sent by a device >>>>> to members of a global multicast group address. Due to >>>>> peer-to-peer absence of authority it may be hard for the device >>>>> to configure and keep a GUA, and hard to inject a GUA in the >>>>> routing system too - hence it would use its LL as src. >>>>=20 >>>> We're not talking multicast and convoluted configurations. >>>=20 >>> Ok but please dont call that convoluted. There is a strong >>> use-case for it and that's the potential solution. If you can >>> think of other solution in which a "beacon" is sent to many >>> receivers away from the subnet, and which cant configure a GUA for >>> itself, then I am interested to hear. >>=20 >> I would argue that in that case, it is better to send with source of >> :: (Unknown) than with LL. >>=20 >> It=92s ugly, it will probably get dropped, but at least the RFC=92s = don=92t >> require it to get dropped as they do with LL. >>=20 >> Frankly, I=92m trying to understand the use case for such a beacon = and >> how/why you have a device that can=92t get a global address but has >> internet connectivity and it is escaping me. Perhaps with more detail >> about the nature of the thing that is beaconing and/or the >> environment in which it operates, other solutions could be proposed. >=20 > I guess yes. >=20 > The idea is for moving objects like cars approaching to other cars or = moving together for a while. They need to signal their presence = somehow, and in some cases setting up networking first can take too much = time. If setting up networking first takes too much time, then they must be on = the same link, right? In that case, they can talk to each other within = link scope. > Currently there are WSMP messages on top of a vehicle-specific WiFi = (i.e. w/o IP) which achieve that: they broadcast their position = everybody to everybody else. It has some advantages but some = inconvenients in terms of too much noise, scalability. Not to mention the security implications since implicit in what you = describe is an almost total lack of meaningful authentication. > My idea would be to have IP Router Advertisements source with LL or :: = and delivered to an IP multicast group with any scope. RAs by definition MUST be link scoped. An RA is only valid for the given = link on which it is advertised. RAs should always be LL sourced. There is a standard multicast group for RAs to be sent to. Cars not on the same link will need to depend on some router to forward = the packets and if they=92ve received an RA from a router on their link, = then they have everything they need in order to set up an address very = quickly. I think it=92s far better for what you are describing to risk = beaconing without completing DAD if you really need the beacon to reach = another link (the need for this still escapes me in the scenario you = describe), than to send out a packet with misaligned scopes expecting it = to be routed based on the most permissive scope. In short, IMHO, a router should process a packet based on the most = restrictive scope of the {SRC,DST} address tuple. Therefore any packet = with a LL address in either field should not be forwarded off-link. ULA and GUA are both global scope addresses even though ULA has silly = semantics overloaded on top of it by likely default policies in some = routers. >>>> The packets I've seen are bog standard unicast ping or UDP 53 >>>> (DNS request) packets. >>>=20 >>> Ok, so that makes wonder what DNS client is it, and what router was >>> its first hop. >>=20 >> Every router between the source and point where the packet was >> dropped is wrong (as well as the origin host). >>=20 >> Not just the first hop, though if the first hop was right, the rest >> being wrong would be undetectable in this scenario. >=20 > Read. Not sure if this is an acknowledgement that you read what I wrote or an = instruction that I should read your reply. In either case, I have read your reply, I have rebutted it above. My = opinion on the matter is unchanged. Owen --Apple-Mail=_9ECEDDAF-5BA3-4535-92B2-F9E92146FED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 6, 2016, at 07:12 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 04/06/2016 =E0 02:11, Owen DeLong a = =E9crit :

On Jun 3, 2016, at 11:50 = , Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:



Le 03/06/2016 =E0 16:38, Gert = Doering a =E9crit :
Hi,

On Fri, Jun 03, 2016 at = 01:24:52PM +0200, Alexandre Petrescu
wrote:
Yes, but.

A message of best-effort "beacon" semantics is = sent by a device
to members of a global multicast group = address.  Due to
peer-to-peer absence of authority it = may be hard for the device
to configure and keep a GUA, = and hard to inject a GUA in the
routing system too - hence = it would use its LL as src.

We're not talking multicast and convoluted configurations.

Ok but please dont call that = convoluted.  There is a strong
use-case for it and = that's the potential solution.  If you can
think of = other solution in which a "beacon" is sent to many
receivers= away from the subnet, and which cant configure a GUA for
itself, then I am interested to hear.

I would argue that in that case, = it is better to send with source of
:: (Unknown) than with = LL.

It=92s ugly, it will probably get = dropped, but at least the RFC=92s don=92t
require it to = get dropped as they do with LL.

Frankly, = I=92m trying to understand the use case for such a beacon and
how/why you have a device that can=92t get a global address = but has
internet connectivity and it is escaping me. = Perhaps with more detail
about the nature of the thing = that is beaconing and/or the
environment in which it = operates, other solutions could be proposed.

I guess yes.

The idea is for moving objects like cars = approaching to other cars or moving together for a while.  They = need to signal their presence somehow, and in some cases setting up = networking first can take too much time.

If setting up = networking first takes too much time, then they must be on the same = link, right? In that case, they can talk to each other within link = scope.

Currently there are WSMP messages on top = of a vehicle-specific WiFi (i.e. w/o IP) which achieve that: they = broadcast their position everybody to everybody else.  It has some = advantages but some inconvenients in terms of too much noise, = scalability.

Not to mention = the security implications since implicit in what you describe is an = almost total lack of meaningful authentication.

My idea would be to have IP Router = Advertisements source with LL or :: and delivered to an IP multicast = group with any scope.

RAs by = definition MUST be link scoped. An RA is only valid for the given link = on which it is advertised.

RAs = should always be LL sourced.

There = is a standard multicast group for RAs to be sent to.

Cars not on the same link will need to depend on = some router to forward the packets and if they=92ve received an RA from = a router on their link, then they have everything they need in order to = set up an address very quickly. I think it=92s far better for what you = are describing to risk beaconing without completing DAD if you really = need the beacon to reach another link (the need for this still escapes = me in the scenario you describe), than to send out a packet with = misaligned scopes expecting it to be routed based on the most permissive = scope.

In short, IMHO, a router = should process a packet based on the most restrictive scope of the = {SRC,DST} address tuple. Therefore any packet with a LL address in = either field should not be forwarded off-link.

ULA and GUA are both global scope addresses even = though ULA has silly semantics overloaded on top of it by likely default = policies in some routers.

The packets I've seen = are bog standard unicast ping or UDP 53
(DNS request) = packets.

Ok, so that makes = wonder what DNS client is it, and what router was
its = first hop.

Every router = between the source and point where the packet was
dropped = is wrong (as well as the origin host).

Not = just the first hop, though if the first hop was right, the rest
being wrong would be undetectable in this scenario.

Read.

Not sure if this = is an acknowledgement that you read what I wrote or an instruction that = I should read your reply.

In either = case, I have read your reply, I have rebutted it above. My opinion on = the matter is unchanged.

Owen

= --Apple-Mail=_9ECEDDAF-5BA3-4535-92B2-F9E92146FED3-- From nobody Mon Jun 6 10:45: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 9243D12D1B7 for ; Mon, 6 Jun 2016 10:45:47 -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=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 RvEEw0l6EBeO for ; Mon, 6 Jun 2016 10:45:44 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4213C12D0F1 for ; Mon, 6 Jun 2016 10:45:43 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 09C3661BD2 for ; Mon, 6 Jun 2016 19:45:42 +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 9C70760143; Mon, 6 Jun 2016 19:45:41 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8B3AB32CC1; Mon, 6 Jun 2016 19:45:41 +0200 (CEST) Date: Mon, 6 Jun 2016 19:45:41 +0200 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160606174541.GF79185@Space.Net> References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <20160603202738.GL52179@Space.Net> <389689c2-9014-b09f-8bac-35b9a6973f3d@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="veXX9dWIonWZEC6h" Content-Disposition: inline In-Reply-To: <389689c2-9014-b09f-8bac-35b9a6973f3d@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] Packets with LL src and GUA dst 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, 06 Jun 2016 17:45:47 -0000 --veXX9dWIonWZEC6h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jun 06, 2016 at 04:06:44PM +0200, Alexandre Petrescu wrote: > > If you want to communicate with off-net machines and have no GUA, that > > situation *is* convoluted. Or one could say I would be surprised if > > it works at all, given that multicast routing usually relies on > > reverse-path-trees which totally break for LLA sources. >=20 > I think the reverse-path-trees are guided by the GUAs of the routers not= =20 > of the end-user consumer of the content. So yes, it should work. Don't "think". Try to understand what "reverse-path" is supposed to mean: the path where a packet destined to the source of the packet in question will be sent to. Note there is no path for LLAs. Guess what? Right. [..] > >> Ok, so that makes wonder what DNS client is it, and what router was its > >> first hop. > > > > Hard to say, since I only have a link-local address as a source... >=20 > I see. I can understand the wory. >=20 > But if there are too many of them you can set a firewall rule to block=20 > them, right? Totally missing the point. This thread happens *because* some of us use firewall rules to block stuff at our borders that is not supposed to show up there, and we found that it *does* show up. So there *is* a firewall rule, and it demonstrates misbehaviour of hosts and routers. 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 --veXX9dWIonWZEC6h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXVbbCAAoJEN9WwGXkzn/FD5kP/38xEXO8a2e+iCjPpaWY3uyw sb6YVmGpDZbNt+42nuzP8QZXLvBwBkRUn4rLlXYWHYvV1bMbbXwoN/cfoBhiVNPA /R+WqWrbooMj7YEeSQx64RhEDYkqP0ibckp6/MBAHpBWzAMaNO1vDEC1aLDnhsrN JfJD5N2ZW3CDvnVpVHUO0mHbfIr89dB4J3zqgjFxP6zkqwhFy7jL9gbyk8HoWReG ahazDdi0bamjjLUHR5CWiz1YrlO3nFN+RWRW9QbQISO5lM03qcTsc0G7R0WoiVtD RoCN5M31L/7/BD14VvPx2vLxM7hJPvVpA5Te/X/I5+mglZyAZmkGKbzwbOcGuAeC Tpbz/eCWBlzg51LzmfB3bplhkP2pa0lIi6vO9enxNWtFfFNJeBta4CxxbXvdoj25 zt1+Gpr4e3sBNLRPJHepE1LfIzOT6cIGz6lL7c2gEZB+4OnUvKFmwnXxJcMaWh7q J3RApeGQqIsg6BKJ93u2vDgzdqK/PI0r3joR3VHeefrEaR0IL4txpjmraVEw793A rEVd4HN2b6i41sxyNh4f3CVHykoYwW479FagZpBvXa1vUWEeEJ+Z+o8WprK+tfZo em4DxKz3umRLngPbOpF/difS1yy+vIM/BgKee4h8b/t99m3x4iF9uNnjZjfQP4nM t2KuRNrlTodh3x56mgbk =NPzB -----END PGP SIGNATURE----- --veXX9dWIonWZEC6h-- From nobody Tue Jun 7 09:24: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 5F4B912D7B1 for ; Tue, 7 Jun 2016 09:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.936 X-Spam-Level: X-Spam-Status: No, score=-115.936 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, T_FILL_THIS_FORM_SHORT=0.01, 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 5GEy7TA8ST2B for ; Tue, 7 Jun 2016 09:24:21 -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 367AB12D095 for ; Tue, 7 Jun 2016 09:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14135; q=dns/txt; s=iport; t=1465316661; x=1466526261; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RvccUl5q2iLjyOt5ziYJ5tehcwc2JXkxMqjC656fOUo=; b=Jpko6F4Mv5m2rqGq35eXAixQzQKJOCxPGtoMxsa/iG4wKJckj9haQ+rb /4spXfpu31XrVyJroxl8DGG5KZhzLqXj6qaWdjve+DBU2Opk7QGjzrWpN EGZFnriRrTKMee0rAaYSSTp7ONx9/JjYTDwdf7Dj5+GPFZr7kvnwJ61BO A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAgD79FZX/5pdJa1MEYM+Vn0GtWeEf?= =?us-ascii?q?oF5FwEKhSdKAoE+OBQBAQEBAQEBZRwLhEUBAQEEAQEBGksGGwIBGQMBAigHJws?= =?us-ascii?q?UBwIIAgQTDgaIGw6wQwKJHoJ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBDgkFiB4Ig?= =?us-ascii?q?UuBA4E5AYJYEQE8FoJ2gi4FiAWFYYVShRMBgy2BaW2II4FqhFKIZI9eAR42ghS?= =?us-ascii?q?BWm6IWjZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,434,1459814400"; d="asc'?scan'208,217";a="115362048" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 16:24:19 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u57GOJ0L032586 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jun 2016 16:24:20 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 11:24: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.1104.009; Tue, 7 Jun 2016 11:24:19 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: NomCom 2016-2017 Second Call for Volunteers Thread-Index: AQHRwMmezDPPlpCBZEqRB0wEKKw1w5/ehFIA Date: Tue, 7 Jun 2016 16:24:19 +0000 Message-ID: <57481D34-FD38-4377-BD84-9DE333A54B6A@cisco.com> References: <20160607143317.13664.96093.idtracker@ietfa.amsl.com> In-Reply-To: <20160607143317.13664.96093.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=_63E83BF9-E0B0-4B8B-AD46-3C774D278486"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: NomCom 2016-2017 Second Call for Volunteers 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, 07 Jun 2016 16:24:23 -0000 --Apple-Mail=_63E83BF9-E0B0-4B8B-AD46-3C774D278486 Content-Type: multipart/alternative; boundary="Apple-Mail=_E9E69D3E-948B-4EA2-8636-A29F77424A94" --Apple-Mail=_E9E69D3E-948B-4EA2-8636-A29F77424A94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ---------- Forwarded message ---------- From: NomCom Chair 2016 > Date: Tue, Jun 7, 2016 at 10:33 AM Subject: NomCom 2016-2017 Second Call for Volunteers To: IETF Announcement List > Subject: NomCom 2016-2017 Second Call for Volunteers The IETF nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in RFC 7437, that means three out of the five past meetings up to the = time this email announcement goes out to start the solicitation of = volunteers. The five meetings out of which you must have attended *three* are: IETF =3D 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as = a candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, = are IAOC: Lou Berger IAB: Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs = and the General area has 1; all other areas have 2 ADs. Thus, all areas = (with the exception of GEN) have at least one continuing AD. Current members tagged with a * have indicated that they will not accept another = nomination to serve in their current role. The primary activity for this nomcom will begin in July 2016 and should = be completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to = candidates. While being a nomcom member does require some time commitment it is also = a very rewarding experience. As a member of the nomcom it is very important that you be able to = attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful = for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, = as follows: To: nomcom-chair-2016@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days = stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject = line. If you are not yet sure if you would like to volunteer, please consider = that nomcom members play a very important role in shaping the leadership of = the IETF. Questions by email or voice are welcome. Volunteering for the = nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ = I will be publishing details of the randomness seeds to be used for the RFC 3797 selection process within the next few weeks. Thank you! Lucy Lynch llynch@civil-tongue.net nomcom-chair-2016@ietf.org _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail=_E9E69D3E-948B-4EA2-8636-A29F77424A94 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

---------- Forwarded message ----------
From: NomCom Chair 2016 <nomcom-chair-2016@ietf.org>
Date: Tue, Jun 7, 2016 at 10:33 AM
Subject: NomCom 2016-2017 Second Call for Volunteers
To: IETF Announcement List <ietf-announce@ietf.org>


Subject: NomCom 2016-2017 Second Call for Volunteers

The IETF nomcom appoints individuals to fill the open slots on the IAOC,
the IAB, and the IESG.

Ten voting members for the nomcom are selected in a verifiably random way
from a pool of volunteers. The more volunteers, the better chance we have of
choosing a random yet representative cross section of the IETF population.

The details of the operation of the nomcom can be found in RFC 7437, and
BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings.  As specified
in RFC 7437, that means three out of the five past meetings up to the time
this email announcement goes out to start the solicitation of volunteers.
The five meetings out of which you must have attended *three* are:

IETF = 91 (Honolulu)      \
       92 (Dallas)         \
       93 (Prague)          -*** ANY THREE!
       94 (Yokohama)       /
       95 (Buenos Aires)  /


If you qualify, please volunteer. Before you decide to volunteer, please
remember that anyone appointed to this Nomcom will not be considered as a
candidate for any of the positions that the 2016 - 2017 Nomcom is
responsible for filling.

The list of people and posts whose terms end with the March 2017 IETF
meeting, and thus the positions for which this nomcom is responsible, are

IAOC:

    Lou Berger

IAB:

    Ralph Droms*
    Russ Housley*
    Robert Sparks
    Andrew Sullivan
    Dave Thaler
    Suzanne Woolf

IESG:

    Jari Arkko (GEN)
    Deborah Brungard (RTG)
    Ben Campbell (ART)
    Spencer Dawkins (TSV)
    Stephen Farrell (SEC)*
    Joel Jaeggli (OPS)*
    Terry Manderson (INT)
    Alvaro Retana (RTG)


All appointments are for 2 years. The ART and Routing areas have 3 ADs and
the General area has 1; all other areas have 2 ADs. Thus, all areas (with
the exception of GEN) have at least one continuing AD. Current members
tagged with a * have indicated that they will not accept another nomination
to serve in their current role.

The primary activity for this nomcom will begin in July 2016 and should be
completed in January 2017.  The nomcom will have regularly scheduled
conference calls to ensure progress. There will be activities to collect
requirements from the community, review candidate questionnaires, review
feedback from community members about candidates, and talk to candidates.

While being a nomcom member does require some time commitment it is also a
very rewarding experience.

As a member of the nomcom it is very important that you be able to attend
IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for
orientation.  Being at IETF98 is not essential.

Please volunteer by sending me an email before 23:59 UTC June 20, 2016, as
follows:

To: nomcom-chair-2016@ietf.org
Subject: Nomcom 2016-17 Volunteer

Please include the following information in the email body:

Your Full Name: __________
    // as you write it on the IETF registration form
Current Primary Affiliation:
    // Typically what goes in the Company field
    // in the IETF Registration Form
Emails: _______________
   // All email addresses used to register for the past 5 IETF meetings
   // Preferred email address first
Telephone: _______________________
    // For confirmation if selected

You should expect an email response from me within 5 business days stating
whether or not you are qualified.  If you don't receive this response,
please re-send your email with the tag "RESEND"" added to the subject line.

If you are not yet sure if you would like to volunteer, please consider that
nomcom members play a very important role in shaping the leadership of the
IETF. Questions by email or voice are welcome. Volunteering for the nomcom
is a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:

    https://datatracker.ietf.org/nomcom/2016/

I will be publishing details of the randomness seeds to be used for the
RFC 3797 selection process within the next few weeks.

Thank you!

Lucy Lynch
llynch@civil-tongue.net
nomcom-chair-2016@ietf.org


_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion
--Apple-Mail=_E9E69D3E-948B-4EA2-8636-A29F77424A94-- --Apple-Mail=_63E83BF9-E0B0-4B8B-AD46-3C774D278486 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 iQIVAwUBV1b1MkayAOS/EQ8MAQLPDxAAl/VdMNG3PQEpO9rHnarxczc6OZWx9Yk7 7IoqhJipR43vEJC6HnZ7ljrVj0AZdVrgzUQLe2BO1wd/PDdwmIesN3GNWWoeQa/H loWShEMsDRaLwU0Z+CF35tGKF/Xp6rT6OMudgEEYB4jd8hgZtQ80OCBZM82OQM1w Lnlh0egVlh/cL0driUzFgqAwTh6slydiaayWdOT/N1iWNR36Fbhx/BhZPUoniCq8 1LHq8ZP75QmQJefQMO8FHDi3N8cdRXykJ6m6FPf/IXdk4oRvAeWmIGRgvxg0B20i tTMGwNt4qi9znH0Wp3Q+Ph5aIksYJjyQeJHPL+VcYopFF6UJwjseBbmohBdiwezZ h0fYbJxCF10wsnlUyBMme5rioYxMthJTm52F/SSIdlqL/wh/QkcM2qV7OEgMpkGK 9MkEVAi2JvBifGTXyV2INng1pTFQAiRfHOkWHPEQsJxOML5v6YOovY0H2glxEJCU s7BJnfC1c2zyGsSvgjr3WgmhW3+TLCZSZPeKFT/41yYHzs544eqk69OOldL6yD77 iGEfyrvoBso10mpcRQ/DAVg+IxQS7yfZBNZW93Mka1D1/zDNSgUSR30cXx+dcZdx XGT7ETDJrDqfZXUn11wHD0Zb1JNwq0yzzzKJA/4LCFa2kmwgisUuQlflIIvGEDWP /Z7qpSeyhiQ= =3pQI -----END PGP SIGNATURE----- --Apple-Mail=_63E83BF9-E0B0-4B8B-AD46-3C774D278486-- From nobody Tue Jun 7 19:00:41 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 A2CB012D56E for ; Tue, 7 Jun 2016 19:00:40 -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 885b8p24lL-g for ; Tue, 7 Jun 2016 19:00:39 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4C012D1BB for ; Tue, 7 Jun 2016 19:00:38 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id hl6so4059146pac.2 for ; Tue, 07 Jun 2016 19:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZW7fXHulP5FFG2LeQFucv5zM7Z39Ns2B6dCydPAl6DY=; b=wVZ5HCwFJEaDFngWWyjZpgJ4kZdwCXdpKJMR/l4lthXPautTtTleQAIlkpRhKh9921 T0OcrhjiV1WPJIweZDM9rO1yIaMf69EqWFJxPIQwZ/vmjICQYD75H0qQPJzFaibG63eX o5I4POx0ow6jOc31yqsT2QCrWzuiOcuYMHgpmJRFz3txYSsmIU7QrnN584Up/0xirftf Uv+c8wT1J1V0pp3gXQ/u6Xx64hg/qqFo78l95I5GNDPV7FxG7hIZa2DzPxnnFJi1F4iM C5CntX+TxAXB8K6n+aVdnE/ZmhJUgKkcPEz93uTNUYW9p/R0vlVt+gfV3e/j+mPv4WGh 12dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZW7fXHulP5FFG2LeQFucv5zM7Z39Ns2B6dCydPAl6DY=; b=DGPEdrvgkpVEagmeqHsaHqg7yqNN8tpGmVNmmZ1jCqwbx+AGcJYqYaVraEoFOTvLwd 1f7ok1K4jCb2r9ruecC7w7lKiJa8csCjpmBMxnWxlsEL7Uyl1Zoymhf7iHghl9VBBFC2 aRYy6UV6HpEbk+j2vBsBhEUTAhFdFd2P1xnQfrr0xcC2UC3gTattjMAzzxvvqeEe4gE0 zWVWKnbrPQHJHMMN2WMmb9URuk6V/Lf6K616CEfCjVSoHzuhRAWO4iHbuziSn6Yaz32c m9kaL7Y7QBA5jZ2WEgz0EM6dq0auX1QPNxxwKqatMLW1Q8FVCtOPcx2R/tMmt/pOCAJq nArQ== X-Gm-Message-State: ALyK8tLi/EhAHgY1JhBo85hgWEqVYIU9E7/L7WkSI3JrLdhHqilogO18BJ8AsT1P1tUG7A== X-Received: by 10.66.123.69 with SMTP id ly5mr2796845pab.57.1465351238104; Tue, 07 Jun 2016 19:00:38 -0700 (PDT) Received: from ?IPv6:2406:e007:4237:1:6c58:b191:2903:daea? ([2406:e007:4237:1:6c58:b191:2903:daea]) by smtp.gmail.com with ESMTPSA id q188sm38093551pfq.66.2016.06.07.19.00.34 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 19:00:37 -0700 (PDT) References: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> To: IPv6 Operations From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> Message-ID: <5234ab3f-bbf1-4c50-7dc9-5dd2fee4ae8d@gmail.com> Date: Wed, 8 Jun 2016 14:00:38 +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: <20160608015359.2813.17962.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Fwd: I-D Action: draft-carpenter-6man-whats-global-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, 08 Jun 2016 02:00:40 -0000 FYI, discuss in 6man... -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-6man-whats-global-00.txt Date: Tue, 07 Jun 2016 18:53:59 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : What does 'global' mean in IPv6? Author : Brian Carpenter Filename : draft-carpenter-6man-whats-global-00.txt Pages : 4 Date : 2016-06-07 Abstract: The word 'global' is used in two different ways in various IPv6-related RFCs and an IANA registry. This document describes the resulting problem. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-6man-whats-global/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-carpenter-6man-whats-global-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 From nobody Wed Jun 8 03:17: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 CE6FF12D596 for ; Wed, 8 Jun 2016 03:17:19 -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 QAwRTbz3wZIi for ; Wed, 8 Jun 2016 03:17:17 -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 862DD12D54C for ; Wed, 8 Jun 2016 03:17:17 -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 u58AH5uT022131; Wed, 8 Jun 2016 12:17:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24295209538; Wed, 8 Jun 2016 12:17: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 16253209536; Wed, 8 Jun 2016 12:17:36 +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 u58AH5vX009505; Wed, 8 Jun 2016 12:17:05 +0200 To: Owen DeLong References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> From: Alexandre Petrescu Message-ID: <76e16478-f783-245c-af34-dfad8c37ea91@gmail.com> Date: Wed, 8 Jun 2016 12:17:05 +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: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 10:17:20 -0000 Le 06/06/2016 à 18:46, Owen DeLong a écrit : > >> On Jun 6, 2016, at 06:55 , Alexandre Petrescu >> > > wrote: >> >> >> >> Le 03/06/2016 à 18:35, Owen DeLong a écrit : >>> >>>> On Jun 3, 2016, at 04:24 , Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Le 03/06/2016 à 08:11, Mikael Abrahamsson a écrit : >>>>> >>>>> Hi, >>>>> >>>>> I'm getting reports of people getting packets "over the >>>>> Internet" with LL source address and GUA dst address. This >>>>> seems to be a direct violation of >>>>> https://tools.ietf.org/html/rfc4291#section-2.5.6 ? >>>> >>>> Yes, but. >>>> >>>> A message of best-effort "beacon" semantics is sent by a >>>> device to members of a global multicast group address. Due to >>>> peer-to-peer absence of authority it may be hard for the >>>> device to configure and keep a GUA, and hard to inject a GUA in >>>> the routing system too - hence it would use its LL as src. >>> >>> This is unacceptable behavior. It would be better for such a >>> device to cobble together its own ULA for this purpose than to >>> use its LL as source. >> >> But that would create a packet with src ULA and dst GUA. Would >> that be more acceptable than src LL and dst GUA? > > Much more acceptable. ULA can be routed among consenting parties. LL > can not. Noted. > > I’d still drop it at all my borders, so your packet wouldn’t see the > light of day if it tried to transit my network either way, but at > least the ULA isn’t a clear RFC violation and some people might > forward it. > >>> (And you know how much I hate ULA). >>> >>> No multicast packet with a scope greater than LINK should be >>> sourced from an LL address. >>> >>> I don’t know if the RFCs clearly state that, but I would argue >>> that if they don’t say that yet, they certainly should. >> >> I would argue they shouldn't. >> >> There should be a possibility for a device which can't configure a >> GUA or a ULA to still send packets to a group of interested >> parties. > > There’s no such thing as a device which can’t configure a ULA. I agree. But the problem is two different devices meeting and each configuring an ULA within the same prefix. Each device may make its own random ULA but there will be little chance they have the same prefix. So they couldnt communicate using these ULAs. The ULAs may be needed (rather than link-local address) because devices need to send packets through multiple IP subnets formed by these pairs of devices. On another hand, if only the LL-address was used and the dst was a multicast group with any scope (global or LL) then there would be no need to form ULAs at all. > A device which has only an LL address should, by definition, only be > able to communicate on-link and therefore should not generate a > packet with a scope greater than link. I think I could agree - it can make sense, but that is a definition that is not present in some document. >>>> I dont think there is any other IP mechanism for such a device >>>> to beacon its message across subnets, but to src==LL and >>>> dst==global-mcast. >>>> >>>> Given that, while I would agree to a common practice of >>>> same-scoped src and dst fields in same IPv6 header I would >>>> consider the exceptions too. >>> >>> Making an exception here is silly. It invites mischief and the >>> use case you describe is better handled using other mechanisms. >> >> Which ones? > > ULA, Fixing whatever is wrong with the device that it can’t get an > address, etc. Absent the authority of fixed infrastructure it can be very difficult to make mobile devices get an address. [...] >> Because we talk multiple cases: - src LL dst GUA > > This is valid so long as the packet is not forwarded by a router to > an interface other than the one on which it was received. > > Any attempt to leave the confines of the link is, in fact, an error. > >> - src LL dsr mcast-global > > This packet should not be forwarded off link. Any attempt to do so > is an error. It sounds like the forwarding operation should look at the src address in order to avoid that error - but typical forwarding operations only consider the dst, not the src of a packet. Ingress filtering is something applied by some operator networks, but it's an exception. >> - src ULA dst GUA > > There’s no real semantic difference between ULA and GUA other than > some theoretical idea that most people should (and may well) block > ULA by default at their borders. > > This is one of the reasons I really think ULA was a horrible idea > from the start. Noted. Alex > > Owen > > From nobody Wed Jun 8 03:19: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 1FB5212D549 for ; Wed, 8 Jun 2016 03:19:08 -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 eO9FHSnn1LUC for ; Wed, 8 Jun 2016 03:19:05 -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 1963A12D0F7 for ; Wed, 8 Jun 2016 03:19:04 -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 u58AIuEs023009; Wed, 8 Jun 2016 12:18:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C97EB209529; Wed, 8 Jun 2016 12:19:26 +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 B0CBA206A5A; Wed, 8 Jun 2016 12:19:26 +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 u58AItj9010970; Wed, 8 Jun 2016 12:18:55 +0200 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Owen DeLong References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> From: Alexandre Petrescu Message-ID: Date: Wed, 8 Jun 2016 12:18:55 +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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 10:19:08 -0000 Le 06/06/2016 à 17:03, 神明é”哉 a écrit : > At Fri, 3 Jun 2016 17:11:47 -0700, Owen DeLong > wrote: > >>> Ok but please dont call that convoluted. There is a strong >>> use-case for it and that's the potential solution. If you can >>> think of other solution in which a "beacon" is sent to many >>> receivers away from the subnet, and which cant configure a GUA >>> for itself, then I am interested to hear. >> >> I would argue that in that case, it is better to send with source >> of :: (Unknown) than with LL. >> >> It’s ugly, it will probably get dropped, but at least the RFC’s >> don’t require it to get dropped as they do with LL. > > (in case no one has pointed this out) I'd interpret the following > text of RFC4291 (or rfc4291bis for that matter) as "drop": > > An IPv6 packet with a source address of unspecified must never be > forwarded by an IPv6 router. I wonder why so. Is this maybe to solve a security issue? I think it is not good to set this in stone, because there can be applications taking advantage of sending packets w/o specifying their src address. Alex > > -- JINMEI, Tatuya > From nobody Wed Jun 8 03:25: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 6AE5D12D528 for ; Wed, 8 Jun 2016 03:25:44 -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 0TEV5JIzARC9 for ; Wed, 8 Jun 2016 03:25:42 -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 4BC4512D1DD for ; Wed, 8 Jun 2016 03:25:42 -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 u58APZYZ015977; Wed, 8 Jun 2016 12:25:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 913E92094CE; Wed, 8 Jun 2016 12:26:06 +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 818ED209464; Wed, 8 Jun 2016 12:26:06 +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 u58APZY5024488; Wed, 8 Jun 2016 12:25:35 +0200 To: Owen DeLong References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> <9a19b42c-b374-eef8-2335-619adebe81ba@gmail.com> <4063541B-4CF0-49B4-9A54-E7A775BAE769@delong.com> From: Alexandre Petrescu Message-ID: <39d47bd9-6ea8-8e29-506e-747125697264@gmail.com> Date: Wed, 8 Jun 2016 12:25:35 +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: <4063541B-4CF0-49B4-9A54-E7A775BAE769@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 10:25:44 -0000 Le 06/06/2016 à 18:53, Owen DeLong a écrit : > >> On Jun 6, 2016, at 07:12 , Alexandre Petrescu >> > > wrote: >> >> >> >> Le 04/06/2016 à 02:11, Owen DeLong a écrit : >>> >>>> On Jun 3, 2016, at 11:50 , Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> >>>> >>>> Le 03/06/2016 à 16:38, Gert Doering a écrit : >>>>> Hi, >>>>> >>>>> On Fri, Jun 03, 2016 at 01:24:52PM +0200, Alexandre Petrescu >>>>> wrote: >>>>>> Yes, but. >>>>>> >>>>>> A message of best-effort "beacon" semantics is sent by a >>>>>> device to members of a global multicast group address. >>>>>> Due to peer-to-peer absence of authority it may be hard for >>>>>> the device to configure and keep a GUA, and hard to inject >>>>>> a GUA in the routing system too - hence it would use its >>>>>> LL as src. >>>>> >>>>> We're not talking multicast and convoluted configurations. >>>> >>>> Ok but please dont call that convoluted. There is a strong >>>> use-case for it and that's the potential solution. If you can >>>> think of other solution in which a "beacon" is sent to many >>>> receivers away from the subnet, and which cant configure a GUA >>>> for itself, then I am interested to hear. >>> >>> I would argue that in that case, it is better to send with >>> source of :: (Unknown) than with LL. >>> >>> It’s ugly, it will probably get dropped, but at least the RFC’s >>> don’t require it to get dropped as they do with LL. >>> >>> Frankly, I’m trying to understand the use case for such a beacon >>> and how/why you have a device that can’t get a global address >>> but has internet connectivity and it is escaping me. Perhaps >>> with more detail about the nature of the thing that is beaconing >>> and/or the environment in which it operates, other solutions >>> could be proposed. >> >> I guess yes. >> >> The idea is for moving objects like cars approaching to other cars >> or moving together for a while. They need to signal their presence >> somehow, and in some cases setting up networking first can take too >> much time. > > If setting up networking first takes too much time, then they must > be on the same link, right? In that case, they can talk to each > other within link scope. Yes, pairs of cars can talk to each other easily within their respective link scopes. But sending an IP message across an entire traffic jam (w/o going to infrastructure), can be difficult if the cars dont forward. >> Currently there are WSMP messages on top of a vehicle-specific WiFi >> (i.e. w/o IP) which achieve that: they broadcast their position >> everybody to everybody else. It has some advantages but some >> inconvenients in terms of too much noise, scalability. > > Not to mention the security implications since implicit in what you > describe is an almost total lack of meaningful authentication. Yes, I agree. > >> My idea would be to have IP Router Advertisements source with LL >> or :: and delivered to an IP multicast group with any scope. > > RAs by definition MUST be link scoped. An RA is only valid for the > given link on which it is advertised. > > RAs should always be LL sourced. > > There is a standard multicast group for RAs to be sent to. > > Cars not on the same link will need to depend on some router to > forward the packets and if they’ve received an RA from a router on > their link, then they have everything they need in order to set up > an address very quickly. Sounds easy, but consider this: should a car configure an address from a received RA? Or should it advertise an RA to the other car so the _other_ car configures an address from its RA? > I think it’s far better for what you are describing to risk beaconing > without completing DAD if you really need the beacon to reach another > link (the need for this still escapes me in the scenario you > describe), than to send out a packet with misaligned scopes expecting > it to be routed based on the most permissive scope. I can agree, provided there can be a notion of 'authorized' car when two cars meet. Typically it's hard to decide which one is more authorized than the other to. With two cars arriving at an intersection there is this notion of priority, or 'give way', so we could decide which car derives an address from which prefix. But two cars following each other it's hard to say who sends the RA and who configures an address. > In short, IMHO, a router should process a packet based on the most > restrictive scope of the {SRC,DST} address tuple. Therefore any > packet with a LL address in either field should not be forwarded > off-link. Noted. > ULA and GUA are both global scope addresses even though ULA has silly > semantics overloaded on top of it by likely default policies in some > routers. Noted. >>>>> The packets I've seen are bog standard unicast ping or UDP 53 >>>>> (DNS request) packets. >>>> >>>> Ok, so that makes wonder what DNS client is it, and what >>>> router was its first hop. >>> >>> Every router between the source and point where the packet was >>> dropped is wrong (as well as the origin host). >>> >>> Not just the first hop, though if the first hop was right, the >>> rest being wrong would be undetectable in this scenario. >> >> Read. > > Not sure if this is an acknowledgement that you read what I wrote or > an instruction that I should read your reply. It's an ack: I read, past tense. Alex > > In either case, I have read your reply, I have rebutted it above. My > opinion on the matter is unchanged. > > Owen > From nobody Wed Jun 8 03:36: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 9043012B05E for ; Wed, 8 Jun 2016 03:36:25 -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 gySiqza50rfW for ; Wed, 8 Jun 2016 03:36:24 -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 0271D12D5A3 for ; Wed, 8 Jun 2016 03:36:23 -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 u58AaLHG005498; Wed, 8 Jun 2016 12:36:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 60B2F209536; Wed, 8 Jun 2016 12:36:52 +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 53E292074EF; Wed, 8 Jun 2016 12:36:52 +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 u58AaLFi026261; Wed, 8 Jun 2016 12:36:21 +0200 To: Gert Doering References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <20160603202738.GL52179@Space.Net> <389689c2-9014-b09f-8bac-35b9a6973f3d@gmail.com> <20160606174541.GF79185@Space.Net> From: Alexandre Petrescu Message-ID: <6633bb0e-3ff1-5bc3-e4b8-98d90e08eb26@gmail.com> Date: Wed, 8 Jun 2016 12:36:21 +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: <20160606174541.GF79185@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 10:36:25 -0000 Le 06/06/2016 à 19:45, Gert Doering a écrit : > Hi, > > On Mon, Jun 06, 2016 at 04:06:44PM +0200, Alexandre Petrescu wrote: >>> If you want to communicate with off-net machines and have no GUA, >>> that situation *is* convoluted. Or one could say I would be >>> surprised if it works at all, given that multicast routing >>> usually relies on reverse-path-trees which totally break for LLA >>> sources. >> >> I think the reverse-path-trees are guided by the GUAs of the >> routers not of the end-user consumer of the content. So yes, it >> should work. > > Don't "think". Try to understand what "reverse-path" is supposed to > mean: the path where a packet destined to the source of the packet > in question will be sent to. It's hard to parse: a packet is not sent to a path, but to a destination. What do you mean? I still think it's possible to have multicast trees with neighboring routers using only link-local addresses, and through different IP subnets. Neighboring routers in a multicast tree can identify each other only by their respective link-local address. The dynamic construction of a multicast tree can happen without need of GUAs or ULAs (LLs are sufficient), provided the protocol uses link-scoped advertisements containing distance vectors. (of course assuming the LL addresses are globally unique like when derived from IEEE MAC addresses, or from random numbers). Alex > Note there is no path for LLAs. > > Guess what? > > Right. > > > [..] >>>> Ok, so that makes wonder what DNS client is it, and what router >>>> was its first hop. >>> >>> Hard to say, since I only have a link-local address as a >>> source... >> >> I see. I can understand the wory. >> >> But if there are too many of them you can set a firewall rule to >> block them, right? > > Totally missing the point. This thread happens *because* some of us > use firewall rules to block stuff at our borders that is not supposed > to show up there, and we found that it *does* show up. > > So there *is* a firewall rule, and it demonstrates misbehaviour of > hosts and routers. > > Gert Doering -- NetMaster > From nobody Wed Jun 8 07:05:58 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 1DB0912D94E for ; Wed, 8 Jun 2016 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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 GjLJ-99mDK-3 for ; Wed, 8 Jun 2016 07:05:56 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AF612D8E2 for ; Wed, 8 Jun 2016 07:05:50 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BB72A8053C; Wed, 8 Jun 2016 16:05:42 +0200 (CEST) To: Erik Kline , Enno Rey References: <20160603122659.GD89557@ernw.de> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57571CED.6000404@gont.com.ar> Date: Tue, 7 Jun 2016 21:13:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 14:05:57 -0000 On 06/03/2016 04:07 PM, Erik Kline wrote: > I wonder what the distribution of the hoplimits in the receive LL > src'd packets is. If it looks like a count down from 255 that's a > protocol violation. If they look more like count down from, say, 64, > then that sounds more like a corner case bug. Why so? If anything, that'd only be a bug if the node was employing GSTM. Besides strictly speaking there's no default Hop Limit -- so 255 might be employd as the default, and hence receiving something that "was decremented from 255" could be the rule rather than the exception. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Jun 8 07:08: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 1131012D606 for ; Wed, 8 Jun 2016 07:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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 Z1pvL1se2jo5 for ; Wed, 8 Jun 2016 07:08:46 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463D312D62F for ; Wed, 8 Jun 2016 07:08:46 -0700 (PDT) Received: from [172.29.145.169] (host-94-247-8-11.venis.it [94.247.8.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A9C478024C; Wed, 8 Jun 2016 16:08:41 +0200 (CEST) To: Owen DeLong , Mikael Abrahamsson References: From: Fernando Gont Message-ID: <57571D6E.2050102@gont.com.ar> Date: Tue, 7 Jun 2016 21:15:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 14:08:48 -0000 On 06/03/2016 06:12 PM, Owen DeLong wrote: > Open bugs. > > A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. Actually, it shouldn't forward such packets no matter what. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Jun 8 09:31: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 2495B12D5B7 for ; Wed, 8 Jun 2016 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Tz0Ak5_3u-QI for ; Wed, 8 Jun 2016 09:31:20 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 D150A12D093 for ; Wed, 8 Jun 2016 09:31:19 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p22so6991009qka.2 for ; Wed, 08 Jun 2016 09:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/sgLc7Qc/NJ7/GB7ZhnsLTdOyHIlmuCLrvv6Z72y0kE=; b=GGw5kgb5fQPjbh4OBI6JFW2q7FLPzetgNYVKh/ixFVStTPuKCtAMNrG9jJCrv9yuW/ Lr1RzAXkU+rX6aL1mkQgJ+kobGjyd00sQ9tcBTPED74bJRTNJykaHTphVXd8zZvcF3y3 /fqvNA6iRx21UL3PilQXS6H4fsvSsiSrFQY1cjR4H+e2k1NcUcH3kevlJQSyJCv+2RlM Kjk2fTYmUi/CzkZz2RwbdgrL6/7EX9+98d5hi3/+f15ePy1RS4An1c+IVaBb46ES2sZH QQpUcD4kaYQ549NcKJR+lvU0vxWKleeEDXJNhP9Fo+7+dQ6jKXRuaOCfNiaMx1edys7d alIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/sgLc7Qc/NJ7/GB7ZhnsLTdOyHIlmuCLrvv6Z72y0kE=; b=EHVSwLp4BQZduUXWeyEw3ihxN79ev2O01VTd/hzNKOBsEeJJKMQly9pKD27x/RNxQD 2agunrKkcx8JTL6KzwHRuntp3KbLqSiIC2RecWX5GT8s7OxNStQDVbJNWPSQ68bQ3qZo 3kbnclILhfKGneHyLXnUBS7qBQsqdTtmpzyLdF1AC1MxuxGM8M4vSRE2axFnXi60XbvL ocUg8FUc+DTKACK25Xv+Op9AHxgz15YET9VXbkxlklKM3HpxVrFyuHIaAielbjxJPpXM phChEI2f61xOs+LyV4QTbnEJusCzegxp3lqBIFEa3ZVLjM1P5NqYX0ctUjecCmM5M4sx QhZw== X-Gm-Message-State: ALyK8tI3Dd4nD2XfImkyvjxDJjbNInvOlv+N6vAR9LNTaMgE9Y2RWxKP0oSVEEwvjyXRvyVg7x0rmtnq4n1HFw== X-Received: by 10.55.207.149 with SMTP id v21mr5732762qkl.195.1465403478952; Wed, 08 Jun 2016 09:31:18 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Wed, 8 Jun 2016 09:31:18 -0700 (PDT) In-Reply-To: References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 8 Jun 2016 09:31:18 -0700 X-Google-Sender-Auth: aI9RgAhmR7MvJevWbZ8Avc2qYYo Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 16:31:21 -0000 At Wed, 8 Jun 2016 12:18:55 +0200, Alexandre Petrescu wrote: > > An IPv6 packet with a source address of unspecified must never be > > forwarded by an IPv6 router. > > I wonder why so. Is this maybe to solve a security issue? > > I think it is not good to set this in stone, because there can be > applications taking advantage of sending packets w/o specifying their > src address. I don't remember why. It was first introduced in RFC3513, so if you want to overturn it, you might want to delve into the discussion at that time to figure out the "why" and write a new draft proposing an update on top of the understanding. -- JINMEI, Tatuya From nobody Wed Jun 8 10:12: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 A4D81127078 for ; Wed, 8 Jun 2016 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 jUp6GALmyPxD for ; Wed, 8 Jun 2016 10:12:51 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 036E4126BF7 for ; Wed, 8 Jun 2016 10:12:51 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id q32so7457538qgq.3 for ; Wed, 08 Jun 2016 10:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lVqsCfArA6z4juG5xJY20PD+n4UACOQ7rwuvRo2dJ0M=; b=uYTPLV1oEEFPcZIl01qSpVVBKLT4u/oMnlBSZxaSkckr4RWIjDnY9G2EblpuxtoVzI kzE5wZVs7uG28gR5omhT/HoYWE/vD3RTtEeBZ1gHqHK9EQ0hF8nA+dUw89yJY6xPlQGa 8IJEG2KCbu02Uc4W50Bev5bw0UjcNPK+INjEZrb23sz8JnltwPU84xcY8cjBIQtqlRhH M/pou9k3Z+Fjdli/roC536nJFklPjXl2JvjQ303SknoRQebeggtcDvVKiLbDurHnQ4bn 6L6ADqlY1V1eVAnGHrsK9tQ5hS8k5U7TowIPiUkIc3yT4VfV2DyEls4CJNveKmvUeUXW YzmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lVqsCfArA6z4juG5xJY20PD+n4UACOQ7rwuvRo2dJ0M=; b=PSFTdY8XEjiXcrD3fpUyv586WvGOR6ciRdlsEKjsZkAqgpCeGL6h7CgWcqqCZ6dwh2 RLv84SYBlIykvkxKuTC+QdD4shlp9gMmFZPPTdOlBSzeiKnyEQKaC1gC4LvI5lETnTJ6 zEbW7RtPNZUX5q9r6uV/pJNQqP/oGpAa7W7iPHY8wKJLI2x/Y9DUwr0GOikUz7NvFn5F dosA+kU/6WTPPabXc4iLA+N4YacshRCUoUVNEFgfYFA1zr/NmS3cKtkua+yAKnmrRyvC 2owRhCBdkx0LkbFkb/M7ieQqYXHvM3FmkrC5GCYbHf4eV1qJx2YMXgiXEaaPA1ysZQ+9 IGUA== X-Gm-Message-State: ALyK8tIVmJY9rxDVNhQJUoYEYxhBsVY05PAPxyz3p8dj94SRz6qWBbmL5e274aPxqBQz9lZCdBjSGDSGL9R4XQ== X-Received: by 10.140.18.244 with SMTP id 107mr5383896qgf.95.1465405970078; Wed, 08 Jun 2016 10:12:50 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Wed, 8 Jun 2016 10:12:49 -0700 (PDT) In-Reply-To: <57571D6E.2050102@gont.com.ar> References: <57571D6E.2050102@gont.com.ar> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 8 Jun 2016 10:12:49 -0700 X-Google-Sender-Auth: U_Kg24f6DwXt82FSPpBKFu3LCic Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 17:12:52 -0000 At Tue, 7 Jun 2016 21:15:58 +0200, Fernando Gont wrote: > > A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. > > Actually, it shouldn't forward such packets no matter what. Do you mean in your opinion, or per the protocol specification? If you meant the latter, it's not really correct. See, for example, the following part of Section 9 of RFC4007: [...] if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link. -- JINMEI, Tatuya From nobody Wed Jun 8 13:53: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 6B1CE12D513 for ; Wed, 8 Jun 2016 13:53:02 -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 cAWTclmsGcUk for ; Wed, 8 Jun 2016 13:53:01 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6372312D1CA for ; Wed, 8 Jun 2016 13:53:01 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id hl6so5688506pac.2 for ; Wed, 08 Jun 2016 13:53: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=bsUqUUX5b6V0ZORmnCLJg/a5k2OUOE2NOdFB4jyIm/0=; b=Kindp4KthqxbW7Z4gPk/0S5fmkuvY+d65vw4cY3DG5GqdPTeKuXKsIiD7KEEfqhprx O8VO6wSf8XBtNQPfVzEWReP9NSZDkaEk5uGZs3MZcABf7tqwomZ6orBfIeROZxqbS4aS MgRDp06Fugh37i0KDYBBOn2p9aopE8FzmB57QLliLmqCvRJqi4fr6KRAOT6j6uUGPndx o8ods0gpiurAIXdJPZ7UOjms9Swp2/oICEH47Mcj2hWwXqM9f2UXYVrEFnsPB/kHeGHQ wW1V89YaeEZHOaiu5abVrbAodWL0kLNRCDqNtDpt6eNxXWqLbWAU684kK+18QqPSpx88 1Lqw== 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=bsUqUUX5b6V0ZORmnCLJg/a5k2OUOE2NOdFB4jyIm/0=; b=dpywOy6HDP6Ym8THk3Tk0Bzs8tHTEhJtnn7rHna/nOIYJTmZCi/yI5kKyTRd/tsJNn 9SWtgb3e7QgYu07aXvS/i+LsvReSCjhfBaZv8yMD7RbGGtC+q5Z/POvO5/DXOIwi/JHn 51r9keJFcdDHW/+FQ03WA2BxQLD31rrndZ4W52vPyNSH9HtruQQG23pyqvVepOz4/OkY fMQ+6W0odez+c6YUyOjd8IxyzY6yalTx0JGl01lLGpzwQXYUbFbq0ZEmP5lynj098E/K Vs9uOjWY+LW5w2p/2KTbPgGBPEgHvC6QWt6zVc0jU3HhgtoFBIJV8WAUTNsJG24BDPbJ ujeA== X-Gm-Message-State: ALyK8tKh3b/v/Dg7tpxWJ0V3ofStmswhRIfg0od9PBjHXQxn7N6eURAVkz8OJ8r4TDFXsA== X-Received: by 10.66.248.133 with SMTP id ym5mr7779604pac.46.1465419180856; Wed, 08 Jun 2016 13:53:00 -0700 (PDT) Received: from [192.168.178.22] ([118.148.75.18]) by smtp.gmail.com with ESMTPSA id f27sm4521508pff.17.2016.06.08.13.52.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 13:53:00 -0700 (PDT) To: Fernando Gont , Owen DeLong , Mikael Abrahamsson References: <57571D6E.2050102@gont.com.ar> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 9 Jun 2016 08:53:04 +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: <57571D6E.2050102@gont.com.ar> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 20:53:02 -0000 On 08/06/2016 07:15, Fernando Gont wrote: > On 06/03/2016 06:12 PM, Owen DeLong wrote: >> Open bugs. >> >> A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. > > Actually, it shouldn't forward such packets no matter what. Surely there could be NBMA links where a router needs to forward LL packets among neighbors? Brian From nobody Wed Jun 8 16:00: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 0496B12D7F8 for ; Wed, 8 Jun 2016 16:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pVDrBn4pgt8i for ; Wed, 8 Jun 2016 16:00:27 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 BB36712D0FF for ; Wed, 8 Jun 2016 16:00:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u58N0cQ0028399; Wed, 8 Jun 2016 16:00:38 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u58N0Y8S028382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 16:00:34 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Jun 2016 16:00:22 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Wed, 8 Jun 2016 16:00:22 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Fernando Gont , Owen DeLong , Mikael Abrahamsson Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXA Date: Wed, 8 Jun 2016 23:00:22 +0000 Message-ID: References: <57571D6E.2050102@gont.com.ar> In-Reply-To: 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: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 08 Jun 2016 23:00:29 -0000 Hi Brian, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Wednesday, June 08, 2016 1:53 PM > To: Fernando Gont ; Owen DeLong ; = Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Packets with LL src and GUA dst >=20 > On 08/06/2016 07:15, Fernando Gont wrote: > > On 06/03/2016 06:12 PM, Owen DeLong wrote: > >> Open bugs. > >> > >> A device should not forward a packet with LL source or destination add= ress to any port other than the port on which it arrived. > > > > Actually, it shouldn't forward such packets no matter what. >=20 > Surely there could be NBMA links where a router needs to forward LL > packets among neighbors? Yes, that happens on AERO links. But, the hop-limit is not decremented. Thanks - Fred fred.l.templin@boeing.com > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jun 8 17:44: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 02B6212D65E for ; Wed, 8 Jun 2016 17:44:05 -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 ZR-aVn11yZoP for ; Wed, 8 Jun 2016 17:44:03 -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 4B8E712D0F3 for ; Wed, 8 Jun 2016 17:44:03 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id g67so34611430vkb.3 for ; Wed, 08 Jun 2016 17:44:03 -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=ipL6aVFiAo9RjBYa0S37dJmZtwfbQ9fQJXSdvjB3iwo=; b=olctTZslLPNsHMgbn++eK1rPMJE92WXd76gaSLx0cs7MtWzFO4OXafB1cZ9Q5+m1CF 7IY714OjAff8hffgft0jPzRgonVZ+u2dv87E5wRxTwbj7hrNG8LOwP3JtSqBJiJkwhcm Ui+mtw/xMgiLiYaMyhgy20NQMPKFSflXeRXBb2qx6qulaLpig5sTT5eyH8Jzh0Eh9T2v XG1eyLO4yW2Dk66WN2zt0+xBCqYV0T7ynJoUJixwh4+L1xYpxgttNB9fK7Gx/BNdq7eM D9hBwzC8RRBb9qNARrf3Ivvj8gcA5bumgKzITUOMoOdiLNq7V8+akNFutg4ecp4uuo4u oRNw== 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=ipL6aVFiAo9RjBYa0S37dJmZtwfbQ9fQJXSdvjB3iwo=; b=a6mw7E+a2NE/thpKBbtuYuJmPse05cnEg3maMWed5EUXx1dQ8Yr+GhXiP0qI0038YI R5JHWwaAd+00iM2+KOZSajIB8RPaTPk+syEbeH3VFGEO/zp57wkGBbpAQP+9q9qoctiB /FHxl+3QhEF19TNCOt1IIFeq3Wg3mk2rKFfimuedhPu/Ljiy53PjXRNWMqcLkXUShEoh 5LYOtZ60ES3a9tFdkQcIqoyChCu3l+lwiinNg/aVWMv43Ay1RNBeruto9zm/7CXoEO4y U2oZL+ytRyi3RU4WpKI7qHlbtN+JLg/vNGg3GCYJ9KemlCw+yzMe01+IPK9raDt5LSHR TLQg== X-Gm-Message-State: ALyK8tJySvlG/0hlFVZG7C3b8r7q6wjvtVKfLyd/FJ85nKe9KNFnpk3nK9CBg4shtvtexEGPoizknRlDWT50MQ== X-Received: by 10.31.136.194 with SMTP id k185mr3569419vkd.2.1465433042433; Wed, 08 Jun 2016 17:44:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.54 with HTTP; Wed, 8 Jun 2016 17:43:32 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> From: Mark Smith Date: Thu, 9 Jun 2016 10:43:32 +1000 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 00:44:05 -0000 On 9 June 2016 at 09:00, Templin, Fred L wrote: > Hi Brian, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Wednesday, June 08, 2016 1:53 PM >> To: Fernando Gont ; Owen DeLong ; Mikael Abrahamsson >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Packets with LL src and GUA dst >> >> On 08/06/2016 07:15, Fernando Gont wrote: >> > On 06/03/2016 06:12 PM, Owen DeLong wrote: >> >> Open bugs. >> >> >> >> A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. >> > >> > Actually, it shouldn't forward such packets no matter what. >> >> Surely there could be NBMA links where a router needs to forward LL >> packets among neighbors? > > Yes, that happens on AERO links. But, the hop-limit is not decremented. > RFC4007, "Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link." I'd expect the hop-limit to be decremented. I'm pretty sure that the ND packets which start with HL of 255, and would be dropped if the HL doesn't arrive as 255, would not be impacted because they're specifically not to be forwarded, even back onto the same link. (The above is what would allow "Indicating Link-Local Unicast Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) to work.) Regards, Mark. > Thanks - Fred > fred.l.templin@boeing.com > >> Brian >> >> _______________________________________________ >> 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 Jun 9 00:25: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 A9BF012D09B for ; Thu, 9 Jun 2016 00:25:21 -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 bbpn_s1aLk70 for ; Thu, 9 Jun 2016 00:25:12 -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 A015812D0DF for ; Thu, 9 Jun 2016 00:25:11 -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 u597P9SP011040 for ; Thu, 9 Jun 2016 09:25:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5FCC22021AB for ; Thu, 9 Jun 2016 09:25:41 +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 4D82D2007FF for ; Thu, 9 Jun 2016 09:25:41 +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 u597P94D001673 for ; Thu, 9 Jun 2016 09:25:09 +0200 To: v6ops@ietf.org References: <57571D6E.2050102@gont.com.ar> From: Alexandre Petrescu Message-ID: <227a8aec-8322-447b-a8a3-bd69b350bb0c@gmail.com> Date: Thu, 9 Jun 2016 09:25:08 +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: <57571D6E.2050102@gont.com.ar> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 07:25:22 -0000 Le 07/06/2016 à 21:15, Fernando Gont a écrit : > On 06/03/2016 06:12 PM, Owen DeLong wrote: >> Open bugs. >> >> A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. > > Actually, it shouldn't forward such packets no matter what. I dont know how would that be implemented other than by looking at the src address. Alex > > From nobody Thu Jun 9 00:27: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 BA31712D197 for ; Thu, 9 Jun 2016 00:27:02 -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 CqsplYjCnmce for ; Thu, 9 Jun 2016 00:27:00 -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 8FCAB12D09B for ; Thu, 9 Jun 2016 00:27:00 -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 u597QsgM011132; Thu, 9 Jun 2016 09:26:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A0A6209873; Thu, 9 Jun 2016 09:27:26 +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 11B0B200DFD; Thu, 9 Jun 2016 09:27:26 +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 u597Qrv2003776; Thu, 9 Jun 2016 09:26:53 +0200 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> From: Alexandre Petrescu Message-ID: <115ed18d-40fd-e24b-be33-39ed735c2444@gmail.com> Date: Thu, 9 Jun 2016 09:26:53 +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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 07:27:03 -0000 Le 08/06/2016 à 18:31, 神明é”哉 a écrit : > At Wed, 8 Jun 2016 12:18:55 +0200, > Alexandre Petrescu wrote: > >>> An IPv6 packet with a source address of unspecified must never be >>> forwarded by an IPv6 router. >> >> I wonder why so. Is this maybe to solve a security issue? >> >> I think it is not good to set this in stone, because there can be >> applications taking advantage of sending packets w/o specifying their >> src address. > > I don't remember why. It was first introduced in RFC3513, so if you > want to overturn it, you might want to delve into the discussion at > that time to figure out the "why" and write a new draft proposing an > update on top of the understanding. Tatuya, Thanks for the suggestion. I did not know RFC 3513 was the place where this was first specified. I will think about writing a draft. Alex > > -- > JINMEI, Tatuya > From nobody Thu Jun 9 01:19: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 B65B712D518 for ; Thu, 9 Jun 2016 01:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qN8GTe_nlB-u for ; Thu, 9 Jun 2016 01:19:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AC07312D1E4 for ; Thu, 9 Jun 2016 01:19:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bAvBC-0000FVC; Thu, 9 Jun 2016 10:19:06 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <13046bf1-9404-74b4-ca5b-d8ecd3964dd4@gmail.com> <20160603143802.GG52179@Space.Net> <63d5f848-9ff7-6764-f6ac-7871b99bc4d8@gmail.com> <54055F7B-B4D7-4659-BDC2-25EACEAC471A@delong.com> In-reply-to: Your message of "Wed, 8 Jun 2016 09:31:18 -0700 ." Date: Thu, 09 Jun 2016 10:19:05 +0200 Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 08:19:11 -0000 >> I think it is not good to set this in stone, because there can be >> applications taking advantage of sending packets w/o specifying their >> src address. > >I don't remember why. It was first introduced in RFC3513, so if you >want to overturn it, you might want to delve into the discussion at >that time to figure out the "why" and write a new draft proposing an >update on top of the understanding. I wonder how (forwarding of packets with LL or unspecified source across admin boundaries) would interact with BCP38. An exception for packet-to-big error ICMPs is easy enough to specify, but may be very costly to enforce at a border routers. From nobody Thu Jun 9 07:46: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 F211B12D7F5 for ; Thu, 9 Jun 2016 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4BM0fqWtEbSN for ; Thu, 9 Jun 2016 07:45:58 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 6176012D61B for ; Thu, 9 Jun 2016 07:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u59Ek9QM003865; Thu, 9 Jun 2016 07:46:09 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u59Ek1vJ003635 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 07:46:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Jun 2016 07:45:48 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 9 Jun 2016 07:45:48 -0700 From: "Templin, Fred L" To: Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4A== Date: Thu, 9 Jun 2016 14:45:48 +0000 Message-ID: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> In-Reply-To: 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 14:46:01 -0000 SGkgTWFyaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBK dW5lIDA4LCAyMDE2IDU6NDQgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4NCj4gQ2M6IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb20+OyBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250LmNvbS5hcj47IE93ZW4g RGVMb25nDQo+IDxvd2VuQGRlbG9uZy5jb20+OyBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBz d20ucHAuc2U+OyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQYWNrZXRz IHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0DQo+IA0KPiBPbiA5IEp1bmUgMjAxNiBhdCAwOTowMCwg VGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPiBI aSBCcmlhbiwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBFIENhcnBlbnRlcg0KPiA+PiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMDgsIDIwMTYgMTo1MyBQ TQ0KPiA+PiBUbzogRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI+OyBPd2VuIERl TG9uZyA8b3dlbkBkZWxvbmcuY29tPjsgTWlrYWVsIEFicmFoYW1zc29uIDxzd21pa2VAc3dtLnBw LnNlPg0KPiA+PiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10g UGFja2V0cyB3aXRoIExMIHNyYyBhbmQgR1VBIGRzdA0KPiA+Pg0KPiA+PiBPbiAwOC8wNi8yMDE2 IDA3OjE1LCBGZXJuYW5kbyBHb250IHdyb3RlOg0KPiA+PiA+IE9uIDA2LzAzLzIwMTYgMDY6MTIg UE0sIE93ZW4gRGVMb25nIHdyb3RlOg0KPiA+PiA+PiBPcGVuIGJ1Z3MuDQo+ID4+ID4+DQo+ID4+ ID4+IEEgZGV2aWNlIHNob3VsZCBub3QgZm9yd2FyZCBhIHBhY2tldCB3aXRoIExMIHNvdXJjZSBv ciBkZXN0aW5hdGlvbiBhZGRyZXNzIHRvIGFueSBwb3J0IG90aGVyIHRoYW4gdGhlIHBvcnQgb24g d2hpY2ggaXQgYXJyaXZlZC4NCj4gPj4gPg0KPiA+PiA+IEFjdHVhbGx5LCBpdCBzaG91bGRuJ3Qg Zm9yd2FyZCBzdWNoIHBhY2tldHMgbm8gbWF0dGVyIHdoYXQuDQo+ID4+DQo+ID4+IFN1cmVseSB0 aGVyZSBjb3VsZCBiZSBOQk1BIGxpbmtzIHdoZXJlIGEgcm91dGVyIG5lZWRzIHRvIGZvcndhcmQg TEwNCj4gPj4gcGFja2V0cyBhbW9uZyBuZWlnaGJvcnM/DQo+ID4NCj4gPiBZZXMsIHRoYXQgaGFw cGVucyBvbiBBRVJPIGxpbmtzLiBCdXQsIHRoZSBob3AtbGltaXQgaXMgbm90IGRlY3JlbWVudGVk Lg0KPiA+DQo+IA0KPiBSRkM0MDA3LA0KPiANCj4gDQo+ICJUaHVzLCBpZiBhDQo+ICAgIHJvdXRl ciByZWNlaXZlcyBhIHBhY2tldCB3aXRoIGEgbGluay1sb2NhbCBkZXN0aW5hdGlvbiBhZGRyZXNz IHRoYXQNCj4gICAgaXMgbm90IG9uZSBvZiB0aGUgcm91dGVyJ3Mgb3duIGxpbmstbG9jYWwgYWRk cmVzc2VzIG9uIHRoZSBhcnJpdmFsDQo+ICAgIGxpbmssIHRoZSByb3V0ZXIgaXMgZXhwZWN0ZWQg dG8gdHJ5IHRvIGZvcndhcmQgdGhlIHBhY2tldCB0byB0aGUNCj4gICAgZGVzdGluYXRpb24gb24g dGhhdCBsaW5rIChzdWJqZWN0IHRvIHN1Y2Nlc3NmdWwgZGV0ZXJtaW5hdGlvbiBvZiB0aGUNCj4g ICAgZGVzdGluYXRpb24ncyBsaW5rLWxheWVyIGFkZHJlc3MgdmlhIHRoZSBOZWlnaGJvciBEaXNj b3ZlcnkgcHJvdG9jb2wNCj4gICAgWzldKS4gIFRoZSBmb3J3YXJkZWQgcGFja2V0IG1heSBiZSB0 cmFuc21pdHRlZCBiYWNrIHRocm91Z2ggdGhlDQo+ICAgIGFycml2YWwgaW50ZXJmYWNlLCBvciB0 aHJvdWdoIGFueSBvdGhlciBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gdGhlDQo+ICAgIHNhbWUgbGlu ay4iDQo+IA0KPiBJJ2QgZXhwZWN0IHRoZSBob3AtbGltaXQgdG8gYmUgZGVjcmVtZW50ZWQuDQoN ClRoZSBrZXkgdGV4dCBpbiB0aGUgYWJvdmUgcGFzc2FnZXMgaXMgIm1heSBiZSB0cmFuc21pdHRl ZCBiYWNrIHRocm91Z2gNCnRoZSBhcnJpdmFsIGludGVyZmFjZSwgb3IgdGhyb3VnaCBhbnkgb3Ro ZXIgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBzYW1lDQpsaW5rIi4gVGhpcyBtZWFucyB0aGF0 IHRoZSBwYWNrZXQgd2l0aCBMTCBzb3VyY2UgYWRkcmVzcyBuZXZlciByZWFsbHkgbGVhdmUNCnRo ZSBsaW5rIHRoZXkgYXJyaXZlZCBvbi4gSW5zdGVhZCwgdGhleSBhcmUgImhhaXJwaW5uZWQiIGVp dGhlciBhdCB0aGUgSVANCm9yIHN1Yi1JUCBsYXllcnMuIFNvLCB0aGUgaG9wLWxpbWl0IHNob3Vs ZCBub3QgYmUgZGVjcmVtZW50ZWQuDQoNClRoaXMgbGVhdmVzIHRoZSBxdWVzdGlvbiBhcyB0byB3 aGF0IHRvIGRvIGFib3V0IGxvb3BzLCBzaW5jZSBhIHBhY2tldCB3aXRoDQphIG5vbi1kZWNyZW1l bnRpbmcgaG9wLWxpbWl0IGNvdWxkIHBvdGVudGlhbGx5IGxvb3AgZm9yZXZlci4gVGhlIG9ubHkN CmFuc3dlciB0aGF0IG1ha2VzIHNlbnNlIGlzIHRvIGVuZ2luZWVyIHRoZSBsaW5rIHNvIHRoYXQg bm8gbG9vcHMgd2lsbA0KZXZlciBiZSBwb3NzaWJsZSBzdWNoIGFzIGluIEFFUk8uDQoNClRoYW5r cyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBJJ20gcHJldHR5IHN1cmUg dGhhdCB0aGUgTkQgcGFja2V0cyB3aGljaCBzdGFydCB3aXRoIEhMIG9mIDI1NSwgYW5kDQo+IHdv dWxkIGJlIGRyb3BwZWQgaWYgdGhlIEhMIGRvZXNuJ3QgYXJyaXZlIGFzIDI1NSwgd291bGQgbm90 IGJlDQo+IGltcGFjdGVkIGJlY2F1c2UgdGhleSdyZSBzcGVjaWZpY2FsbHkgbm90IHRvIGJlIGZv cndhcmRlZCwgZXZlbiBiYWNrDQo+IG9udG8gdGhlIHNhbWUgbGluay4NCj4gDQo+IChUaGUgYWJv dmUgaXMgd2hhdCB3b3VsZCBhbGxvdyAiSW5kaWNhdGluZyBMaW5rLUxvY2FsIFVuaWNhc3QNCj4g RGVzdGluYXRpb25zIGFyZSBPZmYtTGluayIgKGRyYWZ0LXNtaXRoLTZtYW4tbGluay1sb2NhbHMt b2ZmLWxpbmspIHRvDQo+IHdvcmsuKQ0KPiANCj4gUmVnYXJkcywNCj4gTWFyay4NCj4gDQo+IA0K PiA+IFRoYW5rcyAtIEZyZWQNCj4gPiBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4NCj4g Pj4gICAgQnJpYW4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+IHY2b3BzQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4g Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Thu Jun 9 08:45:07 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 2D98712D127; Thu, 9 Jun 2016 08:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609154506.16858.34354.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 08:45:06 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com Subject: [v6ops] v6ops - Update to a Meeting Session Request for IETF 96 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: Thu, 09 Jun 2016 15:45:06 -0000 An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg v6ops Second Priority: softwire lmap intarea tsvarea Special Requests: --------------------------------------------------------- From nobody Thu Jun 9 08:45:40 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 0244912D127; Thu, 9 Jun 2016 08:45:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160609154538.16883.4386.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 08:45:38 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com Subject: [v6ops] v6ops - Update to a Meeting Session Request for IETF 96 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: Thu, 09 Jun 2016 15:45:38 -0000 An update to a meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: tsvwg sunset4 rtgwg pcp ospf opsec opsawg mtgvenue dnsop aqm 6man Second Priority: tsvarea intarea lmap softwire Special Requests: --------------------------------------------------------- From nobody Thu Jun 9 10:24: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 DC10512D8C4 for ; Thu, 9 Jun 2016 10:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 br5r4Pr2fkeT for ; Thu, 9 Jun 2016 10:24:45 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 7688012D8A2 for ; Thu, 9 Jun 2016 10:24:45 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id i187so24437479qkd.3 for ; Thu, 09 Jun 2016 10:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kFcRPNnC/8cuyXWdx49vgEsUWzRRmE9lg/Whv5cC4bs=; b=A1N9xMltrQ4MNCYFGLE0tEE8gT1t1PEnxgxY2bZoTSvVy4/5yoRCOHI+3AGN/lx1oA c2EL7e2tEof5TuZVasX/j/s9zqTaOh1qA7MVYB7O2Xo1bdifINi3q2jaLiUlh8J8hvlI LROZGvoMmTs5Atei+ge1fie0uO7dfvtuyP0VGEGPeRmIyyA97dKpvyDtIvakrG9xTOuI is7ayzpaDROK89YAEGdaFxYxEWvA9KqhTOiDK0xEUWqj86JlqSOnFH9TmDmjbmvgcem8 6NJag0mUJhYQVC+glkpywxRG9Lsw0wdWOZG7l7FiOlMSEgJMgC/k6wWjYj1TZW+4E6pg am5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kFcRPNnC/8cuyXWdx49vgEsUWzRRmE9lg/Whv5cC4bs=; b=YdK8ISsaWI9CIwDiXOB1XSsJIw46/QuADNHS+b0EhwF8zgp0G8LLuO7/Exuq7XY0Ke sTVpDZQbDp8327BRj4jq8HxuVebpPsyL5NzQldr4oT+iRvkUwjKrbWiCU4q10qKtkAYz jn0Y1QzMwlq8e0IlmlrF94l17KxUsJCu5cZYBpH3Mnxyc28lKG0fTvrQPy47rRRswfeE B6lmCijsPmUj31CEvu9ttNIuWQwteR4NbHhM2PyMqZyZsPnoppT8y5Eb20HmHlhfDba3 OKzntJbaH2g5nqATHIpQdMc4UdtEeLzso9aAsgyUxxroaca16fhRE1u4k2aZB/IwQgKn Oe9g== X-Gm-Message-State: ALyK8tIkX9JG7VRGgEkNUIGDPuUbA7ymdnCz1gvj2EpJtpXI8agP+10R5der00zKCy1p/YT/meaIm899Dvk3vg== X-Received: by 10.55.20.208 with SMTP id 77mr11044443qku.124.1465493084508; Thu, 09 Jun 2016 10:24:44 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Thu, 9 Jun 2016 10:24:43 -0700 (PDT) In-Reply-To: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 9 Jun 2016 10:24:43 -0700 X-Google-Sender-Auth: 9ySs64hTLAaisALFfCujwDlzF_8 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 17:24:47 -0000 At Thu, 9 Jun 2016 14:45:48 +0000, "Templin, Fred L" wrote: > > RFC4007, > > > > > > "Thus, if a > > router receives a packet with a link-local destination address that > > is not one of the router's own link-local addresses on the arrival > > link, the router is expected to try to forward the packet to the > > destination on that link (subject to successful determination of the > > destination's link-layer address via the Neighbor Discovery protocol > > [9]). The forwarded packet may be transmitted back through the > > arrival interface, or through any other interface attached to the > > same link." > > > > I'd expect the hop-limit to be decremented. > > The key text in the above passages is "may be transmitted back through > the arrival interface, or through any other interface attached to the same > link". This means that the packet with LL source address never really leave > the link they arrived on. Instead, they are "hairpinned" either at the IP > or sub-IP layers. So, the hop-limit should not be decremented. I'm pretty sure that the original intent of this text is to mean this "forwarding" to be just like other normal cases, i.e., forwarding a packet received on one interface to one link to another interface to another link. Or, just like the case where a default router is not the best path to an off-link destination and the best next hop is in the same link as the receiving link (in that case the receiving router will transmit the packet back through the arrival interface, possibly sending a neighbor discovery redirect). So I'm pretty sure that the hop-limit is assumed to be decremented. Saying "should not be decremented" based on this RFC text is most likely to be a misinterpretation. Whether such a behavior is justified for some special cases can be a different question, but that shouldn't automatically apply to the general case described in this RFC. -- JINMEI, Tatuya From nobody Thu Jun 9 11:09: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 1BECE12D176 for ; Thu, 9 Jun 2016 11:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gh_FZE2tss4R for ; Thu, 9 Jun 2016 11:09:16 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 96CD512D113 for ; Thu, 9 Jun 2016 11:09:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u59I9RhN014230; Thu, 9 Jun 2016 11:09:27 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u59I9G1V013504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 11:09:16 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Jun 2016 11:09:04 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 9 Jun 2016 11:09:04 -0700 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAAo7qA//+U0hA= Date: Thu, 9 Jun 2016 18:09:04 +0000 Message-ID: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 18:09:18 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogamlubWVpLnRhdHV5 YUBnbWFpbC5jb20gW21haWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m ID8/Pz8NCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMDksIDIwMTYgMTA6MjUgQU0NCj4gVG86IFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IE1hcmsgU21p dGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+OyB2Nm9wc0BpZXRmLm9yZzsgRmVybmFuZG8gR29u dCA8ZmVybmFuZG9AZ29udC5jb20uYXI+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFBhY2tldHMg d2l0aCBMTCBzcmMgYW5kIEdVQSBkc3QNCj4gDQo+IEF0IFRodSwgOSBKdW4gMjAxNiAxNDo0NTo0 OCArMDAwMCwNCj4gIlRlbXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ IHdyb3RlOg0KPiANCj4gPiA+IFJGQzQwMDcsDQo+ID4gPg0KPiA+ID4NCj4gPiA+ICJUaHVzLCBp ZiBhDQo+ID4gPiAgICByb3V0ZXIgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBhIGxpbmstbG9jYWwg ZGVzdGluYXRpb24gYWRkcmVzcyB0aGF0DQo+ID4gPiAgICBpcyBub3Qgb25lIG9mIHRoZSByb3V0 ZXIncyBvd24gbGluay1sb2NhbCBhZGRyZXNzZXMgb24gdGhlIGFycml2YWwNCj4gPiA+ICAgIGxp bmssIHRoZSByb3V0ZXIgaXMgZXhwZWN0ZWQgdG8gdHJ5IHRvIGZvcndhcmQgdGhlIHBhY2tldCB0 byB0aGUNCj4gPiA+ICAgIGRlc3RpbmF0aW9uIG9uIHRoYXQgbGluayAoc3ViamVjdCB0byBzdWNj ZXNzZnVsIGRldGVybWluYXRpb24gb2YgdGhlDQo+ID4gPiAgICBkZXN0aW5hdGlvbidzIGxpbmst bGF5ZXIgYWRkcmVzcyB2aWEgdGhlIE5laWdoYm9yIERpc2NvdmVyeSBwcm90b2NvbA0KPiA+ID4g ICAgWzldKS4gIFRoZSBmb3J3YXJkZWQgcGFja2V0IG1heSBiZSB0cmFuc21pdHRlZCBiYWNrIHRo cm91Z2ggdGhlDQo+ID4gPiAgICBhcnJpdmFsIGludGVyZmFjZSwgb3IgdGhyb3VnaCBhbnkgb3Ro ZXIgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZQ0KPiA+ID4gICAgc2FtZSBsaW5rLiINCj4gPiA+ DQo+ID4gPiBJJ2QgZXhwZWN0IHRoZSBob3AtbGltaXQgdG8gYmUgZGVjcmVtZW50ZWQuDQo+ID4N Cj4gPiBUaGUga2V5IHRleHQgaW4gdGhlIGFib3ZlIHBhc3NhZ2VzIGlzICJtYXkgYmUgdHJhbnNt aXR0ZWQgYmFjayB0aHJvdWdoDQo+ID4gdGhlIGFycml2YWwgaW50ZXJmYWNlLCBvciB0aHJvdWdo IGFueSBvdGhlciBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gdGhlIHNhbWUNCj4gPiBsaW5rIi4gVGhp cyBtZWFucyB0aGF0IHRoZSBwYWNrZXQgd2l0aCBMTCBzb3VyY2UgYWRkcmVzcyBuZXZlciByZWFs bHkgbGVhdmUNCj4gPiB0aGUgbGluayB0aGV5IGFycml2ZWQgb24uIEluc3RlYWQsIHRoZXkgYXJl ICJoYWlycGlubmVkIiBlaXRoZXIgYXQgdGhlIElQDQo+ID4gb3Igc3ViLUlQIGxheWVycy4gU28s IHRoZSBob3AtbGltaXQgc2hvdWxkIG5vdCBiZSBkZWNyZW1lbnRlZC4NCj4gDQo+IEknbSBwcmV0 dHkgc3VyZSB0aGF0IHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgdGhpcyB0ZXh0IGlzIHRvIG1lYW4g dGhpcw0KPiAiZm9yd2FyZGluZyIgdG8gYmUganVzdCBsaWtlIG90aGVyIG5vcm1hbCBjYXNlcywg aS5lLiwgZm9yd2FyZGluZyBhDQo+IHBhY2tldCByZWNlaXZlZCBvbiBvbmUgaW50ZXJmYWNlIHRv IG9uZSBsaW5rIHRvIGFub3RoZXIgaW50ZXJmYWNlIHRvDQo+IGFub3RoZXIgbGluay4gIE9yLCBq dXN0IGxpa2UgdGhlIGNhc2Ugd2hlcmUgYSBkZWZhdWx0IHJvdXRlciBpcyBub3QNCj4gdGhlIGJl c3QgcGF0aCB0byBhbiBvZmYtbGluayBkZXN0aW5hdGlvbiBhbmQgdGhlIGJlc3QgbmV4dCBob3Ag aXMgaW4NCj4gdGhlIHNhbWUgbGluayBhcyB0aGUgcmVjZWl2aW5nIGxpbmsgKGluIHRoYXQgY2Fz ZSB0aGUgcmVjZWl2aW5nIHJvdXRlcg0KPiB3aWxsIHRyYW5zbWl0IHRoZSBwYWNrZXQgYmFjayB0 aHJvdWdoIHRoZSBhcnJpdmFsIGludGVyZmFjZSwgcG9zc2libHkNCj4gc2VuZGluZyBhIG5laWdo Ym9yIGRpc2NvdmVyeSByZWRpcmVjdCkuICBTbyBJJ20gcHJldHR5IHN1cmUgdGhhdCB0aGUNCj4g aG9wLWxpbWl0IGlzIGFzc3VtZWQgdG8gYmUgZGVjcmVtZW50ZWQuICBTYXlpbmcgInNob3VsZCBu b3QgYmUNCj4gZGVjcmVtZW50ZWQiIGJhc2VkIG9uIHRoaXMgUkZDIHRleHQgaXMgbW9zdCBsaWtl bHkgdG8gYmUgYQ0KPiBtaXNpbnRlcnByZXRhdGlvbi4NCg0KVGhpcyBnb3Qgc3RhcnRlZCBpbiBy ZXNwb25zZSB0byBCcmlhbiBDYXJwZW50ZXIncyBzdGF0ZW1lbnQgdGhhdDoNCg0KICAiU3VyZWx5 IHRoZXJlIGNvdWxkIGJlIE5CTUEgbGlua3Mgd2hlcmUgYSByb3V0ZXIgbmVlZHMgdG8gZm9yd2Fy ZCBMTA0KICAgcGFja2V0cyBhbW9uZyBuZWlnaGJvcnM/Ig0KDQp3aGVyZSBCcmlhbiB3YXMgcmVm ZXJyaW5nIHRvIG5laWdoYm9ycyAqb24gdGhlIHNhbWUgbGluayouIEkgcmVzcG9uZGVkDQp0aGF0 IHRoYXQgaXMgZXhhY3RseSB0aGUgY2FzZSBmb3IgQUVSTy4NCg0KSXQgc2VlbXMgdG8gbWUgdGhh dCBmb3J3YXJkaW5nIExMIHBhY2tldHMgYmV0d2VlbiBuZWlnaGJvcnMgb24gdGhlDQpzYW1lIGxp bmsgaXMgYSBzdWItSVAgYWN0aXZpdHkgdGhhdCAqc2hvdWxkIG5vdCogcmVzdWx0IGluIGRlY3Jl bWVudGluZw0KdGhlIGhvcC1jb3VudC4gT24gdGhlIG90aGVyIGhhbmQsIGZvcndhcmRpbmcgcGFj a2V0cyBiZXR3ZWVuDQpub2RlcyBvbiBkaWZmZXJlbnQgbGlua3MgaXMgYW4gSVAgYWN0aXZpdHkg dGhhdCAqc2hvdWxkKiByZXN1bHQgaW4NCmRlY3JlbWVudGluZyB0aGUgaG9wIChvciBtYXliZSB0 aGVyZSBhcmUgb3RoZXIgY29uc2lkZXJhdGlvbnMNCmZvciBlbnRpdGllcyBsaWtlIE5EIFByb3h5 cykuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBXaGV0 aGVyIHN1Y2ggYSBiZWhhdmlvciBpcyBqdXN0aWZpZWQgZm9yIHNvbWUgc3BlY2lhbCBjYXNlcyBj YW4gYmUgYQ0KPiBkaWZmZXJlbnQgcXVlc3Rpb24sIGJ1dCB0aGF0IHNob3VsZG4ndCBhdXRvbWF0 aWNhbGx5IGFwcGx5IHRvIHRoZQ0KPiBnZW5lcmFsIGNhc2UgZGVzY3JpYmVkIGluIHRoaXMgUkZD Lg0KPiANCj4gLS0NCj4gSklOTUVJLCBUYXR1eWENCg0K From nobody Thu Jun 9 11:16:58 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 BFBAC12D905 for ; Thu, 9 Jun 2016 11:16:57 -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 YAlDYoag3lJw for ; Thu, 9 Jun 2016 11:16:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A0F9712D8F9 for ; Thu, 9 Jun 2016 11:16:56 -0700 (PDT) Received: from [190.88.3.210] (sub-3ip210.rev.onenet.cw [190.88.3.210]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u59IEdbM024292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Jun 2016 11:14:41 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Owen DeLong X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Thu, 9 Jun 2016 14:14:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FCC7A02-3894-4B08-89A7-44D996C5B648@delong.com> References: <57571D6E.2050102@gont.com.ar> To: Brian E Carpenter X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Thu, 09 Jun 2016 11:14:42 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 18:16:58 -0000 > On Jun 8, 2016, at 16:53, Brian E Carpenter w= rote: >=20 >> On 08/06/2016 07:15, Fernando Gont wrote: >>> On 06/03/2016 06:12 PM, Owen DeLong wrote: >>> Open bugs. >>>=20 >>> A device should not forward a packet with LL source or destination addre= ss to any port other than the port on which it arrived. >>=20 >> Actually, it shouldn't forward such packets no matter what. >=20 > Surely there could be NBMA links where a router needs to forward LL > packets among neighbors? Yes... That's why there's an exemption for "on the same link".=20 Owen >=20 > Brian From nobody Thu Jun 9 11:23: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 20AE812D526 for ; Thu, 9 Jun 2016 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lI7FVcEUrlAV for ; Thu, 9 Jun 2016 11:23:27 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 6D7D112D1BC for ; Thu, 9 Jun 2016 11:23:27 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c34so12226874qte.0 for ; Thu, 09 Jun 2016 11:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BPTrPnOvAjsk/73syS9kqbVcQOy3Tce2PBth9r0MIn0=; b=m+uWwnf4pnK1g9gCj1gX3Du0510O1BxN9g6wy+NnlGj0toLkd7UAFs1QT1LgzKWcZV VYier1dDPiZV4PicG7U6WEn9jCCq0SYrDo/rNeS3rMOE4YVdW5+jBdzLL3iuY8VB2Jcj RBkotogCatSFlnZNbFUYXkvQA8cr6LG9LxkkcWuK3n+jPQxzIYNszwZe6LoKZzO9MEhj UMt6rZmrhQKnEVvfabSkU/EpoXFJQIjbJ5peisS7kKgWWFxC4psL579j7UIDomH+Wok/ rRH2PTMjhTSWawr97NAC10J4gUkOt3inq2eCrrsDbjbFUiDkVp5ojpN6qPdxrJQxoQxa tSdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BPTrPnOvAjsk/73syS9kqbVcQOy3Tce2PBth9r0MIn0=; b=aBgHyIs+Cb8fn4Cx+qZEpepY1Ht8fRvLzyNqFtnW9A0wvdrWanUzstRDSXhIef3AYy PMFZlWRTtsggT1tIai1IEUDP6YWbEev7vhV3tB5kq6m78c4XueSqPsAZ1IJetPYX9QLH mPXsIlEAdbRPh5/lq5i+Y9PIIo0zvN1/XMoJKfMPMv+YmN/QGaFHzWekZRuLzpu2FPaZ pn8FkD9r0PxFX4SQwozQWWgcqiVs2If8EwMMxJDPW603y9kb7yPLXhT4QMkR1WtHu36O 4GzUCdLe0bHlB5Q1sznThGJ0pAHx+cndzYxzOwurQRwQcpemylZyRPYwBoAcspISQFJa w0+Q== X-Gm-Message-State: ALyK8tIkfbsiGi4j4uB8Q5K+td12RbSgDib3poivC+7uCX05EhlbYROrr9LByc5dYB+HdFQcO/Iy0lOx3ZOuHA== X-Received: by 10.200.55.219 with SMTP id e27mr11729525qtc.93.1465496606500; Thu, 09 Jun 2016 11:23:26 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Thu, 9 Jun 2016 11:23:25 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 9 Jun 2016 11:23:25 -0700 X-Google-Sender-Auth: PnbXrBmB8lS2GVJ2AtO-vKR130M Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 18:23:32 -0000 At Thu, 9 Jun 2016 18:09:04 +0000, "Templin, Fred L" wrote: > > > > "Thus, if a > > > > router receives a packet with a link-local destination address that > > > > is not one of the router's own link-local addresses on the arrival > > > > link, the router is expected to try to forward the packet to the > > > > destination on that link (subject to successful determination of the > > > > destination's link-layer address via the Neighbor Discovery protocol > > > > [9]). The forwarded packet may be transmitted back through the > > > > arrival interface, or through any other interface attached to the > > > > same link." > > > > > > > > I'd expect the hop-limit to be decremented. > > > > > > The key text in the above passages is "may be transmitted back through > > > the arrival interface, or through any other interface attached to the same > > > link". This means that the packet with LL source address never really leave > > > the link they arrived on. Instead, they are "hairpinned" either at the IP > > > or sub-IP layers. So, the hop-limit should not be decremented. [...] > This got started in response to Brian Carpenter's statement that: > > "Surely there could be NBMA links where a router needs to forward LL > packets among neighbors?" > > where Brian was referring to neighbors *on the same link*. I responded > that that is exactly the case for AERO. > > It seems to me that forwarding LL packets between neighbors on the > same link is a sub-IP activity that *should not* result in decrementing > the hop-count. On the other hand, forwarding packets between > nodes on different links is an IP activity that *should* result in > decrementing the hop (or maybe there are other considerations > for entities like ND Proxys). I don't know if there's any RFC that justifies this interpretation, but my main point is that it's not appropriate to try to justify it by referring to RFC 4007 (such as by citing the text "may be transmitted..." and interpreting it in favor of your preferred behavior). -- JINMEI, Tatuya From nobody Thu Jun 9 13:09:40 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 355C012D9B9 for ; Thu, 9 Jun 2016 13:09:39 -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 1Ldg-CM6wjEJ for ; Thu, 9 Jun 2016 13:09:37 -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 221A812D734 for ; Thu, 9 Jun 2016 13:09:36 -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 u59K9Yw6031872 for ; Thu, 9 Jun 2016 22:09:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5773C20A63D for ; Thu, 9 Jun 2016 22:10:07 +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 4D915201D62 for ; Thu, 9 Jun 2016 22:10:07 +0200 (CEST) Received: from [132.166.84.211] ([132.166.84.211]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u59K9Yp4024368 for ; Thu, 9 Jun 2016 22:09:34 +0200 To: v6ops@ietf.org References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> Date: Thu, 9 Jun 2016 22:09:32 +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=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 20:09:39 -0000 Le 09/06/2016 à 19:24, 神明é”哉 a écrit : > At Thu, 9 Jun 2016 14:45:48 +0000, > "Templin, Fred L" wrote: > >>> RFC4007, >>> >>> >>> "Thus, if a >>> router receives a packet with a link-local destination address that >>> is not one of the router's own link-local addresses on the arrival >>> link, the router is expected to try to forward the packet to the >>> destination on that link (subject to successful determination of the >>> destination's link-layer address via the Neighbor Discovery protocol >>> [9]). The forwarded packet may be transmitted back through the >>> arrival interface, or through any other interface attached to the >>> same link." >>> >>> I'd expect the hop-limit to be decremented. >> >> The key text in the above passages is "may be transmitted back through >> the arrival interface, or through any other interface attached to the same >> link". This means that the packet with LL source address never really leave >> the link they arrived on. Instead, they are "hairpinned" either at the IP >> or sub-IP layers. So, the hop-limit should not be decremented. > > I'm pretty sure that the original intent of this text is to mean this > "forwarding" to be just like other normal cases, i.e., forwarding a > packet received on one interface to one link to another interface to > another link. Or, just like the case where a default router is not > the best path to an off-link destination and the best next hop is in > the same link as the receiving link (in that case the receiving router > will transmit the packet back through the arrival interface, possibly > sending a neighbor discovery redirect). So I'm pretty sure that the > hop-limit is assumed to be decremented. Saying "should not be > decremented" based on this RFC text is most likely to be a > misinterpretation. > > Whether such a behavior is justified for some special cases can be a > different question, but that shouldn't automatically apply to the > general case described in this RFC. To clarify my position: the _general_ case is that a router forwards without looking at the source address at all. The rest are particular cases. Alex > > -- > JINMEI, Tatuya > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jun 9 13:42: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 E4B6512D9E0 for ; Thu, 9 Jun 2016 13:42:22 -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 TTJVEg0OFzuH for ; Thu, 9 Jun 2016 13:42:20 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 2D93212D9E8 for ; Thu, 9 Jun 2016 13:42:20 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id d127so71636518vkh.2 for ; Thu, 09 Jun 2016 13:42:20 -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=X/ZrOrihfV0gFDybaVKvaZ0c5GrTkewsFPqSQOpYSOY=; b=p5ije5MGFdTu00xi4Z0I0OO+ZzYvztU0JwNCOyRq5lLKj8SKY6pCS6cXYM/DfxgrHt oEBUkJV5rbm+kmGYynoXz1DKtuogDgKS3MKlKzfCpm6V1l4WcTnuI9DUDSTRbapSmGf0 rfSzJrDQzTSCq9rQHvKa9M8YucoH5qAc3wxXGJ3CQLhEXZzFcBWRhVLsskp1VDeH/tfh /XObYM9AFD53w5bjCodugQkOY1KhGyOO+ZW0D8NuitCcVeeYoDZ28SHYeSaAtRWBOc1h p6e1sqf/3YTCVIlpEgPbmWCURiWO42nPj3eG/SmocVihIPq5r+B3JbB9oLDCI/SUnnow pg9w== 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=X/ZrOrihfV0gFDybaVKvaZ0c5GrTkewsFPqSQOpYSOY=; b=h2IzYawDWzedX+rc5rgO1l++987lwn7VAtJbNGAn01aOTwIzavhgjnrkQ2gEFqV4gx c/66gloT2uFfSfCOA04o7JzuwMl19kD6RipGsdrE5lJT+wgD/LlfFnT9Pfy3qHJPp1zj MCkhw5utgjb1PtE9/PftuPAyzuwjP2D9FSLaOAwHr+b38YKaEtVr4NRyhBHNEh4SfhC1 f8IHnhcBAWle6u57JDX/oYZOdZgn4/ib2NDqQbmUe7MldEiS8SxWeCsiFmGRPZGTz/uG Y8M31Qk8uWmE/aHDwUm0BZSfzOVpATFkgLdlm4Pl2JvSJYw223PWEiwU5awFKiGTs/Yp +NcA== X-Gm-Message-State: ALyK8tLNKtjEvq3e9lG54vySCV8G9QwsWWB5ltA67JzAyseB4n2HH+oA7f5ZvTtHuoFPRukqgUkAO2Taw/l7cg== X-Received: by 10.31.8.77 with SMTP id 74mr5549239vki.150.1465504939116; Thu, 09 Jun 2016 13:42:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.54 with HTTP; Thu, 9 Jun 2016 13:41:49 -0700 (PDT) In-Reply-To: <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> From: Mark Smith Date: Fri, 10 Jun 2016 06:41:49 +1000 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 20:42:23 -0000 Hi Fred, On 10 June 2016 at 00:45, Templin, Fred L wrote: > Hi Mark, > >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Wednesday, June 08, 2016 5:44 PM >> To: Templin, Fred L >> Cc: Brian E Carpenter ; Fernando Gont ; Owen DeLong >> ; Mikael Abrahamsson ; v6ops@ietf.org >> Subject: Re: [v6ops] Packets with LL src and GUA dst >> >> On 9 June 2016 at 09:00, Templin, Fred L wrote: >> > Hi Brian, >> > >> >> -----Original Message----- >> >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >> >> Sent: Wednesday, June 08, 2016 1:53 PM >> >> To: Fernando Gont ; Owen DeLong ; Mikael Abrahamsson >> >> Cc: v6ops@ietf.org >> >> Subject: Re: [v6ops] Packets with LL src and GUA dst >> >> >> >> On 08/06/2016 07:15, Fernando Gont wrote: >> >> > On 06/03/2016 06:12 PM, Owen DeLong wrote: >> >> >> Open bugs. >> >> >> >> >> >> A device should not forward a packet with LL source or destination address to any port other than the port on which it arrived. >> >> > >> >> > Actually, it shouldn't forward such packets no matter what. >> >> >> >> Surely there could be NBMA links where a router needs to forward LL >> >> packets among neighbors? >> > >> > Yes, that happens on AERO links. But, the hop-limit is not decremented. >> > >> >> RFC4007, >> >> >> "Thus, if a >> router receives a packet with a link-local destination address that >> is not one of the router's own link-local addresses on the arrival >> link, the router is expected to try to forward the packet to the >> destination on that link (subject to successful determination of the >> destination's link-layer address via the Neighbor Discovery protocol >> [9]). The forwarded packet may be transmitted back through the >> arrival interface, or through any other interface attached to the >> same link." >> >> I'd expect the hop-limit to be decremented. > > The key text in the above passages is "may be transmitted back through > the arrival interface, or through any other interface attached to the same > link". This means that the packet with LL source address never really leave > the link they arrived on. Instead, they are "hairpinned" either at the IP > or sub-IP layers. So, the hop-limit should not be decremented. > I should have realised the place to look. RFC2460/RFC2460bis says for the Hop Limit field that it is "Decremented by 1 by each node that forwards the packet." The above RFC4007 text is from a section titled to "Forwarding", so I think the HL should be decremented per RFC2460, even when being forwarded back onto the same link. Regards, Mark. > This leaves the question as to what to do about loops, since a packet with > a non-decrementing hop-limit could potentially loop forever. The only > answer that makes sense is to engineer the link so that no loops will > ever be possible such as in AERO. > > Thanks - Fred > fred.l.templin@boeing.com > >> I'm pretty sure that the ND packets which start with HL of 255, and >> would be dropped if the HL doesn't arrive as 255, would not be >> impacted because they're specifically not to be forwarded, even back >> onto the same link. >> >> (The above is what would allow "Indicating Link-Local Unicast >> Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) to >> work.) >> >> Regards, >> Mark. >> >> >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > >> >> Brian >> >> >> >> _______________________________________________ >> >> 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 Jun 9 14:19:40 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 19CB812D0C5 for ; Thu, 9 Jun 2016 14:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BkBtE7NzilU0 for ; Thu, 9 Jun 2016 14:19:37 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 1430A12D0BD for ; Thu, 9 Jun 2016 14:19:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u59LJmm8024616; Thu, 9 Jun 2016 14:19:48 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u59LJZv2024510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 14:19:35 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Jun 2016 14:19:22 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Thu, 9 Jun 2016 14:19:22 -0700 From: "Templin, Fred L" To: Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9A= Date: Thu, 9 Jun 2016 21:19:22 +0000 Message-ID: <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 09 Jun 2016 21:19:39 -0000 SGkgTWFyaywNCg0KRXZlcnlvbmUgc2VlbXMgdG8gYmUgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIg b24gdGhpcyB0aHJlYWQsIGJ1dCB0byBhZGRyZXNzIHlvdXIgcG9pbnQ6DQoNCj4gSSBzaG91bGQg aGF2ZSByZWFsaXNlZCB0aGUgcGxhY2UgdG8gbG9vay4gUkZDMjQ2MC9SRkMyNDYwYmlzIHNheXMg Zm9yDQo+IHRoZSBIb3AgTGltaXQgZmllbGQgdGhhdCBpdCBpcyAiRGVjcmVtZW50ZWQgYnkgMSBi eSBlYWNoIG5vZGUgdGhhdA0KPiBmb3J3YXJkcyB0aGUgcGFja2V0LiINCg0KSXQgZGVwZW5kcyBv biB3aGF0IHlvdSBtZWFuIGJ5ICJmb3J3YXJkaW5nIi4gVGhlIFJGQzI0NjAgdGV4dCBpcyByZWZl cnJpbmcNCnRvIGZvcndhcmRpbmcgKmF0IHRoZSBJUCBsYXllciouIEluIHJlc3BvbnNlIHRvIEJy aWFuJ3MgcXVlc3Rpb24sIEkgYW5zd2VyZWQNCnRoYXQgQUVSTyAoYW5kIHByb2JhYmx5IG90aGVy IE5CTUEgbGluayB0eXBlcykgZm9yd2FyZCBMTCBwYWNrZXRzICphdCB0aGUNCnN1Yi1JUCBsYXll ciouIE1lYW5pbmcsIHRoZSBwYWNrZXRzIG5ldmVyIGxlYXZlIHRoZSBpbnRlcmZhY2UgdGhleSBh cmUgcmVjZWl2ZWQNCm9uIGFuZCBnZXQgaGFpcnBpbm5lZCBvdXQgdG8gdGhlIG5leHQgaG9wIHdp dGhvdXQgZXZlciBwb3BwaW5nIHVwIHRvIHRoZSBJUA0KIGxheWVyLiBJbiB0aGF0IGNhc2UsIHNp bmNlIHRoZSBJUCBsYXllciBuZXZlciBoYW5kbGVzIHRoZW0sIHRoZSBob3AtbGltaXQgaXMNCnVu Y2hhbmdlZC4gSSBzaG91bGQgaGF2ZSBsZWZ0IGl0IGF0IHRoYXQgYW5kIG5vdCB0cmllZCB0byBl eHRyYXBvbGF0ZSB0byB0aGUNCmNhc2Ugb2YgdGhlIHBhY2tldCBwb3BwaW5nIHVwIHRvIHRoZSBJ UCBsYXllciwgYnV0IHRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uDQoNCkZyZWQNCmZyZWQu bC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NCj4gU2VudDog VGh1cnNkYXksIEp1bmUgMDksIDIwMTYgMTo0MiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT47IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29t LmFyPjsgT3dlbiBEZUxvbmcNCj4gPG93ZW5AZGVsb25nLmNvbT47IE1pa2FlbCBBYnJhaGFtc3Nv biA8c3dtaWtlQHN3bS5wcC5zZT47IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZv cHNdIFBhY2tldHMgd2l0aCBMTCBzcmMgYW5kIEdVQSBkc3QNCj4gDQo+IEhpIEZyZWQsDQo+IA0K PiBPbiAxMCBKdW5lIDIwMTYgYXQgMDA6NDUsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gSGkgTWFyaywNCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNt aXRoQGdtYWlsLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA4LCAyMDE2IDU6NDQg UE0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4N Cj4gPj4gQ2M6IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ OyBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250LmNvbS5hcj47IE93ZW4gRGVMb25nDQo+ID4+ IDxvd2VuQGRlbG9uZy5jb20+OyBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+ OyB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQYWNrZXRzIHdpdGgg TEwgc3JjIGFuZCBHVUEgZHN0DQo+ID4+DQo+ID4+IE9uIDkgSnVuZSAyMDE2IGF0IDA5OjAwLCBU ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+PiA+ IEhpIEJyaWFuLA0KPiA+PiA+DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+ID4+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQo+ID4+ID4+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAw OCwgMjAxNiAxOjUzIFBNDQo+ID4+ID4+IFRvOiBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250 LmNvbS5hcj47IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20+OyBNaWthZWwgQWJyYWhhbXNz b24NCj4gPHN3bWlrZUBzd20ucHAuc2U+DQo+ID4+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+ PiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQYWNrZXRzIHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0 DQo+ID4+ID4+DQo+ID4+ID4+IE9uIDA4LzA2LzIwMTYgMDc6MTUsIEZlcm5hbmRvIEdvbnQgd3Jv dGU6DQo+ID4+ID4+ID4gT24gMDYvMDMvMjAxNiAwNjoxMiBQTSwgT3dlbiBEZUxvbmcgd3JvdGU6 DQo+ID4+ID4+ID4+IE9wZW4gYnVncy4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gQSBkZXZpY2Ug c2hvdWxkIG5vdCBmb3J3YXJkIGEgcGFja2V0IHdpdGggTEwgc291cmNlIG9yIGRlc3RpbmF0aW9u IGFkZHJlc3MgdG8gYW55IHBvcnQgb3RoZXIgdGhhbiB0aGUgcG9ydCBvbiB3aGljaCBpdA0KPiBh cnJpdmVkLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gQWN0dWFsbHksIGl0IHNob3VsZG4ndCBmb3J3 YXJkIHN1Y2ggcGFja2V0cyBubyBtYXR0ZXIgd2hhdC4NCj4gPj4gPj4NCj4gPj4gPj4gU3VyZWx5 IHRoZXJlIGNvdWxkIGJlIE5CTUEgbGlua3Mgd2hlcmUgYSByb3V0ZXIgbmVlZHMgdG8gZm9yd2Fy ZCBMTA0KPiA+PiA+PiBwYWNrZXRzIGFtb25nIG5laWdoYm9ycz8NCj4gPj4gPg0KPiA+PiA+IFll cywgdGhhdCBoYXBwZW5zIG9uIEFFUk8gbGlua3MuIEJ1dCwgdGhlIGhvcC1saW1pdCBpcyBub3Qg ZGVjcmVtZW50ZWQuDQo+ID4+ID4NCj4gPj4NCj4gPj4gUkZDNDAwNywNCj4gPj4NCj4gPj4NCj4g Pj4gIlRodXMsIGlmIGENCj4gPj4gICAgcm91dGVyIHJlY2VpdmVzIGEgcGFja2V0IHdpdGggYSBs aW5rLWxvY2FsIGRlc3RpbmF0aW9uIGFkZHJlc3MgdGhhdA0KPiA+PiAgICBpcyBub3Qgb25lIG9m IHRoZSByb3V0ZXIncyBvd24gbGluay1sb2NhbCBhZGRyZXNzZXMgb24gdGhlIGFycml2YWwNCj4g Pj4gICAgbGluaywgdGhlIHJvdXRlciBpcyBleHBlY3RlZCB0byB0cnkgdG8gZm9yd2FyZCB0aGUg cGFja2V0IHRvIHRoZQ0KPiA+PiAgICBkZXN0aW5hdGlvbiBvbiB0aGF0IGxpbmsgKHN1YmplY3Qg dG8gc3VjY2Vzc2Z1bCBkZXRlcm1pbmF0aW9uIG9mIHRoZQ0KPiA+PiAgICBkZXN0aW5hdGlvbidz IGxpbmstbGF5ZXIgYWRkcmVzcyB2aWEgdGhlIE5laWdoYm9yIERpc2NvdmVyeSBwcm90b2NvbA0K PiA+PiAgICBbOV0pLiAgVGhlIGZvcndhcmRlZCBwYWNrZXQgbWF5IGJlIHRyYW5zbWl0dGVkIGJh Y2sgdGhyb3VnaCB0aGUNCj4gPj4gICAgYXJyaXZhbCBpbnRlcmZhY2UsIG9yIHRocm91Z2ggYW55 IG90aGVyIGludGVyZmFjZSBhdHRhY2hlZCB0byB0aGUNCj4gPj4gICAgc2FtZSBsaW5rLiINCj4g Pj4NCj4gPj4gSSdkIGV4cGVjdCB0aGUgaG9wLWxpbWl0IHRvIGJlIGRlY3JlbWVudGVkLg0KPiA+ DQo+ID4gVGhlIGtleSB0ZXh0IGluIHRoZSBhYm92ZSBwYXNzYWdlcyBpcyAibWF5IGJlIHRyYW5z bWl0dGVkIGJhY2sgdGhyb3VnaA0KPiA+IHRoZSBhcnJpdmFsIGludGVyZmFjZSwgb3IgdGhyb3Vn aCBhbnkgb3RoZXIgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRoZSBzYW1lDQo+ID4gbGluayIuIFRo aXMgbWVhbnMgdGhhdCB0aGUgcGFja2V0IHdpdGggTEwgc291cmNlIGFkZHJlc3MgbmV2ZXIgcmVh bGx5IGxlYXZlDQo+ID4gdGhlIGxpbmsgdGhleSBhcnJpdmVkIG9uLiBJbnN0ZWFkLCB0aGV5IGFy ZSAiaGFpcnBpbm5lZCIgZWl0aGVyIGF0IHRoZSBJUA0KPiA+IG9yIHN1Yi1JUCBsYXllcnMuIFNv LCB0aGUgaG9wLWxpbWl0IHNob3VsZCBub3QgYmUgZGVjcmVtZW50ZWQuDQo+ID4NCj4gDQo+IEkg c2hvdWxkIGhhdmUgcmVhbGlzZWQgdGhlIHBsYWNlIHRvIGxvb2suIFJGQzI0NjAvUkZDMjQ2MGJp cyBzYXlzIGZvcg0KPiB0aGUgSG9wIExpbWl0IGZpZWxkIHRoYXQgaXQgaXMgIkRlY3JlbWVudGVk IGJ5IDEgYnkgZWFjaCBub2RlIHRoYXQNCj4gZm9yd2FyZHMgdGhlIHBhY2tldC4iDQo+IA0KPiBU aGUgYWJvdmUgUkZDNDAwNyB0ZXh0IGlzIGZyb20gYSBzZWN0aW9uIHRpdGxlZCB0byAiRm9yd2Fy ZGluZyIsIHNvIEkNCj4gdGhpbmsgdGhlIEhMIHNob3VsZCBiZSBkZWNyZW1lbnRlZCBwZXIgUkZD MjQ2MCwgZXZlbiB3aGVuIGJlaW5nDQo+IGZvcndhcmRlZCBiYWNrIG9udG8gdGhlIHNhbWUgbGlu ay4NCj4gDQo+IFJlZ2FyZHMsDQo+IE1hcmsuDQo+IA0KPiA+IFRoaXMgbGVhdmVzIHRoZSBxdWVz dGlvbiBhcyB0byB3aGF0IHRvIGRvIGFib3V0IGxvb3BzLCBzaW5jZSBhIHBhY2tldCB3aXRoDQo+ ID4gYSBub24tZGVjcmVtZW50aW5nIGhvcC1saW1pdCBjb3VsZCBwb3RlbnRpYWxseSBsb29wIGZv cmV2ZXIuIFRoZSBvbmx5DQo+ID4gYW5zd2VyIHRoYXQgbWFrZXMgc2Vuc2UgaXMgdG8gZW5naW5l ZXIgdGhlIGxpbmsgc28gdGhhdCBubyBsb29wcyB3aWxsDQo+ID4gZXZlciBiZSBwb3NzaWJsZSBz dWNoIGFzIGluIEFFUk8uDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBs aW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IEknbSBwcmV0dHkgc3VyZSB0aGF0IHRoZSBORCBwYWNr ZXRzIHdoaWNoIHN0YXJ0IHdpdGggSEwgb2YgMjU1LCBhbmQNCj4gPj4gd291bGQgYmUgZHJvcHBl ZCBpZiB0aGUgSEwgZG9lc24ndCBhcnJpdmUgYXMgMjU1LCB3b3VsZCBub3QgYmUNCj4gPj4gaW1w YWN0ZWQgYmVjYXVzZSB0aGV5J3JlIHNwZWNpZmljYWxseSBub3QgdG8gYmUgZm9yd2FyZGVkLCBl dmVuIGJhY2sNCj4gPj4gb250byB0aGUgc2FtZSBsaW5rLg0KPiA+Pg0KPiA+PiAoVGhlIGFib3Zl IGlzIHdoYXQgd291bGQgYWxsb3cgIkluZGljYXRpbmcgTGluay1Mb2NhbCBVbmljYXN0DQo+ID4+ IERlc3RpbmF0aW9ucyBhcmUgT2ZmLUxpbmsiIChkcmFmdC1zbWl0aC02bWFuLWxpbmstbG9jYWxz LW9mZi1saW5rKSB0bw0KPiA+PiB3b3JrLikNCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4gTWFy ay4NCj4gPj4NCj4gPj4NCj4gPj4gPiBUaGFua3MgLSBGcmVkDQo+ID4+ID4gZnJlZC5sLnRlbXBs aW5AYm9laW5nLmNvbQ0KPiA+PiA+DQo+ID4+ID4+ICAgIEJyaWFuDQo+ID4+ID4+DQo+ID4+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+PiA+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+ID4NCj4gPj4gPg0K PiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCg0K From nobody Thu Jun 9 18:21: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 CCCD712D88C for ; Thu, 9 Jun 2016 18:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, 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 EO9oUF3poc-E for ; Thu, 9 Jun 2016 18:21:31 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 188EE12D87F for ; Thu, 9 Jun 2016 18:21:31 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e4so78832420vkb.1 for ; Thu, 09 Jun 2016 18:21:31 -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=FELWv63GEo10XZqKU7P1QJthxrMQV3dEtlds5xCaJV8=; b=1IIHZkZmJTdaM4JU4z8ds0R5yIiKl9naeeHLXbEnlL+kmQ783YtxGjHhDsTfXJyG+n sAtvw0PAMRBN5Ucmu22DvPydfZeGA90KcN/3w7go0fmM2ZVkr1KC3pw8mUOUasuNwItF +6QtiMHUjJdgKuqZ7Dwodj3LJEHiGRNAe5UQFeqTK72bPeDQOhfvp2aWwFSk/iBYkIEb IYPEu3jXhE4SAYXSWwMA1y8p8wT4WLjHbzL/a4f+DhTFS3sfC1IwGZjRmFFJ/BPgurG9 nSuLpTNwhonFd5VS6Lx2JcJ170fcr72wjZsxFQ7rlFOnZ48iw9OBOJESiSjXWBMBWCry onCQ== 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=FELWv63GEo10XZqKU7P1QJthxrMQV3dEtlds5xCaJV8=; b=Thcfg+b64K0M120TqE5Uh67rrPOxZ8GbGMXoA7JkHBSrsCe2I6pnqxTHa/ndUHNO9X mIEFKT0WWb4WLNCFQLNvVPf+11Jz/e4GlHYH/fSbf9pkGvMBKtj3xkT76Ef/RqIunvB1 FO4403zih17AMAM6OHbIVFoanag2/AVxcalUfdg5Scy7oyzHxDbPsw/BVjfcvvZZkjZf aZf2vobidnnF7QpXMjB3OX/j6DTOqUjp/2OH1VnGF0SM96hlQlOZgdJVCh42Yw0+D0gV tj8zXpIEF/uJ8Egt/XjNXd+VSYizOPVogjJxcokn4Lyngd2jB7eYR4UAEc7nsZOluYrY BhvA== X-Gm-Message-State: ALyK8tJ+t4rU7H/+mT/TXUqOoJzRHUecZgJOsoq3ym1uuo/oRmN3wHzRa+ZOwt+u4S8aqw7BFFLvB8r2XU2RFw== MIME-Version: 1.0 X-Received: by 10.176.69.141 with SMTP id u13mr2800706uau.133.1465521690016; Thu, 09 Jun 2016 18:21:30 -0700 (PDT) Received: by 10.176.4.54 with HTTP; Thu, 9 Jun 2016 18:21:29 -0700 (PDT) Received: by 10.176.4.54 with HTTP; Thu, 9 Jun 2016 18:21:29 -0700 (PDT) In-Reply-To: <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> Date: Fri, 10 Jun 2016 11:21:29 +1000 Message-ID: From: Mark Smith To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=94eb2c0cbf7abe874e0534e25bc3 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 01:21:34 -0000 --94eb2c0cbf7abe874e0534e25bc3 Content-Type: text/plain; charset=UTF-8 On 10 Jun 2016 7:19 AM, "Templin, Fred L" wrote: > > Hi Mark, > > Everyone seems to be talking past each other on this thread, but to address your point: > > > I should have realised the place to look. RFC2460/RFC2460bis says for > > the Hop Limit field that it is "Decremented by 1 by each node that > > forwards the packet." > > It depends on what you mean by "forwarding". The RFC2460 text is referring > to forwarding *at the IP layer*. Right. People were saying that LL addressed packets should never be forwarded, and I think they were talking about layer 3 forwarding of them. I was pointing out that they can be as per-RFC4007, limited to back on to the link they came from. Regards, Mark. >In response to Brian's question, I answered > that AERO (and probably other NBMA link types) forward LL packets *at the > sub-IP layer*. Meaning, the packets never leave the interface they are received > on and get hairpinned out to the next hop without ever popping up to the IP > layer. In that case, since the IP layer never handles them, the hop-limit is > unchanged. I should have left it at that and not tried to extrapolate to the > case of the packet popping up to the IP layer, but thanks for the clarification. > > Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Mark Smith [mailto:markzzzsmith@gmail.com] > > Sent: Thursday, June 09, 2016 1:42 PM > > To: Templin, Fred L > > Cc: Brian E Carpenter ; Fernando Gont < fernando@gont.com.ar>; Owen DeLong > > ; Mikael Abrahamsson ; v6ops@ietf.org > > Subject: Re: [v6ops] Packets with LL src and GUA dst > > > > Hi Fred, > > > > On 10 June 2016 at 00:45, Templin, Fred L wrote: > > > Hi Mark, > > > > > >> -----Original Message----- > > >> From: Mark Smith [mailto:markzzzsmith@gmail.com] > > >> Sent: Wednesday, June 08, 2016 5:44 PM > > >> To: Templin, Fred L > > >> Cc: Brian E Carpenter ; Fernando Gont < fernando@gont.com.ar>; Owen DeLong > > >> ; Mikael Abrahamsson ; v6ops@ietf.org > > >> Subject: Re: [v6ops] Packets with LL src and GUA dst > > >> > > >> On 9 June 2016 at 09:00, Templin, Fred L wrote: > > >> > Hi Brian, > > >> > > > >> >> -----Original Message----- > > >> >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter > > >> >> Sent: Wednesday, June 08, 2016 1:53 PM > > >> >> To: Fernando Gont ; Owen DeLong < owen@delong.com>; Mikael Abrahamsson > > > > >> >> Cc: v6ops@ietf.org > > >> >> Subject: Re: [v6ops] Packets with LL src and GUA dst > > >> >> > > >> >> On 08/06/2016 07:15, Fernando Gont wrote: > > >> >> > On 06/03/2016 06:12 PM, Owen DeLong wrote: > > >> >> >> Open bugs. > > >> >> >> > > >> >> >> A device should not forward a packet with LL source or destination address to any port other than the port on which it > > arrived. > > >> >> > > > >> >> > Actually, it shouldn't forward such packets no matter what. > > >> >> > > >> >> Surely there could be NBMA links where a router needs to forward LL > > >> >> packets among neighbors? > > >> > > > >> > Yes, that happens on AERO links. But, the hop-limit is not decremented. > > >> > > > >> > > >> RFC4007, > > >> > > >> > > >> "Thus, if a > > >> router receives a packet with a link-local destination address that > > >> is not one of the router's own link-local addresses on the arrival > > >> link, the router is expected to try to forward the packet to the > > >> destination on that link (subject to successful determination of the > > >> destination's link-layer address via the Neighbor Discovery protocol > > >> [9]). The forwarded packet may be transmitted back through the > > >> arrival interface, or through any other interface attached to the > > >> same link." > > >> > > >> I'd expect the hop-limit to be decremented. > > > > > > The key text in the above passages is "may be transmitted back through > > > the arrival interface, or through any other interface attached to the same > > > link". This means that the packet with LL source address never really leave > > > the link they arrived on. Instead, they are "hairpinned" either at the IP > > > or sub-IP layers. So, the hop-limit should not be decremented. > > > > > > > I should have realised the place to look. RFC2460/RFC2460bis says for > > the Hop Limit field that it is "Decremented by 1 by each node that > > forwards the packet." > > > > The above RFC4007 text is from a section titled to "Forwarding", so I > > think the HL should be decremented per RFC2460, even when being > > forwarded back onto the same link. > > > > Regards, > > Mark. > > > > > This leaves the question as to what to do about loops, since a packet with > > > a non-decrementing hop-limit could potentially loop forever. The only > > > answer that makes sense is to engineer the link so that no loops will > > > ever be possible such as in AERO. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> I'm pretty sure that the ND packets which start with HL of 255, and > > >> would be dropped if the HL doesn't arrive as 255, would not be > > >> impacted because they're specifically not to be forwarded, even back > > >> onto the same link. > > >> > > >> (The above is what would allow "Indicating Link-Local Unicast > > >> Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) to > > >> work.) > > >> > > >> Regards, > > >> Mark. > > >> > > >> > > >> > Thanks - Fred > > >> > fred.l.templin@boeing.com > > >> > > > >> >> Brian > > >> >> > > >> >> _______________________________________________ > > >> >> 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 > > > > --94eb2c0cbf7abe874e0534e25bc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 10 Jun 2016 7:19 AM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>
> Hi Mark,
>
> Everyone seems to be talking past each other on this thread, but to ad= dress your point:
>
> > I should have realised the place to look. RFC2460/RFC2460bis says= for
> > the Hop Limit field that it is "Decremented by 1 by each nod= e that
> > forwards the packet."
>
> It depends on what you mean by "forwarding". The RFC2460 tex= t is referring
> to forwarding *at the IP layer*.

Right. People were saying that LL addressed packets should n= ever be forwarded, and I think they were talking about layer 3 forwarding o= f them. I was pointing out that they can be as per-RFC4007, limited to back= on to the link they came from.

Regards,
Mark.

>In response to Brian's question, I answered
> that AERO (and probably other NBMA link types) forward LL packets *at = the
> sub-IP layer*.
Meaning, the packets never leave the interface they are received
> on and get hairpinned out to the next hop without ever popping up to t= he IP
> =C2=A0layer. In that case, since the IP layer never handles them, the = hop-limit is
> unchanged. I should have left it at that and not tried to extrapolate = to the
> case of the packet popping up to the IP layer, but thanks for the clar= ification.
>
> Fred
> fred.l.templin@boeing.com=
>
> > -----Original Message-----
> > From: Mark Smith [mailto:markzzzsmith@gmail.com]
> > Sent: Thursday, June 09, 2016 1:42 PM
> > To: Templin, Fred L <Fred.L.Templin@boeing.com>
> > Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; Fernando Gont <fernando@gont.com.ar>; Owen DeLong
> > <owen@delong.com>; M= ikael Abrahamsson <swmike@swm.pp.se<= /a>>; v6ops@ietf.org
> > Subject: Re: [v6ops] Packets with LL src and GUA dst
> >
> > Hi Fred,
> >
> > On 10 June 2016 at 00:45, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> > > Hi Mark,
> > >
> > >> -----Original Message-----
> > >> From: Mark Smith [mailto:markzzzsmith@gmail.com]
> > >> Sent: Wednesday, June 08, 2016 5:44 PM
> > >> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> > >> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; Fernando Gont <fernando@gont.com.ar>; Owen DeL= ong
> > >> <owen@delong.com>; Mikael Abrahamsson <swmike@s= wm.pp.se>; v6ops@ietf.org
> > >> Subject: Re: [v6ops] Packets with LL src and GUA dst
> > >>
> > >> On 9 June 2016 at 09:00, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:<= br> > > >> > Hi Brian,
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter > > >> >> Sent: Wednesday, June 08, 2016 1:53 PM
> > >> >> To: Fernando Gont <fernando@gont.com.ar>; Owen DeLong <owen@delong.com>; Mikael Abrahamsson
> > <swmike@swm.pp.se><= br> > > >> >> Cc: v6ops@iet= f.org
> > >> >> Subject: Re: [v6ops] Packets with LL src and GU= A dst
> > >> >>
> > >> >> On 08/06/2016 07:15, Fernando Gont wrote:
> > >> >> > On 06/03/2016 06:12 PM, Owen DeLong wrote:=
> > >> >> >> Open bugs.
> > >> >> >>
> > >> >> >> A device should not forward a packet w= ith LL source or destination address to any port other than the port on whi= ch it
> > arrived.
> > >> >> >
> > >> >> > Actually, it shouldn't forward such pa= ckets no matter what.
> > >> >>
> > >> >> Surely there could be NBMA links where a router= needs to forward LL
> > >> >> packets among neighbors?
> > >> >
> > >> > Yes, that happens on AERO links. But, the hop-limit= is not decremented.
> > >> >
> > >>
> > >> RFC4007,
> > >>
> > >>
> > >> "Thus, if a
> > >>=C2=A0 =C2=A0 router receives a packet with a link-local = destination address that
> > >>=C2=A0 =C2=A0 is not one of the router's own link-loc= al addresses on the arrival
> > >>=C2=A0 =C2=A0 link, the router is expected to try to forw= ard the packet to the
> > >>=C2=A0 =C2=A0 destination on that link (subject to succes= sful determination of the
> > >>=C2=A0 =C2=A0 destination's link-layer address via th= e Neighbor Discovery protocol
> > >>=C2=A0 =C2=A0 [9]).=C2=A0 The forwarded packet may be tra= nsmitted back through the
> > >>=C2=A0 =C2=A0 arrival interface, or through any other int= erface attached to the
> > >>=C2=A0 =C2=A0 same link."
> > >>
> > >> I'd expect the hop-limit to be decremented.
> > >
> > > The key text in the above passages is "may be transmitt= ed back through
> > > the arrival interface, or through any other interface attach= ed to the same
> > > link". This means that the packet with LL source addres= s never really leave
> > > the link they arrived on. Instead, they are "hairpinned= " either at the IP
> > > or sub-IP layers. So, the hop-limit should not be decremente= d.
> > >
> >
> > I should have realised the place to look. RFC2460/RFC2460bis says= for
> > the Hop Limit field that it is "Decremented by 1 by each nod= e that
> > forwards the packet."
> >
> > The above RFC4007 text is from a section titled to "Forwardi= ng", so I
> > think the HL should be decremented per RFC2460, even when being > > forwarded back onto the same link.
> >
> > Regards,
> > Mark.
> >
> > > This leaves the question as to what to do about loops, since= a packet with
> > > a non-decrementing hop-limit could potentially loop forever.= The only
> > > answer that makes sense is to engineer the link so that no l= oops will
> > > ever be possible such as in AERO.
> > >
> > > Thanks - Fred
> > > fred.l.templin@= boeing.com
> > >
> > >> I'm pretty sure that the ND packets which start with= HL of 255, and
> > >> would be dropped if the HL doesn't arrive as 255, wo= uld not be
> > >> impacted because they're specifically not to be forw= arded, even back
> > >> onto the same link.
> > >>
> > >> (The above is what would allow "Indicating Link-Loc= al Unicast
> > >> Destinations are Off-Link" (draft-smith-6man-link-l= ocals-off-link) to
> > >> work.)
> > >>
> > >> Regards,
> > >> Mark.
> > >>
> > >>
> > >> > Thanks - Fred
> > >> > fred.l= .templin@boeing.com
> > >> >
> > >> >>=C2=A0 =C2=A0 Brian
> > >> >>
> > >> >> _______________________________________________=
> > >> >> v6ops mailing list
> > >> >> v6ops@ietf.or= g
> > >> >> https://www.ietf.org/mailman/listinfo/v6ops
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > v6ops mailing list
> > >> > v6ops@ietf.org
> > >> > https://www.ietf.org/mailman/listinfo/v6ops
> > >
>

--94eb2c0cbf7abe874e0534e25bc3-- From nobody Fri Jun 10 10:13: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 E8E7412D5FB for ; Fri, 10 Jun 2016 10:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 b_8SZ8ChoaTZ for ; Fri, 10 Jun 2016 10:13:48 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE77E12D0CB for ; Fri, 10 Jun 2016 10:13:48 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id v48so21195526qgd.2 for ; Fri, 10 Jun 2016 10:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=D/uH+5qgCKJIoIr5gesP91CoXFBT1CjoH+37I/zJFk0=; b=aZnL2nsE5CVD43yXogAeoZQrPGkiBuRSCzgNK264n+Fi+ldpGjkVXs5SMq+nebSxmF z24p9u/mvK8IHhqHkHYRcsHp8fyu3j93m0B5NNzRPQX/vEy31xjPXXAuYambksb53Nqc BfrtVb/MjwWSOW+GNz/VSgFS0rmLorjyP7QKcc+eJ3e6KKZy+PHvO+o9vXo+yFWecOxY fTuJvbXOV1uK86lP5gVGmgPcmo/eRYrZdWc/p4CHlCc8yYuvaTRk33c0fjLJf5RSAcZk esq6SrsEB+g47bQc+D3O9eUNZCoyhWkQcBrzmZd/8y4lo5Y+2siiFjeQfpjXufyaSzjc +UaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=D/uH+5qgCKJIoIr5gesP91CoXFBT1CjoH+37I/zJFk0=; b=ZVmqun+eQU5OoXz1NNIlW3haDSKWjJ0gyLE9XbbFOszzzJFk2nzCMkcASIocn2Doje Mjtl+3ReHlDTH+GrJZu9/fe+5vBXZRODMqly9m5ek4Sug/IdAl/ByiYbEPtC4pVOnaFo Ysy392c0P2YMYcDXskbssSu66UjhSoBjiYKsNcJou5MMWSFSjSrFTxzhw1f9twSxeemQ 4fJ8wERuqPkJHJagpmDSQUsUzo0hYODhS56c/fOPsC0bAi0TY7CB0oLz+MT14an8EkMV ic029nBh64ZwoCBE9btzmXEH/i08qj5/PrnzaQcIB+TuJJSfvk5U9lsRv5oLGZp3ZjDa ZgDw== X-Gm-Message-State: ALyK8tKVjCYeBIpaUjNEmsahQTvF/QovHjaPltq5G/BYjiOXQ1JhsBBb4Xj4Pn0c6k9eX7kiNlMWHyzS7yx0xg== X-Received: by 10.140.153.135 with SMTP id 129mr3028040qhz.71.1465578827814; Fri, 10 Jun 2016 10:13:47 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.45.199 with HTTP; Fri, 10 Jun 2016 10:13:46 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 10 Jun 2016 10:13:46 -0700 X-Google-Sender-Auth: dbFXUfCBC_1M_VY3N8PyIePj92w Message-ID: To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 17:13:50 -0000 At Fri, 10 Jun 2016 11:21:29 +1000, Mark Smith wrote: > > Everyone seems to be talking past each other on this thread, but to > address your point: > > > > > I should have realised the place to look. RFC2460/RFC2460bis says for > > > the Hop Limit field that it is "Decremented by 1 by each node that > > > forwards the packet." > > > > It depends on what you mean by "forwarding". The RFC2460 text is referring > > to forwarding *at the IP layer*. > > Right. People were saying that LL addressed packets should never be > forwarded, and I think they were talking about layer 3 forwarding of them. > I was pointing out that they can be as per-RFC4007, limited to back on to > the link they came from. As far as I understand it RFC4007 only talks about "layer 3 forwarding". We can freely discuss whether there's such a concept as "forwarding sub-IP layer" and/or whether the hop limit should be decremented in that case, but RFC4007 should be independent from that discussion. -- JINMEI, Tatuya From nobody Fri Jun 10 10:42: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 CDA6D12D887 for ; Fri, 10 Jun 2016 10:42:18 -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 FysL43eG3QTL for ; Fri, 10 Jun 2016 10:42:17 -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 D8D8012D142 for ; Fri, 10 Jun 2016 10:42:17 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5AHfwYB001740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 10:41:59 -0700 (PDT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Mark Smith References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <575AFBE6.1090607@isi.edu> Date: Fri, 10 Jun 2016 10:41:58 -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: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 17:42:19 -0000 On 6/10/2016 10:13 AM, 神明é”哉 wrote: > As far as I understand it RFC4007 only talks about "layer 3 > forwarding". In IETF terminology, I have always understood "forwarding" to be the more common term used only for layer-3 relaying. > We can freely discuss whether there's such a concept as > "forwarding sub-IP layer" In IETF terminology, I have always understood that to be more commonly called "switching". > and/or whether the hop limit should be > decremented in that case, but RFC4007 should be independent from that > discussion. The hop should be decremented only at the layer where relaying occurs, be that application (web proxying), transport, network, or link (where that layer has a hop count to decrement, of course). Any other decrement ends up defeating the purpose of layering, to isolate one layer's properties from another. Joe From nobody Fri Jun 10 11:42: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 4A11F12D8BF for ; Fri, 10 Jun 2016 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Ip-qT0iL8sqW for ; Fri, 10 Jun 2016 11:42:20 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 2BE6412D1C0 for ; Fri, 10 Jun 2016 11:32:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5AIWv8l016166; Fri, 10 Jun 2016 11:32:57 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5AIWsEO016148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 11:32:54 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Jun 2016 11:32:41 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 10 Jun 2016 11:32:41 -0700 From: "Templin, Fred L" To: Joe Touch , =?utf-8?B?56We5piO6YGU5ZOJ?= , Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CAAViffYAADJvg Date: Fri, 10 Jun 2016 18:32:41 +0000 Message-ID: <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> In-Reply-To: <575AFBE6.1090607@isi.edu> 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 18:42:21 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFtt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZSBUb3VjaA0KPiBT ZW50OiBGcmlkYXksIEp1bmUgMTAsIDIwMTYgMTA6NDIgQU0NCj4gVG86IOelnuaYjumBlOWTiSA8 amlubWVpQHdpZGUuYWQuanA+OyBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0K PiBDYzogdjZvcHNAaWV0Zi5vcmc7IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFy Pg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBQYWNrZXRzIHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0 DQo+IA0KPiANCj4gDQo+IE9uIDYvMTAvMjAxNiAxMDoxMyBBTSwg56We5piO6YGU5ZOJIHdyb3Rl Og0KPiA+IEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgaXQgUkZDNDAwNyBvbmx5IHRhbGtzIGFib3V0 ICJsYXllciAzDQo+ID4gZm9yd2FyZGluZyIuDQo+IEluIElFVEYgdGVybWlub2xvZ3ksIEkgaGF2 ZSBhbHdheXMgdW5kZXJzdG9vZCAiZm9yd2FyZGluZyIgdG8gYmUgdGhlDQo+IG1vcmUgY29tbW9u IHRlcm0gdXNlZCBvbmx5IGZvciBsYXllci0zIHJlbGF5aW5nLg0KPiANCj4gPiAgV2UgY2FuIGZy ZWVseSBkaXNjdXNzIHdoZXRoZXIgdGhlcmUncyBzdWNoIGEgY29uY2VwdCBhcw0KPiA+ICJmb3J3 YXJkaW5nIHN1Yi1JUCBsYXllciINCj4gDQo+IEluIElFVEYgdGVybWlub2xvZ3ksIEkgaGF2ZSBh bHdheXMgdW5kZXJzdG9vZCB0aGF0IHRvIGJlIG1vcmUgY29tbW9ubHkNCj4gY2FsbGVkICJzd2l0 Y2hpbmciLg0KDQpUaGUgdGVybSAic3dpdGNoaW5nIiBkb2VzIG5vdCBmaXQgd2VsbCB3aXRoIG15 IG9ic2VydmF0aW9ucyBvZiBob3cgc3ViLUlQDQpsYXllciBmb3J3YXJkaW5nIHdvcmtzIG9uIEFF Uk8gbGlua3MuIFRoZSBMTCBwYWNrZXQgY29tZXMgaW50byB0aGUgQUVSTw0KaW50ZXJmYWNlIGFu ZCBhIHN1Yi1JUCBsYXllciBmb3J3YXJkaW5nIHRhYmxlIGRpcmVjdHMgdGhhdCBpdCBiZSBzZW50 IG9uIHRvIGENCmRpZmZlcmVudCBuZWlnaGJvciBpbnN0ZWFkIG9mIGJlaW5nIHBhc3NlZCB1cCB0 byB0aGUgSVAgbGF5ZXIuICJTdWItSVANCmxheWVyIGZvcndhcmRpbmciIGlzIHRoZSB0ZXJtaW5v bG9neSB0aGF0IEkgdGhpbmsgYmVzdCBjb252ZXlzIHRoZSBjb25jZXB0DQphcyBJIGhhdmUgb2Jz ZXJ2ZWQgaXQuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCiAN Cj4gPiBhbmQvb3Igd2hldGhlciB0aGUgaG9wIGxpbWl0IHNob3VsZCBiZQ0KPiA+IGRlY3JlbWVu dGVkIGluIHRoYXQgY2FzZSwgYnV0IFJGQzQwMDcgc2hvdWxkIGJlIGluZGVwZW5kZW50IGZyb20g dGhhdA0KPiA+IGRpc2N1c3Npb24uDQo+IA0KPiBUaGUgaG9wIHNob3VsZCBiZSBkZWNyZW1lbnRl ZCBvbmx5IGF0IHRoZSBsYXllciB3aGVyZSByZWxheWluZyBvY2N1cnMsDQo+IGJlIHRoYXQgYXBw bGljYXRpb24gKHdlYiBwcm94eWluZyksIHRyYW5zcG9ydCwgbmV0d29yaywgb3IgbGluayAod2hl cmUNCj4gdGhhdCBsYXllciBoYXMgYSBob3AgY291bnQgdG8gZGVjcmVtZW50LCBvZiBjb3Vyc2Up Lg0KPiANCj4gQW55IG90aGVyIGRlY3JlbWVudCBlbmRzIHVwIGRlZmVhdGluZyB0aGUgcHVycG9z ZSBvZiBsYXllcmluZywgdG8NCj4gaXNvbGF0ZSBvbmUgbGF5ZXIncyBwcm9wZXJ0aWVzIGZyb20g YW5vdGhlci4NCj4gDQo+IEpvZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Fri Jun 10 11:51: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 180C212D095 for ; Fri, 10 Jun 2016 11:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OBICpiKdGCjf for ; Fri, 10 Jun 2016 11:51:31 -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 EEAE912B047 for ; Fri, 10 Jun 2016 11:51:30 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5AIoggW022326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 11:50:42 -0700 (PDT) To: "Templin, Fred L" , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= , Mark Smith References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <575B0C02.3030606@isi.edu> Date: Fri, 10 Jun 2016 11:50: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: <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u5AIoggW022326 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 18:51:32 -0000 On 6/10/2016 11:32 AM, Templin, Fred L wrote: >> In IETF terminology, I have always understood that to be more commonly >> > called "switching". > The term "switching" does not fit well with my observations of how sub-IP > layer forwarding works on AERO links. The LL packet comes into the AERO > interface and a sub-IP layer forwarding table directs that it be sent on to a > different neighbor instead of being passed up to the IP layer. "Sub-IP > layer forwarding" is the terminology that I think best conveys the concept > as I have observed it. The trouble is that we have too many terms: switching relaying forwarding All of these could generically be used to describe nearly any case. Switching just means there's a decision of multiple outputs, which may or may not occur (e.g., you can forward to different nodes on a LAN but still use only one output port to that LAN). Both relaying and forwarding refer to transiting a message. All of them can use tables to govern the decisions made. Again, my view is that *typically* when the term "forwarding" is used without additional clarification, it refers to the IP layer, and when "switching" is used it refers to the link layer. It's always best to be more specific when there are ambiguities, though. Joe From nobody Fri Jun 10 12:01:58 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 4CC9D12D856 for ; Fri, 10 Jun 2016 12:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zSQ2XBcDJiOf for ; Fri, 10 Jun 2016 12:01:54 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 BEE0012D75D for ; Fri, 10 Jun 2016 12:01:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5AJ1wwr016992; Fri, 10 Jun 2016 12:01:58 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5AJ1rgX016926 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 12:01:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Jun 2016 12:01:41 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 10 Jun 2016 12:01:41 -0700 From: "Templin, Fred L" To: Joe Touch , =?utf-8?B?56We5piO6YGU5ZOJ?= , Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CAAViffYAADJvggAB7xAD//4s0AA== Date: Fri, 10 Jun 2016 19:01:41 +0000 Message-ID: <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> <575B0C02.3030606@isi.edu> In-Reply-To: <575B0C02.3030606@isi.edu> 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 19:01:56 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAxMCwgMjAxNiAx MTo1MSBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD47IE1hcmsgU21pdGggPG1hcmt6enpz bWl0aEBnbWFpbC5jb20+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZzsgRmVybmFuZG8gR29udCA8ZmVy bmFuZG9AZ29udC5jb20uYXI+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFBhY2tldHMgd2l0aCBM TCBzcmMgYW5kIEdVQSBkc3QNCj4gDQo+IA0KPiANCj4gT24gNi8xMC8yMDE2IDExOjMyIEFNLCBU ZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4+IEluIElFVEYgdGVybWlub2xvZ3ksIEkgaGF2ZSBh bHdheXMgdW5kZXJzdG9vZCB0aGF0IHRvIGJlIG1vcmUgY29tbW9ubHkNCj4gPj4gPiBjYWxsZWQg InN3aXRjaGluZyIuDQo+ID4gVGhlIHRlcm0gInN3aXRjaGluZyIgZG9lcyBub3QgZml0IHdlbGwg d2l0aCBteSBvYnNlcnZhdGlvbnMgb2YgaG93IHN1Yi1JUA0KPiA+IGxheWVyIGZvcndhcmRpbmcg d29ya3Mgb24gQUVSTyBsaW5rcy4gVGhlIExMIHBhY2tldCBjb21lcyBpbnRvIHRoZSBBRVJPDQo+ ID4gaW50ZXJmYWNlIGFuZCBhIHN1Yi1JUCBsYXllciBmb3J3YXJkaW5nIHRhYmxlIGRpcmVjdHMg dGhhdCBpdCBiZSBzZW50IG9uIHRvIGENCj4gPiBkaWZmZXJlbnQgbmVpZ2hib3IgaW5zdGVhZCBv ZiBiZWluZyBwYXNzZWQgdXAgdG8gdGhlIElQIGxheWVyLiAiU3ViLUlQDQo+ID4gbGF5ZXIgZm9y d2FyZGluZyIgaXMgdGhlIHRlcm1pbm9sb2d5IHRoYXQgSSB0aGluayBiZXN0IGNvbnZleXMgdGhl IGNvbmNlcHQNCj4gPiBhcyBJIGhhdmUgb2JzZXJ2ZWQgaXQuDQo+IA0KPiBUaGUgdHJvdWJsZSBp cyB0aGF0IHdlIGhhdmUgdG9vIG1hbnkgdGVybXM6DQo+IA0KPiAgICAgc3dpdGNoaW5nDQo+ICAg ICByZWxheWluZw0KPiAgICAgZm9yd2FyZGluZw0KPiANCj4gQWxsIG9mIHRoZXNlIGNvdWxkIGdl bmVyaWNhbGx5IGJlIHVzZWQgdG8gZGVzY3JpYmUgbmVhcmx5IGFueSBjYXNlLg0KPiBTd2l0Y2hp bmcganVzdCBtZWFucyB0aGVyZSdzIGEgZGVjaXNpb24gb2YgbXVsdGlwbGUgb3V0cHV0cywgd2hp Y2ggbWF5DQo+IG9yIG1heSBub3Qgb2NjdXIgKGUuZy4sIHlvdSBjYW4gZm9yd2FyZCB0byBkaWZm ZXJlbnQgbm9kZXMgb24gYSBMQU4gYnV0DQo+IHN0aWxsIHVzZSBvbmx5IG9uZSBvdXRwdXQgcG9y dCB0byB0aGF0IExBTikuIEJvdGggcmVsYXlpbmcgYW5kDQo+IGZvcndhcmRpbmcgcmVmZXIgdG8g dHJhbnNpdGluZyBhIG1lc3NhZ2UuDQo+IA0KPiBBbGwgb2YgdGhlbSBjYW4gdXNlIHRhYmxlcyB0 byBnb3Zlcm4gdGhlIGRlY2lzaW9ucyBtYWRlLg0KPiANCj4gQWdhaW4sIG15IHZpZXcgaXMgdGhh dCAqdHlwaWNhbGx5KiB3aGVuIHRoZSB0ZXJtICJmb3J3YXJkaW5nIiBpcyB1c2VkDQo+IHdpdGhv dXQgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9uLCBpdCByZWZlcnMgdG8gdGhlIElQIGxheWVyLCBh bmQgd2hlbg0KPiAic3dpdGNoaW5nIiBpcyB1c2VkIGl0IHJlZmVycyB0byB0aGUgbGluayBsYXll ci4NCj4gDQo+IEl0J3MgYWx3YXlzIGJlc3QgdG8gYmUgbW9yZSBzcGVjaWZpYyB3aGVuIHRoZXJl IGFyZSBhbWJpZ3VpdGllcywgdGhvdWdoLg0KDQpXaGF0IGhhcHBlbnMgd2l0aCBBRVJPIGlzIHRo YXQgYSB0dW5uZWxlZCBwYWNrZXQgY29tZXMgaW4gZnJvbSBhbg0KdW5kZXJseWluZyBuZXR3b3Jr IGludGVyZmFjZSBhbmQgZ2V0cyBzdWNrZWQgdXAgYnkgYW4gYXBwbGljYXRpb24gdGhhdA0KYWxz byBjb25maWd1cmVzIGEgVFVOVEFQIGludGVyZmFjZS4gVGhlIGFwcGxpY2F0aW9uIHBlZWtzIGF0 IGluZm9ybWF0aW9uDQppbnNpZGUgdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQgYW5kIGRlY2lkZXMg d2hldGhlciB0byBwYXNzIGl0IHVwIHRvIHRoZQ0KbG9jYWwgSVAgbGF5ZXIgdmlhIHRoZSBUVU5U QVAgaW50ZXJmYWNlLCBvciBzZW5kIGl0IGJhY2sgb3V0IGFuIHVuZGVybHlpbmcNCm5ldHdvcmsg aW50ZXJmYWNlIHRvIGFub3RoZXIgbmVpZ2hib3Igd2l0aG91dCBkaXN0dXJiaW5nIHRoZSBsb2Nh bCBJUCBsYXllci4NCg0KVGhpcyBsYXR0ZXIgYmVoYXZpb3IgaXMgd2hhdCBJIGFtIHNlZWtpbmcg dG8gbmFtZS4gSW4gbXkgbWluZCwgInN3aXRjaGluZyINCmRvZXMgbm90IHNvdW5kIHJpZ2h0LiAi U3ViLUlQIGxheWVyIGZvcndhcmRpbmciIHNvdW5kcyByaWdodCwgYnV0IHRvIGENCmNlcnRhaW4g ZXh0ZW50IHNvIGRvZXMgInJlbGF5aW5nIi4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBs aW5AYm9laW5nLmNvbQ0KDQo+IEpvZQ0KPiANCg0K From nobody Fri Jun 10 12:28: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 667AF12D526 for ; Fri, 10 Jun 2016 12:28:48 -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 iQYHtSOic-O8 for ; Fri, 10 Jun 2016 12:28:47 -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 589D7128B44 for ; Fri, 10 Jun 2016 12:28:47 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5AJS5ve018779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 12:28:05 -0700 (PDT) To: "Templin, Fred L" , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= , Mark Smith References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> <575B0C02.3030606@isi.edu> <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <575B14C5.5030904@isi.edu> Date: Fri, 10 Jun 2016 12:28:05 -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: <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 19:28:48 -0000 On 6/10/2016 12:01 PM, Templin, Fred L wrote: > What happens with AERO is that a tunneled packet comes in from an > underlying network interface and gets sucked up by an application that > also configures a TUNTAP interface. It's largely an implementation artifact as to whether this happens inside a driver, elsewhere in the OS, or at the application layer using TUNTAP. > The application peeks at information > inside the encapsulated packet and decides whether to pass it up to the > local IP layer via the TUNTAP interface, or send it back out an underlying > network interface to another neighbor without disturbing the local IP layer. > > This latter behavior is what I am seeking to name. In my mind, "switching" > does not sound right. "Sub-IP layer forwarding" sounds right, but to a > certain extent so does "relaying". You're using IP to make decisions. That's IP forwarding. The fact that you don't disturb the layers in which IP is encapsulated is an implementation artifact - you could easily strip off those headers and put them back as needed. I.e., when an ethernet switch decides where a packet goes by it's IP payload address, I call that forwarding, not "ethernet switching with DPI". Joe From nobody Fri Jun 10 12:44: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 DD8E612D185 for ; Fri, 10 Jun 2016 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Xi_gGB9jDJGM for ; Fri, 10 Jun 2016 12:44:53 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 63586128B44 for ; Fri, 10 Jun 2016 12:44:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5AJj3S4032380; Fri, 10 Jun 2016 12:45:04 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5AJj284031887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 12:45:02 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Jun 2016 12:44:50 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 10 Jun 2016 12:44:50 -0700 From: "Templin, Fred L" To: Joe Touch , =?utf-8?B?56We5piO6YGU5ZOJ?= , Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CAAViffYAADJvggAB7xAD//4s0AIAAfz6A//+MYGA= Date: Fri, 10 Jun 2016 19:44:50 +0000 Message-ID: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> <575B0C02.3030606@isi.edu> <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> <575B14C5.5030904@isi.edu> In-Reply-To: <575B14C5.5030904@isi.edu> 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 19:44:55 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAxMCwgMjAxNiAx MjoyOCBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD47IE1hcmsgU21pdGggPG1hcmt6enpz bWl0aEBnbWFpbC5jb20+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZzsgRmVybmFuZG8gR29udCA8ZmVy bmFuZG9AZ29udC5jb20uYXI+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFBhY2tldHMgd2l0aCBM TCBzcmMgYW5kIEdVQSBkc3QNCj4gDQo+IA0KPiANCj4gT24gNi8xMC8yMDE2IDEyOjAxIFBNLCBU ZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4gV2hhdCBoYXBwZW5zIHdpdGggQUVSTyBpcyB0aGF0 IGEgdHVubmVsZWQgcGFja2V0IGNvbWVzIGluIGZyb20gYW4NCj4gPiB1bmRlcmx5aW5nIG5ldHdv cmsgaW50ZXJmYWNlIGFuZCBnZXRzIHN1Y2tlZCB1cCBieSBhbiBhcHBsaWNhdGlvbiB0aGF0DQo+ ID4gYWxzbyBjb25maWd1cmVzIGEgVFVOVEFQIGludGVyZmFjZS4NCj4gSXQncyBsYXJnZWx5IGFu IGltcGxlbWVudGF0aW9uIGFydGlmYWN0IGFzIHRvIHdoZXRoZXIgdGhpcyBoYXBwZW5zDQo+IGlu c2lkZSBhIGRyaXZlciwgZWxzZXdoZXJlIGluIHRoZSBPUywgb3IgYXQgdGhlIGFwcGxpY2F0aW9u IGxheWVyIHVzaW5nDQo+IFRVTlRBUC4NCg0KSXQgaXMgYW4gaW1wbGVtZW50YXRpb24gYXJ0aWZh Y3QsIHllcywgYW5kIGl0IGNhbiBhbHNvIGJlIGRvbmUgaW5zaWRlIGEgbmV0d29yaw0KZHJpdmVy IHRydWUuIFRoZSBkcml2ZXIgc2l0cyBiZXR3ZWVuIHRoZSBwaHlzaWNhbCBsYXllciBhbmQgdGhl IElQIGxheWVyLiBJbg0Kd2hhdCBJIGRlc2NyaWJlZCB3aXRoIG15IGFwcCB1c2luZyBUVU5UQVAs IHRoZSBhcHAgaXRzZWxmIGlzIGJlaGF2aW5nIGFzDQppZiBpdCBpcyBhIG5ldHdvcmsgZHJpdmVy Lg0KDQo+ID4gVGhlIGFwcGxpY2F0aW9uIHBlZWtzIGF0IGluZm9ybWF0aW9uDQo+ID4gaW5zaWRl IHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0IGFuZCBkZWNpZGVzIHdoZXRoZXIgdG8gcGFzcyBpdCB1 cCB0byB0aGUNCj4gPiBsb2NhbCBJUCBsYXllciB2aWEgdGhlIFRVTlRBUCBpbnRlcmZhY2UsIG9y IHNlbmQgaXQgYmFjayBvdXQgYW4gdW5kZXJseWluZw0KPiA+IG5ldHdvcmsgaW50ZXJmYWNlIHRv IGFub3RoZXIgbmVpZ2hib3Igd2l0aG91dCBkaXN0dXJiaW5nIHRoZSBsb2NhbCBJUCBsYXllci4N Cj4gPg0KPiA+IFRoaXMgbGF0dGVyIGJlaGF2aW9yIGlzIHdoYXQgSSBhbSBzZWVraW5nIHRvIG5h bWUuIEluIG15IG1pbmQsICJzd2l0Y2hpbmciDQo+ID4gZG9lcyBub3Qgc291bmQgcmlnaHQuICJT dWItSVAgbGF5ZXIgZm9yd2FyZGluZyIgc291bmRzIHJpZ2h0LCBidXQgdG8gYQ0KPiA+IGNlcnRh aW4gZXh0ZW50IHNvIGRvZXMgInJlbGF5aW5nIi4NCj4gDQo+IFlvdSdyZSB1c2luZyBJUCB0byBt YWtlIGRlY2lzaW9ucy4gVGhhdCdzIElQIGZvcndhcmRpbmcuDQoNCkkgYW0gc2l0dGluZyBpbnNp ZGUgdGhlIG5ldHdvcmsgZHJpdmVyIGFuZCBwZWVraW5nIGF0IGluZm9ybWF0aW9uIGluc2lkZQ0K dGhlIG5leHQgbGF5ZXIgaGVhZGVyLCB0cnVlLiBUaGF0IGluZm9ybWF0aW9uIGluY2x1ZGVzIElQ IGFkZHJlc3NlcywNCnRydWUuIEJ1dCwgdGhlIG5ldHdvcmsgZHJpdmVyIG5ldmVyIHBhc3Npbmcg dGhlIHBhY2tldCB1cCB0byB0aGUgSVAgbGF5ZXIuDQpJbnN0ZWFkLCB0aGUgbmV0d29yayBkcml2 ZXIgcHVzaGVzIGl0IGJhY2sgZG93biB0byB0aGUgcGh5c2ljYWwgbWVkaWENCndoZXJlIGl0IHdp bGwgYmUgY29udmV5ZWQgdG8gYSBkaWZmZXJlbnQgQUVSTyBpbnRlcmZhY2UgbmVpZ2hib3IuDQoN Cj4gVGhlIGZhY3QgdGhhdCB5b3UgZG9uJ3QgZGlzdHVyYiB0aGUgbGF5ZXJzIGluIHdoaWNoIElQ IGlzIGVuY2Fwc3VsYXRlZA0KPiBpcyBhbiBpbXBsZW1lbnRhdGlvbiBhcnRpZmFjdCAtIHlvdSBj b3VsZCBlYXNpbHkgc3RyaXAgb2ZmIHRob3NlIGhlYWRlcnMNCj4gYW5kIHB1dCB0aGVtIGJhY2sg YXMgbmVlZGVkLg0KDQpBRVJPIGhhcyBhIG5vdGlvbiBvZiAicmUtZW5jYXBzdWxhdGlvbiIgKHdo aWNoIEkgdGhpbmsgaXMgdGhlIHNhbWUgYXMNCndoYXQgdGhlIExJU1AgZ3V5cyBjYWxsIGl0KS4g SW4gInJlLWVuY2Fwc3VsYXRpb24iLCB0aGUgTDIgaGVhZGVyIGlzIHJlcGxhY2VkDQp3aXRoIGEg ZGlmZmVyZW50IEwyIGhlYWRlciBidXQgdGhlIElQIGhlYWRlciByZW1haW5zIHVuY2hhbmdlZCAo aS5lLiwgYW5kDQpub3QgZXZlbiB0aGUgaG9wLWxpbWl0L1RUTCBnZXRzIGRlY3JlbWVudGVkKS4N Cg0KSW4gdGhlIHByb2Nlc3MsIGhvd2V2ZXIsIHRoZSBMMiBoZWFkZXIgaG9wLWxpbWl0L1RUTCBn ZXRzIGRlY3JlbWVudGVkOw0Kb3RoZXJ3aXNlLCB3ZSBjb3VsZCBoaXQgYW4gaW50ZXJtaW5hYmxl IGxvb3AuIEJ1dCwgdGhlIElQIGhvcC1saW1pdC9UVEwgaXMNCnVuY2hhbmdlZC4NCg0KVGhhbmtz IC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQoNCj4gDQo+IEkuZS4sIHdoZW4g YW4gZXRoZXJuZXQgc3dpdGNoIGRlY2lkZXMgd2hlcmUgYSBwYWNrZXQgZ29lcyBieSBpdCdzIElQ DQo+IHBheWxvYWQgYWRkcmVzcywgSSBjYWxsIHRoYXQgZm9yd2FyZGluZywgbm90ICJldGhlcm5l dCBzd2l0Y2hpbmcgd2l0aCBEUEkiLg0KPiANCj4gSm9lDQo+IA0KDQo= From nobody Fri Jun 10 13:29: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 DC41C12D11E for ; Fri, 10 Jun 2016 13:29:17 -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 G5oOo60xpiDX for ; Fri, 10 Jun 2016 13:29:16 -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 2111E12B031 for ; Fri, 10 Jun 2016 13:29:16 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5AKShim026657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 13:28:44 -0700 (PDT) To: "Templin, Fred L" , =?UTF-8?B?56We5piO6YGU?= =?UTF-8?B?5ZOJ?= , Mark Smith References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> <575B0C02.3030606@isi.edu> <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> <575B14C5.5030904@isi.edu> From: Joe Touch Message-ID: <575B22FB.5090106@isi.edu> Date: Fri, 10 Jun 2016 13:28:43 -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: multipart/alternative; boundary="------------020409000008070305050304" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 20:29:18 -0000 This is a multi-part message in MIME format. --------------020409000008070305050304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/10/2016 12:44 PM, Templin, Fred L wrote: ... > >> You're using IP to make decisions. That's IP forwarding. > I am sitting inside the network driver and peeking at information inside > the next layer header, true. That information includes IP addresses, > true. But, the network driver never passing the packet up to the IP layer. The IP layer is whatever layer looks at IP and makes decisions. I think you're trying to differentiate your mechanism from that in the OS, but that too is just an implementation choice. Here's an example where the packets stay on the network card and just the headers get passed around to figure out what happens - it's still IP forwarding, though: S. Walton, A. Hutton, and J. Touch, “High-Speed Data Paths in Host-Based Routers ,†/IEEE Computer/, Nov. 1998, pp. 46-52. ... > > AERO has a notion of "re-encapsulation" (which I think is the same as > what the LISP guys call it). In "re-encapsulation", the L2 header is replaced > with a different L2 header but the IP header remains unchanged (i.e., and > not even the hop-limit/TTL gets decremented). > > In the process, however, the L2 header hop-limit/TTL gets decremented; > otherwise, we could hit an interminable loop. But, the IP hop-limit/TTL is > unchanged. If you change L2 headers without affecting the IP header, you're trying to make two different "subnets" (as RFC 3819) act like one logical subnet to IP: This document defines a subnetwork as a layer 2 network, which is a network that does not rely upon the services of IP routers to forward packets between parts of the subnetwork. However, IP routers may bridge frames at Layer 2 between parts of a subnetwork. Sometimes, it is convenient to aggregate a group of such subnetworks into a single logical subnetwork. The fact that you use L3 to make decisions is - I suspect - an optimization at that point. You probably could have used just L2 to make these decisions if you wanted. Joe --------------020409000008070305050304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/10/2016 12:44 PM, Templin, Fred L wrote:

...

You're using IP to make decisions. That's IP forwarding.

I am sitting inside the network driver and peeking at information inside
the next layer header, true. That information includes IP addresses,
true. But, the network driver never passing the packet up to the IP layer.
The IP layer is whatever layer looks at IP and makes decisions.

I think you're trying to differentiate your mechanism from that in the OS, but that too is just an implementation choice.

Here's an example where the packets stay on the network card and just the headers get passed around to figure out what happens - it's still IP forwarding, though:

S. Walton, A. Hutton, and J. Touch, “High-Speed Data Paths in Host-Based Routers,†IEEE Computer, Nov. 1998, pp. 46-52.

...

AERO has a notion of "re-encapsulation" (which I think is the same as
what the LISP guys call it). In "re-encapsulation", the L2 header is replaced
with a different L2 header but the IP header remains unchanged (i.e., and
not even the hop-limit/TTL gets decremented).

In the process, however, the L2 header hop-limit/TTL gets decremented;
otherwise, we could hit an interminable loop. But, the IP hop-limit/TTL is
unchanged.

If you change L2 headers without affecting the IP header, you're trying to make two different "subnets" (as RFC 3819) act like one logical subnet to IP:

   This document defines a subnetwork as a layer 2 network, which is a
   network that does not rely upon the services of IP routers to forward
   packets between parts of the subnetwork.  However, IP routers may
   bridge frames at Layer 2 between parts of a subnetwork.  Sometimes,
   it is convenient to aggregate a group of such subnetworks into a
   single logical subnetwork.

The fact that you use L3 to make decisions is - I suspect - an optimization at that point. You probably could have used just L2 to make these decisions if you wanted.

Joe
--------------020409000008070305050304-- From nobody Fri Jun 10 13:41: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 CFD5112D11E for ; Fri, 10 Jun 2016 13:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 o1Vqo_2qanUC for ; Fri, 10 Jun 2016 13:41:07 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 36EFA12D948 for ; Fri, 10 Jun 2016 13:41:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5AKfJbL028786; Fri, 10 Jun 2016 13:41:19 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5AKfAsO028071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 13:41:10 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Jun 2016 13:40:57 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 10 Jun 2016 13:40:57 -0700 From: "Templin, Fred L" To: Joe Touch , =?utf-8?B?56We5piO6YGU5ZOJ?= , Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CAAViffYAADJvggAB7xAD//4s0AIAAfz6A//+MYGAAEJIbgAAOe3Cw Date: Fri, 10 Jun 2016 20:40:57 +0000 Message-ID: <5afb5ed6ec1c4d3f8a5864efa39753f2@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <575AFBE6.1090607@isi.edu> <71f7f44b2a9045f4ab049e2788bc081a@XCH15-05-05.nw.nos.boeing.com> <575B0C02.3030606@isi.edu> <18955e43e24b4f319e9edfe88c19a06e@XCH15-05-05.nw.nos.boeing.com> <575B14C5.5030904@isi.edu> <575B22FB.5090106@isi.edu> In-Reply-To: <575B22FB.5090106@isi.edu> 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: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 10 Jun 2016 20:41:09 -0000 SGkgSm9lLA0KDQo+ICAgIEhvd2V2ZXIsIElQIHJvdXRlcnMgbWF5DQo+ICAgIGJyaWRnZSBmcmFt ZXMgYXQgTGF5ZXIgMiBiZXR3ZWVuIHBhcnRzIG9mIGEgc3VibmV0d29yay4gIFNvbWV0aW1lcywN Cj4gICAgaXQgaXMgY29udmVuaWVudCB0byBhZ2dyZWdhdGUgYSBncm91cCBvZiBzdWNoIHN1Ym5l dHdvcmtzIGludG8gYQ0KPiAgICBzaW5nbGUgbG9naWNhbCBzdWJuZXR3b3JrLg0KDQpBRVJPIGlz IGEgc2VnbWVudGVkIGxpbmsgdGhhdCBpcyBwYXRjaGVkIHRvZ2V0aGVyIGJ5IGZvcndhcmRpbmcg bm9kZXMgaW50bw0KYSBzaW5nbGUgbG9naWNhbCBsaW5rLiBTbywgdGhlIGFib3ZlIHRleHQgcmlu Z3MgdHJ1ZSB0byB3aGF0IGlzIGhhcHBlbmluZyB3aXRoDQpBRVJPLCB5ZXMuDQoNClRoYW5rcyAt IEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KDQpGcm9tOiBKb2UgVG91Y2ggW21h aWx0bzp0b3VjaEBpc2kuZWR1XSANClNlbnQ6IEZyaWRheSwgSnVuZSAxMCwgMjAxNiAxOjI5IFBN DQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsg56We5piO 6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD47IE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFp bC5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmc7IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQu Y29tLmFyPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gUGFja2V0cyB3aXRoIExMIHNyYyBhbmQgR1VB IGRzdA0KDQoNCk9uIDYvMTAvMjAxNiAxMjo0NCBQTSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0K DQouLi4NCg0KDQoNCllvdSdyZSB1c2luZyBJUCB0byBtYWtlIGRlY2lzaW9ucy4gVGhhdCdzIElQ IGZvcndhcmRpbmcuDQoNCkkgYW0gc2l0dGluZyBpbnNpZGUgdGhlIG5ldHdvcmsgZHJpdmVyIGFu ZCBwZWVraW5nIGF0IGluZm9ybWF0aW9uIGluc2lkZQ0KdGhlIG5leHQgbGF5ZXIgaGVhZGVyLCB0 cnVlLiBUaGF0IGluZm9ybWF0aW9uIGluY2x1ZGVzIElQIGFkZHJlc3NlcywNCnRydWUuIEJ1dCwg dGhlIG5ldHdvcmsgZHJpdmVyIG5ldmVyIHBhc3NpbmcgdGhlIHBhY2tldCB1cCB0byB0aGUgSVAg bGF5ZXIuDQpUaGUgSVAgbGF5ZXIgaXMgd2hhdGV2ZXIgbGF5ZXIgbG9va3MgYXQgSVAgYW5kIG1h a2VzIGRlY2lzaW9ucy4NCg0KSSB0aGluayB5b3UncmUgdHJ5aW5nIHRvIGRpZmZlcmVudGlhdGUg eW91ciBtZWNoYW5pc20gZnJvbSB0aGF0IGluIHRoZSBPUywgYnV0IHRoYXQgdG9vIGlzIGp1c3Qg YW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLg0KDQpIZXJlJ3MgYW4gZXhhbXBsZSB3aGVyZSB0aGUg cGFja2V0cyBzdGF5IG9uIHRoZSBuZXR3b3JrIGNhcmQgYW5kIGp1c3QgdGhlIGhlYWRlcnMgZ2V0 IHBhc3NlZCBhcm91bmQgdG8gZmlndXJlIG91dCB3aGF0IGhhcHBlbnMgLSBpdCdzIHN0aWxsIElQ IGZvcndhcmRpbmcsIHRob3VnaDoNCg0KUy4gV2FsdG9uLCBBLiBIdXR0b24sIGFuZCBKLiBUb3Vj aCwg4oCcSGlnaC1TcGVlZCBEYXRhIFBhdGhzIGluIEhvc3QtQmFzZWQgUm91dGVycyzigJ0gSUVF RSBDb21wdXRlciwgTm92LiAxOTk4LCBwcC4gNDYtNTIuIA0KDQouLi4NCg0KDQoNCkFFUk8gaGFz IGEgbm90aW9uIG9mICJyZS1lbmNhcHN1bGF0aW9uIiAod2hpY2ggSSB0aGluayBpcyB0aGUgc2Ft ZSBhcw0Kd2hhdCB0aGUgTElTUCBndXlzIGNhbGwgaXQpLiBJbiAicmUtZW5jYXBzdWxhdGlvbiIs IHRoZSBMMiBoZWFkZXIgaXMgcmVwbGFjZWQNCndpdGggYSBkaWZmZXJlbnQgTDIgaGVhZGVyIGJ1 dCB0aGUgSVAgaGVhZGVyIHJlbWFpbnMgdW5jaGFuZ2VkIChpLmUuLCBhbmQNCm5vdCBldmVuIHRo ZSBob3AtbGltaXQvVFRMIGdldHMgZGVjcmVtZW50ZWQpLg0KDQpJbiB0aGUgcHJvY2VzcywgaG93 ZXZlciwgdGhlIEwyIGhlYWRlciBob3AtbGltaXQvVFRMIGdldHMgZGVjcmVtZW50ZWQ7DQpvdGhl cndpc2UsIHdlIGNvdWxkIGhpdCBhbiBpbnRlcm1pbmFibGUgbG9vcC4gQnV0LCB0aGUgSVAgaG9w LWxpbWl0L1RUTCBpcw0KdW5jaGFuZ2VkLg0KDQpJZiB5b3UgY2hhbmdlIEwyIGhlYWRlcnMgd2l0 aG91dCBhZmZlY3RpbmcgdGhlIElQIGhlYWRlciwgeW91J3JlIHRyeWluZyB0byBtYWtlIHR3byBk aWZmZXJlbnQgInN1Ym5ldHMiIChhcyBSRkMgMzgxOSkgYWN0IGxpa2Ugb25lIGxvZ2ljYWwgc3Vi bmV0IHRvIElQOg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3VibmV0d29yayBhcyBhIGxh eWVyIDIgbmV0d29yaywgd2hpY2ggaXMgYQ0KICAgbmV0d29yayB0aGF0IGRvZXMgbm90IHJlbHkg dXBvbiB0aGUgc2VydmljZXMgb2YgSVAgcm91dGVycyB0byBmb3J3YXJkDQogICBwYWNrZXRzIGJl dHdlZW4gcGFydHMgb2YgdGhlIHN1Ym5ldHdvcmsuICBIb3dldmVyLCBJUCByb3V0ZXJzIG1heQ0K ICAgYnJpZGdlIGZyYW1lcyBhdCBMYXllciAyIGJldHdlZW4gcGFydHMgb2YgYSBzdWJuZXR3b3Jr LiAgU29tZXRpbWVzLA0KICAgaXQgaXMgY29udmVuaWVudCB0byBhZ2dyZWdhdGUgYSBncm91cCBv ZiBzdWNoIHN1Ym5ldHdvcmtzIGludG8gYQ0KICAgc2luZ2xlIGxvZ2ljYWwgc3VibmV0d29yay4g DQoNClRoZSBmYWN0IHRoYXQgeW91IHVzZSBMMyB0byBtYWtlIGRlY2lzaW9ucyBpcyAtIEkgc3Vz cGVjdCAtIGFuIG9wdGltaXphdGlvbiBhdCB0aGF0IHBvaW50LiBZb3UgcHJvYmFibHkgY291bGQg aGF2ZSB1c2VkIGp1c3QgTDIgdG8gbWFrZSB0aGVzZSBkZWNpc2lvbnMgaWYgeW91IHdhbnRlZC4N Cg0KSm9lDQo= From nobody Fri Jun 10 17:50:11 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 E728712D800 for ; Fri, 10 Jun 2016 17:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, 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 eQ-QYKAMtd9N for ; Fri, 10 Jun 2016 17:50:08 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 B2A7F12D1B2 for ; Fri, 10 Jun 2016 17:50:07 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u64so7248375vkf.3 for ; Fri, 10 Jun 2016 17:50:07 -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=LoZ7PsNuj7xq3vvhJwbHhAWLA8/q6V/mWx5lpSH1srE=; b=eSfsWHTFOpg2f4uvUzLYbBdREiuRrDdrjAD4ew+nZV1Br3YPWhpbAxbmhrFvPnqAEg 4Zzj94EA/b/aDjEqZ2zqZKH+szsiT0Dipzv92Sy2kJCe3LFXAE/sjaDFH5A2X+sqSPAi qkUUMyLpVw7FD5Dg3sn/pca5mM4NgHfG/w0xtV056N8KXD3C6zlmOAkQyJamV2JAhKzJ 2jmiO4AHYSY7UOcwxXxV5vSrr7nnuLOJLuMnXXpnkOn+McikwoGxJFBUgLZyLWz7gE/C pcijBeqQ9ykQTQBf7w2bzIsE/J87NLXKi2bcetNGB9HPqWzggLhHYXq4j5wbBrOHSBmM sr3w== 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=LoZ7PsNuj7xq3vvhJwbHhAWLA8/q6V/mWx5lpSH1srE=; b=BQiu4/5wO94KU5qwb5Nsh2vJgv8HGpB5GWsxQNxBiShV0fwzM2qbFR+Cn2wipsuRrq yPWzaEBwtAISwQAaLKI2OezasNqaT+Xy6TcznuaU/WwDdhF8qjwj5beiWMtFDOkG9lsD pEMjOJQQ21mjYByjrMlghDauPLvnmw/4M5VQA5W5odyOfoUBHi2QMn3bEvnmwVAe4GUh C1XMf4POy70jeFJgNAP6cgEj9UeTWvJSp7Z7mvkHpPjgpVjgeUcxWF9dpoUqPzRAxxwI vPkMKQGqaH6x4MfpnVQ6LU73+JdgjS1KFzPr08Flfzhdzv4VgdYPQgfVhje3RT7XrKwz +pFg== X-Gm-Message-State: ALyK8tJrcmVj7HDbTNFyPqD5qaziiugf4uxcIawhmjej5Hn/q5HNX/KnvkI28wSiMUg7hZcEs3zsNbuRc16yrw== MIME-Version: 1.0 X-Received: by 10.31.136.194 with SMTP id k185mr2006984vkd.2.1465606206777; Fri, 10 Jun 2016 17:50:06 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Fri, 10 Jun 2016 17:50:06 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Fri, 10 Jun 2016 17:50:06 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> Date: Sat, 11 Jun 2016 10:50:06 +1000 Message-ID: From: Mark Smith To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a11441b7c55f1110534f609a2 Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 11 Jun 2016 00:50:10 -0000 --001a11441b7c55f1110534f609a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 Jun 2016 3:13 AM, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: > > At Fri, 10 Jun 2016 11:21:29 +1000, > Mark Smith wrote: > > > > Everyone seems to be talking past each other on this thread, but to > > address your point: > > > > > > > I should have realised the place to look. RFC2460/RFC2460bis says for > > > > the Hop Limit field that it is "Decremented by 1 by each node that > > > > forwards the packet." > > > > > > It depends on what you mean by "forwarding". The RFC2460 text is referring > > > to forwarding *at the IP layer*. > > > > Right. People were saying that LL addressed packets should never be > > forwarded, and I think they were talking about layer 3 forwarding of them. > > I was pointing out that they can be as per-RFC4007, limited to back on to > > the link they came from. > > As far as I understand it RFC4007 only talks about "layer 3 > forwarding". We can freely discuss whether there's such a concept as > "forwarding sub-IP layer" and/or whether the hop limit should be > decremented in that case, but RFC4007 should be independent from that > discussion. > So how can it not be layer 3 forwarding if the device is looking at layer 3 addresses and acting on them? This seems to have wandered off topic - it was about whether a packet with a LL src and a GUA dst should be (layer 3) forwarded by a router. I think the should be able to be, as long as the LL src and GUA dst are on the same (rfc2460) link, meaning the packet is forwarded back onto the link it came from (via same or different attached interface). It should be dropped otherwise. Same with LL dst. - forwarded back onto same link as per RFC4007. These forwarding checks may be hard/expensive or impossible to implement on fast forwarding hardware, which is why these packets are leaking. I think LL src. and GUA dst. are currently technically legitimate packets. The origin host has somehow got a GUA dst (probably AAAA lookup over IPv4), doesn't have anything but a LL address to use as a source because LLs are autoconfigured and it has no other IPv6 addresses to use as a src. In theory, the host shouldn't send unless the GUA is known to be on-link, however the host doesn't know, has a default router somehow (e.g. RA with no PIOs), so assumes that the default router will know better as per RFC5942 (all dsts are off-link by default except LLs). In these cases the router(s) along the path are not doing any source address validation, which is how packets with LL src. are making it to the GUA dst. Other than the router(s) not performing a source address check for LL sources and dropping if the dst is not on the same link it came from, I think all other behavior that is allowing this to happen is legitimate and has some valid use cases so shouldn't be changed. Regards, Mark. > -- > JINMEI, Tatuya --001a11441b7c55f1110534f609a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 11 Jun 2016 3:13 AM, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" &l= t;jinmei@wide.ad.jp> wrote:
>
> At Fri, 10 Jun 2016 11:21:29 +1000,
> Mark Smith <markzzzsmith@= gmail.com> wrote:
>
> > > Everyone seems to be talking past each other on this thread,= but to
> > address your point:
> > >
> > > > I should have realised the place to look. RFC2460/RFC24= 60bis says for
> > > > the Hop Limit field that it is "Decremented by 1 b= y each node that
> > > > forwards the packet."
> > >
> > > It depends on what you mean by "forwarding". The R= FC2460 text is referring
> > > to forwarding *at the IP layer*.
> >
> > Right. People were saying that LL addressed packets should never = be
> > forwarded, and I think they were talking about layer 3 forwarding= of them.
> > I was pointing out that they can be as per-RFC4007, limited to ba= ck on to
> > the link they came from.
>
> As far as I understand it RFC4007 only talks about "layer 3
> forwarding".=C2=A0 We can freely discuss whether there's such= a concept as
> "forwarding sub-IP layer" and/or whether the hop limit shoul= d be
> decremented in that case, but RFC4007 should be independent from that<= br> > discussion.
>

So how can it not be layer 3 forwarding if the device is loo= king at layer 3 addresses and acting on them?

This seems to have wandered off topic - it was about whether= a packet with a LL src and a GUA dst should be (layer 3) forwarded by a ro= uter.

I think the should be able to be, as long as the LL src and = GUA dst are on the same (rfc2460) link, meaning the packet is forwarded bac= k onto the link it came from (via same or different attached interface). It= should be dropped otherwise.

Same with LL dst. - forwarded back onto same link as per RFC= 4007.

These forwarding checks may be hard/expensive or impossible = to implement on fast forwarding hardware, which is why these packets are le= aking.

I think LL src. and GUA dst. are currently technically legit= imate packets. The origin host has somehow got a GUA dst (probably AAAA loo= kup over IPv4), doesn't have anything but a LL address to use as a sour= ce because LLs are autoconfigured and it has no other IPv6 addresses to use= as a src.

In theory, the host shouldn't send unless the GUA is kno= wn to be on-link, however the host doesn't know, has a default router s= omehow (e.g. RA with no PIOs), so assumes that the default router will know= better as per RFC5942 (all dsts are off-link by default except LLs).

In these cases the router(s) along the path are not doing an= y source address validation, which is how packets with LL src. are making i= t to the GUA dst.

Other than the router(s) not performing a source address che= ck for LL sources and dropping if the dst is not on the same link it came f= rom, I think all other behavior that is allowing this to happen is legitima= te and has some valid use cases so shouldn't be changed.

Regards,
Mark.

> --
> JINMEI, Tatuya

--001a11441b7c55f1110534f609a2-- From nobody Fri Jun 10 18:07: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 697F012D7BE for ; Fri, 10 Jun 2016 18:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hlwd7cAYqioN for ; Fri, 10 Jun 2016 18:07:50 -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 B882512D78C for ; Fri, 10 Jun 2016 18:07:50 -0700 (PDT) Received: from [128.9.184.155] ([128.9.184.155]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u5B17DHW016187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jun 2016 18:07:13 -0700 (PDT) To: Mark Smith , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <575B6441.5020807@isi.edu> Date: Fri, 10 Jun 2016 18:07:13 -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=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u5B17DHW016187 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 11 Jun 2016 01:07:51 -0000 On 6/10/2016 5:50 PM, Mark Smith wrote: > > So how can it not be layer 3 forwarding if the device is looking at > layer 3 addresses and acting on them? > The key is whether: a) looking at L3 addresses is strictly required, or simply a convenience to avoid maintaining a larger set of L2 tables b) whether the goal is to appear to L3 as a subnet or not You can always deliberately try to act like a single IP subnet *if you want to*. Joe From nobody Sun Jun 12 16:33: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 7CFE812D759 for ; Sun, 12 Jun 2016 16:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.526 X-Spam-Level: X-Spam-Status: No, score=-7.526 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.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 NqPN-zvzrxMj for ; Sun, 12 Jun 2016 16:32:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA2512D752 for ; Sun, 12 Jun 2016 16:32:56 -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 u5CNVsni031077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Jun 2016 16:31:54 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_083A2CEA-8848-4473-80AF-1CDE816F4F69" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> Date: Sun, 12 Jun 2016 16:31:53 -0700 Message-Id: <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@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]); Sun, 12 Jun 2016 16:31:54 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 12 Jun 2016 23:33:03 -0000 --Apple-Mail=_083A2CEA-8848-4473-80AF-1CDE816F4F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 9, 2016, at 13:09 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 09/06/2016 =C3=A0 19:24, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a = =C3=A9crit : >> At Thu, 9 Jun 2016 14:45:48 +0000, >> "Templin, Fred L" wrote: >>=20 >>>> RFC4007, >>>>=20 >>>>=20 >>>> "Thus, if a >>>> router receives a packet with a link-local destination address = that >>>> is not one of the router's own link-local addresses on the = arrival >>>> link, the router is expected to try to forward the packet to the >>>> destination on that link (subject to successful determination of = the >>>> destination's link-layer address via the Neighbor Discovery = protocol >>>> [9]). The forwarded packet may be transmitted back through the >>>> arrival interface, or through any other interface attached to the >>>> same link." >>>>=20 >>>> I'd expect the hop-limit to be decremented. >>>=20 >>> The key text in the above passages is "may be transmitted back = through >>> the arrival interface, or through any other interface attached to = the same >>> link". This means that the packet with LL source address never = really leave >>> the link they arrived on. Instead, they are "hairpinned" either at = the IP >>> or sub-IP layers. So, the hop-limit should not be decremented. >>=20 >> I'm pretty sure that the original intent of this text is to mean this >> "forwarding" to be just like other normal cases, i.e., forwarding a >> packet received on one interface to one link to another interface to >> another link. Or, just like the case where a default router is not >> the best path to an off-link destination and the best next hop is in >> the same link as the receiving link (in that case the receiving = router >> will transmit the packet back through the arrival interface, possibly >> sending a neighbor discovery redirect). So I'm pretty sure that the >> hop-limit is assumed to be decremented. Saying "should not be >> decremented" based on this RFC text is most likely to be a >> misinterpretation. >>=20 >> Whether such a behavior is justified for some special cases can be a >> different question, but that shouldn't automatically apply to the >> general case described in this RFC. >=20 > To clarify my position: the _general_ case is that a router forwards = without looking at the source address at all. Inappropriate behavior in IPv6, as the router is required not to forward = packets with LL Source Addresses to interfaces that are not on the same = link as the arriving interface. Owen >=20 > The rest are particular cases. >=20 > Alex >=20 >>=20 >> -- >> JINMEI, Tatuya >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops = >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_083A2CEA-8848-4473-80AF-1CDE816F4F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 9, 2016, at 13:09 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 09/06/2016 =C3=A0 19:24, =E7=A5=9E=E6=98= =8E=E9=81=94=E5=93=89 a =C3=A9crit :
At Thu, 9 Jun 2016 14:45:48 +0000,
"Templin, = Fred L" <Fred.L.Templin@boeing.com> wrote:

RFC4007,


"Thus, = if a
  router receives a packet with a = link-local destination address that
  is not one = of the router's own link-local addresses on the arrival
  link, the router is expected to try to forward = the packet to the
  destination on that link = (subject to successful determination of the
  destination's link-layer address via the Neighbor = Discovery protocol
  [9]).  The forwarded = packet may be transmitted back through the
  arrival interface, or through any other interface = attached to the
  same link."

I'd expect the hop-limit to be decremented.

The key text in the above = passages is "may be transmitted back through
the arrival = interface, or through any other interface attached to the same
link". This means that the packet with LL source address = never really leave
the link they arrived on. Instead, they = are "hairpinned" either at the IP
or sub-IP layers. So, = the hop-limit should not be decremented.

I'm pretty sure that the original intent of this text is to = mean this
"forwarding" to be just like other normal cases, = i.e., forwarding a
packet received on one interface to one = link to another interface to
another link.  Or, just = like the case where a default router is not
the best path = to an off-link destination and the best next hop is in
the = same link as the receiving link (in that case the receiving router
will transmit the packet back through the arrival interface, = possibly
sending a neighbor discovery redirect).  So = I'm pretty sure that the
hop-limit is assumed to be = decremented.  Saying "should not be
decremented" = based on this RFC text is most likely to be a
misinterpretation.

Whether such = a behavior is justified for some special cases can be a
different question, but that shouldn't automatically apply to = the
general case described in this RFC.

To clarify my position: the _general_ case is = that a router forwards without looking at the source address at = all.

Inappropriate = behavior in IPv6, as the router is required not to forward packets with = LL Source Addresses to interfaces that are not on the same link as the = arriving interface.

Owen

The rest are particular = cases.

Alex


--
JINMEI, Tatuya

_______________________________________________
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=_083A2CEA-8848-4473-80AF-1CDE816F4F69-- From nobody Sun Jun 12 16:36: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 B90A912D759 for ; Sun, 12 Jun 2016 16:36:01 -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 V5nzy-X6a6xK for ; Sun, 12 Jun 2016 16:35:59 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4212D752 for ; Sun, 12 Jun 2016 16:35:59 -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 u5CNXhv1031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Jun 2016 16:33:43 -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: <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> Date: Sun, 12 Jun 2016 16:33:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <622C9359-6716-4550-A715-9331DB94ADCE@delong.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> To: "Templin, Fred L" 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]); Sun, 12 Jun 2016 16:33:44 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 12 Jun 2016 23:36:01 -0000 Fred, FWIW, I think that the consequences of not decrementing the hop limit = when doing in-link forwarding at a router are too great to justify your proposed = interpretation. Such a router is very unlikely to forward BPDUs on the same path and = therefore, you may end up with a hybridized loop where your =E2=80=9Csub-layer 3=E2=80=9D = forwarding is taking place along a path that doesn=E2=80=99t do =E2=80=9Clayer 2=E2=80=9D forwarding. = This would be, IMHO, bad. The behavior should be consistent at each layer. Owen > On Jun 9, 2016, at 14:19 , Templin, Fred L = wrote: >=20 > Hi Mark, >=20 > Everyone seems to be talking past each other on this thread, but to = address your point: >=20 >> I should have realised the place to look. RFC2460/RFC2460bis says for >> the Hop Limit field that it is "Decremented by 1 by each node that >> forwards the packet." >=20 > It depends on what you mean by "forwarding". The RFC2460 text is = referring > to forwarding *at the IP layer*. In response to Brian's question, I = answered > that AERO (and probably other NBMA link types) forward LL packets *at = the > sub-IP layer*. Meaning, the packets never leave the interface they are = received > on and get hairpinned out to the next hop without ever popping up to = the IP > layer. In that case, since the IP layer never handles them, the = hop-limit is > unchanged. I should have left it at that and not tried to extrapolate = to the > case of the packet popping up to the IP layer, but thanks for the = clarification. >=20 > Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Thursday, June 09, 2016 1:42 PM >> To: Templin, Fred L >> Cc: Brian E Carpenter ; Fernando Gont = ; Owen DeLong >> ; Mikael Abrahamsson ; = v6ops@ietf.org >> Subject: Re: [v6ops] Packets with LL src and GUA dst >>=20 >> Hi Fred, >>=20 >> On 10 June 2016 at 00:45, Templin, Fred L = wrote: >>> Hi Mark, >>>=20 >>>> -----Original Message----- >>>> From: Mark Smith [mailto:markzzzsmith@gmail.com] >>>> Sent: Wednesday, June 08, 2016 5:44 PM >>>> To: Templin, Fred L >>>> Cc: Brian E Carpenter ; Fernando Gont = ; Owen DeLong >>>> ; Mikael Abrahamsson ; = v6ops@ietf.org >>>> Subject: Re: [v6ops] Packets with LL src and GUA dst >>>>=20 >>>> On 9 June 2016 at 09:00, Templin, Fred L = wrote: >>>>> Hi Brian, >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E = Carpenter >>>>>> Sent: Wednesday, June 08, 2016 1:53 PM >>>>>> To: Fernando Gont ; Owen DeLong = ; Mikael Abrahamsson >> >>>>>> Cc: v6ops@ietf.org >>>>>> Subject: Re: [v6ops] Packets with LL src and GUA dst >>>>>>=20 >>>>>> On 08/06/2016 07:15, Fernando Gont wrote: >>>>>>> On 06/03/2016 06:12 PM, Owen DeLong wrote: >>>>>>>> Open bugs. >>>>>>>>=20 >>>>>>>> A device should not forward a packet with LL source or = destination address to any port other than the port on which it >> arrived. >>>>>>>=20 >>>>>>> Actually, it shouldn't forward such packets no matter what. >>>>>>=20 >>>>>> Surely there could be NBMA links where a router needs to forward = LL >>>>>> packets among neighbors? >>>>>=20 >>>>> Yes, that happens on AERO links. But, the hop-limit is not = decremented. >>>>>=20 >>>>=20 >>>> RFC4007, >>>>=20 >>>>=20 >>>> "Thus, if a >>>> router receives a packet with a link-local destination address = that >>>> is not one of the router's own link-local addresses on the = arrival >>>> link, the router is expected to try to forward the packet to the >>>> destination on that link (subject to successful determination of = the >>>> destination's link-layer address via the Neighbor Discovery = protocol >>>> [9]). The forwarded packet may be transmitted back through the >>>> arrival interface, or through any other interface attached to the >>>> same link." >>>>=20 >>>> I'd expect the hop-limit to be decremented. >>>=20 >>> The key text in the above passages is "may be transmitted back = through >>> the arrival interface, or through any other interface attached to = the same >>> link". This means that the packet with LL source address never = really leave >>> the link they arrived on. Instead, they are "hairpinned" either at = the IP >>> or sub-IP layers. So, the hop-limit should not be decremented. >>>=20 >>=20 >> I should have realised the place to look. RFC2460/RFC2460bis says for >> the Hop Limit field that it is "Decremented by 1 by each node that >> forwards the packet." >>=20 >> The above RFC4007 text is from a section titled to "Forwarding", so I >> think the HL should be decremented per RFC2460, even when being >> forwarded back onto the same link. >>=20 >> Regards, >> Mark. >>=20 >>> This leaves the question as to what to do about loops, since a = packet with >>> a non-decrementing hop-limit could potentially loop forever. The = only >>> answer that makes sense is to engineer the link so that no loops = will >>> ever be possible such as in AERO. >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>>> I'm pretty sure that the ND packets which start with HL of 255, and >>>> would be dropped if the HL doesn't arrive as 255, would not be >>>> impacted because they're specifically not to be forwarded, even = back >>>> onto the same link. >>>>=20 >>>> (The above is what would allow "Indicating Link-Local Unicast >>>> Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) = to >>>> work.) >>>>=20 >>>> Regards, >>>> Mark. >>>>=20 >>>>=20 >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >=20 From nobody Mon Jun 13 08:11: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 B4BC012D549 for ; Mon, 13 Jun 2016 08:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5Iuahs5G1lvK for ; Mon, 13 Jun 2016 08:11:40 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 9EE6A12D124 for ; Mon, 13 Jun 2016 08:11:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5DFBen6009603; Mon, 13 Jun 2016 08:11:40 -0700 Received: from XCH15-05-03.nw.nos.boeing.com (xch15-05-03.nw.nos.boeing.com [137.137.100.66]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5DFBZWL009539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2016 08:11:35 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-03.nw.nos.boeing.com (2002:8989:6442::8989:6442) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Jun 2016 08:11:34 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 13 Jun 2016 08:11:34 -0700 From: "Templin, Fred L" To: Owen DeLong Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CABVS6gIAAkFXg Date: Mon, 13 Jun 2016 15:11:34 +0000 Message-ID: <85f944433fc94e07bc2bc428b279ffa4@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <622C9359-6716-4550-A715-9331DB94ADCE@delong.com> In-Reply-To: <622C9359-6716-4550-A715-9331DB94ADCE@delong.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: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 15:11:43 -0000 SGkgT3dlbiwNCg0KSGVyZSBpcyB0aGUgdGV4dCAoc3VwcGxpZWQgYnkgSm9lIFRvdWNoKSB0aGF0 IGFjY3VyYXRlbHkgZGVzY3JpYmVzIHdoYXQgQUVSTyBpcyBkb2luZzoNCg0KPiAgICBIb3dldmVy LCBJUCByb3V0ZXJzIG1heQ0KPiAgICBicmlkZ2UgZnJhbWVzIGF0IExheWVyIDIgYmV0d2VlbiBw YXJ0cyBvZiBhIHN1Ym5ldHdvcmsuICBTb21ldGltZXMsDQo+ICAgIGl0IGlzIGNvbnZlbmllbnQg dG8gYWdncmVnYXRlIGEgZ3JvdXAgb2Ygc3VjaCBzdWJuZXR3b3JrcyBpbnRvIGENCj4gICAgc2lu Z2xlIGxvZ2ljYWwgc3VibmV0d29yay4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5A Ym9laW5nLmNvbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE93ZW4g RGVMb25nIFttYWlsdG86b3dlbkBkZWxvbmcuY29tXQ0KPiBTZW50OiBTdW5kYXksIEp1bmUgMTIs IDIwMTYgNDozNCBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPg0KPiBDYzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT47IEJyaWFu IEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBGZXJuYW5kbyBHb250 DQo+IDxmZXJuYW5kb0Bnb250LmNvbS5hcj47IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3 bS5wcC5zZT47IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFBhY2tldHMg d2l0aCBMTCBzcmMgYW5kIEdVQSBkc3QNCj4gDQo+IEZyZWQsDQo+IA0KPiBGV0lXLCBJIHRoaW5r IHRoYXQgdGhlIGNvbnNlcXVlbmNlcyBvZiBub3QgZGVjcmVtZW50aW5nIHRoZSBob3AgbGltaXQg d2hlbiBkb2luZyBpbi1saW5rDQo+IGZvcndhcmRpbmcgYXQgYSByb3V0ZXIgYXJlIHRvbyBncmVh dCB0byBqdXN0aWZ5IHlvdXIgcHJvcG9zZWQgaW50ZXJwcmV0YXRpb24uDQo+IA0KPiBTdWNoIGEg cm91dGVyIGlzIHZlcnkgdW5saWtlbHkgdG8gZm9yd2FyZCBCUERVcyBvbiB0aGUgc2FtZSBwYXRo IGFuZCB0aGVyZWZvcmUsIHlvdSBtYXkNCj4gZW5kIHVwIHdpdGggYSBoeWJyaWRpemVkIGxvb3Ag d2hlcmUgeW91ciDigJxzdWItbGF5ZXIgM+KAnSBmb3J3YXJkaW5nIGlzIHRha2luZyBwbGFjZSBh bG9uZw0KPiBhIHBhdGggdGhhdCBkb2VzbuKAmXQgZG8g4oCcbGF5ZXIgMuKAnSBmb3J3YXJkaW5n LiBUaGlzIHdvdWxkIGJlLCBJTUhPLCBiYWQuDQo+IA0KPiBUaGUgYmVoYXZpb3Igc2hvdWxkIGJl IGNvbnNpc3RlbnQgYXQgZWFjaCBsYXllci4NCj4gDQo+IE93ZW4NCj4gDQo+ID4gT24gSnVuIDks IDIwMTYsIGF0IDE0OjE5ICwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIE1hcmssDQo+ID4NCj4gPiBFdmVyeW9uZSBzZWVtcyB0 byBiZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlciBvbiB0aGlzIHRocmVhZCwgYnV0IHRvIGFkZHJl c3MgeW91ciBwb2ludDoNCj4gPg0KPiA+PiBJIHNob3VsZCBoYXZlIHJlYWxpc2VkIHRoZSBwbGFj ZSB0byBsb29rLiBSRkMyNDYwL1JGQzI0NjBiaXMgc2F5cyBmb3INCj4gPj4gdGhlIEhvcCBMaW1p dCBmaWVsZCB0aGF0IGl0IGlzICJEZWNyZW1lbnRlZCBieSAxIGJ5IGVhY2ggbm9kZSB0aGF0DQo+ ID4+IGZvcndhcmRzIHRoZSBwYWNrZXQuIg0KPiA+DQo+ID4gSXQgZGVwZW5kcyBvbiB3aGF0IHlv dSBtZWFuIGJ5ICJmb3J3YXJkaW5nIi4gVGhlIFJGQzI0NjAgdGV4dCBpcyByZWZlcnJpbmcNCj4g PiB0byBmb3J3YXJkaW5nICphdCB0aGUgSVAgbGF5ZXIqLiBJbiByZXNwb25zZSB0byBCcmlhbidz IHF1ZXN0aW9uLCBJIGFuc3dlcmVkDQo+ID4gdGhhdCBBRVJPIChhbmQgcHJvYmFibHkgb3RoZXIg TkJNQSBsaW5rIHR5cGVzKSBmb3J3YXJkIExMIHBhY2tldHMgKmF0IHRoZQ0KPiA+IHN1Yi1JUCBs YXllciouIE1lYW5pbmcsIHRoZSBwYWNrZXRzIG5ldmVyIGxlYXZlIHRoZSBpbnRlcmZhY2UgdGhl eSBhcmUgcmVjZWl2ZWQNCj4gPiBvbiBhbmQgZ2V0IGhhaXJwaW5uZWQgb3V0IHRvIHRoZSBuZXh0 IGhvcCB3aXRob3V0IGV2ZXIgcG9wcGluZyB1cCB0byB0aGUgSVANCj4gPiBsYXllci4gSW4gdGhh dCBjYXNlLCBzaW5jZSB0aGUgSVAgbGF5ZXIgbmV2ZXIgaGFuZGxlcyB0aGVtLCB0aGUgaG9wLWxp bWl0IGlzDQo+ID4gdW5jaGFuZ2VkLiBJIHNob3VsZCBoYXZlIGxlZnQgaXQgYXQgdGhhdCBhbmQg bm90IHRyaWVkIHRvIGV4dHJhcG9sYXRlIHRvIHRoZQ0KPiA+IGNhc2Ugb2YgdGhlIHBhY2tldCBw b3BwaW5nIHVwIHRvIHRoZSBJUCBsYXllciwgYnV0IHRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRp b24uDQo+ID4NCj4gPiBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE1hcmsgU21pdGggW21h aWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAw OSwgMjAxNiAxOjQyIFBNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+ID4+IENjOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPjsgRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI+OyBPd2Vu IERlTG9uZw0KPiA+PiA8b3dlbkBkZWxvbmcuY29tPjsgTWlrYWVsIEFicmFoYW1zc29uIDxzd21p a2VAc3dtLnBwLnNlPjsgdjZvcHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10g UGFja2V0cyB3aXRoIExMIHNyYyBhbmQgR1VBIGRzdA0KPiA+Pg0KPiA+PiBIaSBGcmVkLA0KPiA+ Pg0KPiA+PiBPbiAxMCBKdW5lIDIwMTYgYXQgMDA6NDUsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+PiBIaSBNYXJrLA0KPiA+Pj4NCj4gPj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IE1hcmsgU21pdGggW21h aWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPiA+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAwOCwgMjAxNiA1OjQ0IFBNDQo+ID4+Pj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4NCj4gPj4+PiBDYzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbT47IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFy PjsgT3dlbiBEZUxvbmcNCj4gPj4+PiA8b3dlbkBkZWxvbmcuY29tPjsgTWlrYWVsIEFicmFoYW1z c29uIDxzd21pa2VAc3dtLnBwLnNlPjsgdjZvcHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBQYWNrZXRzIHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0DQo+ID4+Pj4NCj4gPj4+ PiBPbiA5IEp1bmUgMjAxNiBhdCAwOTowMCwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPiB3cm90ZToNCj4gPj4+Pj4gSGkgQnJpYW4sDQo+ID4+Pj4+DQo+ID4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4gRnJvbTogdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50ZXIN Cj4gPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwOCwgMjAxNiAxOjUzIFBNDQo+ID4+Pj4+ PiBUbzogRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20uYXI+OyBPd2VuIERlTG9uZyA8 b3dlbkBkZWxvbmcuY29tPjsgTWlrYWVsIEFicmFoYW1zc29uDQo+ID4+IDxzd21pa2VAc3dtLnBw LnNlPg0KPiA+Pj4+Pj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTog W3Y2b3BzXSBQYWNrZXRzIHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gT24gMDgvMDYvMjAxNiAwNzoxNSwgRmVybmFuZG8gR29udCB3cm90ZToNCj4gPj4+Pj4+PiBP biAwNi8wMy8yMDE2IDA2OjEyIFBNLCBPd2VuIERlTG9uZyB3cm90ZToNCj4gPj4+Pj4+Pj4gT3Bl biBidWdzLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBIGRldmljZSBzaG91bGQgbm90IGZvcndh cmQgYSBwYWNrZXQgd2l0aCBMTCBzb3VyY2Ugb3IgZGVzdGluYXRpb24gYWRkcmVzcyB0byBhbnkg cG9ydCBvdGhlciB0aGFuIHRoZSBwb3J0IG9uIHdoaWNoIGl0DQo+ID4+IGFycml2ZWQuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBBY3R1YWxseSwgaXQgc2hvdWxkbid0IGZvcndhcmQgc3VjaCBwYWNr ZXRzIG5vIG1hdHRlciB3aGF0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFN1cmVseSB0aGVyZSBjb3Vs ZCBiZSBOQk1BIGxpbmtzIHdoZXJlIGEgcm91dGVyIG5lZWRzIHRvIGZvcndhcmQgTEwNCj4gPj4+ Pj4+IHBhY2tldHMgYW1vbmcgbmVpZ2hib3JzPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBZZXMsIHRoYXQg aGFwcGVucyBvbiBBRVJPIGxpbmtzLiBCdXQsIHRoZSBob3AtbGltaXQgaXMgbm90IGRlY3JlbWVu dGVkLg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gUkZDNDAwNywNCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4gIlRodXMsIGlmIGENCj4gPj4+PiAgIHJvdXRlciByZWNlaXZlcyBhIHBhY2tldCB3aXRo IGEgbGluay1sb2NhbCBkZXN0aW5hdGlvbiBhZGRyZXNzIHRoYXQNCj4gPj4+PiAgIGlzIG5vdCBv bmUgb2YgdGhlIHJvdXRlcidzIG93biBsaW5rLWxvY2FsIGFkZHJlc3NlcyBvbiB0aGUgYXJyaXZh bA0KPiA+Pj4+ICAgbGluaywgdGhlIHJvdXRlciBpcyBleHBlY3RlZCB0byB0cnkgdG8gZm9yd2Fy ZCB0aGUgcGFja2V0IHRvIHRoZQ0KPiA+Pj4+ICAgZGVzdGluYXRpb24gb24gdGhhdCBsaW5rIChz dWJqZWN0IHRvIHN1Y2Nlc3NmdWwgZGV0ZXJtaW5hdGlvbiBvZiB0aGUNCj4gPj4+PiAgIGRlc3Rp bmF0aW9uJ3MgbGluay1sYXllciBhZGRyZXNzIHZpYSB0aGUgTmVpZ2hib3IgRGlzY292ZXJ5IHBy b3RvY29sDQo+ID4+Pj4gICBbOV0pLiAgVGhlIGZvcndhcmRlZCBwYWNrZXQgbWF5IGJlIHRyYW5z bWl0dGVkIGJhY2sgdGhyb3VnaCB0aGUNCj4gPj4+PiAgIGFycml2YWwgaW50ZXJmYWNlLCBvciB0 aHJvdWdoIGFueSBvdGhlciBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gdGhlDQo+ID4+Pj4gICBzYW1l IGxpbmsuIg0KPiA+Pj4+DQo+ID4+Pj4gSSdkIGV4cGVjdCB0aGUgaG9wLWxpbWl0IHRvIGJlIGRl Y3JlbWVudGVkLg0KPiA+Pj4NCj4gPj4+IFRoZSBrZXkgdGV4dCBpbiB0aGUgYWJvdmUgcGFzc2Fn ZXMgaXMgIm1heSBiZSB0cmFuc21pdHRlZCBiYWNrIHRocm91Z2gNCj4gPj4+IHRoZSBhcnJpdmFs IGludGVyZmFjZSwgb3IgdGhyb3VnaCBhbnkgb3RoZXIgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIHRo ZSBzYW1lDQo+ID4+PiBsaW5rIi4gVGhpcyBtZWFucyB0aGF0IHRoZSBwYWNrZXQgd2l0aCBMTCBz b3VyY2UgYWRkcmVzcyBuZXZlciByZWFsbHkgbGVhdmUNCj4gPj4+IHRoZSBsaW5rIHRoZXkgYXJy aXZlZCBvbi4gSW5zdGVhZCwgdGhleSBhcmUgImhhaXJwaW5uZWQiIGVpdGhlciBhdCB0aGUgSVAN Cj4gPj4+IG9yIHN1Yi1JUCBsYXllcnMuIFNvLCB0aGUgaG9wLWxpbWl0IHNob3VsZCBub3QgYmUg ZGVjcmVtZW50ZWQuDQo+ID4+Pg0KPiA+Pg0KPiA+PiBJIHNob3VsZCBoYXZlIHJlYWxpc2VkIHRo ZSBwbGFjZSB0byBsb29rLiBSRkMyNDYwL1JGQzI0NjBiaXMgc2F5cyBmb3INCj4gPj4gdGhlIEhv cCBMaW1pdCBmaWVsZCB0aGF0IGl0IGlzICJEZWNyZW1lbnRlZCBieSAxIGJ5IGVhY2ggbm9kZSB0 aGF0DQo+ID4+IGZvcndhcmRzIHRoZSBwYWNrZXQuIg0KPiA+Pg0KPiA+PiBUaGUgYWJvdmUgUkZD NDAwNyB0ZXh0IGlzIGZyb20gYSBzZWN0aW9uIHRpdGxlZCB0byAiRm9yd2FyZGluZyIsIHNvIEkN Cj4gPj4gdGhpbmsgdGhlIEhMIHNob3VsZCBiZSBkZWNyZW1lbnRlZCBwZXIgUkZDMjQ2MCwgZXZl biB3aGVuIGJlaW5nDQo+ID4+IGZvcndhcmRlZCBiYWNrIG9udG8gdGhlIHNhbWUgbGluay4NCj4g Pj4NCj4gPj4gUmVnYXJkcywNCj4gPj4gTWFyay4NCj4gPj4NCj4gPj4+IFRoaXMgbGVhdmVzIHRo ZSBxdWVzdGlvbiBhcyB0byB3aGF0IHRvIGRvIGFib3V0IGxvb3BzLCBzaW5jZSBhIHBhY2tldCB3 aXRoDQo+ID4+PiBhIG5vbi1kZWNyZW1lbnRpbmcgaG9wLWxpbWl0IGNvdWxkIHBvdGVudGlhbGx5 IGxvb3AgZm9yZXZlci4gVGhlIG9ubHkNCj4gPj4+IGFuc3dlciB0aGF0IG1ha2VzIHNlbnNlIGlz IHRvIGVuZ2luZWVyIHRoZSBsaW5rIHNvIHRoYXQgbm8gbG9vcHMgd2lsbA0KPiA+Pj4gZXZlciBi ZSBwb3NzaWJsZSBzdWNoIGFzIGluIEFFUk8uDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIC0gRnJlZA0K PiA+Pj4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+Pj4NCj4gPj4+PiBJJ20gcHJldHR5 IHN1cmUgdGhhdCB0aGUgTkQgcGFja2V0cyB3aGljaCBzdGFydCB3aXRoIEhMIG9mIDI1NSwgYW5k DQo+ID4+Pj4gd291bGQgYmUgZHJvcHBlZCBpZiB0aGUgSEwgZG9lc24ndCBhcnJpdmUgYXMgMjU1 LCB3b3VsZCBub3QgYmUNCj4gPj4+PiBpbXBhY3RlZCBiZWNhdXNlIHRoZXkncmUgc3BlY2lmaWNh bGx5IG5vdCB0byBiZSBmb3J3YXJkZWQsIGV2ZW4gYmFjaw0KPiA+Pj4+IG9udG8gdGhlIHNhbWUg bGluay4NCj4gPj4+Pg0KPiA+Pj4+IChUaGUgYWJvdmUgaXMgd2hhdCB3b3VsZCBhbGxvdyAiSW5k aWNhdGluZyBMaW5rLUxvY2FsIFVuaWNhc3QNCj4gPj4+PiBEZXN0aW5hdGlvbnMgYXJlIE9mZi1M aW5rIiAoZHJhZnQtc21pdGgtNm1hbi1saW5rLWxvY2Fscy1vZmYtbGluaykgdG8NCj4gPj4+PiB3 b3JrLikNCj4gPj4+Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4gTWFyay4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4+IFRoYW5rcyAtIEZyZWQNCj4gPj4+Pj4gZnJlZC5sLnRlbXBsaW5AYm9laW5n LmNvbQ0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gICBCcmlhbg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+PiB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+Pj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pg0KPiA+ DQo+IA0KDQo= From nobody Mon Jun 13 08:38: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 1D10E12D597 for ; Mon, 13 Jun 2016 08:38: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 rKzYi56L4R2H for ; Mon, 13 Jun 2016 08:38:47 -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 799E412D549 for ; Mon, 13 Jun 2016 08:38:47 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5DFbxqU008733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 08:38:00 -0700 (PDT) To: "Templin, Fred L" , Owen DeLong References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <622C9359-6716-4550-A715-9331DB94ADCE@delong.com> <85f944433fc94e07bc2bc428b279ffa4@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <575ED357.5010309@isi.edu> Date: Mon, 13 Jun 2016 08:37:59 -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: <85f944433fc94e07bc2bc428b279ffa4@XCH15-05-05.nw.nos.boeing.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" , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 15:38:49 -0000 Hi, all, To be clear on my text: Bridging different L2 subnets into a single logical subnet isn't a required *router* function. A device operating in that way is acting as an L2 switch/bridge, not an L3 router. Yes, some L3 routers include L2 capabilities, though. Some such devices use L3 headers to help determine which L2 addresses are part of the same logical subnet, but that's a convenience and shouldn't be a requirement either. Joe On 6/13/2016 8:11 AM, Templin, Fred L wrote: > Hi Owen, > > Here is the text (supplied by Joe Touch) that accurately describes what AERO is doing: > >> However, IP routers may >> bridge frames at Layer 2 between parts of a subnetwork. Sometimes, >> it is convenient to aggregate a group of such subnetworks into a >> single logical subnetwork. > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Owen DeLong [mailto:owen@delong.com] >> Sent: Sunday, June 12, 2016 4:34 PM >> To: Templin, Fred L >> Cc: Mark Smith ; Brian E Carpenter ; Fernando Gont >> ; Mikael Abrahamsson ; v6ops@ietf.org >> Subject: Re: [v6ops] Packets with LL src and GUA dst >> >> Fred, >> >> FWIW, I think that the consequences of not decrementing the hop limit when doing in-link >> forwarding at a router are too great to justify your proposed interpretation. >> >> Such a router is very unlikely to forward BPDUs on the same path and therefore, you may >> end up with a hybridized loop where your “sub-layer 3†forwarding is taking place along >> a path that doesn’t do “layer 2†forwarding. This would be, IMHO, bad. >> >> The behavior should be consistent at each layer. >> >> Owen >> >>> On Jun 9, 2016, at 14:19 , Templin, Fred L wrote: >>> >>> Hi Mark, >>> >>> Everyone seems to be talking past each other on this thread, but to address your point: >>> >>>> I should have realised the place to look. RFC2460/RFC2460bis says for >>>> the Hop Limit field that it is "Decremented by 1 by each node that >>>> forwards the packet." >>> It depends on what you mean by "forwarding". The RFC2460 text is referring >>> to forwarding *at the IP layer*. In response to Brian's question, I answered >>> that AERO (and probably other NBMA link types) forward LL packets *at the >>> sub-IP layer*. Meaning, the packets never leave the interface they are received >>> on and get hairpinned out to the next hop without ever popping up to the IP >>> layer. In that case, since the IP layer never handles them, the hop-limit is >>> unchanged. I should have left it at that and not tried to extrapolate to the >>> case of the packet popping up to the IP layer, but thanks for the clarification. >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: Mark Smith [mailto:markzzzsmith@gmail.com] >>>> Sent: Thursday, June 09, 2016 1:42 PM >>>> To: Templin, Fred L >>>> Cc: Brian E Carpenter ; Fernando Gont ; Owen DeLong >>>> ; Mikael Abrahamsson ; v6ops@ietf.org >>>> Subject: Re: [v6ops] Packets with LL src and GUA dst >>>> >>>> Hi Fred, >>>> >>>> On 10 June 2016 at 00:45, Templin, Fred L wrote: >>>>> Hi Mark, >>>>> >>>>>> -----Original Message----- >>>>>> From: Mark Smith [mailto:markzzzsmith@gmail.com] >>>>>> Sent: Wednesday, June 08, 2016 5:44 PM >>>>>> To: Templin, Fred L >>>>>> Cc: Brian E Carpenter ; Fernando Gont ; Owen DeLong >>>>>> ; Mikael Abrahamsson ; v6ops@ietf.org >>>>>> Subject: Re: [v6ops] Packets with LL src and GUA dst >>>>>> >>>>>> On 9 June 2016 at 09:00, Templin, Fred L wrote: >>>>>>> Hi Brian, >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >>>>>>>> Sent: Wednesday, June 08, 2016 1:53 PM >>>>>>>> To: Fernando Gont ; Owen DeLong ; Mikael Abrahamsson >>>> >>>>>>>> Cc: v6ops@ietf.org >>>>>>>> Subject: Re: [v6ops] Packets with LL src and GUA dst >>>>>>>> >>>>>>>> On 08/06/2016 07:15, Fernando Gont wrote: >>>>>>>>> On 06/03/2016 06:12 PM, Owen DeLong wrote: >>>>>>>>>> Open bugs. >>>>>>>>>> >>>>>>>>>> A device should not forward a packet with LL source or destination address to any port other than the port on which it >>>> arrived. >>>>>>>>> Actually, it shouldn't forward such packets no matter what. >>>>>>>> Surely there could be NBMA links where a router needs to forward LL >>>>>>>> packets among neighbors? >>>>>>> Yes, that happens on AERO links. But, the hop-limit is not decremented. >>>>>>> >>>>>> RFC4007, >>>>>> >>>>>> >>>>>> "Thus, if a >>>>>> router receives a packet with a link-local destination address that >>>>>> is not one of the router's own link-local addresses on the arrival >>>>>> link, the router is expected to try to forward the packet to the >>>>>> destination on that link (subject to successful determination of the >>>>>> destination's link-layer address via the Neighbor Discovery protocol >>>>>> [9]). The forwarded packet may be transmitted back through the >>>>>> arrival interface, or through any other interface attached to the >>>>>> same link." >>>>>> >>>>>> I'd expect the hop-limit to be decremented. >>>>> The key text in the above passages is "may be transmitted back through >>>>> the arrival interface, or through any other interface attached to the same >>>>> link". This means that the packet with LL source address never really leave >>>>> the link they arrived on. Instead, they are "hairpinned" either at the IP >>>>> or sub-IP layers. So, the hop-limit should not be decremented. >>>>> >>>> I should have realised the place to look. RFC2460/RFC2460bis says for >>>> the Hop Limit field that it is "Decremented by 1 by each node that >>>> forwards the packet." >>>> >>>> The above RFC4007 text is from a section titled to "Forwarding", so I >>>> think the HL should be decremented per RFC2460, even when being >>>> forwarded back onto the same link. >>>> >>>> Regards, >>>> Mark. >>>> >>>>> This leaves the question as to what to do about loops, since a packet with >>>>> a non-decrementing hop-limit could potentially loop forever. The only >>>>> answer that makes sense is to engineer the link so that no loops will >>>>> ever be possible such as in AERO. >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>>> I'm pretty sure that the ND packets which start with HL of 255, and >>>>>> would be dropped if the HL doesn't arrive as 255, would not be >>>>>> impacted because they're specifically not to be forwarded, even back >>>>>> onto the same link. >>>>>> >>>>>> (The above is what would allow "Indicating Link-Local Unicast >>>>>> Destinations are Off-Link" (draft-smith-6man-link-locals-off-link) to >>>>>> work.) >>>>>> >>>>>> Regards, >>>>>> Mark. >>>>>> >>>>>> >>>>>>> Thanks - Fred >>>>>>> fred.l.templin@boeing.com >>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 Mon Jun 13 12:02: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 AEF5212D0A1 for ; Mon, 13 Jun 2016 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 9vToOk6zwM83 for ; Mon, 13 Jun 2016 12:02:15 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 211F812D945 for ; Mon, 13 Jun 2016 12:02:04 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id v48so54989640qgd.2 for ; Mon, 13 Jun 2016 12:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4UA/2pEFG8S2QvSHdD/aDdio1bNtE3cXmt4m2m+8AGo=; b=wukAdjTk1VaYLMTq0avg6AZXyRjTAbIVz1S0bFY8ceTRs9/y78frlkbIfE4n5qaZt5 d6fqLY9gHPUPEuvitIkgqku5lEynpvLvEiWJ+1vswk8DHMUmmUAFO2FvwVkTp3uAIxpv 8jGaZQ8DWxwPcMj5ARjdF3OCpCEwe3Hl8gObbim275/Y/PydGtgxF3kd24v8uLRn8oib qk0aRrl1jLV0c42x5izN9mV6J6+t9XCljKaDpJVFCw+1Z60PamL6dDUSJ3Gy+MRU+kFl S/U5WMsmFKbpyXsPltN+pLoguJhqA2rTNciMK4gS9fAUXS7XT/PamU1+Bn4E70geUfp9 NzxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4UA/2pEFG8S2QvSHdD/aDdio1bNtE3cXmt4m2m+8AGo=; b=juREIrfI/dI4+4pbSV7/woKc2JJiM0XHnSPdd6dkR63/C2u5NuP90hA1Pq8COYwj4S pXq5NA03uYKfmPkV5WCPp1no6d4Bl/6de5Wc5sG6b5trORADWZAn86Q2aPzw9jik44Fb tazORBhD/9cUKZuGruXrScLaNnRy43cji3aBe/43GSsIOKivL7rVb7MrwgDhk7bYO7Dd rHypBiUvBKE9xwmz2hJPe7b7Q56zxrsso+KK9wolINyIsoyz8kOWx+VxO5s9/t2W64y6 Ffe+qBmyQNMHRnnAAsEzHR15C+V1k6GBWQnqWLBSYDlZX3Cc79dTrupYx4/W2P87bL78 pm4g== X-Gm-Message-State: ALyK8tL90uXI6v98z8/s+sDib23OPVxXlts3gS33yJT/RQrVAyQ0Gb8KMpuwhQ//MYjlOCVdOMY/k2JwbHOT5w== X-Received: by 10.140.148.209 with SMTP id 200mr16021009qhu.60.1465844523309; Mon, 13 Jun 2016 12:02:03 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.166 with HTTP; Mon, 13 Jun 2016 12:02:01 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 13 Jun 2016 12:02:01 -0700 X-Google-Sender-Auth: mTVLKZyiim5IF5ODIKLKN5DAdLE Message-ID: To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 19:02:22 -0000 At Sat, 11 Jun 2016 10:50:06 +1000, Mark Smith wrote: > > > Right. People were saying that LL addressed packets should never be > > > forwarded, and I think they were talking about layer 3 forwarding of > them. > > > I was pointing out that they can be as per-RFC4007, limited to back on > to > > > the link they came from. > > > > As far as I understand it RFC4007 only talks about "layer 3 > > forwarding". We can freely discuss whether there's such a concept as > > "forwarding sub-IP layer" and/or whether the hop limit should be > > decremented in that case, but RFC4007 should be independent from that > > discussion. > > So how can it not be layer 3 forwarding if the device is looking at layer 3 > addresses and acting on them? It can't. I believe we're on the same page on that point. I just wanted to make it clear that text in RFC4007 can't be used to justify some odd behavior unrelated to layer 3 (e.g., "skip decrementing hop limit because it's 'sub-layer3 forwarding' - no part of the RFC4007 text talks about such things). > This seems to have wandered off topic - it was about whether a packet with > a LL src and a GUA dst should be (layer 3) forwarded by a router. Right, whether/how packets whose dest is LL was completely off topic of the original thread (I don't think it was me who introduced this distraction, though:-). -- JINMEI, Tatuya From nobody Mon Jun 13 12:22: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 D39EA12D945 for ; Mon, 13 Jun 2016 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AiVwTHSwgTw5 for ; Mon, 13 Jun 2016 12:22:32 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 3D53A12D0B0 for ; Mon, 13 Jun 2016 12:22:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5DJMOpk021007; Mon, 13 Jun 2016 12:22:24 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5DJMIEU020914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2016 12:22:18 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Jun 2016 12:22:17 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 13 Jun 2016 12:22:17 -0700 From: "Templin, Fred L" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Mark Smith Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CABiYLiIAABMDA Date: Mon, 13 Jun 2016 19:22:17 +0000 Message-ID: <1a0003cc8ce24bd9a5ee90da3a81c431@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: 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: [137.136.248.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 19:22:36 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of ???? > Sent: Monday, June 13, 2016 12:02 PM > To: Mark Smith > Cc: v6ops list ; Fernando Gont > Subject: Re: [v6ops] Packets with LL src and GUA dst >=20 > At Sat, 11 Jun 2016 10:50:06 +1000, > Mark Smith wrote: >=20 > > > > Right. People were saying that LL addressed packets should never be > > > > forwarded, and I think they were talking about layer 3 forwarding o= f > > them. > > > > I was pointing out that they can be as per-RFC4007, limited to back= on > > to > > > > the link they came from. > > > > > > As far as I understand it RFC4007 only talks about "layer 3 > > > forwarding". We can freely discuss whether there's such a concept as > > > "forwarding sub-IP layer" and/or whether the hop limit should be > > > decremented in that case, but RFC4007 should be independent from that > > > discussion. > > > > So how can it not be layer 3 forwarding if the device is looking at lay= er 3 > > addresses and acting on them? >=20 > It can't. I believe we're on the same page on that point. I just > wanted to make it clear that text in RFC4007 can't be used to justify > some odd behavior unrelated to layer 3 (e.g., "skip decrementing hop > limit because it's 'sub-layer3 forwarding' - no part of the RFC4007 > text talks about such things). Yes it can, per Joe's explanation. This has nothing to do with RFC4007, which I never cited. > > This seems to have wandered off topic - it was about whether a packet w= ith > > a LL src and a GUA dst should be (layer 3) forwarded by a router. >=20 > Right, whether/how packets whose dest is LL was completely off topic > of the original thread (I don't think it was me who introduced this > distraction, though:-). Brian asked about NBMA links; AERO is NBMA. Thanks - Fred fred.l.templin@boeing.com > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jun 13 13:15:14 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 598A412D9BE for ; Mon, 13 Jun 2016 13:15:12 -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 n5_BO2ZWMcup for ; Mon, 13 Jun 2016 13:15:11 -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 7AFA112D62D for ; Mon, 13 Jun 2016 13:13:47 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5DKDBKe024903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 13:13:11 -0700 (PDT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Mark Smith References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <30ead41d-203f-faa2-dcd9-fbae85543ff0@isi.edu> Date: Mon, 13 Jun 2016 13:13:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6EB1B09685EA6DFB46004931" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 20:15:12 -0000 This is a multi-part message in MIME format. --------------6EB1B09685EA6DFB46004931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 6/13/2016 12:02 PM, 神明é”哉 wrote: >> So how can it not be layer 3 forwarding if the device is looking at layer 3 >> > addresses and acting on them? > It can't. A device can look at whatever it wants (or at least has access to). What matters is how it behaves. A device that deliberately doesn't decrement the IP hopcount is intending to make two subnets act like one to IP. It doesn't matter what it looks at or whether it preserves L2 headers. To *IP*, the result is (or ought to be) indistinguishable from a single L2 subnet. The rest is irrelevant - i.e., how it decides which to subnets to combine, etc. However - that behavior ends up making the device look like it's an L2 switch, not an IP router. That behavior is not what is expected of an IP router, but those devices do a lot of things that they're neither expected nor desired to do. Joe --------------6EB1B09685EA6DFB46004931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit



On 6/13/2016 12:02 PM, 神明é”哉 wrote:
So how can it not be layer 3 forwarding if the device is looking at layer 3
> addresses and acting on them?

It can't.
A device can look at whatever it wants (or at least has access to).

What matters is how it behaves.

A device that deliberately doesn't decrement the IP hopcount is intending to make two subnets act like one to IP. It doesn't matter what it looks at or whether it preserves L2 headers. To *IP*, the result is (or ought to be) indistinguishable from a single L2 subnet.

The rest is irrelevant - i.e., how it decides which to subnets to combine, etc.

However - that behavior ends up making the device look like it's an L2 switch, not an IP router. That behavior is not what is expected of an IP router, but those devices do a lot of things that they're neither expected nor desired to do.

Joe
--------------6EB1B09685EA6DFB46004931-- From nobody Mon Jun 13 13:15: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 1983312D645 for ; Mon, 13 Jun 2016 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 nKSDsl0Ry3Ry for ; Mon, 13 Jun 2016 13:15:40 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 EC02812D63C for ; Mon, 13 Jun 2016 13:15:34 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id v48so56122040qgd.2 for ; Mon, 13 Jun 2016 13:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yBEOihTIGlcYt5QGwKX5TlmaS192uzByaMxvI8tSch8=; b=spFcj9EReioXSDR6MOoBeCpcwn4rfU6ANxGgDpdsUYHRh9rzGrB/FQKvh2oltEXLdP vci/JLtjz40iMmTNMlewcsbUIsX1o7atrMD3nlRinTOGoZDZck06V1+nfxc37JAof6hR kx00+K1bHEtlRwTE/Jee4H3Jg6V2YlCEKM4g0aR8oeJxcI7n06Co8F2OlNfPKXpSzMg/ 1TNzfqfIC9YugVkFtehjsD351LOYxhgM4FjqdUCrGSrn51dtVWEkNKM58KyJqk/ko5FA lMFpuJcMuDYt1wUCzXBlEO1NmpwKRTcMi2xFEyHY4tCdneeT2Lf+2Qa13Xq8RjFXW/Tj wXkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yBEOihTIGlcYt5QGwKX5TlmaS192uzByaMxvI8tSch8=; b=iJo9J+03QVP7R46OQnd6ns+WXy53ZMxajVX6MZqkDE8EAmkcTIBMlNtrYhfhrLnqD9 JzVQcKzAGUyA5gQsO9Hs0EI31gOqXzrsDgF1FjKxZqJRMJ4fK37vXL6I9lqfR69MmvD9 5zeE8lA+RRkBt8gjD+qGdZdt0pvcWZ8JGPWzEAeJMKBrayup1qHJZLbqiFsVHnBASAyQ JHeAeZgC2xuJmB9dTUUuBdvP6mOyLvjoil4hO1nuWawAC/ClLIz1E6z+9lxaZ2Og1xuz YwmragCyCFX10vl7d5PzVZ/UxGP2VXE4Srbb1G+2G+s0H7EPQFVqjZjCvRrds4OOnLQJ D/4Q== X-Gm-Message-State: ALyK8tL69s/02GF1dTtIA3uSizNh6uu8i4h5xXg6mJgz73bnRKz1i0VzuzXUCWW4P2G6O03WZqj7SXIZUW+H4A== X-Received: by 10.140.100.179 with SMTP id s48mr15106085qge.19.1465848934074; Mon, 13 Jun 2016 13:15:34 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.166 with HTTP; Mon, 13 Jun 2016 13:15:32 -0700 (PDT) In-Reply-To: <1a0003cc8ce24bd9a5ee90da3a81c431@XCH15-05-05.nw.nos.boeing.com> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <1a0003cc8ce24bd9a5ee90da3a81c431@XCH15-05-05.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 13 Jun 2016 13:15:32 -0700 X-Google-Sender-Auth: Xc1nFfs1O4MQdhVI4H8J1xuxifg Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 20:15:42 -0000 At Mon, 13 Jun 2016 19:22:17 +0000, "Templin, Fred L" wrote: > > > So how can it not be layer 3 forwarding if the device is looking at layer 3 > > > addresses and acting on them? > > > > It can't. I believe we're on the same page on that point. I just > > wanted to make it clear that text in RFC4007 can't be used to justify > > some odd behavior unrelated to layer 3 (e.g., "skip decrementing hop > > limit because it's 'sub-layer3 forwarding' - no part of the RFC4007 > > text talks about such things). > > Yes it can, per Joe's explanation. This has nothing to do with RFC4007, > which I never cited. Regarding the (ir)relevance of RFC4007, I specifically meant this comment: http://www.ietf.org/mail-archive/web/v6ops/current/msg24765.html >> The key text in the above passages is "may be transmitted back through >> the arrival interface, or through any other interface attached to the same >> link". This means that the packet with LL source address never really leave >> the link they arrived on. Instead, they are "hairpinned" either at the IP >> or sub-IP layers. So, the hop-limit should not be decremented. To me, this could read as if you cited RFC4007 (the double-quoted part) and used that text to justify skipping decrementing the hop limit. All I've been trying to do is to clarify that RFC4007 shouldn't be interpreted that way. If, in this comment, you didn't actually intend to cite RFC4007 or didn't mean to use it as a justification for the sub-IP layer things, that's fine (although in that case you might not copy the RFC4007 text with the double-quotations). I just wanted to make it very clear it's not misunderstood. -- JINMEI, Tatuya From nobody Mon Jun 13 13:32: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 3022212D83B for ; Mon, 13 Jun 2016 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 M8N9OLw9ayDF for ; Mon, 13 Jun 2016 13:32:52 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 CBB4912D7DE for ; Mon, 13 Jun 2016 13:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5DKWnoS029630; Mon, 13 Jun 2016 13:32:50 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5DKWdtI029545 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2016 13:32:39 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Jun 2016 13:32:38 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 13 Jun 2016 13:32:38 -0700 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] Packets with LL src and GUA dst Thread-Index: AQHRwcfJ9KPjdx4EnEGkGjbPVrHcCJ/gLyXAgACSiQCAAHQA4IAA2syA//+SS9CABiYLiIAABMDAgACE5QD//416IA== Date: Mon, 13 Jun 2016 20:32:38 +0000 Message-ID: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <81d01eab61cd4adc9e441bcda18e9c06@XCH15-05-05.nw.nos.boeing.com> <1a0003cc8ce24bd9a5ee90da3a81c431@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: 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: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list , Fernando Gont Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 13 Jun 2016 20:32:55 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogamlubWVpLnRhdHV5 YUBnbWFpbC5jb20gW21haWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m ID8/Pz8NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDE2IDE6MTYgUE0NCj4gVG86IFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IE1hcmsgU21pdGgg PG1hcmt6enpzbWl0aEBnbWFpbC5jb20+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IEZl cm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBQYWNrZXRzIHdpdGggTEwgc3JjIGFuZCBHVUEgZHN0DQo+IA0KPiBBdCBNb24sIDEzIEp1biAy MDE2IDE5OjIyOjE3ICswMDAwLA0KPiAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiA+ID4gPiBTbyBob3cgY2FuIGl0IG5vdCBiZSBsYXll ciAzIGZvcndhcmRpbmcgaWYgdGhlIGRldmljZSBpcyBsb29raW5nIGF0IGxheWVyIDMNCj4gPiA+ ID4gYWRkcmVzc2VzIGFuZCBhY3Rpbmcgb24gdGhlbT8NCj4gPiA+DQo+ID4gPiBJdCBjYW4ndC4g IEkgYmVsaWV2ZSB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlIG9uIHRoYXQgcG9pbnQuICBJIGp1c3QN Cj4gPiA+IHdhbnRlZCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGV4dCBpbiBSRkM0MDA3IGNhbid0 IGJlIHVzZWQgdG8ganVzdGlmeQ0KPiA+ID4gc29tZSBvZGQgYmVoYXZpb3IgdW5yZWxhdGVkIHRv IGxheWVyIDMgKGUuZy4sICJza2lwIGRlY3JlbWVudGluZyBob3ANCj4gPiA+IGxpbWl0IGJlY2F1 c2UgaXQncyAnc3ViLWxheWVyMyBmb3J3YXJkaW5nJyAtIG5vIHBhcnQgb2YgdGhlIFJGQzQwMDcN Cj4gPiA+IHRleHQgdGFsa3MgYWJvdXQgc3VjaCB0aGluZ3MpLg0KPiA+DQo+ID4gWWVzIGl0IGNh biwgcGVyIEpvZSdzIGV4cGxhbmF0aW9uLiBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggUkZD NDAwNywNCj4gPiB3aGljaCBJIG5ldmVyIGNpdGVkLg0KPiANCj4gUmVnYXJkaW5nIHRoZSAoaXIp cmVsZXZhbmNlIG9mIFJGQzQwMDcsIEkgc3BlY2lmaWNhbGx5IG1lYW50IHRoaXMNCj4gY29tbWVu dDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQv bXNnMjQ3NjUuaHRtbA0KPiANCj4gPj4gVGhlIGtleSB0ZXh0IGluIHRoZSBhYm92ZSBwYXNzYWdl cyBpcyAibWF5IGJlIHRyYW5zbWl0dGVkIGJhY2sgdGhyb3VnaA0KPiA+PiB0aGUgYXJyaXZhbCBp bnRlcmZhY2UsIG9yIHRocm91Z2ggYW55IG90aGVyIGludGVyZmFjZSBhdHRhY2hlZCB0byB0aGUg c2FtZQ0KPiA+PiBsaW5rIi4gVGhpcyBtZWFucyB0aGF0IHRoZSBwYWNrZXQgd2l0aCBMTCBzb3Vy Y2UgYWRkcmVzcyBuZXZlciByZWFsbHkgbGVhdmUNCj4gPj4gdGhlIGxpbmsgdGhleSBhcnJpdmVk IG9uLiBJbnN0ZWFkLCB0aGV5IGFyZSAiaGFpcnBpbm5lZCIgZWl0aGVyIGF0IHRoZSBJUA0KPiA+ PiBvciBzdWItSVAgbGF5ZXJzLiBTbywgdGhlIGhvcC1saW1pdCBzaG91bGQgbm90IGJlIGRlY3Jl bWVudGVkLg0KPiANCj4gVG8gbWUsIHRoaXMgY291bGQgcmVhZCBhcyBpZiB5b3UgY2l0ZWQgUkZD NDAwNyAodGhlIGRvdWJsZS1xdW90ZWQNCj4gcGFydCkgYW5kIHVzZWQgdGhhdCB0ZXh0IHRvIGp1 c3RpZnkgc2tpcHBpbmcgZGVjcmVtZW50aW5nIHRoZSBob3ANCj4gbGltaXQuICBBbGwgSSd2ZSBi ZWVuIHRyeWluZyB0byBkbyBpcyB0byBjbGFyaWZ5IHRoYXQgUkZDNDAwNw0KPiBzaG91bGRuJ3Qg YmUgaW50ZXJwcmV0ZWQgdGhhdCB3YXkuICBJZiwgaW4gdGhpcyBjb21tZW50LCB5b3UgZGlkbid0 DQo+IGFjdHVhbGx5IGludGVuZCB0byBjaXRlIFJGQzQwMDcgb3IgZGlkbid0IG1lYW4gdG8gdXNl IGl0IGFzIGENCj4ganVzdGlmaWNhdGlvbiBmb3IgdGhlIHN1Yi1JUCBsYXllciB0aGluZ3MsIHRo YXQncyBmaW5lIChhbHRob3VnaCBpbg0KPiB0aGF0IGNhc2UgeW91IG1pZ2h0IG5vdCBjb3B5IHRo ZSBSRkM0MDA3IHRleHQgd2l0aCB0aGUNCj4gZG91YmxlLXF1b3RhdGlvbnMpLiAgSSBqdXN0IHdh bnRlZCB0byBtYWtlIGl0IHZlcnkgY2xlYXIgaXQncyBub3QNCj4gbWlzdW5kZXJzdG9vZC4NCg0K T0ssIEkgdW5kZXJzdGFuZCBub3cuIFllcywgcGVyIHRoZSBtZXNzYWdlIHlvdSBxdW90ZWQgYWJv dmUgaXQgY291bGQgcmVhZA0KYXMgaWYgSSB3YXMgY2l0aW5nIFJGQzQwMDcuIEJ1dCwgdmVyeSBz b29uIGFmdGVyIHRoYXQgbWVzc2FnZSBNYXJrIFNtaXRoIHBvc3RlZA0KYSBjb3JyZWN0aW9uIGFu ZCBJIGFja25vd2xlZGdlZCBhbmQgdGhhbmtlZCBoaW0gZm9yIHRoZSBjbGFyaWZpY2F0aW9uOg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNn MjQ3NzMuaHRtbA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9j dXJyZW50L21zZzI0Nzc0Lmh0bWwNCg0KU2luY2UgdGhlbiwgbm9uZSBvZiBteSBwb3N0cyBoYXZl IGJlZW4gaW50ZW5kZWQgaW4gdGhlIHNwaXJpdCBvZiB0aGUNClJGQzQwMDcgdGV4dC4gU29ycnkg Zm9yIGFueSBjb25mdXNpb24uDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWlu Zy5jb20NCg0KPiAtLQ0KPiBKSU5NRUksIFRhdHV5YQ0KDQo= From nobody Wed Jun 15 01:32: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 3527912B071 for ; Wed, 15 Jun 2016 01:32:23 -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 y5SmlbvFWXK7 for ; Wed, 15 Jun 2016 01:32:20 -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 E193312D190 for ; Wed, 15 Jun 2016 01:32:19 -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 u5F8WCI7016730; Wed, 15 Jun 2016 10:32:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93E1520C352; Wed, 15 Jun 2016 10:32:52 +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 8500220C33F; Wed, 15 Jun 2016 10:32:52 +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 u5F8WBI3000458; Wed, 15 Jun 2016 10:32:11 +0200 To: Owen DeLong References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Alexandre Petrescu Message-ID: Date: Wed, 15 Jun 2016 10:32:11 +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: <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 08:32:24 -0000 Le 13/06/2016 à 01:31, Owen DeLong a écrit : > >> On Jun 9, 2016, at 13:09 , Alexandre Petrescu >> > > wrote: >> >> >> >> Le 09/06/2016 à 19:24, 神明é”哉 a écrit : >>> At Thu, 9 Jun 2016 14:45:48 +0000, "Templin, Fred L" >>> > >>> wrote: >>> >>>>> RFC4007, >>>>> >>>>> >>>>> "Thus, if a router receives a packet with a link-local >>>>> destination address that is not one of the router's own >>>>> link-local addresses on the arrival link, the router is >>>>> expected to try to forward the packet to the destination on >>>>> that link (subject to successful determination of the >>>>> destination's link-layer address via the Neighbor Discovery >>>>> protocol [9]). The forwarded packet may be transmitted back >>>>> through the arrival interface, or through any other >>>>> interface attached to the same link." >>>>> >>>>> I'd expect the hop-limit to be decremented. >>>> >>>> The key text in the above passages is "may be transmitted back >>>> through the arrival interface, or through any other interface >>>> attached to the same link". This means that the packet with LL >>>> source address never really leave the link they arrived on. >>>> Instead, they are "hairpinned" either at the IP or sub-IP >>>> layers. So, the hop-limit should not be decremented. >>> >>> I'm pretty sure that the original intent of this text is to mean >>> this "forwarding" to be just like other normal cases, i.e., >>> forwarding a packet received on one interface to one link to >>> another interface to another link. Or, just like the case where >>> a default router is not the best path to an off-link destination >>> and the best next hop is in the same link as the receiving link >>> (in that case the receiving router will transmit the packet back >>> through the arrival interface, possibly sending a neighbor >>> discovery redirect). So I'm pretty sure that the hop-limit is >>> assumed to be decremented. Saying "should not be decremented" >>> based on this RFC text is most likely to be a misinterpretation. >>> >>> Whether such a behavior is justified for some special cases can >>> be a different question, but that shouldn't automatically apply >>> to the general case described in this RFC. >> >> To clarify my position: the _general_ case is that a router >> forwards without looking at the source address at all. > > Inappropriate behavior in IPv6, as the router is required not to > forward packets with LL Source Addresses to interfaces that are not > on the same link as the arriving interface. In IPv6 this restriction is put on a router receiving a packet with LL src address. In IPv4 RFC3927 LLs this restriction is put on a Host wishing to send such a packet - it should not send it to a router for forwarding (use directly ARP search instead of rt table search first). In IPv4 that spec is silent about a _router_ sending packets with LL src address. So one can easily assume that an IPv4 router is allowed to send a packet with LL src address to another router. IPv4 behaviour is allowed to act this way and IPv6 should be the same if it wanted to be an easy migration target. Alex > > Owen > >> >> The rest are particular cases. >> >> Alex >> >>> >>> -- JINMEI, Tatuya >>> >>> _______________________________________________ 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 Jun 15 02:40: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 E2C2412D0AC for ; Wed, 15 Jun 2016 02:40:30 -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=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 SAmSQPT6mz5P for ; Wed, 15 Jun 2016 02:40:29 -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 F380A127078 for ; Wed, 15 Jun 2016 02:40:28 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5A4F261003 for ; Wed, 15 Jun 2016 11:40:25 +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 09CF3600C4; Wed, 15 Jun 2016 11:40:25 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id E9E7837EAB; Wed, 15 Jun 2016 11:40:24 +0200 (CEST) Date: Wed, 15 Jun 2016 11:40:24 +0200 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160615094024.GU79185@Space.Net> References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 09:40:31 -0000 Hi, On Wed, Jun 15, 2016 at 10:32:11AM +0200, Alexandre Petrescu wrote: > In IPv4 that spec is silent about a _router_ sending packets with LL src > address. So one can easily assume that an IPv4 router is allowed to > send a packet with LL src address to another router. BCP38 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 Jun 15 03:26: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 E5A9512D0AC for ; Wed, 15 Jun 2016 03:26:14 -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 0r-laNqdG1QS for ; Wed, 15 Jun 2016 03:26:13 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 61CCE12D13D for ; Wed, 15 Jun 2016 03:26:13 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 5so18695613ioy.1 for ; Wed, 15 Jun 2016 03:26:13 -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=Xw3fUrPGz+wxn/Onj7q5al6GMRP9PoyjIxCMC63PaqA=; b=eRj6uUqQG9N9jakthX2ZQSMyBJrCJ7YUaCKZwHAWCfH90bsUJNgNGiJl4J9nqEk0r5 aVTu5rbT8k+XDVahS7U/15rq0BkiDhr46x/87BiHETShyCZgkBqrPoMoP7SFDRSLJDwa ZEJ1sVHozpaqjV8n0fMMJDK6KvvzZSXb6uq2O6IZ+bbVHNQb2mYu310sHv2jaFEa5j7K R+2/kH6ZnunZeLnzBmDFrzU7eP9ISI2cjR2Epka0HsblMqqMTh+MljEcvjIncRtRRLyv 6oVAuaHFvID5sRV0VNqF5Oh+U5KK9THStWKMChu2eco9HDoXiniiOJ4g7cJKyr363tQG alNA== 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=Xw3fUrPGz+wxn/Onj7q5al6GMRP9PoyjIxCMC63PaqA=; b=Ns4byz1d8E/ptzPM+wmavGi2nyOzC030A9Q4ewU2Kb4VRmj3gdPWWZdPSlMJ8EaF1A zKLPF8sIgkDnjXfqfu5QEAoM9uZWrSG64lP4SzC72/MvqP6b42NVTI+1h6XioQ6O0KLj UnUFGvGb3f07T45nyEkvcMFS8mnc9q2qnmialHF/zfgI43aiKA3v8fwDGX0k92qVQqcl /c3LH3f1F9Y4WKXdL6YT7RnI8vT+osp3SHPPfN1i3N+x41A/PAHPHdh3NKO0ndwQcrJ/ K/rj634OU0eT6FbO8+Fp9nmg+NaQ7wWE/WOTUfJGz6Umt7w1GDDTsjq0AFkBl0b1+fZQ Rj7Q== X-Gm-Message-State: ALyK8tIczgsazNQNhp4NeOHv6/3bcm1yWHhlJGoenwN8d0VQZKEVEAotJ4gXsPDG3sE/miQuOT2djFLBzIovfA== X-Received: by 10.107.187.196 with SMTP id l187mr38745352iof.72.1465986372749; Wed, 15 Jun 2016 03:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Wed, 15 Jun 2016 03:25:52 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Jen Linkova Date: Wed, 15 Jun 2016 12:25:52 +0200 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 10:26:15 -0000 On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu wrote: > In IPv6 this restriction is put on a router receiving a packet with LL > src address. > > In IPv4 RFC3927 LLs this restriction is put on a Host wishing to send > such a packet - it should not send it to a router for forwarding (use > directly ARP search instead of rt table search first). > > In IPv4 that spec is silent about a _router_ sending packets with LL src > address. So one can easily assume that an IPv4 router is allowed to > send a packet with LL src address to another router. https://tools.ietf.org/html/rfc3927#page-25 " Router Considerations A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols. A router which receives a packet with an IPv4 Link-Local source or destination address MUST NOT forward the packet. This prevents forwarding of packets back onto the network segment from which they originated, or to any other segment." > IPv4 behaviour is allowed to act this way and IPv6 should be the same if > it wanted to be an easy migration target. Doing the wrong things in IPv6 only because 'it worked like that in IPv4' does not sound like a very good idea to me. In general, packets must have source address which makes sense and allows identifying a path back to the packet sender. (The only exception is a packet with undefined address but there is at least L2 address, and such packets are not allowed outside of the link - exactly for that reason). That's why multicast sources are not allowed. Allowing packets with unidentifiable sources is a very slippery slope - from various perspective, including (but not limited to) security concerns. -- SY, Jen Linkova aka Furry From nobody Wed Jun 15 03:50: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 5936112B064; Wed, 15 Jun 2016 03:50:32 -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 KXWDHtHxagaR; Wed, 15 Jun 2016 03:50:31 -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 D2123127058; Wed, 15 Jun 2016 03:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2894; q=dns/txt; s=iport; t=1465987830; x=1467197430; h=from:to:cc:subject:date:message-id:mime-version; bh=X4DVmmnfDqmSDA3KsHWR6/1nOYIzHGCyEqoWDqhEd7E=; b=RiKpSVOORtZYaSps/IJBST+Bx4H4ApUb7ydIytqEiMZbmLa6JoSbVim+ PNMiARXf5Gy+DetCYAHl+MvSDwwLXTXHmsDGn11SsY1E5DhL3sTyYrBos 1scwGUz3rGAeq2uKGRBQfZ1nyUpjhiZVfwZ0pYdv8bhr4txbqYhMPkUVB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgDBMWFX/49dJa1dgnBOVn0GtgiFA?= =?us-ascii?q?YF5IoV1HoEXOBQBAQEBAQEBZSeEUiNWEgEMAT0CBDAnBAENBYgwDq0FkQgBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEXBYYnjA6CWgWYaQGBMIRUiCSPIo9zAR42g29ui?= =?us-ascii?q?Ql/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,475,1459814400"; d="scan'208,217";a="115417710" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 10:50:29 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5FAoTjw016409 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 10:50:30 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.1104.5; Wed, 15 Jun 2016 06:50:29 -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.1104.009; Wed, 15 Jun 2016 06:50:29 -0400 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKA== Date: Wed, 15 Jun 2016 10:50:29 +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.109.75] Content-Type: multipart/alternative; boundary="_000_D386FF9375916evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "fgont@si6networks.com" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" Subject: [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: Wed, 15 Jun 2016 10:50:32 -0000 --_000_D386FF9375916evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGF1dGhvcnMgKGFuZCBPUFNFQyBXRyBjaGFpcnMpIHdvdWxkIHJlYWxseSBhcHByZWNpYXRl IGlmIGEgcmV2aWV3IG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9w c2VjLXY2LTA4IGlzIGRvbmUgaW4gdGhlIGNvbWluZyBkYXlzL3dlZWtzIChpbiB0aW1lIHRvIHN1 Ym1pdCBhIC0wOSBpbiBjYXNlIGl0IG5lZWRzIHRvIGJlIGFtZW5kZWQpLg0KDQpUaGlzIEktRCBp cyBhYm91dCB0aGUgb3BlcmF0aW9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gb3BlcmF0 aW5nIGFuIElQdjYgbmV0d29yayAoYm90aCBhcyBTZXJ2aWNlIFByb3ZpZGVyIGFuZCBlbnRlcnBy aXNlL3N1YnNjcmliZXIpLg0KDQpUaGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3IgeW91ciByZXZp ZXcgYW5kIGJlIHN1cmUgdG8gaW5jbHVkZSBvcHNlY0BpZXRmLm9yZyBpbiB5b3VyIHJlcGx5Lg0K DQotIHRoZSBhdXRob3JzIChNZXJpa2UsIEtLIGFuZCBFcmljKQ0KLSB0aGUgY2hhaXJtZW4gKEd1 bnRlciBhbmQgRXJpYykNCg0KUFM6IE1hcmt1cywgRnJlZCwgRmVybmFuZG8gYW5kIExlZSwgYXMg eW91IGtpbmRseSB2b2x1bnRlZXJlZCB0byByZXZpZXcgaXQgZHVyaW5nIElFVEYtOTUsIEkgYWxz byBwdXQgeW91ciBuYW1lcyA7LSkNCg0KDQoNCg== --_000_D386FF9375916evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGUgYXV0aG9y cyAoYW5kIE9QU0VDIFdHIGNoYWlycykgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgaWYgYSByZXZp ZXcgb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vcHNlYy12Ni0wOCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3Bz ZWMtdjYtMDg8L2E+Jm5ic3A7aXMgZG9uZSBpbiB0aGUgY29taW5nIGRheXMvd2Vla3MgKGluIHRp bWUgdG8gc3VibWl0IGEgLTA5IGluIGNhc2UNCiBpdCBuZWVkcyB0byBiZSBhbWVuZGVkKS48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgSS1EIGlzIGFib3V0IHRoZSBvcGVyYXRp b24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hlbiBvcGVyYXRpbmcgYW4gSVB2NiBuZXR3b3Jr IChib3RoIGFzIFNlcnZpY2UgUHJvdmlkZXIgYW5kIGVudGVycHJpc2Uvc3Vic2NyaWJlcikuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3Ig eW91ciByZXZpZXcgYW5kIGJlIHN1cmUgdG8gaW5jbHVkZSBvcHNlY0BpZXRmLm9yZyBpbiB5b3Vy IHJlcGx5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSB0aGUgYXV0aG9ycyAoTWVy aWtlLCBLSyBhbmQgRXJpYyk8L2Rpdj4NCjxkaXY+LSB0aGUgY2hhaXJtZW4gKEd1bnRlciBhbmQg RXJpYyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBTOiBNYXJrdXMsIEZyZWQsIEZl cm5hbmRvIGFuZCBMZWUsIGFzIHlvdSBraW5kbHkgdm9sdW50ZWVyZWQgdG8gcmV2aWV3IGl0IGR1 cmluZyBJRVRGLTk1LCBJIGFsc28gcHV0IHlvdXIgbmFtZXMgOy0pPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D386FF9375916evynckeciscocom_-- From nobody Wed Jun 15 04:03: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 136E312D146 for ; Wed, 15 Jun 2016 04:03:49 -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 tXNl1XRQbbBB for ; Wed, 15 Jun 2016 04:03:47 -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 3214612D198 for ; Wed, 15 Jun 2016 04:03:46 -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 u5FB3efu025739; Wed, 15 Jun 2016 13:03:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD5FB202268; Wed, 15 Jun 2016 13:04:20 +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 CD1A620C517; Wed, 15 Jun 2016 13:04:20 +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 u5FB3dTv027987; Wed, 15 Jun 2016 13:03:39 +0200 To: Jen Linkova References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Alexandre Petrescu Message-ID: Date: Wed, 15 Jun 2016 13:03:39 +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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 11:03:49 -0000 Le 15/06/2016 à 12:25, Jen Linkova a écrit : > On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu > wrote: >> In IPv6 this restriction is put on a router receiving a packet >> with LL src address. >> >> In IPv4 RFC3927 LLs this restriction is put on a Host wishing to >> send such a packet - it should not send it to a router for >> forwarding (use directly ARP search instead of rt table search >> first). >> >> In IPv4 that spec is silent about a _router_ sending packets with >> LL src address. So one can easily assume that an IPv4 router is >> allowed to send a packet with LL src address to another router. > > https://tools.ietf.org/html/rfc3927#page-25 " > > Router Considerations > > A router MUST NOT forward a packet with an IPv4 Link-Local source or > destination address, irrespective of the router's default route > configuration or routes obtained from dynamic routing protocols. > > A router which receives a packet with an IPv4 Link-Local source or > destination address MUST NOT forward the packet. This prevents > forwarding of packets back onto the network segment from which they > originated, or to any other segment." Ah right, I did not see it. So IPv4 does not stand as a reason - it's the same in IPv4 and IPv6. >> IPv4 behaviour is allowed to act this way and IPv6 should be the >> same if it wanted to be an easy migration target. > > Doing the wrong things in IPv6 only because 'it worked like that in > IPv4' does not sound like a very good idea to me. > > In general, packets must have source address which makes sense and > allows identifying a path back to the packet sender. > > (The only exception is a packet with undefined address but there is > at least L2 address, and such packets are not allowed outside of the > link - exactly for that reason). That's why multicast sources are not > allowed. Allowing packets with unidentifiable sources is a very > slippery slope - from various perspective, including (but not > limited to) security concerns. I read. You know I disagree it's a slippery slope. I will come back later on this need. Alex From nobody Wed Jun 15 04:34: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 EA68312D59F; Wed, 15 Jun 2016 04:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 EN2co57I4XN4; Wed, 15 Jun 2016 04:34:00 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) (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 10FF312D091; Wed, 15 Jun 2016 04:33:56 -0700 (PDT) Received: from [194.106.220.35] by server-4.bemta-14.messagelabs.com id 9F/F9-02097-32D31675; Wed, 15 Jun 2016 11:33:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRWlGSWpSXmKPExsUy9d9HH10l28R wgy0LtC2e7rzCYvFl/wJGiyer3rBZzNj2n83iw995LBYftt5lszh9bC+zA7vHlN8bWT2WLPnJ 5PHhUA+7x+o1r1g8rj7bwxzAGsWamZeUX5HAmnFzw132gn7BiiWNbewNjKv5uhi5OIQENjFKn O37zgzhHGCUeND7jgnCOcUo8WzvJ7YuRk4ONgF9iWWHjrCD2CICZRITn/5gBCliFrjGKDF10g 5GkISwgJXEwnVr2CCKrCU2T/nIAmEbSVz6vpkZxGYRUJXY+HAFUD0HB69AqMTSY6EgYSEBPYm mpgOsIDYn0K5vzb/AbEYBWYkvjavBWpkFxCVuPZnPBGJLCAhILNlznhnCFpV4+fgfK4StIHFp URcrRL2exI2pU9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg1ilOLy lKLdA0t9JKKMtMzSnITM3N0DQ1N9HJTi4sT01NzEpOK9ZLzczcxAuOynoGBcQfjke2ehxglOZ iURHk95BLDhfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwTrEGygkWpaanVqRl5gATBExagoNHSYS 3HSTNW1yQmFucmQ6ROsVoz3Fn8Y21TBw/Ou4DyVvPHgDJTxMOHGMSYsnLz0uVEuedBNImANKW UZoHNxSW0C4xykoJ8zIyMDAI8RSkFuVmlqDKv2IU52BUEuZ9ADKFJzOvBG73K6CzmIDOspkeD 3JWSSJCSqqB0e30zrP80pq3Fu9dMe0Pj7/pdXveRzPfnJ8j+ao+h+eIHOdR9gndhWb5+3dZnv 0+bVvkldnhDzJNX636fqj4ZbAAN+PXg7Mn8PhUbDx6xm367C4W+4frmboXPP57PtC1K0U//k/ hzufLXf+udDjnfJw19ZLIqkmxqZE5++tspm7MqFjQr/Voo6sSS3FGoqEWc1FxIgB36RPbYwMA AA== X-Env-Sender: robert.sleigh@ee.co.uk X-Msg-Ref: server-6.tower-91.messagelabs.com!1465990434!37011938!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19803 invoked from network); 15 Jun 2016 11:33:54 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-6.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2016 11:33:54 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 15 Jun 2016 12:33:42 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Wed, 15 Jun 2016 12:33:53 +0100 Received: from UK30S005EXS05.EEAD.EEINT.CO.UK ([fe80::8c76:d4fb:393f:9994]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0279.002; Wed, 15 Jun 2016 12:33:53 +0100 From: "Sleigh, Robert" To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qXYkg Date: Wed, 15 Jun 2016 11:33:53 +0000 Message-ID: <679694A32AB94046931C676BEF4BA8B85123EA84@UK30S005EXS05.EEAD.EEINT.CO.UK> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Wed, 15 Jun 2016 11:34:03 -0000 Hi Eric et al. Great doc, thanks. Just a couple of typos I spotted. 2.1.2 "This means that using ULA does not prevent route and packet filters to b= e implemented and monitored." Should this read:=20 "This means that using ULA does not prevent route and packet filters havi= ng to be implemented and monitored." 2.7.2.8 "the audit log are easier to manager" Should this read: "the audit logs are easier to manage" Hope this helps Regards Bob 07958 318592 From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evy= ncke) Sent: 15 June 2016 11:50 To: opsec@ietf.org; v6ops@ietf.org Cc: Howard, Lee; fgont@si6networks.com; draft-ietf-opsec-v6@ietf.org; lin= kedin@xn--debrn-nva.de Subject: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 The authors (and OPSEC WG chairs) would really appreciate if a review of=A0= https://tools.ietf.org/html/draft-ietf-opsec-v6-08=A0is done in the comin= g days/weeks (in time to submit a -09 in case it needs to be amended). This I-D is about the operation security considerations when operating an= =20IPv6 network (both as Service Provider and enterprise/subscriber). Thanks a lot in advance for your review and be sure to include opsec@ietf= .org in your reply. - the authors (Merike, KK and Eric) - the chairmen (Gunter and Eric) PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review i= t during IETF-95, I also put your names ;-) NOTICE AND DISCLAIMER This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above.=20 If you're not the intended recipient, note that disclosing, copying, dist= ributing or using this information is prohibited.=20 If you've received this email in error, please let me know immediately on= =20the email address above. Thank you. We monitor our email system, and may record your emails. EE Limited=20 Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, A= L10 9BW Registered in England no: 02382161 EE Limited is a wholly owned subsidiary of: British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From nobody Wed Jun 15 12:28: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 0C10812D0C9 for ; Wed, 15 Jun 2016 12:28:33 -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 mi8rLiKDlDfG for ; Wed, 15 Jun 2016 12:28:31 -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 CCA1B12D61B for ; Wed, 15 Jun 2016 12:28:30 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id u64so43649971vkf.3 for ; Wed, 15 Jun 2016 12:28: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=SsSvJ5xkovZkr8XhynlmhGm7hP6XdT8bjBf0a6Ux9GA=; b=zpY5d17a53wEajdJA6yMk11H03UBZJprix4bSOUQajerbGFwtUS8AK6VqUVoqdOREh yVNWpbI3PvyZj56Fhcp3kYKfz8evdz0/e5T5JzyEFdxAmDJrax+Yke/dBHaWKolA9bAs etAlx1lMrkEDIfux4E/VJ3EH8JSTjiwYGNcdpGqaWqXmw/mYvO8NFgbE23OyRDuN//bp AlWi7kSV/DtAKLdIohQZP7a2TWZIQYEnPxzVWf972/qkGTuLrA6PbKPA4w0JXPy70PHh SxVfowYDaMThePyd3EtWKd3ANph8r9zw+rO8vXzJhbkcxdAQTdhDauiTfFcUet1ORpk0 rOVQ== 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=SsSvJ5xkovZkr8XhynlmhGm7hP6XdT8bjBf0a6Ux9GA=; b=V4r8gYQnpPq3h7Mv2mStkUCx7MXERn5HVSFrgq4qaz6TGIshjT560jufePuN+iDQHN PyH/ihNrj4eL2PrBZMqAoS0twz2r9oy5UudFd0Ao92Tu8rvF8CU7L3dGTZuEbjv2oGGM IG3Ghdp34xW0/DBazR+hxQHrrx2GNvk145JmNdTTozRIseM2pn8UN3/eSBIiJlX2s9ok pP7dQZ2zQMcWdnN2OK6I+l5gMrGQ8hnLXcMfuH3JFLfdT6212fvqWrQ8hUcmBSPZI670 DAPbpd+/jlygwuQbJ6Sfd6z+kxJw8GMMegEKRqJ3iBkFZ2eaHOnjFKm5H8IYjfFlpH0s DU4A== X-Gm-Message-State: ALyK8tIOhTo4zdhsQyeIRt4ZJHKyxLvPXDGKMjIHKZQ/q4K/WlR0GdwzxRyhy63L99z6F49ZHZbNQAit1ppq4w== X-Received: by 10.176.64.37 with SMTP id h34mr210843uad.112.1466018909943; Wed, 15 Jun 2016 12:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.226 with HTTP; Wed, 15 Jun 2016 12:28:28 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Musa Stephen Honlue Date: Wed, 15 Jun 2016 23:28:28 +0400 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=94eb2c122f925c7fcb05355620c8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 19:28:33 -0000 --94eb2c122f925c7fcb05355620c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is bad behaviour both for the source device(LL should not be used for off-link destinations), and for intermediary routers(they should not forward packet sourced with LLA). It is clear enough that responses to such packets won't be able to make their way back. Therefore, if the path of such packets can be traced, it is necessary to report a bug to various vendors concerned for them to deal with this issue in accordance with specifications as per https://tools.ietf.org/html/rfc4291#section-2.5.6. Stephen. 2016-06-15 15:03 GMT+04:00 Alexandre Petrescu : > > > Le 15/06/2016 =C3=A0 12:25, Jen Linkova a =C3=A9crit : > >> On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu >> wrote: >> >>> In IPv6 this restriction is put on a router receiving a packet >>> with LL src address. >>> >>> In IPv4 RFC3927 LLs this restriction is put on a Host wishing to >>> send such a packet - it should not send it to a router for >>> forwarding (use directly ARP search instead of rt table search >>> first). >>> >>> In IPv4 that spec is silent about a _router_ sending packets with >>> LL src address. So one can easily assume that an IPv4 router is >>> allowed to send a packet with LL src address to another router. >>> >> >> https://tools.ietf.org/html/rfc3927#page-25 " >> >> Router Considerations >> >> A router MUST NOT forward a packet with an IPv4 Link-Local source or >> destination address, irrespective of the router's default route >> configuration or routes obtained from dynamic routing protocols. >> >> A router which receives a packet with an IPv4 Link-Local source or >> destination address MUST NOT forward the packet. This prevents >> forwarding of packets back onto the network segment from which they >> originated, or to any other segment." >> > > Ah right, I did not see it. So IPv4 does not stand as a reason - > it's the same in IPv4 and IPv6. > > IPv4 behaviour is allowed to act this way and IPv6 should be the >>> same if it wanted to be an easy migration target. >>> >> >> Doing the wrong things in IPv6 only because 'it worked like that in >> IPv4' does not sound like a very good idea to me. >> >> In general, packets must have source address which makes sense and >> allows identifying a path back to the packet sender. >> >> (The only exception is a packet with undefined address but there is >> at least L2 address, and such packets are not allowed outside of the >> link - exactly for that reason). That's why multicast sources are not >> allowed. Allowing packets with unidentifiable sources is a very >> slippery slope - from various perspective, including (but not >> limited to) security concerns. >> > > I read. > > You know I disagree it's a slippery slope. > > I will come back later on this need. > > Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c122f925c7fcb05355620c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is bad behaviour both for the source device(LL should= not be used for off-link destinations), and for intermediary routers(they = should not forward packet sourced with LLA).

It is clear= enough that responses to such packets won't be able to make their way = back.

Therefore, if the path of such packets can b= e traced, it is necessary to report a bug to various vendors concerned for = them to deal with this issue in accordance with specifications as per https://tools.ietf= .org/html/rfc4291#section-2.5.6.

Stephen.

2016-06-15= 15:03 GMT+04:00 Alexandre Petrescu <alexandre.petrescu@gmail.c= om>:


Le 15/06/2016 =C3=A0 12:25, Jen Linkova a =C3=A9crit :
On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com> wrote:
In IPv6 this restriction is put on a router receiving a packet
with LL src address.

In IPv4 RFC3927 LLs this restriction is put on a Host wishing to
send such a packet - it should not send it to a router for
forwarding (use directly ARP search instead of rt table search
first).

In IPv4 that spec is silent about a _router_ sending packets with
LL src address.=C2=A0 So one can easily=C2=A0 assume that an IPv4 router is=
allowed to send a packet with LL src address to another router.

https://tools.ietf.org/html/rfc3927#page-25 "
Router Considerations

A router MUST NOT forward a packet with an IPv4 Link-Local source or
=C2=A0destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols.

A router which receives a packet with an IPv4 Link-Local source or
destination address MUST NOT forward the packet.=C2=A0 This prevents
forwarding of packets back onto the network segment from which they
originated, or to any other segment."

 Ah right, I did not see it.=C2=A0 So IPv4 does not stand as a reason -
it's the same in IPv4 and IPv6.

IPv4 behaviour is allowed to act this way and IPv6 should be the
same if it wanted to be an easy migration target.

Doing the wrong things in IPv6 only because 'it worked like that in
IPv4' does not sound like a very good idea to me.

In general, packets must have source address which makes sense and
allows identifying a path back to the packet sender.

(The only exception is a packet with undefined address but there is
at least L2 address, and such packets are not allowed outside of the
link - exactly for that reason). That's why multicast sources are not allowed. Allowing packets with unidentifiable sources is a very
slippery slope - from various perspective, including (but not
limited to) security concerns.

 I read.

You know I disagree it's a slippery slope.

I will come back later on this need.

Alex


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

--94eb2c122f925c7fcb05355620c8-- From nobody Wed Jun 15 12:46:15 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 50CCB12DB5D for ; Wed, 15 Jun 2016 12:45:55 -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 JVPB5UtMOmsa for ; Wed, 15 Jun 2016 12:45:52 -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 9F1D512DB5E for ; Wed, 15 Jun 2016 12:45:51 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id h190so30282630ith.1 for ; Wed, 15 Jun 2016 12:45:51 -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=omBwBiGMd45HWvOrFNbCn7Hf7SriMU3CNzSeCp5Cr8o=; b=M/f8nbf0jhQgOSSWoisDWB5QO5SDfunxrYPnhw7g8XGgX7lvDGvFGE1MKMHw2L9I5K hqkTYs3GGLN0MWXNXv6Bw9PzwIvwetCDeNMgc6vixGHCQx2Xx34cXaOL+6Q/oK05fWJC lqLjj9tlmBrZALhfdyrAyxO9iDBRhdkvKhjBNUAEKaBB+NeRU31ummZdAhfwalnQDeXG 2pta7ssVF5VpGE1Kh6laX0x5f2LeKXiaUNAS0RFAQMI5HcTTiwXmXLpISG7xGAu+j9pS OXTUgWcMKGkPUjKGBTLDhxQ6OeflTJuESMN7hYXMu++rS7zE059MgoqQyWe/o57iJ6Is i4vw== 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=omBwBiGMd45HWvOrFNbCn7Hf7SriMU3CNzSeCp5Cr8o=; b=Vej4u3Joom9huaeeT2RmFGcYrfXXx7o0gTKjh6OlosWnTpEbitbcqqqKfNQ5CUT0Tu KWsNY9RH/OMzwfa0Az5JDLgTAjRKBUh+cxf9j8ZYPx/uK68YhLgcucXamKwbkuNqWahi hWd+p6ievSnX6sGzKJZJKbgutjMBKFi6dpjwoTFqdK4Uy/5ojhjSPTQ1Z/bhY2pyoB94 TInSxmvP0174PxjIrtdA6ZPHAlmT6E92NJ0tBNxIHHs0OSSrjHPmjvAFj/xfpIgpSt1J yY6nVMTb7IfuoHbNXAnrQLVkVbQmV6TZSNZUt9lRKDX7S4zbWmrAxj8vmj6SH/wowpjT BfvA== X-Gm-Message-State: ALyK8tI/DYxLQu910Sqror0lpl+Jl64yFZOcQ7IaCK8jLG6b4jNgJ5XzsqUP0eSpeh5sv9eISYS8dSLgqxRzOWWu X-Received: by 10.36.249.137 with SMTP id l131mr3929866ith.21.1466019950823; Wed, 15 Jun 2016 12:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.67.74 with HTTP; Wed, 15 Jun 2016 12:45:31 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Wed, 15 Jun 2016 12:45:31 -0700 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: Wed, 15 Jun 2016 19:45:55 -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. Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We should, in my opinion, make it painfully clear that DHCP (of any protocol) in the absence of link-layer security/auditability features does not provide any satisfactory way "to ensure audibility and traceability" [Section 2.1.6]. From nobody Wed Jun 15 15:20: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 28A4712D881 for ; Wed, 15 Jun 2016 15:20:55 -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 uPePLpjTkJ08 for ; Wed, 15 Jun 2016 15:20:53 -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 987AE12D7F2 for ; Wed, 15 Jun 2016 15:20:53 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id t129so49495742vka.1 for ; Wed, 15 Jun 2016 15:20: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:content-transfer-encoding; bh=IP7y3Afyudm/P0NKptuCP6tss7OyW4cmaEumUk2hMvY=; b=v2Ur/JHuBb6m/WjygJz9CVeFf8hzbnz0RnXt147pRBfkAYDLwrfypPvel9RkQKgChy hXrACNgrj3wvTP+ivNx7mb7vzEvD2qb/ik8xbUjj0fw3cC89ebsJ7YGSmQIIHILATsyo NAk/m/bmoGu3FGT0vssg0/FyPiGX0KkYWkC5TUQerIGwShVRxqdR/1sH7YFghQN/YXf3 PS3l0C5PB+P+1rXtt48HEiBBMHjKauo49++KdvcBchV5zdIMMFpLsNgn4+HyQ0o6TU+T 4c1VoJRWqpC5cRl4jWpVYLvkcND2ZLgS+EWufrTcetAREh7vOssC7ebFnSXnX/GeU5bp p2lg== 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=IP7y3Afyudm/P0NKptuCP6tss7OyW4cmaEumUk2hMvY=; b=jwzylJqf/Er6UrFYHGfo5J636OCdjq4m1sYt+lZCVz2i7saPGL8+YBUGGXNQozas19 fMhYGHIooXkWf72Mk3TyOgRQrXdR2o+IT08FJ2SX8LwpER44RuWfNrnoHWPpGP4BQRon 2+V65c3jFRWg5JuUFP1kOC8zAVqbcwCKv/DX90MwEwruITCldJpW0lqgQS99nLSaHroq ZIEC3XtoLS4kgFZD9P+M64OtvKMVo7A0oEYPqbHx8/qwu+D7+eizw3UDsdiLT0/UWtqi OyzBzaZxVluLxc0zB2ZhAKC+DhQPfYWcrRstrCAdhbBLzHg+GJxIO+6Rw2PvR0/fGED+ DJuA== X-Gm-Message-State: ALyK8tKML6mtsZZUFabsgrcSJiX2xJcBWBb0NDqjFLQn/G61X7q/IVLt69FrooCxP+DBUy4UA9W5QCkahmybcQ== X-Received: by 10.159.35.117 with SMTP id 108mr634161uae.118.1466029252570; Wed, 15 Jun 2016 15:20:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.198 with HTTP; Wed, 15 Jun 2016 15:20:22 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Mark Smith Date: Thu, 16 Jun 2016 08:20:22 +1000 Message-ID: To: Musa Stephen Honlue Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 15 Jun 2016 22:20:55 -0000 On 16 June 2016 at 05:28, Musa Stephen Honlue wrote: > This is bad behaviour both for the source device(LL should not be used fo= r > off-link destinations), This actually contradicts the IPv6 subnet model, described in RFC5942. With exception to Link-Local destinations, hosts are not to assume a destination is on-link, unless they've been informed that the prefix is on-link, by receiving a RA PIO covering the destination with the on-link/L-bit set. This makes sense, it supports a hub-and-spoke rather than a direct node-to-node forwarding model within the subnet, with the router(s) on the link being the first hop for all (non-LL) destinations, rather than direct sending to other hosts attached to the link and using a router to reach off-link destinations. Terminology might be a bit confusing, "dumb" hosts consider all destinations (excepting LLs) "off-link", so they use a router to reach them, where as the "smarter" router knows that some of the destinations are on-link, and forwards to them. The router would not issue redirects for those on-link destinations to the sending hosts. (Too late to change it now, however "on-link" and "off-link" might have better been something like "directly-reachable" and "router-reachable") Regards, Mark. > and for intermediary routers(they should not forward > packet sourced with LLA). > > It is clear enough that responses to such packets won't be able to make > their way back. > > Therefore, if the path of such packets can be traced, it is necessary to > report a bug to various vendors concerned for them to deal with this issu= e > in accordance with specifications as per > https://tools.ietf.org/html/rfc4291#section-2.5.6. > > Stephen. > > 2016-06-15 15:03 GMT+04:00 Alexandre Petrescu > : >> >> >> >> Le 15/06/2016 =C3=A0 12:25, Jen Linkova a =C3=A9crit : >>> >>> On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu >>> wrote: >>>> >>>> In IPv6 this restriction is put on a router receiving a packet >>>> with LL src address. >>>> >>>> In IPv4 RFC3927 LLs this restriction is put on a Host wishing to >>>> send such a packet - it should not send it to a router for >>>> forwarding (use directly ARP search instead of rt table search >>>> first). >>>> >>>> In IPv4 that spec is silent about a _router_ sending packets with >>>> LL src address. So one can easily assume that an IPv4 router is >>>> allowed to send a packet with LL src address to another router. >>> >>> >>> https://tools.ietf.org/html/rfc3927#page-25 " >>> >>> Router Considerations >>> >>> A router MUST NOT forward a packet with an IPv4 Link-Local source or >>> destination address, irrespective of the router's default route >>> configuration or routes obtained from dynamic routing protocols. >>> >>> A router which receives a packet with an IPv4 Link-Local source or >>> destination address MUST NOT forward the packet. This prevents >>> forwarding of packets back onto the network segment from which they >>> originated, or to any other segment." >> >> >> Ah right, I did not see it. So IPv4 does not stand as a reason - >> it's the same in IPv4 and IPv6. >> >>>> IPv4 behaviour is allowed to act this way and IPv6 should be the >>>> same if it wanted to be an easy migration target. >>> >>> >>> Doing the wrong things in IPv6 only because 'it worked like that in >>> IPv4' does not sound like a very good idea to me. >>> >>> In general, packets must have source address which makes sense and >>> allows identifying a path back to the packet sender. >>> >>> (The only exception is a packet with undefined address but there is >>> at least L2 address, and such packets are not allowed outside of the >>> link - exactly for that reason). That's why multicast sources are not >>> allowed. Allowing packets with unidentifiable sources is a very >>> slippery slope - from various perspective, including (but not >>> limited to) security concerns. >> >> >> I read. >> >> You know I disagree it's a slippery slope. >> >> I will come back later on this need. >> >> Alex >> >> >> _______________________________________________ >> 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 Jun 15 16:44: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 9617D12D8E3; Wed, 15 Jun 2016 16:44: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 dnH0L8oJUF0M; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC31712D82E; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id b13so11913579pat.0; Wed, 15 Jun 2016 16:44:44 -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=5B2GvNITSKw42f1FqlRcZGu+CcHDeUTeY0tQKUgJxSo=; b=Gi3F2T92tylZBgY5MEKVTGXqOxHmwLLU0ZNmyh0NtdkdmibURU1glMPAdV5edi5RjV 1mR9jthpRMPH/GHRuDIBIHL6GK8RmqrPZsbC+4pj0wa3PWghILbR1JcOkVsrIWs7LmDR rrG/o8VEINg6X6KeiWizl/ej73QPn7teEoVjom1bMQnVP2kEC8xlCcdrUgzKXggIZ0Dp 2964MUqDU80oai56FUUtyIPTrGaHdGLYvD89FHCQoXVFLOKIg4UmG0xfBBLehVJ5Hsuz yqeLnPiuFGH9/SkeTyrQ6EOU5MCmUg2QINTbsG4qTeJvWCXMrskNcvczTIaah6MCQsgS qmnA== 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=5B2GvNITSKw42f1FqlRcZGu+CcHDeUTeY0tQKUgJxSo=; b=aIlQJtQkww2Dmd/k3WjlQjvYAuL779w923IBbtol4n8m4xyB0ur/VHy+vhx/g6RO39 2uz2apgcnM8HRWaDwdqeEN2WdygKBXEyoKaQ4+y9ZgUgQ+QkRHLU3d1h1ou4srx8FoVb 6Ogh25Jjoyde3axv52tWxxjDPaOhaZJ1QS2BjDc8hXYhMr4wSghc23GEGEvvwAMyGkyI bOy7s7eUWUpBK+2wZypoHfxcsjYdcai6v9ZrvxkzmvF3TA/zPsrE3sdljL3yjsaJeLyG pItXUjCw/NJ2Gr3nycehuFu9BIhV4ybFolKHGNGtoWfOj+KvpiPdnvfAJIgQ9FkgSknf /ztQ== X-Gm-Message-State: ALyK8tL+0CkOOzdEb3ky3+SZiEZkbfohOvQMgk9dQNMecjeEGhOssq4lhPFfTPigKgLQdg== X-Received: by 10.66.135.40 with SMTP id pp8mr1448239pab.113.1466034284288; Wed, 15 Jun 2016 16:44:44 -0700 (PDT) Received: from ?IPv6:2406:e007:58e1:1:28cc:dc4c:9703:6781? ([2406:e007:58e1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ih15sm55526875pab.38.2016.06.15.16.44.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 16:44:43 -0700 (PDT) To: Erik Kline , "Eric Vyncke (evyncke)" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> Date: Thu, 16 Jun 2016 11:44:45 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "linkedin@xn--debrn-nva.de" , "draft-ietf-opsec-v6@ietf.org" , "v6ops@ietf.org" 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: Wed, 15 Jun 2016 23:44:46 -0000 On 16/06/2016 07:45, 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 have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT != security. While I'm here, some other points: "2.2. Extension Headers TBD, a short section referring to all Fernando's I-D & RFC." That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance to security aspects. Second, there is no reason to refer to most of the material (Fernando's or not) unless it's directly relevant to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering, but only if that document is going anywhere. "2.3.3. ND/RA Rate Limiting ... The following drafts are actively discussing methods to rate limit RAs and other ND messages on wifi networks in order to address this issue: o [I-D.thubert-savi-ra-throttler] o [I-D.chakrabarti-nordmark-6man-efficient-nd]" Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. "4.2. Transition Mechanism SP will typically use transition mechanisms such as 6rd, 6PE, MAP, DS-Lite which have been analyzed in the transition Section 2.7.2 section." Shouldn't you add RFC6877 464XLAT now? Finally, I think there should be a Privacy Considerations section. Rgds Brian > > Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > should, in my opinion, make it painfully clear that DHCP (of any > protocol) in the absence of link-layer security/auditability features > does not provide any satisfactory way "to ensure audibility and > traceability" [Section 2.1.6]. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jun 16 02:15: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 9AFED12D0BA; Thu, 16 Jun 2016 02:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 C0bjFTu-mqwM; Thu, 16 Jun 2016 02:15:21 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05212D0A4; Thu, 16 Jun 2016 02:15:20 -0700 (PDT) Received: from [85.158.143.99] by server-1.bemta-6.messagelabs.com id 03/3D-09256-72E62675; Thu, 16 Jun 2016 09:15:19 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRWlGSWpSXmKPExsVy+JUil656XlK 4webPbBZPd15hsfiw9S6bxelje5kdmD2WLPnJFMAYxZqZl5RfkcCaMWHNPcaC6woVsw+vY25g XKDQxcjJISSwnlHi8xGfLkYuIHsPo8Sf6f+ZQRJsAjoS/5fvYgexRQRqJaYc/8MMUsQs8IVR4 ticVUxdjBwcwgJeEhc7vSFqvCUa3v5mhbCdJFrnnWABsVkEVCXWdb8Gi/MKOEt8njqfBWLxMk aJWWuKQGxOAVuJjz+fgNUwCshKfGlcDXYDs4C4xK0n85lAbAkBAYkle84zQ9iiEi8f/2OFsBU kVlyaAHYOs4CmxPpd+hCtihJTuh+yQ6wVlDg58wnUWhWJ9gXLoFqDJU6c3M8ygVFsFpJtsxAm zUIyaRaSSQsYWVYxqhenFpWlFuka6iUVZaZnlOQmZuboGhqY6eWmFhcnpqfmJCYV6yXn525iB EYVAxDsYNz53OkQoyQHk5Ior6NGUrgQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCV7RXKCcYFFqem pFWmYOML5h0hIcPEoivO9ygNK8xQWJucWZ6RCpU4yWHHcW31jLxHHr2QMg+WnCgWNMQix5+Xm pUuK8/CDzBEAaMkrz4MbBUtAlRlkpYV5GoAOFeApSi3IzS1DlXzGKczAqCfM+AVnLk5lXArf1 FdBBTEAH2UyPBzmoJBEhJdXAaK87sedEw0/zFz6bnrdd360cuH55okFE1qRntacfWKyc1rdU6 9n0x16vNUW2rzP3+Wt862bG9ruyBtfzOC/rb5zMsMvEfMnz46dfZDSZbFi8Y8c+tQXRU9ICtu hFHGa8td1swiWu2JnijL1mS+bskHG+JHxNtbvhjsenoxJ8h4tqi0U/cnjeslRiKc5INNRiLip OBAC4Ac88PAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-13.tower-216.messagelabs.com!1466068518!11174090!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 35496 invoked from network); 16 Jun 2016 09:15:19 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-13.tower-216.messagelabs.com with SMTP; 16 Jun 2016 09:15:19 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 11:15:18 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 11:15:18 +0200 From: Marco Ermini To: Brian E Carpenter , Erik Kline , "Eric Vyncke (evyncke)" Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qzYSAgABC14CAAMBooA== Date: Thu, 16 Jun 2016 09:15:17 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> In-Reply-To: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.15.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 09:15:18.0659 (UTC) FILETIME=[99F46530:01D1C7AF] Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" 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: Thu, 16 Jun 2016 09:15:22 -0000 V2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNlY3VyaXR5 LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3QgdG8gc2F5 IHRoYXQgaXQgaXMgbm90Lg0KDQpJIHBlcnNvbmFsbHkgZG9uJ3Qgc3ltcGF0aGl6ZSBvbiBOQVQt aGF0ZXJzLiAgTkFUIGhhcyBpdHMgcmVhc29ucywgZXNwZWNpYWxseSBmb3IgY2Fycmllci1ncmFk ZSBOQVQgYW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5hcmlvLCBhbmQgeWVzLCBpdCBk b2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFnYWluLCBub3QgdGhlIGNvbXBs ZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLg0KDQoNClJlZ2FyZHMsDQrigIvigIvigIvigIvigIsN Ck1hcmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRA0K U2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1MjMgwqBNwqAr NDkgKDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KU2VudDogVGh1cnNkYXksIEp1bmUg MTYsIDIwMTYgMTo0NSBBTQ0KVG86IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKQ0K Q2M6IGZnb250QHNpNm5ldHdvcmtzLmNvbTsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1k ZWJybi1udmEuZGU7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW09QU0VDXSBbdjZvcHNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1vcHNlYy12Ni0wOA0KDQpPbiAxNi8wNi8yMDE2IDA3OjQ1LCBFcmlrIEtsaW5lIHdy b3RlOg0KPiBTZWN0aW9uIDIuMS4yIGlzIGZhciB0b28gcGVybWlzc2l2ZSBmb3IgbXkgdGFzdGVz LiAgV2UgbmVlZCB0byBiZSBhYmxlIA0KPiB0byBzYXkgdGhhdCBVTEErSVB2NiBOQVQgaXMgTk9U IFJFQ09NTUVOREVEIGJ5IHRoZSBJRVRGLg0KDQpJIGhhdmUgc3Ryb25nIHN5bXBhdGh5IHdpdGgg dGhhdCBzdGF0ZW1lbnQsIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIGRvY3VtZW50IHRv IGRvIGl0OyB0aGUgcG9pbnQgaXMgbWFkZSBpbiBSRkM0ODY0IHRvby4gV2hhdCB3ZSBzaG91bGQg ZG8gaGVyZSBpcyB1bmRlcmxpbmUgdGhhdCBOQVQgIT0gc2VjdXJpdHkuDQoNCldoaWxlIEknbSBo ZXJlLCBzb21lIG90aGVyIHBvaW50czoNCg0KIjIuMi4gIEV4dGVuc2lvbiBIZWFkZXJzDQoNCiAg IFRCRCwgYSBzaG9ydCBzZWN0aW9uIHJlZmVycmluZyB0byBhbGwgRmVybmFuZG8ncyBJLUQgJiBS RkMuIg0KDQpUaGF0J3Mgbm90IHRoZSB3aG9sZSBzdG9yeSA7LSkuIEZpcnN0bHksIFJGQyA3MDQ1 IGhhcyBhIGxvdCBvZiByZWxldmFuY2UgdG8gc2VjdXJpdHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVy ZSBpcyBubyByZWFzb24gdG8gcmVmZXIgdG8gbW9zdCBvZiB0aGUgbWF0ZXJpYWwgKEZlcm5hbmRv J3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSByZWxldmFudCB0byBvcHNlYy4gSSB0aGlu ayB0aGUgcmVmZXJlbmNlIGlzIGRyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmcsDQpi dXQgb25seSBpZiB0aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLg0KDQoiMi4zLjMuICBO RC9SQSBSYXRlIExpbWl0aW5nDQouLi4NCiAgIFRoZSBmb2xsb3dpbmcgZHJhZnRzIGFyZSBhY3Rp dmVseSBkaXNjdXNzaW5nIG1ldGhvZHMgdG8NCiAgIHJhdGUgbGltaXQgUkFzIGFuZCBvdGhlciBO RCBtZXNzYWdlcyBvbiB3aWZpIG5ldHdvcmtzIGluIG9yZGVyIHRvDQogICBhZGRyZXNzIHRoaXMg aXNzdWU6DQoNCiAgIG8gIFtJLUQudGh1YmVydC1zYXZpLXJhLXRocm90dGxlcl0NCg0KICAgbyAg W0ktRC5jaGFrcmFiYXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQoNCk5laXRoZXIg b2YgdGhvc2UgZHJhZnRzIGlzIGluIHRoZSBsZWFzdCBhY3RpdmUgKGZyb20gMjAxMiBhbmQgMjAx NSByZXNwZWN0aXZlbHkpLiBEZWFkIGRyYWZ0cyBhcmUgb2Ygbm8gaGVscCB0byB0aGUgcmVhZGVy LCBJTUhPLg0KDQoiNC4yLiAgVHJhbnNpdGlvbiBNZWNoYW5pc20NCg0KICAgU1Agd2lsbCB0eXBp Y2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBFLCBNQVAsDQog ICBEUy1MaXRlIHdoaWNoIGhhdmUgYmVlbiBhbmFseXplZCBpbiB0aGUgdHJhbnNpdGlvbiBTZWN0 aW9uIDIuNy4yDQogICBzZWN0aW9uLiINCg0KU2hvdWxkbid0IHlvdSBhZGQgUkZDNjg3NyA0NjRY TEFUIG5vdz8NCg0KRmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQcml2YWN5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClJnZHMNCiAgICBCcmlhbg0KDQo+IA0KPiBTZWN0aW9u IDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhlIFNBVkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxs LiAgV2UgDQo+IHNob3VsZCwgaW4gbXkgb3BpbmlvbiwgbWFrZSBpdCBwYWluZnVsbHkgY2xlYXIg dGhhdCBESENQIChvZiBhbnkNCj4gcHJvdG9jb2wpIGluIHRoZSBhYnNlbmNlIG9mIGxpbmstbGF5 ZXIgc2VjdXJpdHkvYXVkaXRhYmlsaXR5IGZlYXR1cmVzIA0KPiBkb2VzIG5vdCBwcm92aWRlIGFu eSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0eSBhbmQgDQo+IHRyYWNlYWJp bGl0eSIgW1NlY3Rpb24gMi4xLjZdLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNFQyBt YWlsaW5nIGxpc3QNCk9QU0VDQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29wc2VjDQo= From nobody Thu Jun 16 02:43: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 AB16512B058; Thu, 16 Jun 2016 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, 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 QmueOSfHfKhO; Thu, 16 Jun 2016 02:43:40 -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 E21DF12D096; Thu, 16 Jun 2016 02:43:39 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id u64so65747038vkf.3; Thu, 16 Jun 2016 02:43: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:content-transfer-encoding; bh=2iI5UQF8KkiTKd/02IhQimbzT+gCNR7EtiEVZkZZ2Zc=; b=xr6uq3d4z0D2HiC4qbNINMWNv9HgUY0O7fAPdnaJN6w81jelvUO20uVWMWUEOtBz6M WBQUUJu35H4x4UTq3gmvNOHNXp7HGgjQT2129EkV4+voCMMsR19UnRx7U7NTj04l7QJr x2fxV+ln9CCZP3dc65uun6PkOCof7u2IxXULKpEApAQ3PVCijQwTMwz5KxouKi85gUzk kmjdmBxG15IIvEnIvWmNOIj5FOz/YczTWA6Qc0RkYyT+8yy0dTn4EE/6SSQ+UGoduMLy p0PDIIyiRu30aSwC86ibwx9S/0RuB7YjzABKKXYJLLV4QxhjH/kQyREwHZqDRckcX84y VsLQ== 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=2iI5UQF8KkiTKd/02IhQimbzT+gCNR7EtiEVZkZZ2Zc=; b=Nf3RlGxO7tReAWEsQGjDaLcb2jH2agYgRAXMYbVBcFDuAXbLTuuqCeoFCNLW4rW1o5 B3XVo51O+G/+zpmfI4CTJ4rISeppIVro0qamAucapeDOni4gQX6XxHIkJgfqVFlxiIqT PtVXW0rBloR7BWEMs3CYJU5LBcPmShvCYiTYRCEgqaJ2YIFgfcuLMMWwdd1T8KQLh0fL 9OuKz2WH5Ss9/FlAMLSvxy0GGEdyAdI38yuRw8gGI+2+Cn3DALAxEtXWeBe638skuUOj 7/J65xmp//azhpfYhyp3ZPYEoCidFrWfzwOK27NGEeIz4k3fgh/+1+1SMzpKohd/XHuK LklQ== X-Gm-Message-State: ALyK8tJ/CI3P1yweIZOtHcD/pdN12/2WCfeXmpM3a4VK0xLkdl97oPJyAFH7NR+kIkTvu/JIh+CMj3aW8vm1dQ== X-Received: by 10.31.8.77 with SMTP id 74mr1574627vki.150.1466070218954; Thu, 16 Jun 2016 02:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.168 with HTTP; Thu, 16 Jun 2016 02:43:09 -0700 (PDT) In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> From: Mark Smith Date: Thu, 16 Jun 2016 19:43:09 +1000 Message-ID: To: Marco Ermini Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 16 Jun 2016 09:43:42 -0000 On 16 June 2016 at 19:15, Marco Ermini wrote: > Well, actually, infrastructure hiding IS part of security. It is not the= full picture, but it is incorrect to say that it is not. > > I personally don't sympathize on NAT-haters. NAT has its reasons, especi= ally for carrier-grade NAT CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. Regards, Mark. > > Regards, > > Marco Ermini > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > ResMed Germany Inc > > > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Thursday, June 16, 2016 1:45 AM > To: Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; dra= ft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-0= 8 > > On 16/06/2016 07:45, 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 have strong sympathy with that statement, but I don't think this is the= document to do it; the point is made in RFC4864 too. What we should do her= e is underline that NAT !=3D security. > > While I'm here, some other points: > > "2.2. Extension Headers > > TBD, a short section referring to all Fernando's I-D & RFC." > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance = to security aspects. Second, there is no reason to refer to most of the mat= erial (Fernando's or not) unless it's directly relevant to opsec. I think t= he reference is draft-ietf-opsec-ipv6-eh-filtering, > but only if that document is going anywhere. > > "2.3.3. ND/RA Rate Limiting > ... > The following drafts are actively discussing methods to > rate limit RAs and other ND messages on wifi networks in order to > address this issue: > > o [I-D.thubert-savi-ra-throttler] > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > Neither of those drafts is in the least active (from 2012 and 2015 respec= tively). Dead drafts are of no help to the reader, IMHO. > > "4.2. Transition Mechanism > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > DS-Lite which have been analyzed in the transition Section 2.7.2 > section." > > Shouldn't you add RFC6877 464XLAT now? > > Finally, I think there should be a Privacy Considerations section. > > Rgds > Brian > >> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We >> should, in my opinion, make it painfully clear that DHCP (of any >> protocol) in the absence of link-layer security/auditability features >> does not provide any satisfactory way "to ensure audibility and >> traceability" [Section 2.1.6]. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 16 03:00: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 2B7B412B058 for ; Thu, 16 Jun 2016 03:00: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 sPPY1YBhLp1A for ; Thu, 16 Jun 2016 03:00:46 -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 7D0CE12B05D for ; Thu, 16 Jun 2016 03:00:46 -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 u5GA0iO5022638; Thu, 16 Jun 2016 12:00:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 14BF1201909; Thu, 16 Jun 2016 12:01:26 +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 04963203294; Thu, 16 Jun 2016 12:01:26 +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 u5GA0h6D022865; Thu, 16 Jun 2016 12:00:43 +0200 To: Musa Stephen Honlue References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> From: Alexandre Petrescu Message-ID: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> Date: Thu, 16 Jun 2016 12:00:43 +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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 16 Jun 2016 10:00:49 -0000 Le 15/06/2016 à 21:28, Musa Stephen Honlue a écrit : > This is bad behaviour both for the source device(LL should not be used > for off-link destinations), and for intermediary routers(they should not > forward packet sourced with LLA). > > It is clear enough that responses to such packets won't be able to make > their way back. I agree - but sometimes there is no need for response - protocols such as OSPF or ICMP Router Advertisements, not to mention UDP video streaming, dont need responses. For network control (ICMP), yes there is need to have ability to reply back always, but some software uses ICMP for network control and UDP for video streaming. One should mpt use the LL src if ICMP is expected, but one could very well use LL src for UDP for video streaming (video is just an example app). > Therefore, if the path of such packets can be traced, it is necessary to > report a bug to various vendors concerned for them to deal with this > issue in accordance with specifications as per > https://tools.ietf.org/html/rfc4291#section-2.5.6. I am not sure we must build in a capability to always trace back to originators. This is may be way beyond pure packet data communications. Alex > > Stephen. > > 2016-06-15 15:03 GMT+04:00 Alexandre Petrescu > >: > > > > Le 15/06/2016 à 12:25, Jen Linkova a écrit : > > On Wed, Jun 15, 2016 at 10:32 AM, Alexandre Petrescu > > wrote: > > In IPv6 this restriction is put on a router receiving a packet > with LL src address. > > In IPv4 RFC3927 LLs this restriction is put on a Host wishing to > send such a packet - it should not send it to a router for > forwarding (use directly ARP search instead of rt table search > first). > > In IPv4 that spec is silent about a _router_ sending packets > with > LL src address. So one can easily assume that an IPv4 > router is > allowed to send a packet with LL src address to another router. > > > https://tools.ietf.org/html/rfc3927#page-25 " > > Router Considerations > > A router MUST NOT forward a packet with an IPv4 Link-Local source or > destination address, irrespective of the router's default route > configuration or routes obtained from dynamic routing protocols. > > A router which receives a packet with an IPv4 Link-Local source or > destination address MUST NOT forward the packet. This prevents > forwarding of packets back onto the network segment from which they > originated, or to any other segment." > > > Ah right, I did not see it. So IPv4 does not stand as a reason - > it's the same in IPv4 and IPv6. > > IPv4 behaviour is allowed to act this way and IPv6 should be the > same if it wanted to be an easy migration target. > > > Doing the wrong things in IPv6 only because 'it worked like that in > IPv4' does not sound like a very good idea to me. > > In general, packets must have source address which makes sense and > allows identifying a path back to the packet sender. > > (The only exception is a packet with undefined address but there is > at least L2 address, and such packets are not allowed outside of the > link - exactly for that reason). That's why multicast sources > are not > allowed. Allowing packets with unidentifiable sources is a very > slippery slope - from various perspective, including (but not > limited to) security concerns. > > > I read. > > You know I disagree it's a slippery slope. > > I will come back later on this need. > > Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Jun 16 03:03: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 51CC112D096; Thu, 16 Jun 2016 03:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 I34svSTeb4fn; Thu, 16 Jun 2016 03:03:29 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.115]) by ietfa.amsl.com (Postfix) with ESMTP id 92D0412B05D; Thu, 16 Jun 2016 03:03:28 -0700 (PDT) Received: from [193.109.254.67] by server-11.bemta-14.messagelabs.com id B3/CD-01707-F6972675; Thu, 16 Jun 2016 10:03:27 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRWlGSWpSXmKPExsVy+JUil25+ZVK 4wdfNIhZPd15hsfiw9S6bxelje5kdmD2WLPnJFMAYxZqZl5RfkcCaMX3dBOaC9U4VWxbvZ2lg PODYxcjFISSwnlHixLKF7BDOHkaJ7asPAzmcHGwCOhL/l+8Csjk4RATUJT72MYLUMAt8YJI40 PiPCaRGWMBLYv/eVmYQW0TAW2Lrjc2MEPVGEps3i4GEWQRUJZ7fvcwMEuYVcJa406ENsWopk8 SaqbvBxnAKBEpc3zKFDcRmFJCV+NK4Gmwks4C4xK0n88FqJAQEJJbsOc8MYYtKvHz8jxXCVpS 4/HsKC8h8ZgFNifW79CFaFSWmdD8E+4RXQFDi5MwnLCC2kICKRPuCZVCtwRL3+t4zTWAUm4Vk 2yyESbOQTJqFZNICRpZVjBrFqUVlqUW6hkZ6SUWZ6RkluYmZObqGhiZ6uanFxYnpqTmJScV6y fm5mxiBccUABDsYz05zPsQoycGkJMrrqJEULsSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mCN6YCKC dYlJqeWpGWmQOMcJi0BAePkghvPkiat7ggMbc4Mx0idYrRkuPO4htrmThuPXsAJD9NOHCMSYg lLz8vVUqcNwqkQQCkIaM0D24cLAldYpSVEuZlBDpQiKcgtSg3swRV/hWjOAejkjBvOsgUnsy8 Eritr4AOYgI6yGZ6PMhBJYkIKakGxirFjxPizq1e0TrdvOqm/oZTSaVfffre3My+skOR9UK50 9ddT6JXhvrxSe4MXv1yzUe/ao3l8/J/X2XeJbkuzPnFjw+L6/2PfnG9pcC6rs7PQsvo37b1G6 VzGNrNVePPHzA7u/GR+SfPzjSOJx/bJPN3ZPJl886sMNGTMLvOuav9WfmZF/frnZRYijMSDbW Yi4oTAZiJ5Io9AwAA X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-5.tower-56.messagelabs.com!1466071406!23003325!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6573 invoked from network); 16 Jun 2016 10:03:27 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-5.tower-56.messagelabs.com with SMTP; 16 Jun 2016 10:03:27 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 12:03:26 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 12:03:26 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx7OSZDWt19w1D06Dzoga8sHTvZ/r20RA Date: Thu, 16 Jun 2016 10:03:25 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 10:03:26.0620 (UTC) FILETIME=[535045C0:01D1C7B6] 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: Thu, 16 Jun 2016 10:03:33 -0000 SGksDQoNCk5BVCBjYW4gYmUgc3RpbGwgbmVjZXNzYXJ5IGluIElQdjYgaW4gZHVhbC1zdGFjayBz Y2VuYXJpbywgZm9yIGluc3RhbmNlLCB3aGVyZSBldmVyeSBob3N0IGlzIGFzc2lnbmVkIGJvdGgg YSBJUHY0IGFuZCBJUHY2IGFkZHJlc3NlcyBhbmQgdGhlIENHTiBlcXVpcG1lbnQgY2FuJ3QgaGFu ZGxlIHRoZW0gZGlmZmVyZW50bHkuICBVbmZvcnR1bmF0ZWx5IFJGQyA0ODY0IGRvZXMgbm90IG1l bnRpb24gc3VjaCBjYXNlLCBBRkFJSy4NCg0KSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29u Y2VkZSBpdCBjb3VsZCBiZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vz c2FyeSBhbnltb3JlIGluIElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UgY2FzZXMu DQoNCkkgd2FzIG5vdCByZWFsbHkgbWFraW5nIGEgc3BlY2lmaWMgY2FzZSBmb3IgSVB2NiAtIG15 IG9wcG9zaXRpb24gd2FzIHRvIHRoZSBjb25jZXB0IHRoYXQgTkFUIGlzIG5vdCBzZWN1cml0eSwg YW5kIHRvIHRoZSBmYWN0IHRoYXQgaXQgc2hvdWxkIGJlIHdyaXR0ZW4gYXMgc3VjaCBpbiB0aGUg UkZDLiAgTkFUICpkb2VzKiBwcm92aWRlIGEgZm9ybSBvZiBzZWN1cml0eSAtIHRoZSBmYWN0IHRo YXQgaXQgaXMgbm90IGRlc2lyYWJsZSBvciBpdCBpcyB1bm5lY2Vzc2FyeSB0byB1c2UgaXMgYW5v dGhlciB0b3BpYywgaW4gd2hpY2ggSSBiZWxpZXZlIHdlIGFsbCBhZ3JlZSAoYXQgbGVhc3QgZm9y IDk5JSBvZiB1c2UgY2FzZXMgOy0pKQ0KDQoNClJlZ2FyZHMsDQrigIvigIvigIvigIvigIsNCk1h cmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRA0KU2Vu aW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1MjMgwqBNwqArNDkg KDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21h aWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDExOjQzIEFNDQpUbzogTWFy Y28gRXJtaW5pDQpDYzogQnJpYW4gRSBDYXJwZW50ZXI7IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tl IChldnluY2tlKTsgZmdvbnRAc2k2bmV0d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgdjZvcHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmll dyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTA4DQoNCk9uIDE2IEp1bmUgMjAxNiBhdCAxOToxNSwg TWFyY28gRXJtaW5pIDxNYXJjby5Fcm1pbmlAcmVzbWVkLmNvbT4gd3JvdGU6DQo+IFdlbGwsIGFj dHVhbGx5LCBpbmZyYXN0cnVjdHVyZSBoaWRpbmcgSVMgcGFydCBvZiBzZWN1cml0eS4gIEl0IGlz IG5vdCB0aGUgZnVsbCBwaWN0dXJlLCBidXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSB0aGF0IGl0 IGlzIG5vdC4NCj4NCj4gSSBwZXJzb25hbGx5IGRvbid0IHN5bXBhdGhpemUgb24gTkFULWhhdGVy cy4gIE5BVCBoYXMgaXRzIHJlYXNvbnMsIA0KPiBlc3BlY2lhbGx5IGZvciBjYXJyaWVyLWdyYWRl IE5BVA0KDQpDR04gaXNuJ3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHBy b2JsZW0gb2YgSVNQcyBydW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy4NCg0KIGFuZCBlc3Bl Y2lhbGx5IGluIHRoZSB0ZWxjbyBzY2VuYXJpbywgYW5kIHllcywgaXQgZG9lcyBwcm92aWRlIHNv bWUgbGV2ZWwgb2Ygc2VjdXJpdHkgLSBhZ2Fpbiwgbm90IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCBi dXQgaXQgZG9lcy4NCj4NCg0KTkFUIGlzIG5vdCBuZWNlc3NhcnkgaW4gSVB2Ni4gVGhlIGVxdWl2 YWxlbnQgb2YgTkFUJ3MgcGVyY2VpdmVkIHNlY3VyaXR5IGNhbiBiZSBwcm92aWRlZCB2aWEgYWx0 ZXJuYXRpdmUgbWV0aG9kcywgYXMgZGVzY3JpYmVkIGluIFJGQzQ4NjQuDQoNCkEgZnVydGhlciB0 ZWNobmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0 IGlzIHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEg c2luZ2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4g RXh0ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJ UHY2IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCg0KSWYgeW91IHRydWx5 IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNuJ3QgZG8gZW5v dWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFzIHRoZXJlIGFy ZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNlbGYgc3VwcGxp ZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkgaG9zdHMgZS5n LiBIVFRQIGNvb2tpZXMuICJBIFRlY2huaXF1ZSBmb3IgQ291bnRpbmcgTkFUdGVkIEhvc3RzIg0K KGh0dHBzOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+c21iL3BhcGVycy9mbmF0LnBkZikgc2hvd2Vk IGhvdyBhIGZpZWxkIHdpdGhpbiB0aGUgSVB2NCBoZWFkZXIgdGhhdCBsZWFrZWQgYWNyb3NzIGEg TkFUIHdhcyBhYmxlIHRvIGJlIHVzZWQgdG8gaWRlbnRpZnkgaG9zdHMuDQoNCklmIHlvdSB0cnVs eSB3YW50IHRvIGhpZGUgYSBob3N0IGZyb20gdGhlIEludGVybmV0LCB5ZXQgc3RpbGwgYWxsb3cg aXQgdG8gYWNjZXNzIHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQsIHVuZGVyIElQdjYgeW91ciBuZXR3 b3JrIHdvdWxkIHVzZSBVTEEgYWRkcmVzc2luZywgYW5kIGhhdmUgYSBwZXItYXBwbGljYXRpb24g cHJvdG9jb2wgcHJveHkgc2VydmVyIHRoYXQgbWFrZXMgYWxsIHJlcXVlc3RzIGxvb2sgbGlrZSB0 aGV5J3ZlIGVudGlyZWx5IG9yaWdpbmF0ZWQgZnJvbSB0aGUgYXBwbGljYXRpb24gcHJveHkgc2Vy dmVyIGl0c2VsZi4gVG8gdGhlIEludGVybmV0IHNlcnZlciwgdGhlIGFwcGxpY2F0aW9uIHByb3h5 IHNlcnZlciB3b3VsZCBhcHBlYXIgdG8gYmUgdGhlIGFwcGxpY2F0aW9uIGVuZCBob3N0IG1ha2lu ZyB0aGUgcmVxdWVzdHMsIHByZXZlbnRpbmcgYW55IGludGVybmFsIGhvc3QgaWRlbnRpZmllcnMg b3Igb3RoZXIgYXR0cmlidXRlcyBmcm9tIGxlYWtpbmcuDQoNCg0KUmVnYXJkcywNCk1hcmsuDQoN Cg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBNYXJjbyBFcm1pbmkNCj4NCj4gQ0lTU1AsIENJU0EsIENJ U00sIENFSCwgSVRJTCwgTUNQLCBQaEQgU2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QgRCANCj4g KzQ5ICgwKTg5OSA5MDEgMTUyMyAgTSArNDkgKDApMTc1IDQzOSA1NjQyDQo+DQo+IFJlc01lZCBH ZXJtYW55IEluYw0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBP UFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBF IA0KPiBDYXJwZW50ZXINCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMTo0NSBBTQ0K PiBUbzogRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQo+IENjOiBmZ29udEBzaTZu ZXR3b3Jrcy5jb207IG9wc2VjQGlldGYub3JnOyBsaW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlOyAN Cj4gZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtPUFNFQ10gW3Y2b3BzXSBBc2tpbmcgZm9yIGEgcmV2aWV3IG9mIA0KPiBkcmFmdC1p ZXRmLW9wc2VjLXY2LTA4DQo+DQo+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3Jv dGU6DQo+PiBTZWN0aW9uIDIuMS4yIGlzIGZhciB0b28gcGVybWlzc2l2ZSBmb3IgbXkgdGFzdGVz LiAgV2UgbmVlZCB0byBiZSANCj4+IGFibGUgdG8gc2F5IHRoYXQgVUxBK0lQdjYgTkFUIGlzIE5P VCBSRUNPTU1FTkRFRCBieSB0aGUgSUVURi4NCj4NCj4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3 aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVu dCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUgaW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hv dWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQgTkFUICE9IHNlY3VyaXR5Lg0KPg0KPiBXaGls ZSBJJ20gaGVyZSwgc29tZSBvdGhlciBwb2ludHM6DQo+DQo+ICIyLjIuICBFeHRlbnNpb24gSGVh ZGVycw0KPg0KPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5h bmRvJ3MgSS1EICYgUkZDLiINCj4NCj4gVGhhdCdzIG5vdCB0aGUgd2hvbGUgc3RvcnkgOy0pLiBG aXJzdGx5LCBSRkMgNzA0NSBoYXMgYSBsb3Qgb2YgDQo+IHJlbGV2YW5jZSB0byBzZWN1cml0eSBh c3BlY3RzLiBTZWNvbmQsIHRoZXJlIGlzIG5vIHJlYXNvbiB0byByZWZlciB0byANCj4gbW9zdCBv ZiB0aGUgbWF0ZXJpYWwgKEZlcm5hbmRvJ3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSBy ZWxldmFudCANCj4gdG8gb3BzZWMuIEkgdGhpbmsgdGhlIHJlZmVyZW5jZSBpcyBkcmFmdC1pZXRm LW9wc2VjLWlwdjYtZWgtZmlsdGVyaW5nLA0KPiBidXQgb25seSBpZiB0aGF0IGRvY3VtZW50IGlz IGdvaW5nIGFueXdoZXJlLg0KPg0KPiAiMi4zLjMuICBORC9SQSBSYXRlIExpbWl0aW5nDQo+IC4u Lg0KPiAgICBUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgYWN0aXZlbHkgZGlzY3Vzc2luZyBtZXRo b2RzIHRvDQo+ICAgIHJhdGUgbGltaXQgUkFzIGFuZCBvdGhlciBORCBtZXNzYWdlcyBvbiB3aWZp IG5ldHdvcmtzIGluIG9yZGVyIHRvDQo+ICAgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4NCj4gICAg byAgW0ktRC50aHViZXJ0LXNhdmktcmEtdGhyb3R0bGVyXQ0KPg0KPiAgICBvICBbSS1ELmNoYWty YWJhcnRpLW5vcmRtYXJrLTZtYW4tZWZmaWNpZW50LW5kXSINCj4NCj4gTmVpdGhlciBvZiB0aG9z ZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAyMDE1IHJlc3Bl Y3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFkZXIsIElNSE8u DQo+DQo+ICI0LjIuICBUcmFuc2l0aW9uIE1lY2hhbmlzbQ0KPg0KPiAgICBTUCB3aWxsIHR5cGlj YWxseSB1c2UgdHJhbnNpdGlvbiBtZWNoYW5pc21zIHN1Y2ggYXMgNnJkLCA2UEUsIE1BUCwNCj4g ICAgRFMtTGl0ZSB3aGljaCBoYXZlIGJlZW4gYW5hbHl6ZWQgaW4gdGhlIHRyYW5zaXRpb24gU2Vj dGlvbiAyLjcuMg0KPiAgICBzZWN0aW9uLiINCj4NCj4gU2hvdWxkbid0IHlvdSBhZGQgUkZDNjg3 NyA0NjRYTEFUIG5vdz8NCj4NCj4gRmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQ cml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+DQo+IFJnZHMNCj4gICAgIEJyaWFuDQo+ DQo+Pg0KPj4gU2VjdGlvbiAyLjYuMS41IGNvdWxkIHB1bmNoIHVwIHRoZSBTQVZJIHN0dWZmIGEg Yml0IG1vcmUgYXMgd2VsbC4gIFdlIA0KPj4gc2hvdWxkLCBpbiBteSBvcGluaW9uLCBtYWtlIGl0 IHBhaW5mdWxseSBjbGVhciB0aGF0IERIQ1AgKG9mIGFueQ0KPj4gcHJvdG9jb2wpIGluIHRoZSBh YnNlbmNlIG9mIGxpbmstbGF5ZXIgc2VjdXJpdHkvYXVkaXRhYmlsaXR5IGZlYXR1cmVzIA0KPj4g ZG9lcyBub3QgcHJvdmlkZSBhbnkgc2F0aXNmYWN0b3J5IHdheSAidG8gZW5zdXJlIGF1ZGliaWxp dHkgYW5kIA0KPj4gdHJhY2VhYmlsaXR5IiBbU2VjdGlvbiAyLjEuNl0uDQo+Pg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1haWxp bmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE9QU0VDIG1haWxpbmcgbGlzdA0KPiBPUFNFQ0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jun 16 05:17: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 1C10112D548; Thu, 16 Jun 2016 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, 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 0d_DqhM6zb_k; Thu, 16 Jun 2016 05:17:15 -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 B97A312D531; Thu, 16 Jun 2016 05:17:14 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so70462874vka.1; Thu, 16 Jun 2016 05:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xZS+hGdxvpzHlQnPCCLqNskU6BuvGXtijoyNDQ0+L88=; b=boQ9IHQ5JFCMSHczZUqmGXQCmIjGd8fk5Y3JyU/6aBM/tQ0CAcl99O5T/P4OjHxX05 WzBSctO7o9LV/suP/f64QnoBRuyMof7QJwQuEtiW0d+eMYYC4VBPZBn60NwCY9VAZZxC Hm4ouDxTmHoZZ6+d969E7pI9vr1srEx9PbSKh4TNt3v1RjplZNtMcfmNltN3JBOY1XN9 IIaIolunaNCqJ0O/wUFWXch/VSWeus+IlCkSKeCMXSMHDc4uSz2AXqRKPsvfDd8ExO9W a32u4YTZSXaRD5scRHWhc3r2suBVw7tLzwxVYZgE0rx8AUURzk734y87XM7xfzpVWuXM GOtg== 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=xZS+hGdxvpzHlQnPCCLqNskU6BuvGXtijoyNDQ0+L88=; b=ha1e5b3y+gLwlsYMCHhYFE+uU020yfuoIYu74Pc9h06EJ6AGqMRxqQIyJUJxyIqPgn 8QVYVUikTPbsTqZq5YdHfFIJMeWB1yOJTff6RmEdtpe7g+ADbvwT2Gpu1zo2Xplg697k 0KuDRiT7+la4AZLIe+BDGxi1z4lrcwH+chZH9WXjnrMOJpCzFJlWeKEStKWS4a0TyxcH WK3TbFJdlNhLOq92KHqj1HQArU5Ut6LiYgtpQig3vc8B//RiiU2Y0Om3mY3wTI+Utxj9 7mK6xFk+iSPERt43l3zysAw2A3cdYALsTtQii1kB9Q2Y9W3F7SSreXoiztmdacok+iiA P1Kw== X-Gm-Message-State: ALyK8tKCU2DY2ywN6k2m2EDfNvWeW+RjPYRFD/V3+SVJ9+7xd3C6YmIFv7XnJ0fPRoXxavQjFoS/1CIZZy77lQ== MIME-Version: 1.0 X-Received: by 10.176.69.141 with SMTP id u13mr2029550uau.133.1466079433559; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 05:17:13 -0700 (PDT) In-Reply-To: References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> Date: Thu, 16 Jun 2016 22:17:13 +1000 Message-ID: From: Mark Smith To: Marco Ermini Content-Type: multipart/alternative; boundary=94eb2c0cbf7ad9947e0535643725 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: Thu, 16 Jun 2016 12:17:17 -0000 --94eb2c0cbf7ad9947e0535643725 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 Jun 2016 20:03, "Marco Ermini" wrote: > > Hi, > > NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently. Can you provide an example of this sort of CGN device. IPv4 and IPv6 have to be handled differently because they're different protocols, requiring different code. A single device might be performing NAT on IPv4 traffic it receives and doing standard stateless forwarding of IPv6 traffic. Is that the scenario you're describing? I'd struggle to believe that there are CGN devices where performing NAT on IPv6 traffic is mandatory if IPv4 NAT is being performed. Unfortunately RFC 4864 does not mention such case, AFAIK. > > In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use cases. > > I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be written as such in the RFC. So this draft is purely about IPv6. There will be a lot of IPv4 security measures that can be applied to IPv6, however there will also be others that shouldn't, and opportunities where IPv6 can provide better security that IPv4 (e.g. sparse host addressing in a /64 makes address probing to discover hosts impossible within a useful and practical timeframe.). > NAT *does* provide a form of security What specific security does it provide that is due to the address translation function? If you're thinking about the protection provided due to the state being created during the address translation process, that state can be created without performing address translation, which is what a stateful firewall does and did in IPv4 before NAT became widely deployed. > - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-)) > I don't see a need to deploy NAT with IPv6 as what has been achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT. Regards, Mark. > > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > ResMed Germany Inc > > > > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com] > Sent: Thursday, June 16, 2016 11:43 AM > To: Marco Ermini > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-0= 8 > > On 16 June 2016 at 19:15, Marco Ermini wrote: > > Well, actually, infrastructure hiding IS part of security. It is not the full picture, but it is incorrect to say that it is not. > > > > I personally don't sympathize on NAT-haters. NAT has its reasons, > > especially for carrier-grade NAT > > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. > > and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > > > > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. > > A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. > > If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. > > If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. > > > Regards, > Mark. > > > > > > Regards, > > > > Marco Ermini > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D > > +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > ResMed Germany Inc > > > > > > -----Original Message----- > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: Thursday, June 16, 2016 1:45 AM > > To: Erik Kline; Eric Vyncke (evyncke) > > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; > > draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > > Subject: Re: [OPSEC] [v6ops] Asking for a review of > > draft-ietf-opsec-v6-08 > > > > On 16/06/2016 07:45, 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 have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT !=3D security. > > > > While I'm here, some other points: > > > > "2.2. Extension Headers > > > > TBD, a short section referring to all Fernando's I-D & RFC." > > > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of > > relevance to security aspects. Second, there is no reason to refer to > > most of the material (Fernando's or not) unless it's directly relevant > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering, > > but only if that document is going anywhere. > > > > "2.3.3. ND/RA Rate Limiting > > ... > > The following drafts are actively discussing methods to > > rate limit RAs and other ND messages on wifi networks in order to > > address this issue: > > > > o [I-D.thubert-savi-ra-throttler] > > > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > > > Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. > > > > "4.2. Transition Mechanism > > > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > > DS-Lite which have been analyzed in the transition Section 2.7.2 > > section." > > > > Shouldn't you add RFC6877 464XLAT now? > > > > Finally, I think there should be a Privacy Considerations section. > > > > Rgds > > Brian > > > >> > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > >> should, in my opinion, make it painfully clear that DHCP (of any > >> protocol) in the absence of link-layer security/auditability features > >> does not provide any satisfactory way "to ensure audibility and > >> traceability" [Section 2.1.6]. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --94eb2c0cbf7ad9947e0535643725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Jun 2016 20:03, "Marco Ermini" <Marco.Ermini@resmed.com> wrote:
>
> Hi,
>
> NAT can be still necessary in IPv6 in dual-stack scenario, for instanc= e, where every host is assigned both a IPv4 and IPv6 addresses and the CGN = equipment can't handle them differently.=C2=A0

Can you provide an example of this sort of CGN device.

IPv4 and IPv6 have to be handled differently because they= 9;re different protocols, requiring different code. A single device might b= e performing NAT on IPv4 traffic it receives and doing standard stateless f= orwarding of IPv6 traffic. Is that the scenario you're describing?

I'd struggle to believe that there are CGN devices where= performing NAT on IPv6 traffic is mandatory if IPv4 NAT is being performed= .

Unfortunately RFC 4864 does not mention such case, AFAIK. >
> In any case, I am happy to concede it could be an extreme case and tha= t it is not necessary anymore in IPv6 for the great majority of use cases.<= br> >
> I was not really making a specific case for IPv6 - my opposition was t= o the concept that NAT is not security, and to the fact that it should be w= ritten as such in the RFC.

So this draft is purely about IPv6. There will be a lot of I= Pv4 security measures that can be applied to IPv6, however there will also = be others that shouldn't, and opportunities where IPv6 can provide bett= er security that IPv4 (e.g. sparse host addressing in a /64 makes address p= robing to discover hosts impossible within a useful and practical timeframe= .).

=C2=A0> NAT *does* provide a form of security

What specific security does it provide that is due to the ad= dress translation function?

If you're thinking about the protection provided due to = the state being created during the address translation process, that state = can be created without performing address translation, which is what a stat= eful firewall does and did in IPv4 before NAT became widely deployed.

> - the fact that it is not desirable or it is unnecessar= y to use is another topic, in which I believe we all agree (at least for 99= % of use cases ;-))
>

I don't see a need to deploy NAT with IPv6 as what has b= een achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of= NAT.

Regards,
Mark.

>
> Regards,
> =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B
> Marco Ermini
>
> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> Senior IT Security Analyst
> D=C2=A0+49 (0)899 901 1523 =C2=A0M=C2=A0+49 (0)175 439 5642
>
> ResMed Germany Inc
>
>
>
> -----Original Message-----
> From: Mark Smith [mailto:mar= kzzzsmith@gmail.com]
> Sent: Thursday, June 16, 2016 11:43 AM
> To: Marco Ermini
> Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org
> Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v= 6-08
>
> On 16 June 2016 at 19:15, Marco Ermini <Marco.Ermini@resmed.com> wrote:
> > Well, actually, infrastructure hiding IS part of security.=C2=A0 = It is not the full picture, but it is incorrect to say that it is not.
> >
> > I personally don't sympathize on NAT-haters.=C2=A0 NAT has it= s reasons,
> > especially for carrier-grade NAT
>
> CGN isn't necessary in IPv6, it's to solve the problem of ISPs= running out of IPv4 addresses.
>
> =C2=A0and especially in the telco scenario, and yes, it does provide s= ome level of security - again, not the complete picture, but it does.
> >
>
> NAT is not necessary in IPv6. The equivalent of NAT's perceived se= curity can be provided via alternative methods, as described in RFC4864. >
> A further technique to hide topology that isn't mentioned in RFC48= 64 is to use something like ISATAP or similar, to create a single /64 subne= t over the top of multiple IPv4 subnets. Externally, all hosts will appear = to belong to a single IPv6 subnet, hiding the internal topology.
>
> If you truly want to hide the identities of hosts, NAT doesn't do = enough - it is only translating addresses, where as there are many other ho= st identifiers that the host itself supplies or will receive and supply tha= t can identify hosts e.g. HTTP cookies. "A Technique for Counting NATt= ed Hosts"
> (https://= www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the= IPv4 header that leaked across a NAT was able to be used to identify hosts= .
>
> If you truly want to hide a host from the Internet, yet still allow it= to access things on the Internet, under IPv6 your network would use ULA ad= dressing, and have a per-application protocol proxy server that makes all r= equests look like they've entirely originated from the application prox= y server itself. To the Internet server, the application proxy server would= appear to be the application end host making the requests, preventing any = internal host identifiers or other attributes from leaking.
>
>
> Regards,
> Mark.
>
>
> >
> > Regards,
> >
> > Marco Ermini
> >
> > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst= D
> > +49 (0)899 901 1523=C2=A0 M +49 (0)175 439 5642
> >
> > ResMed Germany Inc
> >
> >
> > -----Original Message-----
> > From: OPSEC [mailto:ops= ec-bounces@ietf.org] On Behalf Of Brian E
> > Carpenter
> > Sent: Thursday, June 16, 2016 1:45 AM
> > To: Erik Kline; Eric Vyncke (evyncke)
> > Cc: fgont@si6networks.co= m; opsec@ietf.org; linkedin@xn--debrn-nva.de;
> > draft-ietf-opsec-= v6@ietf.org; v6ops@ietf.org
> > Subject: Re: [OPSEC] [v6ops] Asking for a review of
> > draft-ietf-opsec-v6-08
> >
> > On 16/06/2016 07:45, Erik Kline wrote:
> >> Section 2.1.2 is far too permissive for my tastes.=C2=A0 We n= eed to be
> >> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.=
> >
> > I have strong sympathy with that statement, but I don't think= this is the document to do it; the point is made in RFC4864 too. What we s= hould do here is underline that NAT !=3D security.
> >
> > While I'm here, some other points:
> >
> > "2.2.=C2=A0 Extension Headers
> >
> >=C2=A0 =C2=A0 TBD, a short section referring to all Fernando's= I-D & RFC."
> >
> > That's not the whole story ;-). Firstly, RFC 7045 has a lot o= f
> > relevance to security aspects. Second, there is no reason to refe= r to
> > most of the material (Fernando's or not) unless it's dire= ctly relevant
> > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filte= ring,
> > but only if that document is going anywhere.
> >
> > "2.3.3.=C2=A0 ND/RA Rate Limiting
> > ...
> >=C2=A0 =C2=A0 The following drafts are actively discussing methods= to
> >=C2=A0 =C2=A0 rate limit RAs and other ND messages on wifi network= s in order to
> >=C2=A0 =C2=A0 address this issue:
> >
> >=C2=A0 =C2=A0 o=C2=A0 [I-D.thubert-savi-ra-throttler]
> >
> >=C2=A0 =C2=A0 o=C2=A0 [I-D.chakrabarti-nordmark-6man-efficient-nd]= "
> >
> > Neither of those drafts is in the least active (from 2012 and 201= 5 respectively). Dead drafts are of no help to the reader, IMHO.
> >
> > "4.2.=C2=A0 Transition Mechanism
> >
> >=C2=A0 =C2=A0 SP will typically use transition mechanisms such as = 6rd, 6PE, MAP,
> >=C2=A0 =C2=A0 DS-Lite which have been analyzed in the transition S= ection 2.7.2
> >=C2=A0 =C2=A0 section."
> >
> > Shouldn't you add RFC6877 464XLAT now?
> >
> > Finally, I think there should be a Privacy Considerations section= .
> >
> > Rgds
> >=C2=A0 =C2=A0 =C2=A0Brian
> >
> >>
> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as w= ell.=C2=A0 We
> >> should, in my opinion, make it painfully clear that DHCP (of = any
> >> protocol) in the absence of link-layer security/auditability = features
> >> does not provide any satisfactory way "to ensure audibil= ity and
> >> traceability" [Section 2.1.6].
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> > _______________________________________________
> > OPSEC mailing list
> > OPSEC@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/opsec
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops

--94eb2c0cbf7ad9947e0535643725-- From nobody Thu Jun 16 07:15: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 3882312D6B5; Thu, 16 Jun 2016 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 gZ3dnzQbHZdg; Thu, 16 Jun 2016 07:15:09 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.249]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8D12D6AE; Thu, 16 Jun 2016 07:15:08 -0700 (PDT) Received: from [85.158.143.99] by server-2.bemta-6.messagelabs.com id 0D/E1-11548-B64B2675; Thu, 16 Jun 2016 14:15:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRWlGSWpSXmKPExsVy+JUil272lqR wg+/3xSye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y/GsLpaCF6UVc/qOsDQw LinpYuTiEBJYzyixb0oTG4Szh1Hi2MOT7F2MnBxsAjoS/5fvArI5OEQE1CU+9jGChJkFPjFJ3 J6SCGILC3hJ7N/bygxiiwh4S2y9sZkRotxI4t82HZAwi4CqxJf7O8Am8go4S6y89I4VYtUrZo ln06aygSQ4BQIlls6cyARiMwrISnxpXM0MsUtc4taT+WBxCQEBiSV7zjND2KISLx//Y4WwFSR WXJrABLKXWUBTYv0ufYhWRYkp3Q+h9gpKnJz5hAXEFhJQkWhfsAyqNVhi4aJdzBMYxWYh2TYL YdIsJJNmIZm0gJFlFaN6cWpRWWqRrrFeUlFmekZJbmJmjq6hgZlebmpxcWJ6ak5iUrFecn7uJ kZgVDEAwQ7Gjn9OhxglOZiURHnr65PChfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwPtoElBMsSk 1PrUjLzAHGN0xagoNHSYT3FUiat7ggMbc4Mx0idYrRkuPO4htrmThuPXsAJD9NOHCMSYglLz8 vVUqc9wlIgwBIQ0ZpHtw4WAq6xCgrJczLCHSgEE9BalFuZgmq/CtGcQ5GJWGIKTyZeSVwW18B HcQEdJDN9HiQg0oSEVJSDYzpETeT95x4fqOw8ey5P261K3fnHYh05Hdc3J2iV1TRduiymd1eL seXWSyi4da6MvOMzvkta23jclGb1a2RIOSxb8c6U365yCk7r3PV+Yqv8Qu/vGXWofsl7f+/Na x2W3DTYvu7M/Ku0Z7+fy9dP8zgwZWvtiTgYKHGzQN/s8Rf7U/aP/Wr4WwlluKMREMt5qLiRAB 2lIoPPAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1466086507!11202740!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7009 invoked from network); 16 Jun 2016 14:15:07 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-8.tower-216.messagelabs.com with SMTP; 16 Jun 2016 14:15:07 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 16 Jun 2016 16:15:06 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Thu, 16 Jun 2016 16:15:06 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx8kDZDWt19w1D06Dzoga8sHTvZ/sGD1g Date: Thu, 16 Jun 2016 14:15:05 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.15.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jun 2016 14:15:06.0985 (UTC) FILETIME=[7BD51D90:01D1C7D9] 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: Thu, 16 Jun 2016 14:15:14 -0000 SSdsbCB0cnkgdGhlIGhvcnJpYmxlIE91dGxvb2sgdG8gcmVwbHkgdXNpbmcgdGV4dCwgcGxlYXNl IGJlZyBteSBwYXJkb24gaWYgdGhpcyBpcyBub3QgZm9ybWF0dGVkIHByb3Blcmx5Lg0KDQpPbiBU aHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBNLCBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6 enNtaXRoQGdtYWlsLmNvbV0gd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBOQVQgY2FuIGJlIHN0aWxs IG5lY2Vzc2FyeSBpbiBJUHY2IGluIGR1YWwtc3RhY2sgc2NlbmFyaW8sIGZvciBpbnN0YW5jZSwg d2hlcmUgZXZlcnkgaG9zdCBpcyBhc3NpZ25lZCBib3RoIGEgSVB2NCBhbmQgSVB2NiBhZGRyZXNz ZXMgYW5kIHRoZQ0KPj4gQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUgdGhlbSBkaWZmZXJlbnRs eS7CoA0KPkNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2 aWNlLg0KDQpJIHdvdWxkIHByZWZlciBub3QgdG8gbWFrZSBuYW1lcywgYnV0IHlvdSB3b3VsZCBi ZSB1bnBsZWFzYW50bHkgc3VycHJpc2VkLiAgQW55d2F5LCBpdCBpcyBhbHNvIG5vdCBqdXN0IGEg bWF0dGVyIG9mIG5vdCBiZWluZyBhYmxlIHRvIGNvbmZpZ3VyZSB0aGVtIGluIGEgY2VydGFpbiB3 YXkgKHdoaWNoIGlzIHBvc3NpYmx5IHRoZSBjYXNlKSwgYnV0IGFsc28gdGhlIGNhc2UgaW4gd2hp Y2ggdGhleSBkb24ndCB3b3JrIHByb3Blcmx5Lg0KDQo+IElQdjQgYW5kIElQdjYgaGF2ZSB0byBi ZSBoYW5kbGVkIGRpZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xz LCByZXF1aXJpbmcgZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZQ0KPiBw ZXJmb3JtaW5nIE5BVCBvbiBJUHY0IHRyYWZmaWMgaXQgcmVjZWl2ZXMgYW5kIGRvaW5nIHN0YW5k YXJkIHN0YXRlbGVzcyBmb3J3YXJkaW5nIG9mIElQdjYgdHJhZmZpYy4gSXMgdGhhdCB0aGUgc2Nl bmFyaW8geW91J3JlIGRlc2NyaWJpbmc/DQoNClllcywgZm9yIGluc3RhbmNlLiAgT3IsIHRoZXkg aGFuZGxlIGNlcnRhaW4gZnVuY3Rpb25zIChlLmcuIE5BVCkgcHVyZWx5IGluIHRoZSBkYXRhIHBs YW5lIGFzIHRoZXkgYXJlIGxvZ2ljYWxseSBzaW1wbGUgdG8gYmUgaW1wbGVtZW50ZWQgaW4gZmly bXdhcmUsIHdoaWxlIG1vcmUgY29tcGxleCBmdW5jdGlvbnMgKGxpa2UgaW1wbGVtZW50aW5nIFVM QSBhZGRyZXNzZXMgdHJhbnNsYXRpb24pIHJlcXVpcmVzIHJvdXRpbmUgZW5naW5lcyB0byBiZSBp bnZvbHZlZCwgdGhlcmVmb3JlIGludm9sdmluZyBkaWZmZXJlbnQgbGF0ZW5jeSBmb3IgZXhlY3V0 aW9uLg0KDQpJdCBpcyBwcmV0dHkgY29tbW9uIHRoYXQgY3VzdG9tZXJzIHdpdGggSVNQcyBvZmZl cmluZyBkdWFsIHN0YWNrLCB0byBleHBlcmllbmNlIGEgaGlnaGVyIGxhdGVuY3kgZm9yIHRoZWly IGNvbm5lY3Rpb24gb25jZSB0aGV5IGltcGxlbWVudCBJUHY2IGFsb25nIHdpdGggSVB2NC4gICBU aGlzIGRvZXMgbm90IGFwcGx5IHdoZW4gb25seSBJUHY0IG9yIG9ubHkgSVB2NiBhcmUgdXNlZC4N Cg0KQW5vdGhlciByZXF1aXJlbWVudCBpcyB0aGF0IGEgc3BlY2lmaWMgbG9nZ2luZyBvciBtb25p dG9yaW5nIHN5c3RlbSBpcyBpbXBsZW1lbnRlZCAoZXNwZWNpYWxseSBmb3IgbGVnYWwgcmVxdWly ZW1lbnRzKSwgYW5kIHRoaXMgaXMgZG9uZSB0aHJvdWdoIGxvZ2dpbmcgTkFUIHRyYW5zbGF0aW9u cy4gIEFuIElTUCBpbXBsZW1lbnRpbmcgSVB2NiBhbG9uZyB3aXRoIElQdjQgd291bGQgYmUgaW4g dGhhdCBzaXR1YXRpb24uDQoNCkx1Y2tpbHksIHJvdXRlciB2ZW5kb3JzIGFyZSBtb3ZpbmcgYXdh eSBmcm9tIHRoZSBhbnRpcXVhdGUgYXJjaGl0ZWN0dXJlIHdoaWNoIHNlcGFyYXRlcyBkYXRhIGFu ZCBtYW5hZ2VtZW50IHBsYW5lLCBmb3IgdmFyaW91cyByZWFzb25zLg0KDQpUaGlzIGlzIGFsc28g d2h5IHdlIHB1Ymxpc2hlZCBkcmFmdC1nb250LW9wc2VjLWlwdjYtZmlyZXdhbGwtcmVxcy0wMy50 eHQsIHRvIG1ha2UgaXQgZXhwbGljaXQgdGhhdCB0aGlzIHNob3VsZCBub3QgaGFwcGVuLg0KDQoo SSBhbSBhd2FyZSB0aGlzIGlzIG9mZi10b3BpYywganVzdCBtYWtpbmcgbXkgcG9pbnQgOi0pKQ0K DQo+PlVuZm9ydHVuYXRlbHkgUkZDIDQ4NjQgZG9lcyBub3QgbWVudGlvbiBzdWNoIGNhc2UsIEFG QUlLLg0KPj4NCj4gSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29uY2VkZSBpdCBjb3VsZCBi ZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSBhbnltb3JlIGlu IElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UNCj4gY2FzZXMuDQoNCk9rYXkNCg0K Pj4gSSB3YXMgbm90IHJlYWxseSBtYWtpbmcgYSBzcGVjaWZpYyBjYXNlIGZvciBJUHY2IC0gbXkg b3Bwb3NpdGlvbiB3YXMgdG8gdGhlIGNvbmNlcHQgdGhhdCBOQVQgaXMgbm90IHNlY3VyaXR5LCBh bmQgdG8gdGhlIGZhY3QgdGhhdCBpdCBzaG91bGQgYmUNCj4+IHdyaXR0ZW4gYXMgc3VjaCBpbiB0 aGUgUkZDLg0KPiBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91dCBJUHY2LiBUaGVyZSB3aWxs IGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhhdCBjYW4gYmUgYXBwbGllZCB0 byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhlcnMNCj4gdGhhdCBzaG91bGRu J3QsIGFuZCBvcHBvcnR1bml0aWVzIHdoZXJlIElQdjYgY2FuIHByb3ZpZGUgYmV0dGVyIHNlY3Vy aXR5IHRoYXQgSVB2NCAoZS5nLiBzcGFyc2UgaG9zdCBhZGRyZXNzaW5nIGluIGEgLzY0IG1ha2Vz IGFkZHJlc3MgcHJvYmluZw0KPiB0byBkaXNjb3ZlciBob3N0cyBpbXBvc3NpYmxlIHdpdGhpbiBh IHVzZWZ1bCBhbmQgcHJhY3RpY2FsIHRpbWVmcmFtZS4pLg0KDQpPa2F5LCBJIGhhdmUgbm90aGlu ZyB0byBvYmplY3Qgb24gdGhpcy4NCg0KDQo+PiBOQVQgKmRvZXMqIHByb3ZpZGUgYSBmb3JtIG9m IHNlY3VyaXR5DQo+V2hhdCBzcGVjaWZpYyBzZWN1cml0eSBkb2VzIGl0IHByb3ZpZGUgdGhhdCBp cyBkdWUgdG8gdGhlIGFkZHJlc3MgdHJhbnNsYXRpb24gZnVuY3Rpb24/DQo+IElmIHlvdSdyZSB0 aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlvbiBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJl aW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRyZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQg c3RhdGUgY2FuIGJlDQo+IGNyZWF0ZWQgd2l0aG91dCBwZXJmb3JtaW5nIGFkZHJlc3MgdHJhbnNs YXRpb24sIHdoaWNoIGlzIHdoYXQgYSBzdGF0ZWZ1bCBmaXJld2FsbCBkb2VzIGFuZCBkaWQgaW4g SVB2NCBiZWZvcmUgTkFUIGJlY2FtZSB3aWRlbHkgZGVwbG95ZWQuDQoNCkkgdG90YWxseSBhZ3Jl ZSB3aXRoIHlvdS4gIEkgYW0gYWN0dWFsbHkgcmVmZXJyaW5nIHRvIHRoZSBwb3NzaWJpbGl0eSB0 byBoaWRlIHRoZSBzeXN0ZW1zIGJlaGluZCB0aGUgTkFUdGVkIGludGVyZmFjZXMgb2YgdGhlIHJv dXRlci9maXJld2FsbCwgbm90IGp1c3QgdGhlaXIgYWRkcmVzc2VzIGJ1dCBhbHNvIHBvcnRzIGFu ZCBzZXJ2aWNlcy4gIElmIHlvdSBvbmx5IGFwcGx5IGZpbHRlcmluZywgeW91IGFyZSBwcm90ZWN0 aW5nIC0gYnV0IG5vdCBoaWRpbmcuDQoNCkluIGEgcGVyZmVjdCB3b3JsZCwgeW91IGhhdmUgc3Vj aCBnb29kIGZpbHRlcnMgdGhhdCB5b3UgY2FuIHRyYW5zcGFyZW50bHkgcHJvdmlkZSB0aGUgcmVh bCBhZGRyZXNzZXMgYW5kIHBvcnRzIGZyb20gY2xpZW50cyB0byB0aGUgcmVzdCBvZiB0aGUgSW50 ZXJuZXQgLSBob3dldmVyIHdlIGRvbid0IGxpdmUgaW4gc3VjaCB3b3JsZCwgdGhlcmVmb3JlIGhp ZGluZyBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIHByb3RlY3Rpb24gaW4gdGhlICJk ZWZlbmNlIGluIGRlcHRoIiBhcHByb2FjaC4NCg0KVGhlIGZhY3QgdGhhdCB0aGlzICJoaWRpbmci IGFjdHVhbGx5IGhpbmRlcnMgdGhlIGRlcGxveW1lbnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFr ZXMgbGlmZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4gbWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3Bp YyBvbiB3aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDotKQ0KDQpUaGVyZSBhcmUgYWxzbyBjYXNlcyB3 aGVyZSBOQVQgb2ZmZXJzIGJldHRlciAob3IgYXQgbGVhc3Qgc2ltcGxlcikgcHJvdGVjdGlvbiB0 aGFuIGZpbHRlcnMuICBGb3IgaW5zdGFuY2UsIHRoZXJlIGFyZSBrbm93biAib3ZlcmJpbGxpbmcg YXR0YWNrcyIgcGVyZm9ybWVkIGluIHRlbGNvIG5ldHdvcmtzLCB3aGVyZSBtb2JpbGUgdGVybWlu YWxzIGFyZSBzZW50IHdpdGggVURQIHBhY2tldHMgdG8ga2VlcCB0aGVtIGFsaXZlIGV2ZW4gaWYg d291bGQgYWN0dWFsbHkgZGlzY29ubmVjdCwgY2F1c2luZyB0aGVtIHRvIGJlIGV4Y2Vzc2l2ZWx5 IGJpbGxlZC4gIEZpbHRlcnMgZm9yIHRob3NlIHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGlj YXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcg b3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUgdGVybWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRm b3J3YXJkIHByb3RlY3Rpb24sIGluc3RlYWQuDQoNClBTLiBJIGFtIGF3YXJlIHRoYXQgbWFqb3Ig ZmlyZXdhbGwgdmVuZG9ycyBpbXBsZW1lbnQgZmlsdGVycyBhZ2FpbnN0IG92ZXJiaWxsaW5nIGF0 dGFja3M7IEkgd2FzIG9ubHkgbWFraW5nIGFuIG9iamVjdGlvbiB0byB0aGUgc2VtYW50aWMgb2Yg dGhlIHNlbnRlbmNlOiBOQVQgKnByb3ZpZGVzKiBzZWN1cml0eSwgc2F5aW5nIHRoZSBjb250cmFy eSBpcyBub3QgY29ycmVjdC4gIFdoZXRoZXIgdGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiBzb21l IG90aGVyIHdheXMgaXMgYW5vdGhlciBtYXR0ZXIuDQoNCg0KPj4gLSB0aGUgZmFjdCB0aGF0IGl0 IGlzIG5vdCBkZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNlIGlzIGFub3RoZXIg dG9waWMsIGluIHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxlYXN0IGZvciA5OSUg b2YgdXNlIGNhc2VzIDstKSkNCj4NCj4gSSBkb24ndCBzZWUgYSBuZWVkIHRvIGRlcGxveSBOQVQg d2l0aCBJUHY2IGFzIHdoYXQgaGFzIGJlZW4gYWNoaWV2ZWQgd2l0aCBJUHY0IE5BVCBjYW4gYmUg YWNoaWV2ZWQgaW4gSVB2NiB3aXRob3V0IHRoZSBkcmF3YmFja3Mgb2YgTkFULg0KDQpJIG1lYW4g dGhlIHNhbWUgYXMgeW91IGRvLCBJIHdvdWxkIGp1c3QgcGhyYXNlIGl0IGFzICJ0aGUgcG9vciBJ U1BzIHdoaWNoIHN0aWxsIGRvIHRoYXQsIHNob3VsZCBjb25zaWRlciBtaWdyYXRpbmcgdGhlaXIg YXJjaGl0ZWN0dXJlIHRvIGJldHRlciBvcHRpb25zIi4NCg0KDQpSZWdhcmRzLA0KTWFyY28NCg0K Pg0KPlJlZ2FyZHMsDQo+TWFyay4NCj4NCj4gUmVnYXJkcywNCj4g4oCL4oCL4oCL4oCL4oCLDQo+ IE1hcmNvIEVybWluaQ0KPg0KPiBDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBo RA0KPiBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlzdA0KPiBEwqArNDkgKDApODk5IDkwMSAxNTIz IMKgTcKgKzQ5ICgwKTE3NSA0MzkgNTY0Mg0KPg0KPiBSZXNNZWQgR2VybWFueSBJbmMNCj4NCj4N Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyayBTbWl0aCBbbWFp bHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAy MDE2IDExOjQzIEFNDQo+IFRvOiBNYXJjbyBFcm1pbmkNCj4gQ2M6IEJyaWFuIEUgQ2FycGVudGVy OyBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSk7IGZnb250QHNpNm5ldHdvcmtzLmNv bTsgb3BzZWNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IGxpbmtlZGlu QHhuLS1kZWJybi1udmEuZGU7IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNd IFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTA4DQo+ DQo+IE9uIDE2IEp1bmUgMjAxNiBhdCAxOToxNSwgTWFyY28gRXJtaW5pIDxNYXJjby5Fcm1pbmlA cmVzbWVkLmNvbT4gd3JvdGU6DQo+ID4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhp ZGluZyBJUyBwYXJ0IG9mIHNlY3VyaXR5LsKgIEl0IGlzIG5vdCB0aGUgZnVsbCBwaWN0dXJlLCBi dXQgaXQgaXMgaW5jb3JyZWN0IHRvIHNheSB0aGF0IGl0IGlzIG5vdC4NCj4gPg0KPiA+IEkgcGVy c29uYWxseSBkb24ndCBzeW1wYXRoaXplIG9uIE5BVC1oYXRlcnMuwqAgTkFUIGhhcyBpdHMgcmVh c29ucywNCj4gPiBlc3BlY2lhbGx5IGZvciBjYXJyaWVyLWdyYWRlIE5BVA0KPg0KPiBDR04gaXNu J3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgSVNQcyBy dW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy4NCj4NCj4gwqBhbmQgZXNwZWNpYWxseSBpbiB0 aGUgdGVsY28gc2NlbmFyaW8sIGFuZCB5ZXMsIGl0IGRvZXMgcHJvdmlkZSBzb21lIGxldmVsIG9m IHNlY3VyaXR5IC0gYWdhaW4sIG5vdCB0aGUgY29tcGxldGUgcGljdHVyZSwgYnV0IGl0IGRvZXMu DQo+ID4NCj4NCj4gTkFUIGlzIG5vdCBuZWNlc3NhcnkgaW4gSVB2Ni4gVGhlIGVxdWl2YWxlbnQg b2YgTkFUJ3MgcGVyY2VpdmVkIHNlY3VyaXR5IGNhbiBiZSBwcm92aWRlZCB2aWEgYWx0ZXJuYXRp dmUgbWV0aG9kcywgYXMgZGVzY3JpYmVkIGluIFJGQzQ4NjQuDQo+DQo+IEEgZnVydGhlciB0ZWNo bmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0IGlz IHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEgc2lu Z2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4gRXh0 ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJUHY2 IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCj4NCj4gSWYgeW91IHRydWx5 IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNuJ3QgZG8gZW5v dWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFzIHRoZXJlIGFy ZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNlbGYgc3VwcGxp ZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkgaG9zdHMgZS5n LiBIVFRQIGNvb2tpZXMuICJBIFRlY2huaXF1ZSBmb3IgQ291bnRpbmcgTkFUdGVkIEhvc3RzIg0K PiAoaHR0cHM6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRmKSBzaG93 ZWQgaG93IGEgZmllbGQgd2l0aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBhY3Jvc3Mg YSBOQVQgd2FzIGFibGUgdG8gYmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy4NCj4NCj4gSWYgeW91 IHRydWx5IHdhbnQgdG8gaGlkZSBhIGhvc3QgZnJvbSB0aGUgSW50ZXJuZXQsIHlldCBzdGlsbCBh bGxvdyBpdCB0byBhY2Nlc3MgdGhpbmdzIG9uIHRoZSBJbnRlcm5ldCwgdW5kZXIgSVB2NiB5b3Vy IG5ldHdvcmsgd291bGQgdXNlIFVMQSBhZGRyZXNzaW5nLCBhbmQgaGF2ZSBhIHBlci1hcHBsaWNh dGlvbiBwcm90b2NvbCBwcm94eSBzZXJ2ZXIgdGhhdCBtYWtlcyBhbGwgcmVxdWVzdHMgbG9vayBs aWtlIHRoZXkndmUgZW50aXJlbHkgb3JpZ2luYXRlZCBmcm9tIHRoZSBhcHBsaWNhdGlvbiBwcm94 eSBzZXJ2ZXIgaXRzZWxmLiBUbyB0aGUgSW50ZXJuZXQgc2VydmVyLCB0aGUgYXBwbGljYXRpb24g cHJveHkgc2VydmVyIHdvdWxkIGFwcGVhciB0byBiZSB0aGUgYXBwbGljYXRpb24gZW5kIGhvc3Qg bWFraW5nIHRoZSByZXF1ZXN0cywgcHJldmVudGluZyBhbnkgaW50ZXJuYWwgaG9zdCBpZGVudGlm aWVycyBvciBvdGhlciBhdHRyaWJ1dGVzIGZyb20gbGVha2luZy4NCj4NCj4NCj4gUmVnYXJkcywN Cj4gTWFyay4NCj4NCj4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBNYXJjbyBFcm1pbmkN Cj4gPg0KPiA+IENJU1NQLCBDSVNBLCBDSVNNLCBDRUgsIElUSUwsIE1DUCwgUGhEIFNlbmlvciBJ VCBTZWN1cml0eSBBbmFseXN0IEQNCj4gPiArNDkgKDApODk5IDkwMSAxNTIzwqAgTSArNDkgKDAp MTc1IDQzOSA1NjQyDQo+ID4NCj4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPg0KPiA+DQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2Vj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+ID4gQ2FycGVudGVyDQo+ ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMTo0NSBBTQ0KPiA+IFRvOiBFcmlrIEts aW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkNCj4gPiBDYzogZmdvbnRAc2k2bmV0d29ya3MuY29t OyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsNCj4gPiBkcmFmdC1p ZXRmLW9wc2VjLXY2QGlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb T1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZg0KPiA+IGRyYWZ0LWlldGYtb3Bz ZWMtdjYtMDgNCj4gPg0KPiA+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3JvdGU6 DQo+ID4+IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZlIGZvciBteSB0YXN0ZXMu wqAgV2UgbmVlZCB0byBiZQ0KPiA+PiBhYmxlIHRvIHNheSB0aGF0IFVMQStJUHY2IE5BVCBpcyBO T1QgUkVDT01NRU5ERUQgYnkgdGhlIElFVEYuDQo+ID4NCj4gPiBJIGhhdmUgc3Ryb25nIHN5bXBh dGh5IHdpdGggdGhhdCBzdGF0ZW1lbnQsIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIGRv Y3VtZW50IHRvIGRvIGl0OyB0aGUgcG9pbnQgaXMgbWFkZSBpbiBSRkM0ODY0IHRvby4gV2hhdCB3 ZSBzaG91bGQgZG8gaGVyZSBpcyB1bmRlcmxpbmUgdGhhdCBOQVQgIT0gc2VjdXJpdHkuDQo+ID4N Cj4gPiBXaGlsZSBJJ20gaGVyZSwgc29tZSBvdGhlciBwb2ludHM6DQo+ID4NCj4gPiAiMi4yLsKg IEV4dGVuc2lvbiBIZWFkZXJzDQo+ID4NCj4gPsKgIMKgIFRCRCwgYSBzaG9ydCBzZWN0aW9uIHJl ZmVycmluZyB0byBhbGwgRmVybmFuZG8ncyBJLUQgJiBSRkMuIg0KPiA+DQo+ID4gVGhhdCdzIG5v dCB0aGUgd2hvbGUgc3RvcnkgOy0pLiBGaXJzdGx5LCBSRkMgNzA0NSBoYXMgYSBsb3Qgb2YNCj4g PiByZWxldmFuY2UgdG8gc2VjdXJpdHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVyZSBpcyBubyByZWFz b24gdG8gcmVmZXIgdG8NCj4gPiBtb3N0IG9mIHRoZSBtYXRlcmlhbCAoRmVybmFuZG8ncyBvciBu b3QpIHVubGVzcyBpdCdzIGRpcmVjdGx5IHJlbGV2YW50DQo+ID4gdG8gb3BzZWMuIEkgdGhpbmsg dGhlIHJlZmVyZW5jZSBpcyBkcmFmdC1pZXRmLW9wc2VjLWlwdjYtZWgtZmlsdGVyaW5nLA0KPiA+ IGJ1dCBvbmx5IGlmIHRoYXQgZG9jdW1lbnQgaXMgZ29pbmcgYW55d2hlcmUuDQo+ID4NCj4gPiAi Mi4zLjMuwqAgTkQvUkEgUmF0ZSBMaW1pdGluZw0KPiA+IC4uLg0KPiA+wqAgwqAgVGhlIGZvbGxv d2luZyBkcmFmdHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0bw0KPiA+wqAgwqAg cmF0ZSBsaW1pdCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9uIHdpZmkgbmV0d29ya3MgaW4g b3JkZXIgdG8NCj4gPsKgIMKgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4gPg0KPiA+wqAgwqAgb8Kg IFtJLUQudGh1YmVydC1zYXZpLXJhLXRocm90dGxlcl0NCj4gPg0KPiA+wqAgwqAgb8KgIFtJLUQu Y2hha3JhYmFydGktbm9yZG1hcmstNm1hbi1lZmZpY2llbnQtbmRdIg0KPiA+DQo+ID4gTmVpdGhl ciBvZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAy MDE1IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFk ZXIsIElNSE8uDQo+ID4NCj4gPiAiNC4yLsKgIFRyYW5zaXRpb24gTWVjaGFuaXNtDQo+ID4NCj4g PsKgIMKgIFNQIHdpbGwgdHlwaWNhbGx5IHVzZSB0cmFuc2l0aW9uIG1lY2hhbmlzbXMgc3VjaCBh cyA2cmQsIDZQRSwgTUFQLA0KPiA+wqAgwqAgRFMtTGl0ZSB3aGljaCBoYXZlIGJlZW4gYW5hbHl6 ZWQgaW4gdGhlIHRyYW5zaXRpb24gU2VjdGlvbiAyLjcuMg0KPiA+wqAgwqAgc2VjdGlvbi4iDQo+ ID4NCj4gPiBTaG91bGRuJ3QgeW91IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiA+DQo+ID4g RmluYWxseSwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBQcml2YWN5IENvbnNpZGVyYXRpb25z IHNlY3Rpb24uDQo+ID4NCj4gPiBSZ2RzDQo+ID7CoCDCoCDCoEJyaWFuDQo+ID4NCj4gPj4NCj4g Pj4gU2VjdGlvbiAyLjYuMS41IGNvdWxkIHB1bmNoIHVwIHRoZSBTQVZJIHN0dWZmIGEgYml0IG1v cmUgYXMgd2VsbC7CoCBXZQ0KPiA+PiBzaG91bGQsIGluIG15IG9waW5pb24sIG1ha2UgaXQgcGFp bmZ1bGx5IGNsZWFyIHRoYXQgREhDUCAob2YgYW55DQo+ID4+IHByb3RvY29sKSBpbiB0aGUgYWJz ZW5jZSBvZiBsaW5rLWxheWVyIHNlY3VyaXR5L2F1ZGl0YWJpbGl0eSBmZWF0dXJlcw0KPiA+PiBk b2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0 eSBhbmQNCj4gPj4gdHJhY2VhYmlsaXR5IiBbU2VjdGlvbiAyLjEuNl0uDQo+ID4+DQo+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHY2b3Bz IG1haWxpbmcgbGlzdA0KPiA+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9QU0VDIG1haWxpbmcgbGlz dA0KPiA+IE9QU0VDQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNlYw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu Jun 16 17:21:40 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 D428512DE1F; Thu, 16 Jun 2016 17:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, 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 kcDUsQas6v3r; Thu, 16 Jun 2016 17:21: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 9B48C12D7D1; Thu, 16 Jun 2016 17:21:28 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id t129so95801463vka.1; Thu, 16 Jun 2016 17:21: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:date:message-id:subject:from:to :cc; bh=r6ujoTLccWEriWSSauQux8MbHlVs4m56qw1Fv33Cy70=; b=J8MOPmbGGiQ9+z1WDUDu+DGABako3qxvV8hb2WVQblzV76bmshJA1/QinmV5CGjfCG hlaoBFvG7Jn88wYp1V7wGFxNNPf776n6EUYUau8ECR/cFzUWcxSt15aRNgK4JliFi+kf tuW/f8k2+kAi/2m6X/9pGGlvrVRZ0qVuSluXbPMBGBKL0dEUeCNJg/rODDI1U8Liqb63 6dxcHDyjKjS3XX8DPevCZVMvCx3U4Vxtw+q+5vy+xsznAPufFg2r0+SV3mK5cDR3wFBS OJlgZUEu93rE8zxUXVsFBjdrCVxPwk6esPIG4oAwdvFBGexlTtEjFlCDUmC8MNXix2vN ioxg== 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=r6ujoTLccWEriWSSauQux8MbHlVs4m56qw1Fv33Cy70=; b=StHD6h70cmPFxdTVMufRNUOVS+yXxjfFPmwm8TX1nfl7lNNgFDhFmpw9e6Y91Q7e9/ ZUzs7a9MvC1drLY2zXKBHmjGimdUjOCjPJMyq07VxEtSBEM1tr6zuQcckFScwEMMSfnA woPvIJa1pr2oWJzLbeZ2YwqUGp9gY5ZevRXrL91IMWIfIfiSFAZWfP95RyW3TC+kmw1B 9ttCwKXPPsBrOZz5fkCGqzCjeMyuHjwuxQG51HWWS6TsnGv4sgpk/7aC39uS0Vx4aKfr vHxTaPUdkFY15YdPk9mv8iLhH6n3YTSj11lx6cU661+SGX2O51L8X3gDy2WhG/RPfbbg 6Efw== X-Gm-Message-State: ALyK8tIhi0dwf50fcf2LF6HwSlGb4YPJtUU013NQEH/wFEIEaWPaPaQa6/7ETpWYztyoPzM+MUODB7Vd88N2Ow== MIME-Version: 1.0 X-Received: by 10.176.2.87 with SMTP id 81mr3036088uas.67.1466122887300; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 17:21:27 -0700 (PDT) In-Reply-To: <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> Date: Fri, 17 Jun 2016 10:21:27 +1000 Message-ID: From: Mark Smith To: Marco Ermini Content-Type: multipart/alternative; boundary=001a1137634ae50e6505356e55a5 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, 17 Jun 2016 00:21:34 -0000 --001a1137634ae50e6505356e55a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 Jun 2016 00:15, "Marco Ermini" wrote: > > I'll try the horrible Outlook to reply using text, please beg my pardon if this is not formatted properly. > > On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto: markzzzsmith@gmail.com] wrote: > >> Hi, > >> > >> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the > >> CGN equipment can't handle them differently. > >Can you provide an example of this sort of CGN device. > > I would prefer not to make names, but you would be unpleasantly surprised= . I'm sceptical, I and I think others would want a concrete example. If people aren't implementing specifications well, we need to know, so that if necessary the specifications can be improved. Anyway, it is also not just a matter of not being able to configure them in a certain way (which is possibly the case), but also the case in which they don't work properly. > > > IPv4 and IPv6 have to be handled differently because they're different protocols, requiring different code. A single device might be > > performing NAT on IPv4 traffic it receives and doing standard stateless forwarding of IPv6 traffic. Is that the scenario you're describing? > > Yes, for instance. OK, so "CGN" is not being performed on IPv6 traffic. >Or, they handle certain functions (e.g. NAT) purely in the data plane as they are logically simple to be implemented in firmware, while more complex functions (like implementing ULA addresses translation) requires routine engines to be involved, therefore involving different latency for execution= . > So this sounds like equipment here additional features cannot be implemented in hardware, so it is implemented in control plane software. This is an example of why not to use NAT. It is technically very complex compared to pure IPv4 and pure IPv6 forwarding. I'm starting to wonder if people think that if they want to use ULAs for some reason, they think they then must NAT them. If they do, I think that might show a misunderstanding of something fundamental about IPv6 - a host natively supports multiple concurrent addresses with different scopes, and tries to choose one of its source address to match the destination address. > It is pretty common that customers with ISPs offering dual stack, to experience a higher latency for their connection once they implement IPv6 along with IPv4. This does not apply when only IPv4 or only IPv6 are used= . > I'd like some examples of this. I've been natively dual stacked at home for the past near 5 years. I have not experienced additional and noticeable higher latency for anything I do. It just works, and I can't tell what is going over IPv4 or IPv6 - and I know that most if not all Google, Facebook and Netflix traffic can and does come over IPv6. I also worked in the residential deployment of IPv6 at the other end of my connection in 2009/2010, and we never received any IPv6 latency complaints. In 2012 it was enabled by default for new customer connections. I have come across presentations over the past years that have shown that IPv6 has reduced latency for dual stack services, because the IPv6 path was different and simpler than the IPv4 path. > Another requirement is that a specific logging or monitoring system is implemented (especially for legal requirements), and this is done through logging NAT translations. An ISP implementing IPv6 along with IPv4 would be in that situation. > No need to do _address translation_ to be able to perform that. > Luckily, router vendors are moving away from the antiquate architecture which separates data and management plane, for various reasons. > Actually, that's going to increase the cost of equipment, because it isn't going to be cheap to do something complex fast. > This is also why we published draft-gont-opsec-ipv6-firewall-reqs-03.txt, to make it explicit that this should not happen. > > (I am aware this is off-topic, just making my point :-)) > > >>Unfortunately RFC 4864 does not mention such case, AFAIK. > >> > > In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use > > cases. > > Okay > > >> I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be > >> written as such in the RFC. > > So this draft is purely about IPv6. There will be a lot of IPv4 security measures that can be applied to IPv6, however there will also be others > > that shouldn't, and opportunities where IPv6 can provide better security that IPv4 (e.g. sparse host addressing in a /64 makes address probing > > to discover hosts impossible within a useful and practical timeframe.). > > Okay, I have nothing to object on this. > > > >> NAT *does* provide a form of security > >What specific security does it provide that is due to the address translation function? > > If you're thinking about the protection provided due to the state being created during the address translation process, that state can be > > created without performing address translation, which is what a stateful firewall does and did in IPv4 before NAT became widely deployed. > > I totally agree with you. I am actually referring to the possibility to hide the systems behind the NATted interfaces of the router/firewall, not just their addresses but also ports and services. If you only apply filtering, you are protecting - but not hiding. > NAT is no where near as effective at hiding systems as people think. Too many attributes of the system behind the NAT leak across NAT, or can be forced to leak across the NAT. It is quite a porous barrier, because NAT is not actually designed to hide systems. Address translation inherently hides some of the attributes of the systems (addresses) but not all of them. > In a perfect world, you have such good filters that you can transparently provide the real addresses and ports from clients to the rest of the Internet It's sounding like you're not up to date with IPv6 firewalling capabilities in devices, and therefore might be assuming that none exist. Are you aware for example that Windows has had a stateful IPv6 firewall, enabled by default, since Windows XP service pack 2, released more than a decade ago? I've been using IPv6 under Linux to access the Internet either via tunnels or natively for more than a decade, using the stateful IPv6 firewall that has been part of the Linux kernel for at least that long. This Android phone has native and public IPv6 addresses and is not behind any sort of IPv6 NAT. It's behind a device that can perform IPv6 stateful firewalling, however I think I've turned it off, because I trust that as Google can't trust there is a network firewall upstream of my phone, they ensure my phone is "Internet proof". The "perfect" world you're referring to is and has been reality for a long time for a lot of people. >- however we don't live in such world, therefore hiding provides an additional layer of protection in the "defence in depth" approach. > > The fact that this "hiding" actually hinders the deployment of many services and makes life worse to engineers in many cases, is another topic on which we agree totally :-) > > There are also cases where NAT offers better (or at least simpler) protection than filters. For instance, there are known "overbilling attacks" performed in telco networks, where mobile terminals are sent with UDP packets to keep them alive even if would actually disconnect, causing them to be excessively billed. Filters for those situations tend to be complicated and need to understand the Layer-7 protocol running over UDP to protect the terminals; NAT offers a straightforward protection, instead. > There is no need to perform _address translation_ to perform this protection. Continuing to say NAT in these examples is a bit like saying "I need my toolbox to bang in nails". You need your toolbox because that is where your hammer is, however it is actually your hammer that you use to bang in nails= . NAT is address translation + stateful filtering inherent in the operation of address translation. People who object to NAT in IPv6 are objecting to the implied assertion that it is necessary to perform address translation to achieve stateful filtering. People who advocate NAT for IPv6 for security purposes don't seem to understand that address translation is *not* required to be able to perform stateful filtering - or they're using the term "NAT" when they should really be using the term "stateful filtering". > PS. I am aware that major firewall vendors implement filters against overbilling attacks; I was only making an objection to the semantic of the sentence: NAT *provides* security, saying the contrary is not correct. "Security against what" is the key question. You can't actually say NAT provides security without defining the threat or context. If you don't define the threat, the implication of such a statement is that it provides security against literally every threat. If a bank implements NAT on their data network, are they now secured against bank robbers coming into a branch with guns? Obviously not. "NAT *provides* security" is going to be wrong in many cases because NAT is an entirely ineffective measure for a large set of threats. > Whether this could be achieved in some other ways is another matter. > It is the *exact* matter here. NAT is being asserted as the security measure that should by used in IPv6, because it has been used in IPv4 (and not necessarily exclusively because of security - lack of IPv4 addresses is another reason), without any consideration of its drawbacks or alternatives that don't have those drawbacks e.g. those described in RFC4864. > > >> - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-)) > > > > I don't see a need to deploy NAT with IPv6 as what has been achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT. > > I mean the same as you do, I would just phrase it as "the poor ISPs which still do that, should consider migrating their architecture to better options". > The cost of CGN capacity to NAT video traffic volumes from popular video sites is likely going to make deploying native IPv6 a cheaper alternative very quickly. Regards, Mark. > > Regards, > Marco > > > > >Regards, > >Mark. > > > > Regards, > > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > > Marco Ermini > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > > Senior IT Security Analyst > > D +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > ResMed Germany Inc > > > > > > > > -----Original Message----- > > From: Mark Smith [mailto:markzzzsmith@gmail.com] > > Sent: Thursday, June 16, 2016 11:43 AM > > To: Marco Ermini > > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org > > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 > > > > On 16 June 2016 at 19:15, Marco Ermini wrote: > > > Well, actually, infrastructure hiding IS part of security. It is not the full picture, but it is incorrect to say that it is not. > > > > > > I personally don't sympathize on NAT-haters. NAT has its reasons, > > > especially for carrier-grade NAT > > > > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses. > > > > and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does. > > > > > > > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864. > > > > A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology. > > > > If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" > > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts. > > > > If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking. > > > > > > Regards, > > Mark. > > > > > > > > > > Regards, > > > > > > Marco Ermini > > > > > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D > > > +49 (0)899 901 1523 M +49 (0)175 439 5642 > > > > > > ResMed Germany Inc > > > > > > > > > -----Original Message----- > > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E > > > Carpenter > > > Sent: Thursday, June 16, 2016 1:45 AM > > > To: Erik Kline; Eric Vyncke (evyncke) > > > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; > > > draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > > > Subject: Re: [OPSEC] [v6ops] Asking for a review of > > > draft-ietf-opsec-v6-08 > > > > > > On 16/06/2016 07:45, 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 have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT !=3D security. > > > > > > While I'm here, some other points: > > > > > > "2.2. Extension Headers > > > > > > TBD, a short section referring to all Fernando's I-D & RFC." > > > > > > That's not the whole story ;-). Firstly, RFC 7045 has a lot of > > > relevance to security aspects. Second, there is no reason to refer to > > > most of the material (Fernando's or not) unless it's directly relevan= t > > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering= , > > > but only if that document is going anywhere. > > > > > > "2.3.3. ND/RA Rate Limiting > > > ... > > > The following drafts are actively discussing methods to > > > rate limit RAs and other ND messages on wifi networks in order to > > > address this issue: > > > > > > o [I-D.thubert-savi-ra-throttler] > > > > > > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" > > > > > > Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO. > > > > > > "4.2. Transition Mechanism > > > > > > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > > > DS-Lite which have been analyzed in the transition Section 2.7.2 > > > section." > > > > > > Shouldn't you add RFC6877 464XLAT now? > > > > > > Finally, I think there should be a Privacy Considerations section. > > > > > > Rgds > > > Brian > > > > > >> > > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. W= e > > >> should, in my opinion, make it painfully clear that DHCP (of any > > >> protocol) in the absence of link-layer security/auditability feature= s > > >> does not provide any satisfactory way "to ensure audibility and > > >> traceability" [Section 2.1.6]. > > >> > > >> _______________________________________________ > > >> v6ops mailing list > > >> v6ops@ietf.org > > >> https://www.ietf.org/mailman/listinfo/v6ops > > >> > > > > > > _______________________________________________ > > > OPSEC mailing list > > > OPSEC@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops --001a1137634ae50e6505356e55a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 17 Jun 2016 00:15, "Marco Ermini" <Marco.Ermini@resmed.com> wrote:
>
> I'll try the horrible Outlook to reply using text, please beg my p= ardon if this is not formatted properly.
>
> On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto:markzzzsmith@gmail.com] wrote:
> >> Hi,
> >>
> >> NAT can be still necessary in IPv6 in dual-stack scenario, fo= r instance, where every host is assigned both a IPv4 and IPv6 addresses and= the
> >> CGN equipment can't handle them differently.=C2=A0
> >Can you provide an example of this sort of CGN device.
>
> I would prefer not to make names, but you would be unpleasantly surpri= sed.

I'm sceptical, I and I think others would want a concret= e example.

If people aren't implementing specifications well, we ne= ed to know, so that if necessary the specifications can be improved.

=C2=A0 Anyway, it is also not just a matter of not being abl= e to configure them in a certain way (which is possibly the case), but also= the case in which they don't work properly.
>
> > IPv4 and IPv6 have to be handled differently because they're = different protocols, requiring different code. A single device might be
> > performing NAT on IPv4 traffic it receives and doing standard sta= teless forwarding of IPv6 traffic. Is that the scenario you're describi= ng?
>
> Yes, for instance.=C2=A0

OK, so "CGN" is not being performed on IPv6 traffi= c.

>Or, they handle certain functions (e.g. NAT) purely in = the data plane as they are logically simple to be implemented in firmware, = while more complex functions (like implementing ULA addresses translation) = requires routine engines to be involved, therefore involving different late= ncy for execution.
>

So this sounds like equipment here additional features canno= t be implemented in hardware, so it is implemented in control plane softwar= e.

This is an example of why not to use NAT. It is technically = very complex compared to pure IPv4 and pure IPv6 forwarding.

I'm starting to wonder if people think that if they want= to use ULAs for some reason, they think they then must NAT them. If they d= o, I think that might show a misunderstanding of something fundamental abou= t IPv6 - a host natively supports multiple concurrent addresses with differ= ent scopes, and tries to choose one of its source address to match the dest= ination address.

> It is pretty common that customers with ISPs offering d= ual stack, to experience a higher latency for their connection once they im= plement IPv6 along with IPv4.=C2=A0 =C2=A0This does not apply when only IPv= 4 or only IPv6 are used.
>

I'd like some examples of this.

I've been natively dual stacked at home for the past nea= r 5 years. I have not experienced additional and noticeable higher latency = for anything I do. It just works, and I can't tell what is going over I= Pv4 or IPv6 - and I know that most if not all Google, Facebook and Netflix = traffic can and does come over IPv6.

I also worked in the residential deployment of IPv6 at the o= ther end of my connection in 2009/2010, and we never received any IPv6 late= ncy complaints. In 2012 it was enabled by default for new customer connecti= ons.

I have come across presentations over the past years that ha= ve shown that IPv6 has reduced latency for dual stack services, because the= IPv6 path was different and simpler than the IPv4 path.

> Another requirement is that a specific logging or monit= oring system is implemented (especially for legal requirements), and this i= s done through logging NAT translations.=C2=A0 An ISP implementing IPv6 alo= ng with IPv4 would be in that situation.
>

No need to do _address translation_ to be able to perform th= at.

> Luckily, router vendors are moving away from the antiqu= ate architecture which separates data and management plane, for various rea= sons.
>

Actually, that's going to increase the cost of equipment= , because it isn't going to be cheap to do something complex fast.

> This is also why we published draft-gont-opsec-ipv6-fir= ewall-reqs-03.txt, to make it explicit that this should not happen.
>
> (I am aware this is off-topic, just making my point :-))
>
> >>Unfortunately RFC 4864 does not mention such case, AFAIK.
> >>
> > In any case, I am happy to concede it could be an extreme case an= d that it is not necessary anymore in IPv6 for the great majority of use > > cases.
>
> Okay
>
> >> I was not really making a specific case for IPv6 - my opposit= ion was to the concept that NAT is not security, and to the fact that it sh= ould be
> >> written as such in the RFC.
> > So this draft is purely about IPv6. There will be a lot of IPv4 s= ecurity measures that can be applied to IPv6, however there will also be ot= hers
> > that shouldn't, and opportunities where IPv6 can provide bett= er security that IPv4 (e.g. sparse host addressing in a /64 makes address p= robing
> > to discover hosts impossible within a useful and practical timefr= ame.).
>
> Okay, I have nothing to object on this.
>
>
> >> NAT *does* provide a form of security
> >What specific security does it provide that is due to the address = translation function?
> > If you're thinking about the protection provided due to the s= tate being created during the address translation process, that state can b= e
> > created without performing address translation, which is what a s= tateful firewall does and did in IPv4 before NAT became widely deployed. >
> I totally agree with you.=C2=A0 I am actually referring to the possibi= lity to hide the systems behind the NATted interfaces of the router/firewal= l, not just their addresses but also ports and services.=C2=A0 If you only = apply filtering, you are protecting - but not hiding.
>

NAT is no where near as effective at hiding systems as peopl= e think. Too many attributes of the system behind the NAT leak across NAT, = or can be forced to leak across the NAT.

It is quite a porous barrier, because NAT is not actually de= signed to hide systems. Address translation inherently hides some of the at= tributes of the systems (addresses) but not all of them.

> In a perfect world, you have such good filters that you= can transparently provide the real addresses and ports from clients to the= rest of the Internet

It's sounding like you're not up to date with IPv6 f= irewalling capabilities in devices, and therefore might be assuming that no= ne exist.

Are you aware for example that Windows has had a stateful IP= v6 firewall, enabled by default, since Windows XP service pack 2, released = more than a decade ago?

I've been using IPv6 under Linux to access the Internet = either via tunnels or natively for more than a decade, using the stateful I= Pv6 firewall that has been part of the Linux kernel for at least that long.=

This Android phone has native and public IPv6 addresses and = is not behind any sort of IPv6 NAT. It's behind a device that can perfo= rm IPv6 stateful firewalling, however I think I've turned it off, becau= se I trust that as Google can't trust there is a network firewall upstr= eam of my phone, they ensure my phone is "Internet proof".

The "perfect" world you're referring to is and= has been reality for a long time for a lot of people.

>- however we don't live in such world, therefore hid= ing provides an additional layer of protection in the "defence in dept= h" approach.
>
> The fact that this "hiding" actually hinders the deployment = of many services and makes life worse to engineers in many cases, is anothe= r topic on which we agree totally :-)
>
> There are also cases where NAT offers better (or at least simpler) pro= tection than filters.=C2=A0 For instance, there are known "overbilling= attacks" performed in telco networks, where mobile terminals are sent= with UDP packets to keep them alive even if would actually disconnect, cau= sing them to be excessively billed.=C2=A0 Filters for those situations tend= to be complicated and need to understand the Layer-7 protocol running over= UDP to protect the terminals; NAT offers a straightforward protection, ins= tead.
>

There is no need to perform _address translation_ to perform= this protection.

Continuing to say NAT in these examples is a bit like saying= "I need my toolbox to bang in nails". You need your toolbox beca= use that is where your hammer is, however it is actually your hammer that y= ou use to bang in nails.

NAT is address translation + stateful filtering inherent in = the operation of address translation. People who object to NAT in IPv6 are = objecting to the implied assertion that it is necessary to perform address = translation to achieve stateful filtering.

People who advocate NAT for IPv6 for security purposes don&#= 39;t seem to understand that address translation is *not* required to be ab= le to perform stateful filtering - or they're using the term "NAT&= quot; when they should really be using the term "stateful filtering&qu= ot;.

> PS. I am aware that major firewall vendors implement fi= lters against overbilling attacks; I was only making an objection to the se= mantic of the sentence: NAT *provides* security, saying the contrary is not= correct.=C2=A0

"Security against what" is the key question. You c= an't actually say NAT provides security without defining the threat or = context. If you don't define the threat, the implication of such a stat= ement is that it provides security against literally every threat.

If a bank implements NAT on their data network, are they now= secured against bank robbers coming into a branch with guns? Obviously not= .

"NAT *provides* security" is going to be wrong in = many cases because NAT is an entirely ineffective measure for a large set o= f threats.

> Whether this could be achieved in some other ways is an= other matter.
>

It is the *exact* matter here.

NAT is being asserted as the security measure that should by= used in IPv6, because it has been used in IPv4 (and not necessarily exclus= ively because of security - lack of IPv4 addresses is another reason), with= out any consideration of its drawbacks or alternatives that don't have = those drawbacks e.g. those described in RFC4864.

>
> >> - the fact that it is not desirable or it is unnecessary to u= se is another topic, in which I believe we all agree (at least for 99% of u= se cases ;-))
> >
> > I don't see a need to deploy NAT with IPv6 as what has been a= chieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT.=
>
> I mean the same as you do, I would just phrase it as "the poor IS= Ps which still do that, should consider migrating their architecture to bet= ter options".
>

The cost of CGN capacity to NAT video traffic volumes from p= opular video sites is likely going to make deploying native IPv6 a cheaper = alternative very quickly.

Regards,
Mark.

>
> Regards,
> Marco
>
> >
> >Regards,
> >Mark.
> >
> > Regards,
> > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B
> > Marco Ermini
> >
> > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> > Senior IT Security Analyst
> > D=C2=A0+49 (0)899 901 1523 =C2=A0M=C2=A0+49 (0)175 439 5642
> >
> > ResMed Germany Inc
> >
> >
> >
> > -----Original Message-----
> > From: Mark Smith [mailto:markzzzsmith@gmail.com]
> > Sent: Thursday, June 16, 2016 11:43 AM
> > To: Marco Ermini
> > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6networks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debrn-nva.de; v6ops@ietf.org
> > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-op= sec-v6-08
> >
> > On 16 June 2016 at 19:15, Marco Ermini <Marco.Ermini@resmed.com> wrote:
> > > Well, actually, infrastructure hiding IS part of security.= =C2=A0 It is not the full picture, but it is incorrect to say that it is no= t.
> > >
> > > I personally don't sympathize on NAT-haters.=C2=A0 NAT h= as its reasons,
> > > especially for carrier-grade NAT
> >
> > CGN isn't necessary in IPv6, it's to solve the problem of= ISPs running out of IPv4 addresses.
> >
> > =C2=A0and especially in the telco scenario, and yes, it does prov= ide some level of security - again, not the complete picture, but it does.<= br> > > >
> >
> > NAT is not necessary in IPv6. The equivalent of NAT's perceiv= ed security can be provided via alternative methods, as described in RFC486= 4.
> >
> > A further technique to hide topology that isn't mentioned in = RFC4864 is to use something like ISATAP or similar, to create a single /64 = subnet over the top of multiple IPv4 subnets. Externally, all hosts will ap= pear to belong to a single IPv6 subnet, hiding the internal topology.
> >
> > If you truly want to hide the identities of hosts, NAT doesn'= t do enough - it is only translating addresses, where as there are many oth= er host identifiers that the host itself supplies or will receive and suppl= y that can identify hosts e.g. HTTP cookies. "A Technique for Counting= NATted Hosts"
> > (htt= ps://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field withi= n the IPv4 header that leaked across a NAT was able to be used to identify = hosts.
> >
> > If you truly want to hide a host from the Internet, yet still all= ow it to access things on the Internet, under IPv6 your network would use U= LA addressing, and have a per-application protocol proxy server that makes = all requests look like they've entirely originated from the application= proxy server itself. To the Internet server, the application proxy server = would appear to be the application end host making the requests, preventing= any internal host identifiers or other attributes from leaking.
> >
> >
> > Regards,
> > Mark.
> >
> >
> > >
> > > Regards,
> > >
> > > Marco Ermini
> > >
> > > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security An= alyst D
> > > +49 (0)899 901 1523=C2=A0 M +49 (0)175 439 5642
> > >
> > > ResMed Germany Inc
> > >
> > >
> > > -----Original Message-----
> > > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E
> > > Carpenter
> > > Sent: Thursday, June 16, 2016 1:45 AM
> > > To: Erik Kline; Eric Vyncke (evyncke)
> > > Cc: fgont@si6networ= ks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de;
> > > draft-ietf-o= psec-v6@ietf.org; v6ops@ietf.org<= br> > > > Subject: Re: [OPSEC] [v6ops] Asking for a review of
> > > draft-ietf-opsec-v6-08
> > >
> > > On 16/06/2016 07:45, Erik Kline wrote:
> > >> Section 2.1.2 is far too permissive for my tastes.=C2=A0= We need to be
> > >> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the = IETF.
> > >
> > > I have strong sympathy with that statement, but I don't = think this is the document to do it; the point is made in RFC4864 too. What= we should do here is underline that NAT !=3D security.
> > >
> > > While I'm here, some other points:
> > >
> > > "2.2.=C2=A0 Extension Headers
> > >
> > >=C2=A0 =C2=A0 TBD, a short section referring to all Fernando&= #39;s I-D & RFC."
> > >
> > > That's not the whole story ;-). Firstly, RFC 7045 has a = lot of
> > > relevance to security aspects. Second, there is no reason to= refer to
> > > most of the material (Fernando's or not) unless it's= directly relevant
> > > to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-= filtering,
> > > but only if that document is going anywhere.
> > >
> > > "2.3.3.=C2=A0 ND/RA Rate Limiting
> > > ...
> > >=C2=A0 =C2=A0 The following drafts are actively discussing me= thods to
> > >=C2=A0 =C2=A0 rate limit RAs and other ND messages on wifi ne= tworks in order to
> > >=C2=A0 =C2=A0 address this issue:
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 [I-D.thubert-savi-ra-throttler]
> > >
> > >=C2=A0 =C2=A0 o=C2=A0 [I-D.chakrabarti-nordmark-6man-efficien= t-nd]"
> > >
> > > Neither of those drafts is in the least active (from 2012 an= d 2015 respectively). Dead drafts are of no help to the reader, IMHO.
> > >
> > > "4.2.=C2=A0 Transition Mechanism
> > >
> > >=C2=A0 =C2=A0 SP will typically use transition mechanisms suc= h as 6rd, 6PE, MAP,
> > >=C2=A0 =C2=A0 DS-Lite which have been analyzed in the transit= ion Section 2.7.2
> > >=C2=A0 =C2=A0 section."
> > >
> > > Shouldn't you add RFC6877 464XLAT now?
> > >
> > > Finally, I think there should be a Privacy Considerations se= ction.
> > >
> > > Rgds
> > >=C2=A0 =C2=A0 =C2=A0Brian
> > >
> > >>
> > >> Section 2.6.1.5 could punch up the SAVI stuff a bit more= as well.=C2=A0 We
> > >> should, in my opinion, make it painfully clear that DHCP= (of any
> > >> protocol) in the absence of link-layer security/auditabi= lity features
> > >> does not provide any satisfactory way "to ensure au= dibility and
> > >> traceability" [Section 2.1.6].
> > >>
> > >> _______________________________________________
> > >> v6ops mailing list
> > >> v6ops@ietf.org
> > >> = https://www.ietf.org/mailman/listinfo/v6ops
> > >>
> > >
> > > _______________________________________________
> > > OPSEC mailing list
> > > OPSEC@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/opsec
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/v6ops

--001a1137634ae50e6505356e55a5-- From nobody Thu Jun 16 18:39: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 34B0F12DE5A; Thu, 16 Jun 2016 18:39:29 -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 GjLP6bkdhEmM; Thu, 16 Jun 2016 18:39:26 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 45BF412D8E3; Thu, 16 Jun 2016 18:39:26 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id i123so21504406pfg.0; Thu, 16 Jun 2016 18:39:26 -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=odFFwxCuq6kkO8jAxT6tY0fM0ohVaoty6Gkts7IHa+A=; b=JgWqkC+cerirZUGo79Nq5mFmK5LIWwxN+mHsxMTCQelGs0j9RRE2o6BhOs44BDm4m9 kaBdjURFLo4ITciTyz9mHRPCAoX2/0FHI+61Shz8LSEDOMN5phmgnnVn+Bt0N8YTdY/N v/g7fRq6J8WI0vuFtG4ymwQ6rXBD1GNpmm2m8Hhb3309bA9tm4d3Nkc7u0ht4jtX0IJS 0fENS9kzw4bKbhzCrR66QtFeVbpsQeucv9mpE8wpAvvEGZZYzdeARuv3AfFJA+AZL1RM V/Vc578vZ/u0r+WJyUtq2ywkRlIEr7VHLDlCcM4XUUtDQ1TF15KGIfFeWPjgFSOBBdOt zRtA== 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=odFFwxCuq6kkO8jAxT6tY0fM0ohVaoty6Gkts7IHa+A=; b=JvtSXlaPuntVYazpg0p+Ic/rZgnIZ5b1SmiiYg1+gt+1FsCQdDiXhNNOihOubYfXOK 9DgAzoxTEPAkr5zQNG7AkwqfLbClHdpHQLgUbMDwLj2P2JyZrCEqkhh9ORuHeVUKkGD/ iG4cKT2QuRd2crCbaD2x5rIEZY/1zY277sbMOcAjnkZTv7BGsMA27RViHarTBOZhc7aP 5kiH9RCWJcQl9p8nhxm5h592BN2m+moeb5nEAJh3LeSEHvMEZqo7KfGppuuueG758Utq jy0zXyHwkTqr79qWFtAUgA8rUcuGIOT1BtgEXDmE1RT6uI+DqTfXpWGeNOj32GD26o1t 9Elw== X-Gm-Message-State: ALyK8tKrnbkhCr22+4LLpipgjPK24XUmRhfcyJ7c0j2MEy6DhyDM1PdhrDZrtYqLPVKPWA== X-Received: by 10.98.70.11 with SMTP id t11mr8657013pfa.16.1466127565821; Thu, 16 Jun 2016 18:39:25 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id c8sm40992272pfb.33.2016.06.16.18.39.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:39:25 -0700 (PDT) To: Marco Ermini , Erik Kline , "Eric Vyncke (evyncke)" References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 17 Jun 2016 13:39:30 +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: <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" 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, 17 Jun 2016 01:39:29 -0000 On 16/06/2016 21:15, Marco Ermini wrote: > Well, actually, infrastructure hiding IS part of security. It is not t= he full picture, but it is incorrect to say that it is not. Have you read RFC4864 recently? Section 4.4 is all about how you don't ne= ed NAT to hide infrastructure topology in IPv6. > I personally don't sympathize on NAT-haters. NAT has its reasons, espe= cially for carrier-grade NAT and especially in the telco scenario, and ye= s, it does provide some level of security - again, not the complete pictu= re, but it does. That's IPv4. This is IPv6. Brian >=20 >=20 > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini >=20 > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 >=20 > ResMed Germany Inc >=20 >=20 > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E Carpen= ter > Sent: Thursday, June 16, 2016 1:45 AM > To: Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; d= raft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16/06/2016 07:45, Erik Kline wrote: >> Section 2.1.2 is far too permissive for my tastes. We need to be able= =20 >> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >=20 > I have strong sympathy with that statement, but I don't think this is t= he document to do it; the point is made in RFC4864 too. What we should do= here is underline that NAT !=3D security. >=20 > While I'm here, some other points: >=20 > "2.2. Extension Headers >=20 > TBD, a short section referring to all Fernando's I-D & RFC." >=20 > That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevanc= e to security aspects. Second, there is no reason to refer to most of the= material (Fernando's or not) unless it's directly relevant to opsec. I t= hink the reference is draft-ietf-opsec-ipv6-eh-filtering, > but only if that document is going anywhere. >=20 > "2.3.3. ND/RA Rate Limiting > ... > The following drafts are actively discussing methods to > rate limit RAs and other ND messages on wifi networks in order to > address this issue: >=20 > o [I-D.thubert-savi-ra-throttler] >=20 > o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >=20 > Neither of those drafts is in the least active (from 2012 and 2015 resp= ectively). Dead drafts are of no help to the reader, IMHO. >=20 > "4.2. Transition Mechanism >=20 > SP will typically use transition mechanisms such as 6rd, 6PE, MAP, > DS-Lite which have been analyzed in the transition Section 2.7.2 > section." >=20 > Shouldn't you add RFC6877 464XLAT now? >=20 > Finally, I think there should be a Privacy Considerations section. >=20 > Rgds > Brian >=20 >> >> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We = >> should, in my opinion, make it painfully clear that DHCP (of any >> protocol) in the absence of link-layer security/auditability features = >> does not provide any satisfactory way "to ensure audibility and=20 >> traceability" [Section 2.1.6]. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 From nobody Thu Jun 16 18:46: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 0950812DA0A; Thu, 16 Jun 2016 18:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_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 ZxADrLFNjejF; Thu, 16 Jun 2016 18:46:16 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 4C93112DE56; Thu, 16 Jun 2016 18:46:16 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id h14so10161240pfe.1; Thu, 16 Jun 2016 18:46: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=ZY0kZ3X+yCP9p6KciCKJCOMMqenZ5XX12oaNASeBKrU=; b=xylTvYBb3/MlGM3TZKIqkaoXIzJzA9wiaZNAH2huQQ2UQ1WYqHIUBc1UJ8gD2ffgbY LhZUd0cHuCAo2G+wWr62FuMcj9SRkFUknQc0TEcaD9FPpGojBe/yCEDD6HcPpAURKdDu HYhdfA2U54DHcMNhpiP0w8YOp9eEWPxtUZ1YWJGMBgsy3IuVa+QAUsXjj7Cqf+54T3xQ tr3PFbqlBgmWyXTreMzLwQW8dnmNykhoWZN5QNvIN7V8m23TmrZJ20bLkcZ6vHd2PkVe 1XP2rgPtiwT/hOSyhQX0X+BmzurfdKa9Zv42OgpjddBYJ7JbMz+wWbf4Z/WZEGXJS1Sq nGcA== 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=ZY0kZ3X+yCP9p6KciCKJCOMMqenZ5XX12oaNASeBKrU=; b=GKpBuZe56HG0Vsy74WcjHrds/fhS5AVTSDmyBPZgJpicxe5Uz/tnjmfq3KfL8xDOkz NhdL3CXP3CF2qB9A7rloWrQNVq2mKAbMG9/Na2aILDPSSY8MW1k5EVHBNp3//PiwJE4o PJUva/CYS4DmGb6PaErqX3YAamcNXlF4xXTatmG2fBza2pJ7/u/BWQCftBnPuZnFTpb1 jT7SsTqQBMHZo3E7mR2F1FuNBSMhV+ShYk4sMXtxU0oFh5ncQqPorq+TjHieh8dByufY 7mwPtBk88+axIKNIDWR0YOdtxVmTeTkLEfOuI9t6LodS3+pzmrOvuzvfF23zdZiIs09F GHiw== X-Gm-Message-State: ALyK8tKVqS9oZ5Sv7/EYkSTWI03UOsjSEZU8ySuLsxDVDT6rz7e6lznifeRuufAzzgHHZw== X-Received: by 10.98.56.86 with SMTP id f83mr8734966pfa.83.1466127975543; Thu, 16 Jun 2016 18:46:15 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.242]) by smtp.gmail.com with ESMTPSA id p1sm63499854pfb.73.2016.06.16.18.46.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 18:46:15 -0700 (PDT) To: Marco Ermini , Mark Smith References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1e28b94a-e920-4b0e-c062-100cc598ba85@gmail.com> Date: Fri, 17 Jun 2016 13:46:20 +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: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 17 Jun 2016 01:46:19 -0000 In addition to what Mark said about this: On 16/06/2016 22:03, Marco Ermini wrote: > Hi, >=20 > NAT can be still necessary in IPv6 in dual-stack scenario, for instance= , where every host is assigned both a IPv4 and IPv6 addresses and the CGN= equipment can't handle them differently. Unfortunately RFC 4864 does no= t mention such case, AFAIK. CGN and IPv6 are completely orthogonal, even in a dual stack scenario. v4 packets go to the CGN function and v6 packets go to the v6 router function, possibly in the same box. So absolutely the equipment handles them differently. (If there are sick products that get this wrong, that is not really the IETF's business. Although it's a bit out of date in seome aspects, RFC 6264, An Incremental Carrier-Grade NAT (CGN) for IPv6= Transition, explains how to do it correctly.) Brian >=20 > In any case, I am happy to concede it could be an extreme case and that= it is not necessary anymore in IPv6 for the great majority of use cases.= >=20 > I was not really making a specific case for IPv6 - my opposition was to= the concept that NAT is not security, and to the fact that it should be = written as such in the RFC. NAT *does* provide a form of security - the = fact that it is not desirable or it is unnecessary to use is another topi= c, in which I believe we all agree (at least for 99% of use cases ;-)) >=20 >=20 > Regards, > =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B > Marco Ermini >=20 > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD > Senior IT Security Analyst > D +49 (0)899 901 1523 M +49 (0)175 439 5642 >=20 > ResMed Germany Inc >=20 >=20 >=20 > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com]=20 > Sent: Thursday, June 16, 2016 11:43 AM > To: Marco Ermini > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); fgont@si6netw= orks.com; opsec@ietf.org; draft-ietf-opsec-v6@ietf.org; linkedin@xn--debr= n-nva.de; v6ops@ietf.org > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16 June 2016 at 19:15, Marco Ermini wrote:= >> Well, actually, infrastructure hiding IS part of security. It is not = the full picture, but it is incorrect to say that it is not. >> >> I personally don't sympathize on NAT-haters. NAT has its reasons,=20 >> especially for carrier-grade NAT >=20 > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running = out of IPv4 addresses. >=20 > and especially in the telco scenario, and yes, it does provide some le= vel of security - again, not the complete picture, but it does. >> >=20 > NAT is not necessary in IPv6. The equivalent of NAT's perceived securit= y can be provided via alternative methods, as described in RFC4864. >=20 > A further technique to hide topology that isn't mentioned in RFC4864 is= to use something like ISATAP or similar, to create a single /64 subnet o= ver the top of multiple IPv4 subnets. Externally, all hosts will appear t= o belong to a single IPv6 subnet, hiding the internal topology. >=20 > If you truly want to hide the identities of hosts, NAT doesn't do enoug= h - it is only translating addresses, where as there are many other host = identifiers that the host itself supplies or will receive and supply that= can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted H= osts" > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field w= ithin the IPv4 header that leaked across a NAT was able to be used to ide= ntify hosts. >=20 > If you truly want to hide a host from the Internet, yet still allow it = to access things on the Internet, under IPv6 your network would use ULA a= ddressing, and have a per-application protocol proxy server that makes al= l requests look like they've entirely originated from the application pro= xy server itself. To the Internet server, the application proxy server wo= uld appear to be the application end host making the requests, preventing= any internal host identifiers or other attributes from leaking. >=20 >=20 > Regards, > Mark. >=20 >=20 >> >> Regards, >> >> Marco Ermini >> >> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D=20 >> +49 (0)899 901 1523 M +49 (0)175 439 5642 >> >> ResMed Germany Inc >> >> >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E=20 >> Carpenter >> Sent: Thursday, June 16, 2016 1:45 AM >> To: Erik Kline; Eric Vyncke (evyncke) >> Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; = >> draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org >> Subject: Re: [OPSEC] [v6ops] Asking for a review of=20 >> draft-ietf-opsec-v6-08 >> >> On 16/06/2016 07:45, Erik Kline wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be=20 >>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I have strong sympathy with that statement, but I don't think this is = the document to do it; the point is made in RFC4864 too. What we should d= o here is underline that NAT !=3D security. >> >> While I'm here, some other points: >> >> "2.2. Extension Headers >> >> TBD, a short section referring to all Fernando's I-D & RFC." >> >> That's not the whole story ;-). Firstly, RFC 7045 has a lot of=20 >> relevance to security aspects. Second, there is no reason to refer to = >> most of the material (Fernando's or not) unless it's directly relevant= =20 >> to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,= >> but only if that document is going anywhere. >> >> "2.3.3. ND/RA Rate Limiting >> ... >> The following drafts are actively discussing methods to >> rate limit RAs and other ND messages on wifi networks in order to >> address this issue: >> >> o [I-D.thubert-savi-ra-throttler] >> >> o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >> >> Neither of those drafts is in the least active (from 2012 and 2015 res= pectively). Dead drafts are of no help to the reader, IMHO. >> >> "4.2. Transition Mechanism >> >> SP will typically use transition mechanisms such as 6rd, 6PE, MAP, >> DS-Lite which have been analyzed in the transition Section 2.7.2 >> section." >> >> Shouldn't you add RFC6877 464XLAT now? >> >> Finally, I think there should be a Privacy Considerations section. >> >> Rgds >> Brian >> >>> >>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We= =20 >>> should, in my opinion, make it painfully clear that DHCP (of any >>> protocol) in the absence of link-layer security/auditability features= =20 >>> does not provide any satisfactory way "to ensure audibility and=20 >>> traceability" [Section 2.1.6]. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jun 16 19:12: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 A2D3B12D924 for ; Thu, 16 Jun 2016 19:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.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 Pr893rxMSC0P for ; Thu, 16 Jun 2016 19:12:13 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 76E2012DC66 for ; Thu, 16 Jun 2016 19:12:11 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 5so66541571ioy.1 for ; Thu, 16 Jun 2016 19:12:11 -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=F55m/HLDOKD3NVKGrkeTL+aBiT0k1zDA7h6eJsCzxUA=; b=ozdm0+s0hMkh+EK/aBd3osiBX5kj1lUL+0v5JqcGCmuofAyZjn6HQdHm9EOW92H/Nl Z0co7W3KueEsUvJI3ZJEA1zJCrlhu1OCxceLrAKhUoRH19nxdG3Ewhn/DPPcyzVXU/cr gB0m9oI7sjvtGuSdhtnHcGC74XrgODXtlzeL7ad5YHcARCcuTuZ/FWqQR8bkKw4+pw4x pWOs4LeBF8v0I6UJ45ISc0pTaQIPeAs4936r2oKU899dB+5Hcq8emFwaY4OHjjVOvmQ9 CxNZkPA6BFnUcpdK8LchXcybZt/h4hTr1GC8mZ4gtMWzDL3ZFo1sBhNVtGZHhlF98QYe BesA== 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=F55m/HLDOKD3NVKGrkeTL+aBiT0k1zDA7h6eJsCzxUA=; b=Uubp3JFG+ex9tpHh7Kws3EZnkcZs7PtOc1p0dzw65wZZeE1pOy4t1M3Z1zxTEHc32r 8z98MtEBVlXpmvFGWppPKRt1WNraftsB1QibjLLVzX0OlPmg3phPNRs9IfPlGKi/NJ5H RCf1UP1L/s77OBmgO84eh53iLmGdr4X26F1I36Z4KIU1mcXfPFFdHGXFQf6BOcuXCgOx JnV/lyuwzgDW8WMAgC0uaENWSGWT52ve487ScV1MNT8f80ihl7/wMg0D2zPz3mcon463 WFI9GZ6TJ6vslVUhtHP54zkNjmdN6pDZ3WIzRZSf0Rxff3BczTx75e07TwXKBSx3xAQx n8Ow== X-Gm-Message-State: ALyK8tLvP08Aw3pkzj149GYm1l7mcSMHtTpDOTgQfLRKpQ8wnggznWA1KLD+a/dzFI+E0VP0CFnQVRiVOtvLc2j2 X-Received: by 10.107.14.140 with SMTP id 134mr7624410ioo.94.1466129530574; Thu, 16 Jun 2016 19:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.225.228 with HTTP; Thu, 16 Jun 2016 19:11:50 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 16 Jun 2016 19:11:50 -0700 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a113fef80ddd36805356fe1f1 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, 17 Jun 2016 02:12:13 -0000 --001a113fef80ddd36805356fe1f1 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 12:45 PM, 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. > +1. I recall long queues at the mike at IETF 94 saying that. > Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We > should, in my opinion, make it painfully clear that DHCP (of any > protocol) in the absence of link-layer security/auditability features > does not provide any satisfactory way "to ensure audibility and > traceability" [Section 2.1.6]. +1. Instead of the text you have here, I would suggest citing section 9.1 of draft-ietf-v6ops-host-addr-availability, which deals with the problem in detail. --001a113fef80ddd36805356fe1f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 15, 2016 at 12:45 PM, Erik Kline <ek@google.com> wrote:
Section 2.1.2 is far too permissive for = my tastes.=C2=A0 We need to be able
to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

+1. I recall long queues at the mike at IETF 94 saying th= at.
=C2=A0
Section 2.6.1.5 could punch up the SAVI stuff a bit more as well.=C2=A0 We=
should, in my opinion, make it painfully clear that DHCP (of any
protocol) in the absence of link-layer security/auditability features
does not provide any satisfactory way "to ensure audibility and
traceability" [Section 2.1.6].

+1. Ins= tead of the text you have here, I would suggest citing section 9.1 of=C2=A0= draft-ietf-v6ops-host-addr-availability, which deals with the problem in de= tail.
--001a113fef80ddd36805356fe1f1-- From nobody Thu Jun 16 21:17: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 6B95912DE3D for ; Thu, 16 Jun 2016 21:17:15 -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 M7bY5XGdcvdz for ; Thu, 16 Jun 2016 21:17:13 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0912DD1C for ; Thu, 16 Jun 2016 21:17:12 -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 u5H4GALw003326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2016 21:16:11 -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: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> Date: Thu, 16 Jun 2016 21:16:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> References: <57571D6E.2050102@gont.com.ar> <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> 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, 16 Jun 2016 21:16:11 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 04:17:15 -0000 > On Jun 16, 2016, at 03:00 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 15/06/2016 =C3=A0 21:28, Musa Stephen Honlue a =C3=A9crit : >> This is bad behaviour both for the source device(LL should not be = used >> for off-link destinations), and for intermediary routers(they should = not >> forward packet sourced with LLA). >>=20 >> It is clear enough that responses to such packets won't be able to = make >> their way back. >=20 > I agree - but sometimes there is no need for response - protocols such = as OSPF or ICMP Router Advertisements, not to mention UDP video = streaming, dont need responses. Um=E2=80=A6 So just to make sure I understand correctly=E2=80=A6 Other than virtual links, OSPF route announcements shouldn=E2=80=99t = have GUA destinations. In the case of a virtual link, an OSPF route announcement shouldn=E2=80=99= t have LL source. In the case you seem to be proposing, virtual link with LL source and = GUA destination, you would be sending a route announcement that = effectively sets an un-reachable next-hop to the remote router. I=E2=80=99m not sure I see any possible benefit of this action under any = circumstances. I can, however, see several problematic outcomes (network singularities anyone?). Similarly, an ICMP RA should have either an LL destination or a = multicast (link scoped) destination. I cannot see any valid case for = sending an RA off-link. So that leaves us with only UDP video streaming as your remaining = theoretical case. Can you please elaborate on what possible useful case of a video = streaming source would not have a GUA or ULA and would attempt to = transmit said video stream off-link? I realize that ULA may not be able to reach the intended destination, = but at least that packet won=E2=80=99t make it past the border of the = network administrative boundary that has agreed to accept this cruft = (hopefully) which I would argue is a very desirable property of whatever = it is you are proposing to do here. > For network control (ICMP), yes there is need to have ability to reply = back always, but some software uses ICMP for network control and UDP for = video streaming. >=20 > One should mpt use the LL src if ICMP is expected, but one could very = well use LL src for UDP for video streaming (video is just an example = app). Again, I do not see a valid use case for LL Source if the destination is = not on-link. This is the entire point of scoped addresses and what you = are wanting to do discards virtually all meaning of scope. What will you want next? ff02:: packets being delivered globally? >> Therefore, if the path of such packets can be traced, it is necessary = to >> report a bug to various vendors concerned for them to deal with this >> issue in accordance with specifications as per >> https://tools.ietf.org/html/rfc4291#section-2.5.6. >=20 > I am not sure we must build in a capability to always trace back to = originators. This is may be way beyond pure packet data communications. That=E2=80=99s not what he is saying. What he is saying is that in the = case A->B->C->D->E->F->G->H->I where A sends a packet with LL src and I = dst and I receives the packet, one should make a best effort to identify = {H, G, F, E, D, C, B, A} and report bugs to the vendors responsible for = the IPv6 stack implementation on each and every one of them because each = and every one of them did something bad. He is absolutely right in saying this. Owen From nobody Thu Jun 16 23: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 53A2912B019 for ; Thu, 16 Jun 2016 23:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 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, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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 HatwCB5ikMDt for ; Thu, 16 Jun 2016 23:59:06 -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 21FB012B024 for ; Thu, 16 Jun 2016 23:59:06 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id t129so104433827vka.1 for ; Thu, 16 Jun 2016 23:59:06 -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=QakM0zvsWYuWXTCWxfK7VEyJWtqF8V+YHEeDueL1yi8=; b=pdl7lLaFjoLdvytLCMLFGbUYKkm16w+mKgAahenkDE32CRN9H+3nqfCCOwEeJmG4Sm 7sH6cIOtZQTXIiOimbvJQUpwXuJAwlgiG3UZiNtRoLOFD5cKme+Ax8gICfkIfvOj9igH 09xpVOLVZ7fFDIJXswv2njCc4leHz/3EIvIPnQPOFJXvqUs1bUFPFuOUGAyQUKAN7ciQ ERsFWhpo2dFKZ11hENgVK+JJ0h7Dw4yuzj6wWl8IZV3fz9VK0Ptt3XdoJ1OsE8OiKf1a kKUo/aqQ6X/LRaV350eoT6DZzS0XwwmBemmASQFWSKbU0ewLG2dYSr+DpSZ2QKnd+mxe yTyg== 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=QakM0zvsWYuWXTCWxfK7VEyJWtqF8V+YHEeDueL1yi8=; b=V59kHkfUCR8PI40f03F+tl54Qrl8u00yrNQ9s6TvEJeCfy57TufhGVOS1heFsbQuOs NjoSXd5JMGwL0vJr0rmBfyboOFu1bM4ezk6fx0ZC2zCzqgrUah8YQNHOt/ohirGbHhWg +RlV0//3Nwb+voI8xNnQiEseqQk8yWSXYZZ+qCufdy2dkBRYLQ/1WIruZGvZKMUvEN1j 06v1s/zLa/jywju89RmcKjME5qGcOBJJAj3+REJwH1VHKWmtgPCBpfmzhLCkv+p7WplT iDqXToYzv12FcHeh1gswyU6jEjCyrLd2/HRDjCQSlmV5CVvBOJBFCJJNQmTYcFeOtkt2 4V1A== X-Gm-Message-State: ALyK8tLOEvarXnB7DvHm2G/sfCdPql8fkNoOiSC8Yy2+Psrl0sTrt2ORJaDzam1oGEUd8mDTWp2atEhUWYuhLw== MIME-Version: 1.0 X-Received: by 10.176.5.103 with SMTP id 94mr153081uax.129.1466146744902; Thu, 16 Jun 2016 23:59:04 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 23:59:04 -0700 (PDT) Received: by 10.176.65.198 with HTTP; Thu, 16 Jun 2016 23:59:04 -0700 (PDT) In-Reply-To: References: <57571D6E.2050102@gont.com.ar> <49e62201c94e485db64a8b0e1978b634@XCH15-05-05.nw.nos.boeing.com> <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> Date: Fri, 17 Jun 2016 16:59:04 +1000 Message-ID: From: Mark Smith To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=94eb2c124d0eeb2a80053573e3b3 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 06:59:08 -0000 --94eb2c124d0eeb2a80053573e3b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 Jun 2016 6:32 PM, "Alexandre Petrescu" wrote: > > > > Le 13/06/2016 =C3=A0 01:31, Owen DeLong a =C3=A9crit : >> >> >>> On Jun 9, 2016, at 13:09 , Alexandre Petrescu >>> >> > wrote: >>> >>> >>> >>> Le 09/06/2016 =C3=A0 19:24, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3= =A9crit : >>>> >>>> At Thu, 9 Jun 2016 14:45:48 +0000, "Templin, Fred L" >>>> > >>>> >>>> wrote: >>>> >>>>>> RFC4007, >>>>>> >>>>>> >>>>>> "Thus, if a router receives a packet with a link-local >>>>>> destination address that is not one of the router's own >>>>>> link-local addresses on the arrival link, the router is >>>>>> expected to try to forward the packet to the destination on >>>>>> that link (subject to successful determination of the >>>>>> destination's link-layer address via the Neighbor Discovery >>>>>> protocol [9]). The forwarded packet may be transmitted back >>>>>> through the arrival interface, or through any other >>>>>> interface attached to the same link." >>>>>> >>>>>> I'd expect the hop-limit to be decremented. >>>>> >>>>> >>>>> The key text in the above passages is "may be transmitted back >>>>> through the arrival interface, or through any other interface >>>>> attached to the same link". This means that the packet with LL >>>>> source address never really leave the link they arrived on. >>>>> Instead, they are "hairpinned" either at the IP or sub-IP >>>>> layers. So, the hop-limit should not be decremented. >>>> >>>> >>>> I'm pretty sure that the original intent of this text is to mean >>>> this "forwarding" to be just like other normal cases, i.e., >>>> forwarding a packet received on one interface to one link to >>>> another interface to another link. Or, just like the case where >>>> a default router is not the best path to an off-link destination >>>> and the best next hop is in the same link as the receiving link >>>> (in that case the receiving router will transmit the packet back >>>> through the arrival interface, possibly sending a neighbor >>>> discovery redirect). So I'm pretty sure that the hop-limit is >>>> assumed to be decremented. Saying "should not be decremented" >>>> based on this RFC text is most likely to be a misinterpretation. >>>> >>>> Whether such a behavior is justified for some special cases can >>>> be a different question, but that shouldn't automatically apply >>>> to the general case described in this RFC. >>> >>> >>> To clarify my position: the _general_ case is that a router >>> forwards without looking at the source address at all. >> >> >> Inappropriate behavior in IPv6, as the router is required not to >> forward packets with LL Source Addresses to interfaces that are not >> on the same link as the arriving interface. > > > In IPv6 this restriction is put on a router receiving a packet with LL > src address. > > In IPv4 RFC3927 LLs this restriction is put on a Host wishing to send > such a packet - it should not send it to a router for forwarding (use > directly ARP search instead of rt table search first). > > In IPv4 that spec is silent about a _router_ sending packets with LL src > address. So one can easily assume that an IPv4 router is allowed to > send a packet with LL src address to another router. > > IPv4 behaviour is allowed to act this way and IPv6 should be the same if > it wanted to be an easy migration target. > IPv6 is specifically different because doing otherwise requires a router to perform proxy ND for hosts that are on the same link but are not directly reachable. This behaviour better suits NBMA links or restricted forwarding broadcast links such as "private VLANs". With the effort involved to deploy a new Internet protocol, it would have been a wasted opportunity to just change the size of the addresses and not make other useful improvements as well, even if they mean people can't just consider IPv6 to be IPv4 with bigger addresses. Regards, Mark. > Alex > >> >> Owen >> >>> >>> The rest are particular cases. >>> >>> Alex >>> >>>> >>>> -- JINMEI, Tatuya >>>> >>>> _______________________________________________ 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 --94eb2c124d0eeb2a80053573e3b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 Jun 2016 6:32 PM, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote:=
>
>
>
> Le 13/06/2016 =C3=A0 01:31, Owen DeLong a =C3=A9crit :
>>
>>
>>> On Jun 9, 2016, at 13:09 , Alexandre Petrescu
>>> <alexandre.= petrescu@gmail.com
>>> <mailto:ale= xandre.petrescu@gmail.com>> wrote:
>>>
>>>
>>>
>>> Le 09/06/2016 =C3=A0 19:24, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 a =C3=A9crit :
>>>>
>>>> At Thu, 9 Jun 2016 14:45:48 +0000, "Templin, Fred L&q= uot;
>>>> <Fred.L.Te= mplin@boeing.com <mailto:Fred.L.Templin@boeing.com>>
>>>>
>>>> wrote:
>>>>
>>>>>> RFC4007,
>>>>>>
>>>>>>
>>>>>> "Thus, if a router receives a packet with a l= ink-local
>>>>>> destination address that is not one of the router&= #39;s own
>>>>>> link-local addresses on the arrival link, the rout= er is
>>>>>> expected to try to forward the packet to the desti= nation on
>>>>>> that link (subject to successful determination of = the
>>>>>> destination's link-layer address via the Neigh= bor Discovery
>>>>>> protocol [9]).=C2=A0 The forwarded packet may be t= ransmitted back
>>>>>> =C2=A0through the arrival interface, or through an= y other
>>>>>> interface attached to the same link."
>>>>>>
>>>>>> I'd expect the hop-limit to be decremented. >>>>>
>>>>>
>>>>> The key text in the above passages is "may be tra= nsmitted back
>>>>> =C2=A0through the arrival interface, or through any ot= her interface
>>>>> =C2=A0attached to the same link". This means that= the packet with LL
>>>>> =C2=A0source address never really leave the link they = arrived on.
>>>>> Instead, they are "hairpinned" either at the= IP or sub-IP
>>>>> layers. So, the hop-limit should not be decremented. >>>>
>>>>
>>>> I'm pretty sure that the original intent of this text = is to mean
>>>> =C2=A0this "forwarding" to be just like other no= rmal cases, i.e.,
>>>> forwarding a packet received on one interface to one link = to
>>>> another interface to another link.=C2=A0 Or, just like the= case where
>>>> =C2=A0a default router is not the best path to an off-link= destination
>>>> =C2=A0and the best next hop is in the same link as the rec= eiving link
>>>> =C2=A0(in that case the receiving router will transmit the= packet back
>>>> =C2=A0through the arrival interface, possibly sending a ne= ighbor
>>>> discovery redirect).=C2=A0 So I'm pretty sure that the= hop-limit is
>>>> assumed to be decremented.=C2=A0 Saying "should not b= e decremented"
>>>> based on this RFC text is most likely to be a misinterpret= ation.
>>>>
>>>> Whether such a behavior is justified for some special case= s can
>>>> be a different question, but that shouldn't automatica= lly apply
>>>> to the general case described in this RFC.
>>>
>>>
>>> To clarify my position: the _general_ case is that a router >>> forwards without looking at the source address at all.
>>
>>
>> Inappropriate behavior in IPv6, as the router is required not to >> forward packets with LL Source Addresses to interfaces that are no= t
>> on the same link as the arriving interface.
>
>
> In IPv6 this restriction is put on a router receiving a packet with LL=
> src address.
>
> In IPv4 RFC3927 LLs this restriction is put on a Host wishing to send<= br> > such a packet - it should not send it to a router for forwarding (use<= br> > directly ARP search instead of rt table search first).
>
> In IPv4 that spec is silent about a _router_ sending packets with LL s= rc
> address.=C2=A0 So one can easily=C2=A0 assume that an IPv4 router is a= llowed to
> send a packet with LL src address to another router.
>
> IPv4 behaviour is allowed to act this way and IPv6 should be the same = if
> it wanted to be an easy migration target.
>

IPv6 is specifically different because doing otherwise requi= res a router to perform proxy ND for hosts that are on the same link but ar= e not directly reachable. This behaviour better suits NBMA links or restric= ted forwarding broadcast links such as "private VLANs".

With the effort involved to deploy a new Internet protocol, = it would have been a wasted opportunity to just change the size of the addr= esses and not make other useful improvements as well, even if they mean peo= ple can't just consider IPv6 to be IPv4 with bigger addresses.

Regards,
Mark.

> Alex
>
>>
>> Owen
>>
>>>
>>> The rest are particular cases.
>>>
>>> Alex
>>>
>>>>
>>>> -- JINMEI, Tatuya
>>>>
>>>> _______________________________________________ v6ops mail= ing
>>>> list v6ops@ietf.org = <mailto:v6ops@ietf.org>
>>>> ht= tps://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>> _______________________________________________ v6ops mailing = list
>>> v6ops@ietf.org <mailt= o:v6ops@ietf.org>
>>> https:= //www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--94eb2c124d0eeb2a80053573e3b3-- From nobody Fri Jun 17 01:56: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 F1C8612B029 for ; Fri, 17 Jun 2016 01:56:29 -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 JJK29MrK6Ixr for ; Fri, 17 Jun 2016 01:56:28 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 A83B612B012 for ; Fri, 17 Jun 2016 01:56:28 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f30so63997677ioj.2 for ; Fri, 17 Jun 2016 01:56: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=Y41CY6W3QhWwa1SIjOJrI16vKISQyBRA7xDpYmjhkUs=; b=bBFstSnBDufczGbgcB66dYtFE5JYF/hmwRVbaV+nuqB5YZngazvQBVnrdW0uTZj9ip gXlgEDeBFKtzEZgD2xZLOW55JSEeVIc6lgCdQjHdPhcPLJboPYq36DySlQ/Fb4/GtBVc 25NYE0bfHJKKYf0djhIchLbiGwMT98B2utVtOT8VmzLNbCmr/+uh3IWZQ7lXYP6CZijB /SKSl5B61TX4yMHQuVhgtrZPKNu6M2+9q6R+huA0VsF7cQqK1R7/AA0NkyuBcgtX4JVM yuLi986JXHJ1vtuGjghdPSr5aReXug/29zcI97/NBzgUIMZiVGbpNQ3KHw31DYWJSGsl 37Zw== 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=Y41CY6W3QhWwa1SIjOJrI16vKISQyBRA7xDpYmjhkUs=; b=e5ofwf1nbOhhqNFwqS8v2WdaXbzVQhXIFWaJxabLYRM+Wt9JhKoskHUQwR7gQ0X2+C iz0cmzSMjNeqEB4hxgtV+6Sruge+ZqTB5EBNALeVBmtnnIYz4s/7no2KAGVeAvQhWSo/ MoD1a6VbJaDzzxdm15z0CiePSWBLc2UMjELaejqriAO4kNyYGi88vgezjlHpGJ7Kclub RTDUmW7ItUhvvNqRpscIIzrl6BUDLRW2yGCrEB+Sc9lD5qweW+mFL2lc8MSwc2CH8jkJ VckLmH45MQTQE7ruN1WDJ2z/s4pM0BqY/LwoYDpdXxw3G/GivCCb20ylrwURFootw9kz NkSQ== X-Gm-Message-State: ALyK8tJGKJQU1a8cVYX4clPBM++tRM2Pdb3jg9ujc0xS5GTkNNnzUy8zSdtgvIC4HAyyyY5NUXBvPctvWb0X+Q== X-Received: by 10.107.175.161 with SMTP id p33mr1368909ioo.78.1466153783057; Fri, 17 Jun 2016 01:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.33.233 with HTTP; Fri, 17 Jun 2016 01:56:02 -0700 (PDT) In-Reply-To: <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> References: <57571D6E.2050102@gont.com.ar> <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> From: Jen Linkova Date: Fri, 17 Jun 2016 10:56:02 +0200 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 08:56:30 -0000 On Thu, Jun 16, 2016 at 12:00 PM, Alexandre Petrescu wrote: > I agree - but sometimes there is no need for response - protocols such as > OSPF or ICMP Router Advertisements, not to mention UDP video streaming, dont > need responses. > > For network control (ICMP), yes there is need to have ability to reply back > always, but some software uses ICMP for network control and UDP for video > streaming. > > One should mpt use the LL src if ICMP is expected, but one could very well > use LL src for UDP for video streaming (video is just an example app). It means that there is no way to signal any errors back to the sender, right? > I am not sure we must build in a capability to always trace back to > originators. This is may be way beyond pure packet data communications. The idea of communication protocol which does not allow (by design) any errors being signaled back sounds like a very bad idea to me... -- SY, Jen Linkova aka Furry From nobody Fri Jun 17 02:32: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 CDE7812B03F for ; Fri, 17 Jun 2016 02:32:50 -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 7yKr7sv2koNx for ; Fri, 17 Jun 2016 02:32:49 -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 EEC0812B012 for ; Fri, 17 Jun 2016 02:32:48 -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 u5H9Wkb4023684; Fri, 17 Jun 2016 11:32:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D1D082032E7; Fri, 17 Jun 2016 11:33: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 C1AA6201E43; Fri, 17 Jun 2016 11:33:29 +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 u5H9WjBS000851; Fri, 17 Jun 2016 11:32:46 +0200 To: Jen Linkova References: <57571D6E.2050102@gont.com.ar> <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> From: Alexandre Petrescu Message-ID: <0c3cef95-e45a-d5de-8df5-abd0a66a0e71@gmail.com> Date: Fri, 17 Jun 2016 11:32:45 +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=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 09:32:51 -0000 Le 17/06/2016 à 10:56, Jen Linkova a écrit : > On Thu, Jun 16, 2016 at 12:00 PM, Alexandre Petrescu > wrote: >> I agree - but sometimes there is no need for response - protocols >> such as OSPF or ICMP Router Advertisements, not to mention UDP >> video streaming, dont need responses. >> >> For network control (ICMP), yes there is need to have ability to >> reply back always, but some software uses ICMP for network control >> and UDP for video streaming. >> >> One should mpt use the LL src if ICMP is expected, but one could >> very well use LL src for UDP for video streaming (video is just an >> example app). > > It means that there is no way to signal any errors back to the > sender, right? Right, an _intermediary_ node may not be able to send errors back to the sender of a packet that that intermediary forwards. And that's ok. The end nodes may signal each other errors by using appropriate addresses if available. This same ability makes it that the network may not be able to always identify who is the real originator of some packet it forwards. It is good too. Some of the positive effects of this ability (not be able to trace to the originators) is: VPN proxies exist which allow to access country-specific content; in emergency situations it is possible to be connected to Internet _around_ areas forbidding connections identified by src, even though not able to make phone calls to the forbidden areas. Be able to send packets and be heard, even though one does not have a GUA. >> I am not sure we must build in a capability to always trace back >> to originators. This is may be way beyond pure packet data >> communications. > > The idea of communication protocol which does not allow (by design) > any errors being signaled back sounds like a very bad idea to me... In general I can agree if the same-scope-src/dst issue was bound to a particular protocol. But it applies to many protocols - addressing architecture design. A bidirectional channel is not always necessary: unidirectional is sufficient to take action in some settings. It's known with UDLR protocol for example. Alex > > From nobody Fri Jun 17 04:29:15 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 2CB5712D1D1; Fri, 17 Jun 2016 04:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 HIJeb1wE1E3n; Fri, 17 Jun 2016 04:29:11 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [85.158.143.249]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC912D19B; Fri, 17 Jun 2016 04:29:10 -0700 (PDT) Received: from [85.158.143.99] by server-2.bemta-6.messagelabs.com id E3/6F-11548-50FD3675; Fri, 17 Jun 2016 11:29:09 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRWlGSWpSXmKPExsVy+JUily7z/eR wgy9bhCye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y9vL7UwFH3Ur9q6dwNzA uES3i5GLQ0hgPaNE14QNjBDOHkaJs6dvMXcxcnKwCehI/F++ix3EFhGolZhy/A8zSBGzwBdGi WNzVjF1MXJwCAt4SVzs9Iao8ZZoePubFcL2k9h3chULiM0ioCrR/OATWJxXwFni7ue/bBDLJj JJfN+8jQ0kwSlgK/H31kywZYwCshJfGleDHcEsIC5x68l8JhBbQkBAYsme88wQtqjEy8f/WCF sRYnLv6ewgNzDLKApsX6XPkSrosSU7ofsEHsFJU7OfAJ2j5CAikT7gmVQrcESs7/dYJrAKDYL ybZZCJNmIZk0C8mkBYwsqxjVi1OLylKLdA31kooy0zNKchMzc3QNDcz0clOLixPTU3MSk4r1k vNzNzECI4sBCHYw7nzudIhRkoNJSZR37rnkcCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvHfvAu UEi1LTUyvSMnOAMQ6TluDgURLhnQWS5i0uSMwtzkyHSJ1itOS4s/jGWiaOW88eAMlPEw4cYxJ iycvPS5US5z0D0iAA0pBRmgc3DpaGLjHKSgnzMgIdKMRTkFqUm1mCKv+KUZyDUUmYdzHIFJ7M vBK4ra+ADmICOkhzHthBJYkIKakGRtaYr4fiPrRpfePo2/k6+JlTxCI52yKBYw8OcBqvzLG3m 3zbTCjQ6BPf7vc5oSzcF07NYgnf8I7508XAGfec9YW/bj1vu2iaHPOr4+dO+c+SZnb/wnNF0u 3ie6Y+Lnml3HerRD5X7HFs/vDyGtfU3S9Ovn59pGL7Xe7mQw5zbibM//XT3MlPr1eJpTgj0VC Luag4EQA6weCAPgMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1466162947!11271579!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27432 invoked from network); 17 Jun 2016 11:29:07 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-8.tower-216.messagelabs.com with SMTP; 17 Jun 2016 11:29:07 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 13:29:06 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%16]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 13:29:08 +0200 From: Marco Ermini To: Brian E Carpenter , Erik Kline , "Eric Vyncke (evyncke)" Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRxvO7NZqKAcq6O0Gp7Rf6mrYAKJ/qzYSAgABC14CAAMBooIAA8f0AgADFp2A= Date: Fri, 17 Jun 2016 11:29:05 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 11:29:06.0849 (UTC) FILETIME=[758AB910:01D1C88B] Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" 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, 17 Jun 2016 11:29:13 -0000 SSBhbSBzb3JyeSBCcmlhbiwgSSBkb24ndCB0aGluayB5b3UgdW5kZXJzdG9vZCBteSBhcmd1bWVu dC4gIEkgYW0gbm90IGFyZ3VpbmcgYWJvdXQgeW91IG1lbnRpb24uICBJIGFtIGFyZ3VpbmcgYWdh aW5zdCB0aGUgc2VtYW50aWMgb2YgYSBwaHJhc2UgdGhhdCBzYXlzICJOQVQgZG9lcyBub3QgcHJv dmlkZSBzZWN1cml0eSIuICBUaGlzIHNlbnRlbmNlIGlzIHNlbWFudGljYWxseSB3cm9uZywgYW5k IHVzdWFsbHkgY29tZXMgZnJvbSBhIHByaW9yaSBOQVQtaGF0ZXJzIChJIGhhdmUgbWV0IGEgZmV3 KS4NCg0KSSBhbSBvbmx5IGFnYWluc3Qgc3RhdGluZyBzdWNoIHNlbnRlbmNlIGluIHRoZSBSRkMs IG5vdCBhZ2FpbnN0IHRoZSBmYWN0IHRoYXQgd2UgZG9uJ3QgbmVlZCBOQVQuICBJIGhvcGUgdGhp cyBpcyBjbGVhcmVyIG5vdy4NCg0KQW55d2F5LCBJIGhhdmUgbWFkZSBteSBwb2ludCBzdWZmaWNp ZW50bHksIEkgYmVsaWV2ZS4NCg0KDQpSZWdhcmRzLA0KTWFyY28uDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgMzo0MCBBTQ0K VG86IE1hcmNvIEVybWluaTsgRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5ja2UpDQpDYzog ZmdvbnRAc2k2bmV0d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJu LW52YS5kZTsgZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1p ZXRmLW9wc2VjLXY2LTA4DQoNCk9uIDE2LzA2LzIwMTYgMjE6MTUsIE1hcmNvIEVybWluaSB3cm90 ZToNCj4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNl Y3VyaXR5LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3Qg dG8gc2F5IHRoYXQgaXQgaXMgbm90Lg0KDQpIYXZlIHlvdSByZWFkIFJGQzQ4NjQgcmVjZW50bHk/ IFNlY3Rpb24gNC40IGlzIGFsbCBhYm91dCBob3cgeW91IGRvbid0IG5lZWQgTkFUIHRvIGhpZGUg aW5mcmFzdHJ1Y3R1cmUgdG9wb2xvZ3kgaW4gSVB2Ni4NCg0KPiBJIHBlcnNvbmFsbHkgZG9uJ3Qg c3ltcGF0aGl6ZSBvbiBOQVQtaGF0ZXJzLiAgTkFUIGhhcyBpdHMgcmVhc29ucywgZXNwZWNpYWxs eSBmb3IgY2Fycmllci1ncmFkZSBOQVQgYW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5h cmlvLCBhbmQgeWVzLCBpdCBkb2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFn YWluLCBub3QgdGhlIGNvbXBsZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLg0KDQpUaGF0J3MgSVB2 NC4gVGhpcyBpcyBJUHY2Lg0KDQogICAgQnJpYW4NCg0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IOKA i+KAi+KAi+KAi+KAiw0KPiBNYXJjbyBFcm1pbmkNCj4gDQo+IENJU1NQLCBDSVNBLCBDSVNNLCBD RUgsIElUSUwsIE1DUCwgUGhEIFNlbmlvciBJVCBTZWN1cml0eSBBbmFseXN0IEQgDQo+ICs0OSAo MCk4OTkgOTAxIDE1MjMgIE0gKzQ5ICgwKTE3NSA0MzkgNTY0Mg0KPiANCj4gUmVzTWVkIEdlcm1h bnkgSW5jDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT1BT RUMgW21haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSAN Cj4gQ2FycGVudGVyDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDE6NDUgQU0NCj4g VG86IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKQ0KPiBDYzogZmdvbnRAc2k2bmV0 d29ya3MuY29tOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgDQo+ IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZiANCj4gZHJhZnQtaWV0 Zi1vcHNlYy12Ni0wOA0KPiANCj4gT24gMTYvMDYvMjAxNiAwNzo0NSwgRXJpayBLbGluZSB3cm90 ZToNCj4+IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZlIGZvciBteSB0YXN0ZXMu ICBXZSBuZWVkIHRvIGJlIA0KPj4gYWJsZSB0byBzYXkgdGhhdCBVTEErSVB2NiBOQVQgaXMgTk9U IFJFQ09NTUVOREVEIGJ5IHRoZSBJRVRGLg0KPiANCj4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3 aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVu dCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUgaW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hv dWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQgTkFUICE9IHNlY3VyaXR5Lg0KPiANCj4gV2hp bGUgSSdtIGhlcmUsIHNvbWUgb3RoZXIgcG9pbnRzOg0KPiANCj4gIjIuMi4gIEV4dGVuc2lvbiBI ZWFkZXJzDQo+IA0KPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZl cm5hbmRvJ3MgSS1EICYgUkZDLiINCj4gDQo+IFRoYXQncyBub3QgdGhlIHdob2xlIHN0b3J5IDst KS4gRmlyc3RseSwgUkZDIDcwNDUgaGFzIGEgbG90IG9mIA0KPiByZWxldmFuY2UgdG8gc2VjdXJp dHkgYXNwZWN0cy4gU2Vjb25kLCB0aGVyZSBpcyBubyByZWFzb24gdG8gcmVmZXIgdG8gDQo+IG1v c3Qgb2YgdGhlIG1hdGVyaWFsIChGZXJuYW5kbydzIG9yIG5vdCkgdW5sZXNzIGl0J3MgZGlyZWN0 bHkgcmVsZXZhbnQgDQo+IHRvIG9wc2VjLiBJIHRoaW5rIHRoZSByZWZlcmVuY2UgaXMgZHJhZnQt aWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZywNCj4gYnV0IG9ubHkgaWYgdGhhdCBkb2N1bWVu dCBpcyBnb2luZyBhbnl3aGVyZS4NCj4gDQo+ICIyLjMuMy4gIE5EL1JBIFJhdGUgTGltaXRpbmcN Cj4gLi4uDQo+ICAgIFRoZSBmb2xsb3dpbmcgZHJhZnRzIGFyZSBhY3RpdmVseSBkaXNjdXNzaW5n IG1ldGhvZHMgdG8NCj4gICAgcmF0ZSBsaW1pdCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9u IHdpZmkgbmV0d29ya3MgaW4gb3JkZXIgdG8NCj4gICAgYWRkcmVzcyB0aGlzIGlzc3VlOg0KPiAN Cj4gICAgbyAgW0ktRC50aHViZXJ0LXNhdmktcmEtdGhyb3R0bGVyXQ0KPiANCj4gICAgbyAgW0kt RC5jaGFrcmFiYXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQo+IA0KPiBOZWl0aGVy IG9mIHRob3NlIGRyYWZ0cyBpcyBpbiB0aGUgbGVhc3QgYWN0aXZlIChmcm9tIDIwMTIgYW5kIDIw MTUgcmVzcGVjdGl2ZWx5KS4gRGVhZCBkcmFmdHMgYXJlIG9mIG5vIGhlbHAgdG8gdGhlIHJlYWRl ciwgSU1ITy4NCj4gDQo+ICI0LjIuICBUcmFuc2l0aW9uIE1lY2hhbmlzbQ0KPiANCj4gICAgU1Ag d2lsbCB0eXBpY2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBF LCBNQVAsDQo+ICAgIERTLUxpdGUgd2hpY2ggaGF2ZSBiZWVuIGFuYWx5emVkIGluIHRoZSB0cmFu c2l0aW9uIFNlY3Rpb24gMi43LjINCj4gICAgc2VjdGlvbi4iDQo+IA0KPiBTaG91bGRuJ3QgeW91 IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiANCj4gRmluYWxseSwgSSB0aGluayB0aGVyZSBz aG91bGQgYmUgYSBQcml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+IA0KPiBSZ2RzDQo+ ICAgICBCcmlhbg0KPiANCj4+DQo+PiBTZWN0aW9uIDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhl IFNBVkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxsLiAgV2UgDQo+PiBzaG91bGQsIGluIG15IG9w aW5pb24sIG1ha2UgaXQgcGFpbmZ1bGx5IGNsZWFyIHRoYXQgREhDUCAob2YgYW55DQo+PiBwcm90 b2NvbCkgaW4gdGhlIGFic2VuY2Ugb2YgbGluay1sYXllciBzZWN1cml0eS9hdWRpdGFiaWxpdHkg ZmVhdHVyZXMgDQo+PiBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICJ0byBl bnN1cmUgYXVkaWJpbGl0eSBhbmQgDQo+PiB0cmFjZWFiaWxpdHkiIFtTZWN0aW9uIDIuMS42XS4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPj4NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9QU0VDIG1haWxpbmcgbGlzdA0K PiBPUFNFQ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29wc2VjDQo+IA0KDQo= From nobody Fri Jun 17 04:47: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 03B7212D533 for ; Fri, 17 Jun 2016 04:47:38 -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 HV0tvNwspSKP for ; Fri, 17 Jun 2016 04:47:35 -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 173F312D534 for ; Fri, 17 Jun 2016 04:47:34 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E0202603BC for ; Fri, 17 Jun 2016 13:47:32 +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 56AAD60878; Fri, 17 Jun 2016 13:47:32 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 44FA6345F4; Fri, 17 Jun 2016 13:47:32 +0200 (CEST) Date: Fri, 17 Jun 2016 13:47:32 +0200 From: Gert Doering To: Marco Ermini Message-ID: <20160617114732.GK79185@Space.Net> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> 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, 17 Jun 2016 11:47:38 -0000 Hi, On Thu, Jun 16, 2016 at 10:03:25AM +0000, Marco Ermini wrote: > NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently. Unfortunately RFC 4864 does not mention such case, AFAIK. Why would anyone route their IPv6 traffic to the IPv4 CGN box? CGN boxes are way expensive, so anyone with a calculator would route everything that does not need NAT around the CGN box. 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 Fri Jun 17 05:44: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 5C88F12D606 for ; Fri, 17 Jun 2016 05:44:05 -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=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 gesH2O0sARmA for ; Fri, 17 Jun 2016 05:44:03 -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 8D21912D5FC for ; Fri, 17 Jun 2016 05:44:03 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3B7D960F40 for ; Fri, 17 Jun 2016 14:44:01 +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 EB032602B7; Fri, 17 Jun 2016 14:44:00 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id DA1023480E; Fri, 17 Jun 2016 14:44:00 +0200 (CEST) Date: Fri, 17 Jun 2016 14:44:00 +0200 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160617124400.GQ79185@Space.Net> References: <773eb60f-3827-a702-1a99-0b3c31b2e9da@gmail.com> <67F4BB77-B492-40AA-848D-39579A3AC671@delong.com> <8c91f195-e2a0-8713-5a7d-0d5d4b60853a@gmail.com> <0c3cef95-e45a-d5de-8df5-abd0a66a0e71@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c3cef95-e45a-d5de-8df5-abd0a66a0e71@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] Packets with LL src and GUA dst 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, 17 Jun 2016 12:44:05 -0000 Hi, On Fri, Jun 17, 2016 at 11:32:45AM +0200, Alexandre Petrescu wrote: > Right, an _intermediary_ node may not be able to send errors back to the > sender of a packet that that intermediary forwards. And that's ok. Please go home and try to understand how the IP protocol suite works, and do not come back before you have succeeded. 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 Fri Jun 17 05:54: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 0EAE512D621 for ; Fri, 17 Jun 2016 05:54:06 -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 NrMrFLQ1Xpby for ; Fri, 17 Jun 2016 05:54:03 -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 6F13C12D620 for ; Fri, 17 Jun 2016 05:54:03 -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 u5HCrtTP025610; Fri, 17 Jun 2016 14:53:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 542BA205E3C; Fri, 17 Jun 2016 14:54:39 +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 43A72205E74; Fri, 17 Jun 2016 14:54:39 +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 u5HCrt8R025535; Fri, 17 Jun 2016 14:53:55 +0200 To: Owen DeLong References: <57571D6E.2050102@gont.com.ar> <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> From: Alexandre Petrescu Message-ID: <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> Date: Fri, 17 Jun 2016 14:53:55 +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: <9AA77CE7-FF01-4140-974E-E7A5A46D8A78@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 12:54:06 -0000 Le 17/06/2016 à 06:16, Owen DeLong a écrit : > >> On Jun 16, 2016, at 03:00 , Alexandre Petrescu >> wrote: >> >> >> >> Le 15/06/2016 à 21:28, Musa Stephen Honlue a écrit : >>> This is bad behaviour both for the source device(LL should not be >>> used for off-link destinations), and for intermediary >>> routers(they should not forward packet sourced with LLA). >>> >>> It is clear enough that responses to such packets won't be able >>> to make their way back. >> >> I agree - but sometimes there is no need for response - protocols >> such as OSPF or ICMP Router Advertisements, not to mention UDP >> video streaming, dont need responses. > > Um… So just to make sure I understand correctly… > > Other than virtual links, OSPF route announcements shouldn’t have GUA > destinations. In the case of a virtual link, an OSPF route > announcement shouldn’t have LL source. Ah, no, I did not mean of virtual links. Simply an IPv6 OSPF router must be able to send an LSA (link-state advertisement) to a multicast group beyond the link. And it is not for that need that it must have a GUA/ULA. A network of OSPF routers must be able to work without any GUA/ULA nor IPv4 on any of the routers. Because it is easy to set up same network with static routes, without OSPF, and without GUA/ULA on them (just the LLs). > In the case you seem to be proposing, virtual link with LL source and > GUA destination, you would be sending a route announcement that > effectively sets an un-reachable next-hop to the remote router. I’m > not sure I see any possible benefit of this action under any > circumstances. I can, however, see several problematic outcomes > (network singularities anyone?). I would agree with you if I proposed virtual links. But not in this case. A network of routers is able to forward packets even though it has not GUA or ULA on any of the routers. > Similarly, an ICMP RA should have either an LL destination or a > multicast (link scoped) destination. I cannot see any valid case for > sending an RA off-link. > > So that leaves us with only UDP video streaming as your remaining > theoretical case. > > Can you please elaborate on what possible useful case of a video > streaming source would not have a GUA or ULA and would attempt to > transmit said video stream off-link? In IoT infratructure-less mobility settings there can be cases where it's hard to form and keep a GUA (I am not talking ULA) for a Thing-class device. For example a wifi point-of-view miniature mobile camera attached on the windshield wiper, but without cellular modem, may IP stream what it sees. Other vehicles hear it, display and further forward. > I realize that ULA may not be able to reach the intended destination, > but at least that packet won’t make it past the border of the network > administrative boundary that has agreed to accept this cruft > (hopefully) which I would argue is a very desirable property of > whatever it is you are proposing to do here. I think I can agree with the ULA usefulness here, because it may be forbidden from leaking to the Internet core (although I dont quite understand the fear of ULAs or LLs -sourced packets showing up in the DFZ - it doesnt look at it anyways because it wants to be fast). >> For network control (ICMP), yes there is need to have ability to >> reply back always, but some software uses ICMP for network control >> and UDP for video streaming. >> >> One should mpt use the LL src if ICMP is expected, but one could >> very well use LL src for UDP for video streaming (video is just an >> example app). > > Again, I do not see a valid use case for LL Source if the destination > is not on-link. Assuming we have a common understanding of on-link. I suspect your assumption of 'link' is not what many people in mobility settings think a link can be. > This is the entire point of scoped addresses and what you are > wanting to do discards virtually all meaning of scope. The whole meaning of scope is new in IPv6 vs IPv4. And it's not easy: ULAs, scoped multicast groups and networks disconnected from the Internet are all scope complications to implementers wondering which additional rules to add (or not) to an otherwise very simple forwarding implementation. It's easy to enunciate and implement that each packet must have same scope in src and dst. But it's harder to say which non-equal scope packets can be forwarded between interfaces of a router. One would not forward a src LL dst GUA because they are different scopes. Yet one _would_ forward a src GUA dst ULA even though they are different scopes too. Moreover, one _would_ forward a src ULA dst site-local multicast group (the ULA scope is almost the same scope as the site-scope) and, worse, an across-subnets site-local multicast group could contain only LL addresses if the subscribers decided to use their LLs (the subscription operation is a link-local operation - MLD). I would also like to mention the difficulty in understanding scopes being 'larger' than others, or scopes 'containing' scopes as they are found in many RFCs. 'Larger' and 'containing' may be intuitive to many readers (e.g. global scope is larger than link scope, the global scope contains all links scopes), but can be hard to implementation (wifi 'overlapping' models dont contain each other and are sometimes disconnected from the Internet). > What will you want next? ff02:: packets being delivered globally? I argued about src LL, not dst LL. I think it is largely agreed that dst LL packets would not be forwarded. I can agree. >>> Therefore, if the path of such packets can be traced, it is >>> necessary to report a bug to various vendors concerned for them >>> to deal with this issue in accordance with specifications as per >>> https://tools.ietf.org/html/rfc4291#section-2.5.6. >> >> I am not sure we must build in a capability to always trace back to >> originators. This is may be way beyond pure packet data >> communications. > > That’s not what he is saying. What he is saying is that in the case > A->B->C->D->E->F->G->H->I where A sends a packet with LL src and I > dst and I receives the packet, one should make a best effort to > identify {H, G, F, E, D, C, B, A} and report bugs to the vendors > responsible for the IPv6 stack implementation on each and every one > of them because each and every one of them did something bad. > > He is absolutely right in saying this. By the specs, yes, he's right. Thanks to the WG members for having provided the refs to the specs. Alex > > Owen > > From nobody Fri Jun 17 06:12:40 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 E87CE12D1E7; Fri, 17 Jun 2016 06:12: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 ZmEddaosXvAl; Fri, 17 Jun 2016 06:12:14 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) by ietfa.amsl.com (Postfix) with ESMTP id 634F512D52B; Fri, 17 Jun 2016 06:12:13 -0700 (PDT) Received: from [85.158.136.227] by server-11.bemta-5.messagelabs.com id 56/75-04210-C27F3675; Fri, 17 Jun 2016 13:12:12 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRWlGSWpSXmKPExsVy+JUil67W9+R wg4kfLSye7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1493ZG0wFDyaxVvRc+s3U wNjdxdrFyMkhJLCeUeLaFIMuRi4gew+jxIRt08ESbAI6Ev+X72LvYuTgEBFQl/jYxwhSwyzwg Uli5oFOJpAaYQEvif17W5lBbBEBb4mtNzYzQthOEsuaDoDVsAioSvx+dwHM5hVwltjU8Z4NYt lLFom5a5aCJTgFAiXWX73NAmIzCshKfGlcDTaUWUBc4taT+WA1EgICEkv2nGeGsEUlXj7+xwp hK0pc/j2FBaI+W+LljfVsEMsEJU7OfMIC8aWKRPuCZVD1wRIt27exTmAUnYVkxSwk7bOQtM8C +p9ZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2JUL04tKkst0rXQSyrKTM8oyU3MzNE1N DDVy00tLk5MT81JTCrWS87P3cQIjEYGINjBeLDZ+RCjJAeTkijv3HPJ4UJ8SfkplRmJxRnxRa U5qcWHGGU4OJQkeC99BcoJFqWmp1akZeYA0wJMWoKDR0mE9wxImre4IDG3ODMdInWK0Z5jweI ba5k4roHJO2Dy04QDx5iEWPLy81KlxHlPgbQJgLRllObBDYWlsUuMslLCvIxAZwrxFKQW5WaW oMq/YhTnYFQS5r0LMoUnM68EbvcroLOYgM7SnAd2VkkiQkqqgdH3M9vsDY3ak/MXng8Pli+97 a+9aqvrc03pWhb9gAcLDc/oFl9qC853juh5PyMpr9bjw8eeGVoFs/zOGcycqaDAwPC+8UFxvd f3LxPnzXhoXD2HfXFs1CHeiEQd2d2eQdV8y0Uc5XsbeTbdOdIXyJspJ3qJpdHCXsvb8L5AQOl Pv7AFIlW7lViKMxINtZiLihMBxAtStV4DAAA= X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-3.tower-162.messagelabs.com!1466169130!10883781!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5877 invoked from network); 17 Jun 2016 13:12:10 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-3.tower-162.messagelabs.com with SMTP; 17 Jun 2016 13:12:10 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 15:12:10 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 15:12:10 +0200 From: Marco Ermini To: Mark Smith Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx8kDZDWt19w1D06Dzoga8sHTvZ/sGD1ggACTCYCAAN1lEA== Date: Fri, 17 Jun 2016 13:12:09 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: multipart/alternative; boundary="_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_" MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 13:12:10.0364 (UTC) FILETIME=[DB343BC0:01D1C899] 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, 17 Jun 2016 13:12:19 -0000 --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBzb3JyeSwgSSBzdXJyZW5kZXIgdGhlIE91dGxvb2sgb24gdGhlIHRoaXJkIGluZGVudA0K DQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NClNlbnQ6 IEZyaWRheSwgSnVuZSAxNywgMjAxNiAyOjIxIEFNDQpUbzogTWFyY28gRXJtaW5pDQpDYzogRXJp YyBWeW5ja2UgKGV2eW5ja2UpOyBkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnOyBFcmlrIEts aW5lOyB2Nm9wc0BpZXRmLm9yZzsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1kZWJybi1u dmEuZGU7IGZnb250QHNpNm5ldHdvcmtzLmNvbTsgQnJpYW4gRSBDYXJwZW50ZXINClN1YmplY3Q6 IFJFOiBbdjZvcHNdIFtPUFNFQ10gQXNraW5nIGZvciBhIHJldmlldyBvZiBkcmFmdC1pZXRmLW9w c2VjLXY2LTA4DQoNCg0KT24gMTcgSnVuIDIwMTYgMDA6MTUsICJNYXJjbyBFcm1pbmkiIDxNYXJj by5Fcm1pbmlAcmVzbWVkLmNvbTxtYWlsdG86TWFyY28uRXJtaW5pQHJlc21lZC5jb20+PiB3cm90 ZToNCj4NCj4gSSdsbCB0cnkgdGhlIGhvcnJpYmxlIE91dGxvb2sgdG8gcmVwbHkgdXNpbmcgdGV4 dCwgcGxlYXNlIGJlZyBteSBwYXJkb24gaWYgdGhpcyBpcyBub3QgZm9ybWF0dGVkIHByb3Blcmx5 Lg0KPg0KPiBPbiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBNLCBNYXJrIFNtaXRoIFtt YWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbTxtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNv bT5dIHdyb3RlOg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gTkFUIGNhbiBiZSBzdGlsbCBuZWNlc3Nh cnkgaW4gSVB2NiBpbiBkdWFsLXN0YWNrIHNjZW5hcmlvLCBmb3IgaW5zdGFuY2UsIHdoZXJlIGV2 ZXJ5IGhvc3QgaXMgYXNzaWduZWQgYm90aCBhIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzIGFuZCB0 aGUNCj4gPj4gQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUgdGhlbSBkaWZmZXJlbnRseS4NCj4g PkNhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2aWNlLg0K Pg0KPiBJIHdvdWxkIHByZWZlciBub3QgdG8gbWFrZSBuYW1lcywgYnV0IHlvdSB3b3VsZCBiZSB1 bnBsZWFzYW50bHkgc3VycHJpc2VkLg0KDQpJJ20gc2NlcHRpY2FsLCBJIGFuZCBJIHRoaW5rIG90 aGVycyB3b3VsZCB3YW50IGEgY29uY3JldGUgZXhhbXBsZS4NCg0KW01hcmNvIEVybWluaV0NCg0K SSBhbSBzb3JyeSwgSSBhbSBub3QgYXV0aG9yaXNlZCB0byBkbyB0aGF0IHB1YmxpY2FsbHkuICBC dXQgdGhpcyBpcyBub3QgbmVjZXNzYXJ5IGFueXdheS4gIFRoZXJlIGlzIG5vIG5lZWQgdG8gbGlz dCBldmVyeXRoaW5nIHRoYXQgd29ya3Mgd3JvbmcsIHRvIGRlZmluZSB3aGF0IHRoZSBjb3JyZWN0 IGJlaGF2aW91ciBzaG91bGQgYmUuDQoNCklmIHBlb3BsZSBhcmVuJ3QgaW1wbGVtZW50aW5nIHNw ZWNpZmljYXRpb25zIHdlbGwsIHdlIG5lZWQgdG8ga25vdywgc28gdGhhdCBpZiBuZWNlc3Nhcnkg dGhlIHNwZWNpZmljYXRpb25zIGNhbiBiZSBpbXByb3ZlZC4NCg0KW01hcmNvIEVybWluaV0NCg0K VGhpcyBpcyB3aHkgd2UgaGF2ZSBkcmFmdC1nb250LW9wc2VjLWlwdjYtZmlyZXdhbGwtcmVxcy0w My50eHQuDQoNCiAgQW55d2F5LCBpdCBpcyBhbHNvIG5vdCBqdXN0IGEgbWF0dGVyIG9mIG5vdCBi ZWluZyBhYmxlIHRvIGNvbmZpZ3VyZSB0aGVtIGluIGEgY2VydGFpbiB3YXkgKHdoaWNoIGlzIHBv c3NpYmx5IHRoZSBjYXNlKSwgYnV0IGFsc28gdGhlIGNhc2UgaW4gd2hpY2ggdGhleSBkb24ndCB3 b3JrIHByb3Blcmx5Lg0KPg0KPiA+IElQdjQgYW5kIElQdjYgaGF2ZSB0byBiZSBoYW5kbGVkIGRp ZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xzLCByZXF1aXJpbmcg ZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZQ0KPiA+IHBlcmZvcm1pbmcg TkFUIG9uIElQdjQgdHJhZmZpYyBpdCByZWNlaXZlcyBhbmQgZG9pbmcgc3RhbmRhcmQgc3RhdGVs ZXNzIGZvcndhcmRpbmcgb2YgSVB2NiB0cmFmZmljLiBJcyB0aGF0IHRoZSBzY2VuYXJpbyB5b3Un cmUgZGVzY3JpYmluZz8NCj4NCj4gWWVzLCBmb3IgaW5zdGFuY2UuDQoNCk9LLCBzbyAiQ0dOIiBp cyBub3QgYmVpbmcgcGVyZm9ybWVkIG9uIElQdjYgdHJhZmZpYy4NCg0KW01hcmNvIEVybWluaV0N Cg0KU29ydCBvZiBDRyBlcXVpcG1lbnQgd2lsbCBiZSBhbnl3YXkgaW4gdGhlIHdheSBhbHNvIGZv ciBkdWFsLXN0YWNrIHJlc2lkZW50aWFsIGNvbm5lY3Rpb25zLCBhbmQgQ0dOIGlzIHN0aWxsIHVz ZWQgb24gcHVyZSBJUHY2IGltcGxlbWVudGF0aW9ucyBhcyB5b3UgbmVlZCB0byBvZmZlciBjb25u ZWN0aXZpdHkgdG8gSVB2NC1vbmx5IGhvc3RzLg0KDQo+T3IsIHRoZXkgaGFuZGxlIGNlcnRhaW4g ZnVuY3Rpb25zIChlLmcuIE5BVCkgcHVyZWx5IGluIHRoZSBkYXRhIHBsYW5lIGFzIHRoZXkgYXJl IGxvZ2ljYWxseSBzaW1wbGUgdG8gYmUgaW1wbGVtZW50ZWQgaW4gZmlybXdhcmUsIHdoaWxlIG1v cmUgY29tcGxleCBmdW5jdGlvbnMgKGxpa2UgaW1wbGVtZW50aW5nIFVMQSBhZGRyZXNzZXMgdHJh bnNsYXRpb24pIHJlcXVpcmVzIHJvdXRpbmUgZW5naW5lcyB0byBiZSBpbnZvbHZlZCwgdGhlcmVm b3JlIGludm9sdmluZyBkaWZmZXJlbnQgbGF0ZW5jeSBmb3IgZXhlY3V0aW9uLg0KPg0KDQpTbyB0 aGlzIHNvdW5kcyBsaWtlIGVxdWlwbWVudCBoZXJlIGFkZGl0aW9uYWwgZmVhdHVyZXMgY2Fubm90 IGJlIGltcGxlbWVudGVkIGluIGhhcmR3YXJlLCBzbyBpdCBpcyBpbXBsZW1lbnRlZCBpbiBjb250 cm9sIHBsYW5lIHNvZnR3YXJlLg0KDQpUaGlzIGlzIGFuIGV4YW1wbGUgb2Ygd2h5IG5vdCB0byB1 c2UgTkFULiBJdCBpcyB0ZWNobmljYWxseSB2ZXJ5IGNvbXBsZXggY29tcGFyZWQgdG8gcHVyZSBJ UHY0IGFuZCBwdXJlIElQdjYgZm9yd2FyZGluZy4NCg0KW01hcmNvIEVybWluaV0NCg0KSSBkbyBh Z3JlZSB3aXRoIHlvdS4NCg0KSSdtIHN0YXJ0aW5nIHRvIHdvbmRlciBpZiBwZW9wbGUgdGhpbmsg dGhhdCBpZiB0aGV5IHdhbnQgdG8gdXNlIFVMQXMgZm9yIHNvbWUgcmVhc29uLCB0aGV5IHRoaW5r IHRoZXkgdGhlbiBtdXN0IE5BVCB0aGVtLiBJZiB0aGV5IGRvLCBJIHRoaW5rIHRoYXQgbWlnaHQg c2hvdyBhIG1pc3VuZGVyc3RhbmRpbmcgb2Ygc29tZXRoaW5nIGZ1bmRhbWVudGFsIGFib3V0IElQ djYgLSBhIGhvc3QgbmF0aXZlbHkgc3VwcG9ydHMgbXVsdGlwbGUgY29uY3VycmVudCBhZGRyZXNz ZXMgd2l0aCBkaWZmZXJlbnQgc2NvcGVzLCBhbmQgdHJpZXMgdG8gY2hvb3NlIG9uZSBvZiBpdHMg c291cmNlIGFkZHJlc3MgdG8gbWF0Y2ggdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MuDQoNCltNYXJj byBFcm1pbmldDQoNCkkgY2FuIHJlYWxseSBzZWUgeW91ciBwb2ludCBoZXJlLiAgSXQgbWF5IHdl bGwgYmUgdGhhdCDigJxwZW9wbGXigJ0gY2FuIG1pc3VuZGVyc3RhbmQgSVB2Ni4gIERlc3BpdGUg aXRzIGV4aXN0ZW5jZSBzaW5jZSBhIGRlY2FkZSwgaXQgaXMgbm90IHdpZGVseSBhZG9wdGVkIG91 dHNpZGUgb2YgY2VydGFpbiBBc2lhbiBjb3VudHJpZXMuDQoNCj4gSXQgaXMgcHJldHR5IGNvbW1v biB0aGF0IGN1c3RvbWVycyB3aXRoIElTUHMgb2ZmZXJpbmcgZHVhbCBzdGFjaywgdG8gZXhwZXJp ZW5jZSBhIGhpZ2hlciBsYXRlbmN5IGZvciB0aGVpciBjb25uZWN0aW9uIG9uY2UgdGhleSBpbXBs ZW1lbnQgSVB2NiBhbG9uZyB3aXRoIElQdjQuICAgVGhpcyBkb2VzIG5vdCBhcHBseSB3aGVuIG9u bHkgSVB2NCBvciBvbmx5IElQdjYgYXJlIHVzZWQuDQo+DQoNCkknZCBsaWtlIHNvbWUgZXhhbXBs ZXMgb2YgdGhpcy4NCg0KSSd2ZSBiZWVuIG5hdGl2ZWx5IGR1YWwgc3RhY2tlZCBhdCBob21lIGZv ciB0aGUgcGFzdCBuZWFyIDUgeWVhcnMuIEkgaGF2ZSBub3QgZXhwZXJpZW5jZWQgYWRkaXRpb25h bCBhbmQgbm90aWNlYWJsZSBoaWdoZXIgbGF0ZW5jeSBmb3IgYW55dGhpbmcgSSBkby4gSXQganVz dCB3b3JrcywgYW5kIEkgY2FuJ3QgdGVsbCB3aGF0IGlzIGdvaW5nIG92ZXIgSVB2NCBvciBJUHY2 IC0gYW5kIEkga25vdyB0aGF0IG1vc3QgaWYgbm90IGFsbCBHb29nbGUsIEZhY2Vib29rIGFuZCBO ZXRmbGl4IHRyYWZmaWMgY2FuIGFuZCBkb2VzIGNvbWUgb3ZlciBJUHY2Lg0KDQpbTWFyY28gRXJt aW5pXQ0KDQpZb3UgYXJlIGx1Y2t5LiAgQWdhaW4sIEkgY2Fubm90IG1ha2UgbmFtZXMsIGJ1dCB5 b3UgYXJlIG15IGd1ZXN0IGlmIHlvdSBjb21lIG5lYXIgTXVuaWNoIHNvbWV0aW1lcywgYW5kIEni gJlsbCBzaG93IHlvdSB0aGUgdHlwaWNhbCBFdXJvcGVhbiBkdWFsIHN0YWNrIGltcGxlbWVudGF0 aW9uLiDimLkNCg0KSSBhbHNvIHdvcmtlZCBpbiB0aGUgcmVzaWRlbnRpYWwgZGVwbG95bWVudCBv ZiBJUHY2IGF0IHRoZSBvdGhlciBlbmQgb2YgbXkgY29ubmVjdGlvbiBpbiAyMDA5LzIwMTAsIGFu ZCB3ZSBuZXZlciByZWNlaXZlZCBhbnkgSVB2NiBsYXRlbmN5IGNvbXBsYWludHMuIEluIDIwMTIg aXQgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBmb3IgbmV3IGN1c3RvbWVyIGNvbm5lY3Rpb25zLg0K DQpbTWFyY28gRXJtaW5pXQ0KDQpUaGVyZSBhcmUgSVNQcyBpbiBHZXJtYW55IHdoaWNoIG9mZmVy IGJ5IGRlZmF1bHQgSVB2NiwgYW5kIHJlcXVpcmVzIHRvIHBheSBhZGRpdGlvbmFsIGZlZXMgaWYg eW91IHdhbnQgSVB2NCAod2hpY2ggaXMgc29tZXRpbWVzIG5lY2Vzc2FyeSBpZiB5b3VyIGNvbXBh bnkgb25seSBpbXBsZW1lbnRzIElQdjQgYW5kIHlvdSBuZWVkIHRvIFZQTiBpbiwgYXMgQ0dOIGZy b20gSVB2NiB0byBJUHY0IGJyZWFrcyBtb3N0IFZQTiBwbGF0Zm9ybXMpLg0KDQpIb3dldmVyLCB0 aGUgRXVyb3BlYW4gb3BlcmF0b3JzIG9mZmVyaW5nIGR1YWwgc3RhY2sgYWxsIHN1ZmZlcnMgZnJv bSBsYXRlbmN5IGlzc3Vlcy4gIEl0IGNhbiBhbHNvIGJlIHBhcnRpYWxseSBkdWUgdG8gdGhlIGNs aWVudCBvcGVyYXRpdmUgc3lzdGVtIGFuZCBob3cgaXQgZGV0ZWN0cyB3aGljaCBpcyB0aGUgYmVz dCBwYXRoIHRvIHVzZSBmb3IgaG9zdHMgdGhhdCBvZmZlciBib3RoIGNvbm5lY3Rpdml0eS4NCg0K SSBoYXZlIGNvbWUgYWNyb3NzIHByZXNlbnRhdGlvbnMgb3ZlciB0aGUgcGFzdCB5ZWFycyB0aGF0 IGhhdmUgc2hvd24gdGhhdCBJUHY2IGhhcyByZWR1Y2VkIGxhdGVuY3kgZm9yIGR1YWwgc3RhY2sg c2VydmljZXMsIGJlY2F1c2UgdGhlIElQdjYgcGF0aCB3YXMgZGlmZmVyZW50IGFuZCBzaW1wbGVy IHRoYW4gdGhlIElQdjQgcGF0aC4NCg0KW01hcmNvIEVybWluaV0NCg0KQWdhaW4sIHRoYXQgaXMg aW4gdGhlIGlkZWFsIHdvcmxkLCBidXQgaXQgaXMgbm90IG15IGV4cGVyaWVuY2Ugd2l0aCBkaWZm ZXJlbnQgRXVyb3BlYW4gcmVzaWRlbnRpYWwgc2VydmljZSBwcm92aWRlcnMuDQoNCklQdjYgc2hv dWxkIGhhdmUgYmVlbiB0aGUgdWx0aW1hdGUgc29sdXRpb24gdG8gbWFueSBpc3N1ZXMsIGJ1dCBh cHBhcmVudGx5IGl0IGhhcyBub3QgYmVlbiB0aGF0IHNpbHZlciBidWxsZXQgdGhhdCBldmVyeW9u ZSB3YXMgaG9waW5nIGZvci4NCg0KPiBBbm90aGVyIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBzcGVj aWZpYyBsb2dnaW5nIG9yIG1vbml0b3Jpbmcgc3lzdGVtIGlzIGltcGxlbWVudGVkIChlc3BlY2lh bGx5IGZvciBsZWdhbCByZXF1aXJlbWVudHMpLCBhbmQgdGhpcyBpcyBkb25lIHRocm91Z2ggbG9n Z2luZyBOQVQgdHJhbnNsYXRpb25zLiAgQW4gSVNQIGltcGxlbWVudGluZyBJUHY2IGFsb25nIHdp dGggSVB2NCB3b3VsZCBiZSBpbiB0aGF0IHNpdHVhdGlvbi4NCj4NCg0KTm8gbmVlZCB0byBkbyBf YWRkcmVzcyB0cmFuc2xhdGlvbl8gdG8gYmUgYWJsZSB0byBwZXJmb3JtIHRoYXQuDQoNCltNYXJj byBFcm1pbmldDQoNCk9mIGNvdXJzZSwgaWYgeW91IGhhdmUgdGhlIHBvc3NpYmlsaXR5LCB5b3Ug Y2FuIGFsd2F5cyBkbyB0aGluZ3MgZGlmZmVyZW50bHkgYW5kIGJldHRlci4NCg0KPiBMdWNraWx5 LCByb3V0ZXIgdmVuZG9ycyBhcmUgbW92aW5nIGF3YXkgZnJvbSB0aGUgYW50aXF1YXRlIGFyY2hp dGVjdHVyZSB3aGljaCBzZXBhcmF0ZXMgZGF0YSBhbmQgbWFuYWdlbWVudCBwbGFuZSwgZm9yIHZh cmlvdXMgcmVhc29ucy4NCj4NCg0KQWN0dWFsbHksIHRoYXQncyBnb2luZyB0byBpbmNyZWFzZSB0 aGUgY29zdCBvZiBlcXVpcG1lbnQsIGJlY2F1c2UgaXQgaXNuJ3QgZ29pbmcgdG8gYmUgY2hlYXAg dG8gZG8gc29tZXRoaW5nIGNvbXBsZXggZmFzdC4NCg0KW01hcmNvIEVybWluaV0NCg0KQXUgY29u dHJhaXJlLCBmb3IgZXF1aXBtZW50IHZlbmRvcnMsIG1vdmluZyBmcm9tIGhhdmluZyBoYXJkd2Fy ZSBhbmQgZGlmZmVyZW50IHBsYW5lcyB0byBtYW5hZ2UsIHRvIGEgc29mdHdhcmUtb25seSB2ZXJz aW9uIHdoaWNoIGNhbiBiZSBzaGlwcGVkIGFzIGJvdGggaGFyZHdhcmUgYW5kIHZpcnR1YWwgaW1h Z2UsIG1lYW5zIG5vdGFibGUgcmVkdWN0aW9uIG9mIGNvc3RzIGluIHRlcm1zIG9mIGRldmVsb3Bt ZW50LCBzdXBwb3J0LCBldGMuDQoNCkJ1dCBvZiBjb3Vyc2UgSSBjb25jZWRlIHRoZXJlIG1heSBi ZSBkaWZmZXJlbmNlcyBjYXNlIGJ5IGNhc2UuDQoNCg0KDQo+IFRoaXMgaXMgYWxzbyB3aHkgd2Ug cHVibGlzaGVkIGRyYWZ0LWdvbnQtb3BzZWMtaXB2Ni1maXJld2FsbC1yZXFzLTAzLnR4dCwgdG8g bWFrZSBpdCBleHBsaWNpdCB0aGF0IHRoaXMgc2hvdWxkIG5vdCBoYXBwZW4uDQo+DQo+IChJIGFt IGF3YXJlIHRoaXMgaXMgb2ZmLXRvcGljLCBqdXN0IG1ha2luZyBteSBwb2ludCA6LSkpDQo+DQo+ ID4+VW5mb3J0dW5hdGVseSBSRkMgNDg2NCBkb2VzIG5vdCBtZW50aW9uIHN1Y2ggY2FzZSwgQUZB SUsuDQo+ID4+DQo+ID4gSW4gYW55IGNhc2UsIEkgYW0gaGFwcHkgdG8gY29uY2VkZSBpdCBjb3Vs ZCBiZSBhbiBleHRyZW1lIGNhc2UgYW5kIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyeSBhbnltb3Jl IGluIElQdjYgZm9yIHRoZSBncmVhdCBtYWpvcml0eSBvZiB1c2UNCj4gPiBjYXNlcy4NCj4NCj4g T2theQ0KPg0KPiA+PiBJIHdhcyBub3QgcmVhbGx5IG1ha2luZyBhIHNwZWNpZmljIGNhc2UgZm9y IElQdjYgLSBteSBvcHBvc2l0aW9uIHdhcyB0byB0aGUgY29uY2VwdCB0aGF0IE5BVCBpcyBub3Qg c2VjdXJpdHksIGFuZCB0byB0aGUgZmFjdCB0aGF0IGl0IHNob3VsZCBiZQ0KPiA+PiB3cml0dGVu IGFzIHN1Y2ggaW4gdGhlIFJGQy4NCj4gPiBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91dCBJ UHY2LiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhhdCBj YW4gYmUgYXBwbGllZCB0byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhlcnMN Cj4gPiB0aGF0IHNob3VsZG4ndCwgYW5kIG9wcG9ydHVuaXRpZXMgd2hlcmUgSVB2NiBjYW4gcHJv dmlkZSBiZXR0ZXIgc2VjdXJpdHkgdGhhdCBJUHY0IChlLmcuIHNwYXJzZSBob3N0IGFkZHJlc3Np bmcgaW4gYSAvNjQgbWFrZXMgYWRkcmVzcyBwcm9iaW5nDQo+ID4gdG8gZGlzY292ZXIgaG9zdHMg aW1wb3NzaWJsZSB3aXRoaW4gYSB1c2VmdWwgYW5kIHByYWN0aWNhbCB0aW1lZnJhbWUuKS4NCj4N Cj4gT2theSwgSSBoYXZlIG5vdGhpbmcgdG8gb2JqZWN0IG9uIHRoaXMuDQo+DQo+DQo+ID4+IE5B VCAqZG9lcyogcHJvdmlkZSBhIGZvcm0gb2Ygc2VjdXJpdHkNCj4gPldoYXQgc3BlY2lmaWMgc2Vj dXJpdHkgZG9lcyBpdCBwcm92aWRlIHRoYXQgaXMgZHVlIHRvIHRoZSBhZGRyZXNzIHRyYW5zbGF0 aW9uIGZ1bmN0aW9uPw0KPiA+IElmIHlvdSdyZSB0aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlv biBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJlaW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRy ZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQgc3RhdGUgY2FuIGJlDQo+ID4gY3JlYXRlZCB3 aXRob3V0IHBlcmZvcm1pbmcgYWRkcmVzcyB0cmFuc2xhdGlvbiwgd2hpY2ggaXMgd2hhdCBhIHN0 YXRlZnVsIGZpcmV3YWxsIGRvZXMgYW5kIGRpZCBpbiBJUHY0IGJlZm9yZSBOQVQgYmVjYW1lIHdp ZGVseSBkZXBsb3llZC4NCj4NCj4gSSB0b3RhbGx5IGFncmVlIHdpdGggeW91LiAgSSBhbSBhY3R1 YWxseSByZWZlcnJpbmcgdG8gdGhlIHBvc3NpYmlsaXR5IHRvIGhpZGUgdGhlIHN5c3RlbXMgYmVo aW5kIHRoZSBOQVR0ZWQgaW50ZXJmYWNlcyBvZiB0aGUgcm91dGVyL2ZpcmV3YWxsLCBub3QganVz dCB0aGVpciBhZGRyZXNzZXMgYnV0IGFsc28gcG9ydHMgYW5kIHNlcnZpY2VzLiAgSWYgeW91IG9u bHkgYXBwbHkgZmlsdGVyaW5nLCB5b3UgYXJlIHByb3RlY3RpbmcgLSBidXQgbm90IGhpZGluZy4N Cj4NCg0KTkFUIGlzIG5vIHdoZXJlIG5lYXIgYXMgZWZmZWN0aXZlIGF0IGhpZGluZyBzeXN0ZW1z IGFzIHBlb3BsZSB0aGluay4gVG9vIG1hbnkgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVtIGJlaGlu ZCB0aGUgTkFUIGxlYWsgYWNyb3NzIE5BVCwgb3IgY2FuIGJlIGZvcmNlZCB0byBsZWFrIGFjcm9z cyB0aGUgTkFULg0KDQpJdCBpcyBxdWl0ZSBhIHBvcm91cyBiYXJyaWVyLCBiZWNhdXNlIE5BVCBp cyBub3QgYWN0dWFsbHkgZGVzaWduZWQgdG8gaGlkZSBzeXN0ZW1zLiBBZGRyZXNzIHRyYW5zbGF0 aW9uIGluaGVyZW50bHkgaGlkZXMgc29tZSBvZiB0aGUgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVt cyAoYWRkcmVzc2VzKSBidXQgbm90IGFsbCBvZiB0aGVtLg0KDQpbTWFyY28gRXJtaW5pXQ0KDQpN b3N0IG9mIHRoZSBOQVQgdnVsbmVyYWJpbGl0aWVzIGNvbWUgZnJvbSBob21lIHJvdXRlcnMsIHdp dGggdGhlaXIgUG5QIGFuZCBvdGhlciBwcm90b2NvbHMgd2hpY2ggYXJlIG9mdGVuIGJhZGx5IGlt cGxlbWVudGVkLCBhcyB3ZWxsIGFzIHByb3RvY29scyB0aGF0IGRvIG5vdCBuZWNlc3NhcmlseSBw bGF5IHdlbGwgd2l0aCBOQVQuICBJZiBpdCBqdXN0IGhpZGVzIElQcyBhbmQgcG9ydHMsIHRoYXQg aXMgYWxyZWFkeSBkb2luZyBzb21ldGhpbmcuDQoNClBsZWFzZSBkbyBub3QgZ2V0IG1lIHdyb25n LiAgSSBhbSBhcyBtdWNoIGFzIGFueW9uZSBlbHNlIGhvcGluZyB0byBzZWUgdGhlIGRheSB0aGF0 IE5BVCBpcyByZWxlZ2F0ZWQgaW50byB0aGUgcGxhY2UgaW4gaGlzdG9yeSB3aGVyZSBpdCBzaG91 bGQgYmUuICBBbmQgSSBhbSAodW5mb3J0dW5hdGVseSkgd2VsbCBhd2FyZSB0aGF0IGFsbCBwcm90 b2NvbHMgd2hpY2ggbmVnb3RpYXRlIGFuIGhpZ2ggcG9ydCB0aHJvdWdoIGFuIGVuY3J5cHRlZCBj aGFubmVsIChGVFAtUywgb3IgY2VydGFpbiB2ZXJzaW9ucyBvZiBNaWNyb3NvZnQgQ29tbXVuaWNh dG9yL0x5bmMsIGNlcnRhaW4gVlBOLCBldGMuKSB3aWxsIG5ldmVyIHdvcmsgd2l0aCBhbnkgTkFU IChJIGVuc3VyZSB5b3UgSSBoYXZlIGxpdmVkIHRoYXQgb24gbXkgc2tpbikuDQoNCkF0IHRoZSBz YW1lIHRpbWUsIEkgY2Fubm90IG5lZ2xlY3QgdGhhdCBwcmFjdGljYWxseSBzcGVha2luZywgbXkg ZXhwZXJpZW5jZSB3aXRoIENHTiB3aXRoIElQdjQgaW4gdGVsY29zIGlzIHRoYXQgaXQgaXMgcXVp dGUgZWZmZWN0aXZlLiAgRmlyZXdhbGwgdmVuZG9ycyBoYXZlIHNwZW50IGEgZGVjYWRlIGZpeGlu ZyBpdCBhbmQgaW1wbGVtZW50aW5nIGV2ZXJ5IHNvcnQgb2YgdmFyaWFudCBzdWNoIGFzIE5BVC1U LCBOQVQtUE1QLCBOQVQgZm9yIFJQQywgZXRjLg0KDQo+IEluIGEgcGVyZmVjdCB3b3JsZCwgeW91 IGhhdmUgc3VjaCBnb29kIGZpbHRlcnMgdGhhdCB5b3UgY2FuIHRyYW5zcGFyZW50bHkgcHJvdmlk ZSB0aGUgcmVhbCBhZGRyZXNzZXMgYW5kIHBvcnRzIGZyb20gY2xpZW50cyB0byB0aGUgcmVzdCBv ZiB0aGUgSW50ZXJuZXQNCg0KSXQncyBzb3VuZGluZyBsaWtlIHlvdSdyZSBub3QgdXAgdG8gZGF0 ZSB3aXRoIElQdjYgZmlyZXdhbGxpbmcgY2FwYWJpbGl0aWVzIGluIGRldmljZXMsIGFuZCB0aGVy ZWZvcmUgbWlnaHQgYmUgYXNzdW1pbmcgdGhhdCBub25lIGV4aXN0Lg0KDQpBcmUgeW91IGF3YXJl IGZvciBleGFtcGxlIHRoYXQgV2luZG93cyBoYXMgaGFkIGEgc3RhdGVmdWwgSVB2NiBmaXJld2Fs bCwgZW5hYmxlZCBieSBkZWZhdWx0LCBzaW5jZSBXaW5kb3dzIFhQIHNlcnZpY2UgcGFjayAyLCBy ZWxlYXNlZCBtb3JlIHRoYW4gYSBkZWNhZGUgYWdvPw0KDQpJJ3ZlIGJlZW4gdXNpbmcgSVB2NiB1 bmRlciBMaW51eCB0byBhY2Nlc3MgdGhlIEludGVybmV0IGVpdGhlciB2aWEgdHVubmVscyBvciBu YXRpdmVseSBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlLCB1c2luZyB0aGUgc3RhdGVmdWwgSVB2NiBm aXJld2FsbCB0aGF0IGhhcyBiZWVuIHBhcnQgb2YgdGhlIExpbnV4IGtlcm5lbCBmb3IgYXQgbGVh c3QgdGhhdCBsb25nLg0KDQpUaGlzIEFuZHJvaWQgcGhvbmUgaGFzIG5hdGl2ZSBhbmQgcHVibGlj IElQdjYgYWRkcmVzc2VzIGFuZCBpcyBub3QgYmVoaW5kIGFueSBzb3J0IG9mIElQdjYgTkFULiBJ dCdzIGJlaGluZCBhIGRldmljZSB0aGF0IGNhbiBwZXJmb3JtIElQdjYgc3RhdGVmdWwgZmlyZXdh bGxpbmcsIGhvd2V2ZXIgSSB0aGluayBJJ3ZlIHR1cm5lZCBpdCBvZmYsIGJlY2F1c2UgSSB0cnVz dCB0aGF0IGFzIEdvb2dsZSBjYW4ndCB0cnVzdCB0aGVyZSBpcyBhIG5ldHdvcmsgZmlyZXdhbGwg dXBzdHJlYW0gb2YgbXkgcGhvbmUsIHRoZXkgZW5zdXJlIG15IHBob25lIGlzICJJbnRlcm5ldCBw cm9vZiIuDQoNClRoZSAicGVyZmVjdCIgd29ybGQgeW91J3JlIHJlZmVycmluZyB0byBpcyBhbmQg aGFzIGJlZW4gcmVhbGl0eSBmb3IgYSBsb25nIHRpbWUgZm9yIGEgbG90IG9mIHBlb3BsZS4NCg0K W01hcmNvIEVybWluaV0NCg0KSSBhbSBzb3JyeSwgSSBkbyBub3QgdGhpbmsgYnJpbmdpbmcgdGhl IGRpc2N1c3Npb24gb24gYSBwZXJzb25hbCBsZXZlbCBpcyB1c2VmdWwgdG8gdGhlIGRpc2N1c3Np b24uICBJZiB0aGlzIGlzIGludGVyZXN0aW5nLCBJIGFtIGF3YXJlIHRoYXQgV2luZG93cyBoYXMg SVB2NiBhbmQgYSBmaXJld2FsbC4gIFRoaXMgaXMgbm90IGEgZGVtb25zdHJhdGlvbiB0aGF0IElQ djYgZmlsdGVycyBhcmUgbmVhciBhcyBnb29kIGFzIElQdjQgb25lcy4NCg0KT24gcmVzaWRlbnRp YWwgcm91dGVycywgdGhlIG15dGggdGhhdCBJUHY2IHdpbGwgY29tZSBhbmQgc29sdmUgYWxsIG9m IHRoZSBOQVQgcHJvYmxlbXMgaXMsIGFuZCBhbGxvdyB1YmlxdWl0b3VzIGFuZCBzZWN1cmUgYWNj ZXNzIHRvIGFsbCB0aGUgZGV2aWNlcyBpcywgaW4gZmFjdCwgYSBteXRoLiAgSVB2NiBicmVha3Mg cHJvdG9jb2xzIGFzIG11Y2ggKGlmIG5vdCBtb3JlKSB0aGFuIElQdjQgTkFULiAgVGhlIG1vc3Qg dXNlZCByZXNpZGVudGlhbCByb3V0ZXJzIGluIEdlcm1hbnkgKGFuZCBwcm91ZGx5IEdlcm1hbiBl bmdpbmVlcmVkIHByb2R1Y3QpIHJlcXVpcmVzIOKAnGFkdmFuY2VkIHZpZXfigJ0gZW5hYmxlZCBq dXN0IHRvIGVuYWJsZSBpdDsgaXQgcHJvdmlkZXMgVUxBcyB2aWEgREhDUHY2LCBhbmQgcGVyZm9y bXMgdHJhbnNsYXRpb24gdG8gcm91dGFibGUgSVB2NiBhZGRyZXNzZXMuICBXaGlsZSBJUHY0IE5B VCBuZWVkcyB0byBwZXJmb3JtIHN0YXRlZnVsIHRyYW5zbGF0aW9uIG9mIElQcyBhbmQgcG9ydHMs IHJlc2lkZW50aWFsIHJvdXRlcnMgb24gSVB2NiBvbmx5IHRyYW5zbGF0ZSBJUHMg4oCTIGJ1dCB0 aGF0IGlzIG5vdCBpbXByb3ZpbmcgYSBsb3QuDQoNCk9uIHRvcCBvZiBpdCwgbm90IHRvIGJyZWFr IGNlcnRhaW4sIG1vcmUgY29tcGxleCBwcm90b2NvbHMgdG8gd29yayAoc3VjaCBhcyBCaXRUb3Jy ZW50IG9mIEZUUCksIHRoZXkgbmVlZCB0byBhY3R1YWxseSB1bmRlcnN0YW5kIHRoZW0gYXQgTGF5 ZXItNyBsZXZlbCB0byBtYWtlIHRoZW0gd29yayB0aHJvdWdoIHRoZSB0cmFuc2xhdGlvbiDigJMg YW5kIGd1ZXNzIHdoYXQsIE5BVCBpcyBtdWNoIG1vcmUgdGVzdGVkLiAgTXkgYWN0dWFsIGNvbXBh bnkgaGFzIHRvIHJlcXVpcmUgdGhlaXIgZW1wbG95ZWVzIHRvIHJlcXVlc3QgSVB2NCBpZiB0aGV5 IHdhbnQgdG8gd29yayBmcm9tIGhvbWUgYW5kIGhhdmUgdGhlaXIgc29mdCBwaG9uZSB3b3JrIHBy b3Blcmx5Lg0KDQpBIGZhbW91cyB2ZW5kb3Igb2YgcGVyc29uYWwgY29tcHV0ZXIgd2hpY2ggYWxz byBwcm92aWRlcyDigJxUVuKAnSBhbmQg4oCcUGhvbmXigJ0gdmVyc2lvbiBvZiB0aGVpciBPUywg dXNlcyBOQVQgdG8gaW1wbGVtZW50IHRoZWlyIGFwcGxpY2F0aW9uIGZpbHRlcmluZy4gIFRoaXMg bWVhbnMgdGhhdCB0aGVyZSBpcyBubyBsYXllci03IHN0YXRlZnVsIGZpbHRlciB3aXRob3V0IE5B VCAoc28gZmFyKS4NCg0KQ2VydGFpbiBmaXJld2FsbCB2ZW5kb3JzIChJIGFtIHNvcnJ5LCBhZ2Fp biwgSSBjYW5ub3QgbWFrZSBuYW1lcywgYnV0IHRoZXkgY2FuIGJlIGZvdW5kIGVhc2lseSkgY29t ZSB3aXRoIElQdjYgZGlzYWJsZWQgYW5kIHdpbGwgc2ltcGx5ICppZ25vcmUqIGFuZCAqbGV0IGNv bWUgdGhyb3VnaCogSVB2NiB0cmFmZmljIGFycml2aW5nIG9uIHRoZWlyIGludGVyZmFjZXMgKmJ5 IGRlZmF1bHQqLiAgQW5kIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQg4oCccGVyc29uYWwgZmlyZXdh bGxz4oCdLCBidXQgb2YgTkFTREFRLXF1b3RlZCDigJxuZXh0IGdlbmVyYXRpb27igJ0gZW50ZXJw cmlzZSB2ZW5kb3Igb2YgYXBwbGlhbmNlcyDigJxHYXJ0bmVyIGxlYWRlciBhZ2Fpbi4gQWdhaW4u 4oCdLg0KDQpQcmFjdGljYWxseSBzcGVha2luZywgdG8gYnJpbmcgSVB2NiB0byBhIHN0YXRlIHdo ZXJlIHRoZSBob3N0cyBhcmUgYXMgc2VjdXJlIGFzIHRoZXkgYXJlIHRvZGF5IG9uIElQdjQgb24g bG9jYWwgbmV0d29ya3MgYmVoaW5kIE5BVCwgeW91IG5lZWQgd2VsbC10aG91Z2h0IGZpcmV3YWxs IHNldHVwcywgbXVjaCBiZXR0ZXIgZGVmYXVsdCwgaW1wcm92ZWQgc29mdHdhcmUgc3RhY2sgYW5k IGFwcGxpY2F0aW9uLXVuZGVyc3RhbmRpbmcgbGF5ZXItNyBmaWx0ZXJzLiAgVGhpcyBpcyBub3Qg dGhlIGFjdHVhbCBjYXNlIGdlbmVyYWxseSBvbiBJUHY2IG5ldHdvcmtzIGFuZCBOQVQgZG9lcyBw cm92aWRlIGEgcG9vci1tYW4g4oCcaGFja+KAnSB0byBhdCBsZWFzdCBwcmV2ZW50IGVhc3kgYWNj ZXNzIHRvIHlvdXIgbmV0d29yay1lbmFibGVkIHJlZnJpZ2VyYXRvciBhbmQgbWljcm93YXZlIGF0 IGhvbWUgZnJvbSBpbnRydWRlcnMuDQoNCg0KDQo+LSBob3dldmVyIHdlIGRvbid0IGxpdmUgaW4g c3VjaCB3b3JsZCwgdGhlcmVmb3JlIGhpZGluZyBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGxheWVy IG9mIHByb3RlY3Rpb24gaW4gdGhlICJkZWZlbmNlIGluIGRlcHRoIiBhcHByb2FjaC4NCj4NCj4g VGhlIGZhY3QgdGhhdCB0aGlzICJoaWRpbmciIGFjdHVhbGx5IGhpbmRlcnMgdGhlIGRlcGxveW1l bnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFrZXMgbGlmZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4g bWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3BpYyBvbiB3aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDot KQ0KPg0KPiBUaGVyZSBhcmUgYWxzbyBjYXNlcyB3aGVyZSBOQVQgb2ZmZXJzIGJldHRlciAob3Ig YXQgbGVhc3Qgc2ltcGxlcikgcHJvdGVjdGlvbiB0aGFuIGZpbHRlcnMuICBGb3IgaW5zdGFuY2Us IHRoZXJlIGFyZSBrbm93biAib3ZlcmJpbGxpbmcgYXR0YWNrcyIgcGVyZm9ybWVkIGluIHRlbGNv IG5ldHdvcmtzLCB3aGVyZSBtb2JpbGUgdGVybWluYWxzIGFyZSBzZW50IHdpdGggVURQIHBhY2tl dHMgdG8ga2VlcCB0aGVtIGFsaXZlIGV2ZW4gaWYgd291bGQgYWN0dWFsbHkgZGlzY29ubmVjdCwg Y2F1c2luZyB0aGVtIHRvIGJlIGV4Y2Vzc2l2ZWx5IGJpbGxlZC4gIEZpbHRlcnMgZm9yIHRob3Nl IHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGljYXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0YW5k IHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcgb3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUgdGVy bWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRmb3J3YXJkIHByb3RlY3Rpb24sIGluc3RlYWQu DQo+DQoNClRoZXJlIGlzIG5vIG5lZWQgdG8gcGVyZm9ybSBfYWRkcmVzcyB0cmFuc2xhdGlvbl8g dG8gcGVyZm9ybSB0aGlzIHByb3RlY3Rpb24uDQoNCltNYXJjbyBFcm1pbmldDQoNClRoZXJlIGlz IG5vIHRoZW9yZXRpY2FsIG5lZWQsIGJ1dCB0aGlzIGlzIHdoYXQgd29ya3MuDQoNCkNvbnRpbnVp bmcgdG8gc2F5IE5BVCBpbiB0aGVzZSBleGFtcGxlcyBpcyBhIGJpdCBsaWtlIHNheWluZyAiSSBu ZWVkIG15IHRvb2xib3ggdG8gYmFuZyBpbiBuYWlscyIuIFlvdSBuZWVkIHlvdXIgdG9vbGJveCBi ZWNhdXNlIHRoYXQgaXMgd2hlcmUgeW91ciBoYW1tZXIgaXMsIGhvd2V2ZXIgaXQgaXMgYWN0dWFs bHkgeW91ciBoYW1tZXIgdGhhdCB5b3UgdXNlIHRvIGJhbmcgaW4gbmFpbHMuDQoNCk5BVCBpcyBh ZGRyZXNzIHRyYW5zbGF0aW9uICsgc3RhdGVmdWwgZmlsdGVyaW5nIGluaGVyZW50IGluIHRoZSBv cGVyYXRpb24gb2YgYWRkcmVzcyB0cmFuc2xhdGlvbi4gUGVvcGxlIHdobyBvYmplY3QgdG8gTkFU IGluIElQdjYgYXJlIG9iamVjdGluZyB0byB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhhdCBpdCBp cyBuZWNlc3NhcnkgdG8gcGVyZm9ybSBhZGRyZXNzIHRyYW5zbGF0aW9uIHRvIGFjaGlldmUgc3Rh dGVmdWwgZmlsdGVyaW5nLg0KDQpQZW9wbGUgd2hvIGFkdm9jYXRlIE5BVCBmb3IgSVB2NiBmb3Ig c2VjdXJpdHkgcHVycG9zZXMgZG9uJ3Qgc2VlbSB0byB1bmRlcnN0YW5kIHRoYXQgYWRkcmVzcyB0 cmFuc2xhdGlvbiBpcyAqbm90KiByZXF1aXJlZCB0byBiZSBhYmxlIHRvIHBlcmZvcm0gc3RhdGVm dWwgZmlsdGVyaW5nIC0gb3IgdGhleSdyZSB1c2luZyB0aGUgdGVybSAiTkFUIiB3aGVuIHRoZXkg c2hvdWxkIHJlYWxseSBiZSB1c2luZyB0aGUgdGVybSAic3RhdGVmdWwgZmlsdGVyaW5nIi4NCg0K W01hcmNvIEVybWluaV0NCg0KSSBhZ3JlZSwgYnV0IG5vIG9uZSBpcyBhZHZvY2F0aW5nIGZvciBO QVQg4oCTIG5vdCBtZSwgY2VydGFpbmx5LiAgQWdhaW4sIEkgYW0gc29ycnksIGJ1dCBJIGJlbGll dmUgdGhlcmUgYXJlIHBlb3BsZSB3aG8gYXJlIG92ZXItc2Vuc2libGUgYWJvdXQgdGhpcyB0b3Bp YyBhbmQgaGF2ZW7igJl0IGdvdCBteSBhcmd1bWVudCBwcm9wZXJseS4NCg0KDQoNCj4gUFMuIEkg YW0gYXdhcmUgdGhhdCBtYWpvciBmaXJld2FsbCB2ZW5kb3JzIGltcGxlbWVudCBmaWx0ZXJzIGFn YWluc3Qgb3ZlcmJpbGxpbmcgYXR0YWNrczsgSSB3YXMgb25seSBtYWtpbmcgYW4gb2JqZWN0aW9u IHRvIHRoZSBzZW1hbnRpYyBvZiB0aGUgc2VudGVuY2U6IE5BVCAqcHJvdmlkZXMqIHNlY3VyaXR5 LCBzYXlpbmcgdGhlIGNvbnRyYXJ5IGlzIG5vdCBjb3JyZWN0Lg0KDQoiU2VjdXJpdHkgYWdhaW5z dCB3aGF0IiBpcyB0aGUga2V5IHF1ZXN0aW9uLiBZb3UgY2FuJ3QgYWN0dWFsbHkgc2F5IE5BVCBw cm92aWRlcyBzZWN1cml0eSB3aXRob3V0IGRlZmluaW5nIHRoZSB0aHJlYXQgb3IgY29udGV4dC4g SWYgeW91IGRvbid0IGRlZmluZSB0aGUgdGhyZWF0LCB0aGUgaW1wbGljYXRpb24gb2Ygc3VjaCBh IHN0YXRlbWVudCBpcyB0aGF0IGl0IHByb3ZpZGVzIHNlY3VyaXR5IGFnYWluc3QgbGl0ZXJhbGx5 IGV2ZXJ5IHRocmVhdC4NCg0KSWYgYSBiYW5rIGltcGxlbWVudHMgTkFUIG9uIHRoZWlyIGRhdGEg bmV0d29yaywgYXJlIHRoZXkgbm93IHNlY3VyZWQgYWdhaW5zdCBiYW5rIHJvYmJlcnMgY29taW5n IGludG8gYSBicmFuY2ggd2l0aCBndW5zPyBPYnZpb3VzbHkgbm90Lg0KDQoiTkFUICpwcm92aWRl cyogc2VjdXJpdHkiIGlzIGdvaW5nIHRvIGJlIHdyb25nIGluIG1hbnkgY2FzZXMgYmVjYXVzZSBO QVQgaXMgYW4gZW50aXJlbHkgaW5lZmZlY3RpdmUgbWVhc3VyZSBmb3IgYSBsYXJnZSBzZXQgb2Yg dGhyZWF0cy4NCg0KW01hcmNvIEVybWluaV0NCg0KSSBkbyBub3QgYmVsaWV2ZSBzby4gIEkgYmVs aWV2ZSB0aGF0IG9uIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbiwgTkFUIGlzIG11Y2ggc2FmZXIg dGhhbiB0aGUgY3VycmVudCBJUHY2IGZpbHRlcnMuDQoNCg0KDQo+IFdoZXRoZXIgdGhpcyBjb3Vs ZCBiZSBhY2hpZXZlZCBpbiBzb21lIG90aGVyIHdheXMgaXMgYW5vdGhlciBtYXR0ZXIuDQo+DQoN Ckl0IGlzIHRoZSAqZXhhY3QqIG1hdHRlciBoZXJlLg0KDQpOQVQgaXMgYmVpbmcgYXNzZXJ0ZWQg YXMgdGhlIHNlY3VyaXR5IG1lYXN1cmUgdGhhdCBzaG91bGQgYnkgdXNlZCBpbiBJUHY2LCBiZWNh dXNlIGl0IGhhcyBiZWVuIHVzZWQgaW4gSVB2NCAoYW5kIG5vdCBuZWNlc3NhcmlseSBleGNsdXNp dmVseSBiZWNhdXNlIG9mIHNlY3VyaXR5IC0gbGFjayBvZiBJUHY0IGFkZHJlc3NlcyBpcyBhbm90 aGVyIHJlYXNvbiksIHdpdGhvdXQgYW55IGNvbnNpZGVyYXRpb24gb2YgaXRzIGRyYXdiYWNrcyBv ciBhbHRlcm5hdGl2ZXMgdGhhdCBkb24ndCBoYXZlIHRob3NlIGRyYXdiYWNrcyBlLmcuIHRob3Nl IGRlc2NyaWJlZCBpbiBSRkM0ODY0Lg0KDQpbTWFyY28gRXJtaW5pXQ0KDQpJIGFtIG5vdCBhc3Nl cnRpbmcgdGhhdCBOQVQgc2hvdWxkIGJlIHVzZWQgaW4gSVB2NiAobm90IHN1cmUgaWYgdGhpcyBp cyByZWZlcnJlZCB0byBtZSkuDQoNCj4NCj4gPj4gLSB0aGUgZmFjdCB0aGF0IGl0IGlzIG5vdCBk ZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNlIGlzIGFub3RoZXIgdG9waWMsIGlu IHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxlYXN0IGZvciA5OSUgb2YgdXNlIGNh c2VzIDstKSkNCj4gPg0KPiA+IEkgZG9uJ3Qgc2VlIGEgbmVlZCB0byBkZXBsb3kgTkFUIHdpdGgg SVB2NiBhcyB3aGF0IGhhcyBiZWVuIGFjaGlldmVkIHdpdGggSVB2NCBOQVQgY2FuIGJlIGFjaGll dmVkIGluIElQdjYgd2l0aG91dCB0aGUgZHJhd2JhY2tzIG9mIE5BVC4NCj4NCj4gSSBtZWFuIHRo ZSBzYW1lIGFzIHlvdSBkbywgSSB3b3VsZCBqdXN0IHBocmFzZSBpdCBhcyAidGhlIHBvb3IgSVNQ cyB3aGljaCBzdGlsbCBkbyB0aGF0LCBzaG91bGQgY29uc2lkZXIgbWlncmF0aW5nIHRoZWlyIGFy Y2hpdGVjdHVyZSB0byBiZXR0ZXIgb3B0aW9ucyIuDQo+DQoNClRoZSBjb3N0IG9mIENHTiBjYXBh Y2l0eSB0byBOQVQgdmlkZW8gdHJhZmZpYyB2b2x1bWVzIGZyb20gcG9wdWxhciB2aWRlbyBzaXRl cyBpcyBsaWtlbHkgZ29pbmcgdG8gbWFrZSBkZXBsb3lpbmcgbmF0aXZlIElQdjYgYSBjaGVhcGVy IGFsdGVybmF0aXZlIHZlcnkgcXVpY2tseS4NCg0KW01hcmNvIEVybWluaV0NCg0K4oCmb3IgaXQg aXMgZ29pbmcgdG8gYm91bmNlIGJhY2sgb25jZSB0aGUgdXN1YWwgSVB2NiBwcm9ibGVtcyBhcmlz ZSDigJMgc3RpY2tpbmcgcHVyZWx5IHRvIHRoZSBleGFtcGxlIHlvdSBtYWRlLCBzZWUgcmVjZW50 bHkgaG93IE5ldEZsaXggaGFkIHRvIGJsb2NrIGNlcnRhaW4gSVB2NiBhY2Nlc3NlcyBiZWNhdXNl IGl0IGNhbuKAmXQgYXBwbHkgaXRzIG9yaWdpbiBmaWx0ZXJzLg0KDQoNCg0KUmVnYXJkcywNCk1h cmsuDQoNCltNYXJjbyBFcm1pbmldDQoNClJlZ2FyZHMuDQoNCj4NCj4gUmVnYXJkcywNCj4gTWFy Y28NCj4NCj4gPg0KPiA+UmVnYXJkcywNCj4gPk1hcmsuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+ IOKAi+KAi+KAi+KAi+KAiw0KPiA+IE1hcmNvIEVybWluaQ0KPiA+DQo+ID4gQ0lTU1AsIENJU0Es IENJU00sIENFSCwgSVRJTCwgTUNQLCBQaEQNCj4gPiBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlz dA0KPiA+IEQgKzQ5ICgwKTg5OSA5MDEgMTUyMyAgTSArNDkgKDApMTc1IDQzOSA1NjQyDQo+ID4N Cj4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhA Z21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPl0NCj4gPiBTZW50OiBUaHVy c2RheSwgSnVuZSAxNiwgMjAxNiAxMTo0MyBBTQ0KPiA+IFRvOiBNYXJjbyBFcm1pbmkNCj4gPiBD YzogQnJpYW4gRSBDYXJwZW50ZXI7IEVyaWsgS2xpbmU7IEVyaWMgVnluY2tlIChldnluY2tlKTsg ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyBvcHNl Y0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9wc2VjLXY2QGll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnPjsgbGlua2VkaW5AeG4t LWRlYnJuLW52YS5kZTxtYWlsdG86bGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZT47IHY2b3BzQGll dGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBb T1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNlYy12Ni0wOA0KPiA+ DQo+ID4gT24gMTYgSnVuZSAyMDE2IGF0IDE5OjE1LCBNYXJjbyBFcm1pbmkgPE1hcmNvLkVybWlu aUByZXNtZWQuY29tPG1haWx0bzpNYXJjby5Fcm1pbmlAcmVzbWVkLmNvbT4+IHdyb3RlOg0KPiA+ ID4gV2VsbCwgYWN0dWFsbHksIGluZnJhc3RydWN0dXJlIGhpZGluZyBJUyBwYXJ0IG9mIHNlY3Vy aXR5LiAgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBpbmNvcnJlY3QgdG8g c2F5IHRoYXQgaXQgaXMgbm90Lg0KPiA+ID4NCj4gPiA+IEkgcGVyc29uYWxseSBkb24ndCBzeW1w YXRoaXplIG9uIE5BVC1oYXRlcnMuICBOQVQgaGFzIGl0cyByZWFzb25zLA0KPiA+ID4gZXNwZWNp YWxseSBmb3IgY2Fycmllci1ncmFkZSBOQVQNCj4gPg0KPiA+IENHTiBpc24ndCBuZWNlc3Nhcnkg aW4gSVB2NiwgaXQncyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBJU1BzIHJ1bm5pbmcgb3V0IG9m IElQdjQgYWRkcmVzc2VzLg0KPiA+DQo+ID4gIGFuZCBlc3BlY2lhbGx5IGluIHRoZSB0ZWxjbyBz Y2VuYXJpbywgYW5kIHllcywgaXQgZG9lcyBwcm92aWRlIHNvbWUgbGV2ZWwgb2Ygc2VjdXJpdHkg LSBhZ2Fpbiwgbm90IHRoZSBjb21wbGV0ZSBwaWN0dXJlLCBidXQgaXQgZG9lcy4NCj4gPiA+DQo+ ID4NCj4gPiBOQVQgaXMgbm90IG5lY2Vzc2FyeSBpbiBJUHY2LiBUaGUgZXF1aXZhbGVudCBvZiBO QVQncyBwZXJjZWl2ZWQgc2VjdXJpdHkgY2FuIGJlIHByb3ZpZGVkIHZpYSBhbHRlcm5hdGl2ZSBt ZXRob2RzLCBhcyBkZXNjcmliZWQgaW4gUkZDNDg2NC4NCj4gPg0KPiA+IEEgZnVydGhlciB0ZWNo bmlxdWUgdG8gaGlkZSB0b3BvbG9neSB0aGF0IGlzbid0IG1lbnRpb25lZCBpbiBSRkM0ODY0IGlz IHRvIHVzZSBzb21ldGhpbmcgbGlrZSBJU0FUQVAgb3Igc2ltaWxhciwgdG8gY3JlYXRlIGEgc2lu Z2xlIC82NCBzdWJuZXQgb3ZlciB0aGUgdG9wIG9mIG11bHRpcGxlIElQdjQgc3VibmV0cy4gRXh0 ZXJuYWxseSwgYWxsIGhvc3RzIHdpbGwgYXBwZWFyIHRvIGJlbG9uZyB0byBhIHNpbmdsZSBJUHY2 IHN1Ym5ldCwgaGlkaW5nIHRoZSBpbnRlcm5hbCB0b3BvbG9neS4NCj4gPg0KPiA+IElmIHlvdSB0 cnVseSB3YW50IHRvIGhpZGUgdGhlIGlkZW50aXRpZXMgb2YgaG9zdHMsIE5BVCBkb2Vzbid0IGRv IGVub3VnaCAtIGl0IGlzIG9ubHkgdHJhbnNsYXRpbmcgYWRkcmVzc2VzLCB3aGVyZSBhcyB0aGVy ZSBhcmUgbWFueSBvdGhlciBob3N0IGlkZW50aWZpZXJzIHRoYXQgdGhlIGhvc3QgaXRzZWxmIHN1 cHBsaWVzIG9yIHdpbGwgcmVjZWl2ZSBhbmQgc3VwcGx5IHRoYXQgY2FuIGlkZW50aWZ5IGhvc3Rz IGUuZy4gSFRUUCBjb29raWVzLiAiQSBUZWNobmlxdWUgZm9yIENvdW50aW5nIE5BVHRlZCBIb3N0 cyINCj4gPiAoaHR0cHM6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRm KSBzaG93ZWQgaG93IGEgZmllbGQgd2l0aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBh Y3Jvc3MgYSBOQVQgd2FzIGFibGUgdG8gYmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy4NCj4gPg0K PiA+IElmIHlvdSB0cnVseSB3YW50IHRvIGhpZGUgYSBob3N0IGZyb20gdGhlIEludGVybmV0LCB5 ZXQgc3RpbGwgYWxsb3cgaXQgdG8gYWNjZXNzIHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQsIHVuZGVy IElQdjYgeW91ciBuZXR3b3JrIHdvdWxkIHVzZSBVTEEgYWRkcmVzc2luZywgYW5kIGhhdmUgYSBw ZXItYXBwbGljYXRpb24gcHJvdG9jb2wgcHJveHkgc2VydmVyIHRoYXQgbWFrZXMgYWxsIHJlcXVl c3RzIGxvb2sgbGlrZSB0aGV5J3ZlIGVudGlyZWx5IG9yaWdpbmF0ZWQgZnJvbSB0aGUgYXBwbGlj YXRpb24gcHJveHkgc2VydmVyIGl0c2VsZi4gVG8gdGhlIEludGVybmV0IHNlcnZlciwgdGhlIGFw cGxpY2F0aW9uIHByb3h5IHNlcnZlciB3b3VsZCBhcHBlYXIgdG8gYmUgdGhlIGFwcGxpY2F0aW9u IGVuZCBob3N0IG1ha2luZyB0aGUgcmVxdWVzdHMsIHByZXZlbnRpbmcgYW55IGludGVybmFsIGhv c3QgaWRlbnRpZmllcnMgb3Igb3RoZXIgYXR0cmlidXRlcyBmcm9tIGxlYWtpbmcuDQo+ID4NCj4g Pg0KPiA+IFJlZ2FyZHMsDQo+ID4gTWFyay4NCj4gPg0KPiA+DQo+ID4gPg0KPiA+ID4gUmVnYXJk cywNCj4gPiA+DQo+ID4gPiBNYXJjbyBFcm1pbmkNCj4gPiA+DQo+ID4gPiBDSVNTUCwgQ0lTQSwg Q0lTTSwgQ0VILCBJVElMLCBNQ1AsIFBoRCBTZW5pb3IgSVQgU2VjdXJpdHkgQW5hbHlzdCBEDQo+ ID4gPiArNDkgKDApODk5IDkwMSAxNTIzICBNICs0OSAoMCkxNzUgNDM5IDU2NDINCj4gPiA+DQo+ ID4gPiBSZXNNZWQgR2VybWFueSBJbmMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IE9QU0VDIFttYWlsdG86b3BzZWMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b3BzZWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlh biBFDQo+ID4gPiBDYXJwZW50ZXINCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2 IDE6NDUgQU0NCj4gPiA+IFRvOiBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkNCj4g PiA+IENjOiBmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNv bT47IG9wc2VjQGlldGYub3JnPG1haWx0bzpvcHNlY0BpZXRmLm9yZz47IGxpbmtlZGluQHhuLS1k ZWJybi1udmEuZGU8bWFpbHRvOmxpbmtlZGluQHhuLS1kZWJybi1udmEuZGU+Ow0KPiA+ID4gZHJh ZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRm Lm9yZz47IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+IFN1Ympl Y3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZg0KPiA+ID4gZHJh ZnQtaWV0Zi1vcHNlYy12Ni0wOA0KPiA+ID4NCj4gPiA+IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVy aWsgS2xpbmUgd3JvdGU6DQo+ID4gPj4gU2VjdGlvbiAyLjEuMiBpcyBmYXIgdG9vIHBlcm1pc3Np dmUgZm9yIG15IHRhc3Rlcy4gIFdlIG5lZWQgdG8gYmUNCj4gPiA+PiBhYmxlIHRvIHNheSB0aGF0 IFVMQStJUHY2IE5BVCBpcyBOT1QgUkVDT01NRU5ERUQgYnkgdGhlIElFVEYuDQo+ID4gPg0KPiA+ ID4gSSBoYXZlIHN0cm9uZyBzeW1wYXRoeSB3aXRoIHRoYXQgc3RhdGVtZW50LCBidXQgSSBkb24n dCB0aGluayB0aGlzIGlzIHRoZSBkb2N1bWVudCB0byBkbyBpdDsgdGhlIHBvaW50IGlzIG1hZGUg aW4gUkZDNDg2NCB0b28uIFdoYXQgd2Ugc2hvdWxkIGRvIGhlcmUgaXMgdW5kZXJsaW5lIHRoYXQg TkFUICE9IHNlY3VyaXR5Lg0KPiA+ID4NCj4gPiA+IFdoaWxlIEknbSBoZXJlLCBzb21lIG90aGVy IHBvaW50czoNCj4gPiA+DQo+ID4gPiAiMi4yLiAgRXh0ZW5zaW9uIEhlYWRlcnMNCj4gPiA+DQo+ ID4gPiAgICBUQkQsIGEgc2hvcnQgc2VjdGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5hbmRvJ3Mg SS1EICYgUkZDLiINCj4gPiA+DQo+ID4gPiBUaGF0J3Mgbm90IHRoZSB3aG9sZSBzdG9yeSA7LSku IEZpcnN0bHksIFJGQyA3MDQ1IGhhcyBhIGxvdCBvZg0KPiA+ID4gcmVsZXZhbmNlIHRvIHNlY3Vy aXR5IGFzcGVjdHMuIFNlY29uZCwgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHJlZmVyIHRvDQo+ID4g PiBtb3N0IG9mIHRoZSBtYXRlcmlhbCAoRmVybmFuZG8ncyBvciBub3QpIHVubGVzcyBpdCdzIGRp cmVjdGx5IHJlbGV2YW50DQo+ID4gPiB0byBvcHNlYy4gSSB0aGluayB0aGUgcmVmZXJlbmNlIGlz IGRyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmcsDQo+ID4gPiBidXQgb25seSBpZiB0 aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLg0KPiA+ID4NCj4gPiA+ICIyLjMuMy4gIE5E L1JBIFJhdGUgTGltaXRpbmcNCj4gPiA+IC4uLg0KPiA+ID4gICAgVGhlIGZvbGxvd2luZyBkcmFm dHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0bw0KPiA+ID4gICAgcmF0ZSBsaW1p dCBSQXMgYW5kIG90aGVyIE5EIG1lc3NhZ2VzIG9uIHdpZmkgbmV0d29ya3MgaW4gb3JkZXIgdG8N Cj4gPiA+ICAgIGFkZHJlc3MgdGhpcyBpc3N1ZToNCj4gPiA+DQo+ID4gPiAgICBvICBbSS1ELnRo dWJlcnQtc2F2aS1yYS10aHJvdHRsZXJdDQo+ID4gPg0KPiA+ID4gICAgbyAgW0ktRC5jaGFrcmFi YXJ0aS1ub3JkbWFyay02bWFuLWVmZmljaWVudC1uZF0iDQo+ID4gPg0KPiA+ID4gTmVpdGhlciBv ZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEyIGFuZCAyMDE1 IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRoZSByZWFkZXIs IElNSE8uDQo+ID4gPg0KPiA+ID4gIjQuMi4gIFRyYW5zaXRpb24gTWVjaGFuaXNtDQo+ID4gPg0K PiA+ID4gICAgU1Agd2lsbCB0eXBpY2FsbHkgdXNlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBzdWNo IGFzIDZyZCwgNlBFLCBNQVAsDQo+ID4gPiAgICBEUy1MaXRlIHdoaWNoIGhhdmUgYmVlbiBhbmFs eXplZCBpbiB0aGUgdHJhbnNpdGlvbiBTZWN0aW9uIDIuNy4yDQo+ID4gPiAgICBzZWN0aW9uLiIN Cj4gPiA+DQo+ID4gPiBTaG91bGRuJ3QgeW91IGFkZCBSRkM2ODc3IDQ2NFhMQVQgbm93Pw0KPiA+ ID4NCj4gPiA+IEZpbmFsbHksIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgUHJpdmFjeSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KPiA+ID4NCj4gPiA+IFJnZHMNCj4gPiA+ICAgICBCcmlhbg0K PiA+ID4NCj4gPiA+Pg0KPiA+ID4+IFNlY3Rpb24gMi42LjEuNSBjb3VsZCBwdW5jaCB1cCB0aGUg U0FWSSBzdHVmZiBhIGJpdCBtb3JlIGFzIHdlbGwuICBXZQ0KPiA+ID4+IHNob3VsZCwgaW4gbXkg b3BpbmlvbiwgbWFrZSBpdCBwYWluZnVsbHkgY2xlYXIgdGhhdCBESENQIChvZiBhbnkNCj4gPiA+ PiBwcm90b2NvbCkgaW4gdGhlIGFic2VuY2Ugb2YgbGluay1sYXllciBzZWN1cml0eS9hdWRpdGFi aWxpdHkgZmVhdHVyZXMNCj4gPiA+PiBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkg d2F5ICJ0byBlbnN1cmUgYXVkaWJpbGl0eSBhbmQNCj4gPiA+PiB0cmFjZWFiaWxpdHkiIFtTZWN0 aW9uIDIuMS42XS4NCj4gPiA+Pg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gPj4gdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiA+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPiA+Pg0KPiA+ID4NCj4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPUFNFQyBt YWlsaW5nIGxpc3QNCj4gPiA+IE9QU0VDQGlldGYub3JnPG1haWx0bzpPUFNFQ0BpZXRmLm9yZz4N Cj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiA+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg== --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBhbSBzb3JyeSwgSSBzdXJyZW5kZXIgdGhlIE91dGxvb2sgb24gdGhlIHRoaXJk IGluZGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWls LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgMjoyMSBBTTxi cj4NCjxiPlRvOjwvYj4gTWFyY28gRXJtaW5pPGJyPg0KPGI+Q2M6PC9iPiBFcmljIFZ5bmNrZSAo ZXZ5bmNrZSk7IGRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmc7IEVyaWsgS2xpbmU7IHY2b3Bz QGlldGYub3JnOyBvcHNlY0BpZXRmLm9yZzsgbGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTsgZmdv bnRAc2k2bmV0d29ya3MuY29tOyBCcmlhbiBFIENhcnBlbnRlcjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3Y2b3BzXSBbT1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v cHNlYy12Ni0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KT24gMTcgSnVuIDIwMTYgMDA6MTUsICZxdW90 O01hcmNvIEVybWluaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmNvLkVybWluaUByZXNt ZWQuY29tIj5NYXJjby5Fcm1pbmlAcmVzbWVkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7IEknbGwgdHJ5IHRoZSBob3JyaWJsZSBPdXRsb29rIHRvIHJlcGx5IHVzaW5nIHRl eHQsIHBsZWFzZSBiZWcgbXkgcGFyZG9uIGlmIHRoaXMgaXMgbm90IGZvcm1hdHRlZCBwcm9wZXJs eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAyOjE3IFBN LCBNYXJrIFNtaXRoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5j b20iPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+XSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7 IEhpLDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE5BVCBjYW4gYmUgc3Rp bGwgbmVjZXNzYXJ5IGluIElQdjYgaW4gZHVhbC1zdGFjayBzY2VuYXJpbywgZm9yIGluc3RhbmNl LCB3aGVyZSBldmVyeSBob3N0IGlzIGFzc2lnbmVkIGJvdGggYSBJUHY0IGFuZCBJUHY2IGFkZHJl c3NlcyBhbmQgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDR04gZXF1aXBtZW50IGNhbid0IGhhbmRs ZSB0aGVtIGRpZmZlcmVudGx5LiZuYnNwOzxicj4NCiZndDsgJmd0O0NhbiB5b3UgcHJvdmlkZSBh biBleGFtcGxlIG9mIHRoaXMgc29ydCBvZiBDR04gZGV2aWNlLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgd291bGQgcHJlZmVyIG5vdCB0byBtYWtlIG5hbWVzLCBidXQgeW91IHdvdWxkIGJlIHVucGxl YXNhbnRseSBzdXJwcmlzZWQuPG86cD48L286cD48L3A+DQo8cD5JJ20gc2NlcHRpY2FsLCBJIGFu ZCBJIHRoaW5rIG90aGVycyB3b3VsZCB3YW50IGEgY29uY3JldGUgZXhhbXBsZS4gPG86cD48L286 cD48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W01hcmNvIEVybWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gc29ycnks IEkgYW0gbm90IGF1dGhvcmlzZWQgdG8gZG8gdGhhdCBwdWJsaWNhbGx5LiZuYnNwOyBCdXQgdGhp cyBpcyBub3QgbmVjZXNzYXJ5IGFueXdheS4mbmJzcDsgVGhlcmUgaXMgbm8gbmVlZCB0byBsaXN0 IGV2ZXJ5dGhpbmcgdGhhdCB3b3JrcyB3cm9uZywgdG8gZGVmaW5lIHdoYXQgdGhlIGNvcnJlY3QN CiBiZWhhdmlvdXIgc2hvdWxkIGJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+ SWYgcGVvcGxlIGFyZW4ndCBpbXBsZW1lbnRpbmcgc3BlY2lmaWNhdGlvbnMgd2VsbCwgd2UgbmVl ZCB0byBrbm93LCBzbyB0aGF0IGlmIG5lY2Vzc2FyeSB0aGUgc3BlY2lmaWNhdGlvbnMgY2FuIGJl IGltcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGlzIGlzIHdoeSB3ZSBoYXZlIGRyYWZ0LWdvbnQtb3BzZWMtaXB2Ni1maXJld2Fs bC1yZXFzLTAzLnR4dC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+ Jm5ic3A7IEFueXdheSwgaXQgaXMgYWxzbyBub3QganVzdCBhIG1hdHRlciBvZiBub3QgYmVpbmcg YWJsZSB0byBjb25maWd1cmUgdGhlbSBpbiBhIGNlcnRhaW4gd2F5ICh3aGljaCBpcyBwb3NzaWJs eSB0aGUgY2FzZSksIGJ1dCBhbHNvIHRoZSBjYXNlIGluIHdoaWNoIHRoZXkgZG9uJ3Qgd29yayBw cm9wZXJseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElQdjQgYW5kIElQdjYgaGF2ZSB0byBi ZSBoYW5kbGVkIGRpZmZlcmVudGx5IGJlY2F1c2UgdGhleSdyZSBkaWZmZXJlbnQgcHJvdG9jb2xz LCByZXF1aXJpbmcgZGlmZmVyZW50IGNvZGUuIEEgc2luZ2xlIGRldmljZSBtaWdodCBiZTxicj4N CiZndDsgJmd0OyBwZXJmb3JtaW5nIE5BVCBvbiBJUHY0IHRyYWZmaWMgaXQgcmVjZWl2ZXMgYW5k IGRvaW5nIHN0YW5kYXJkIHN0YXRlbGVzcyBmb3J3YXJkaW5nIG9mIElQdjYgdHJhZmZpYy4gSXMg dGhhdCB0aGUgc2NlbmFyaW8geW91J3JlIGRlc2NyaWJpbmc/PGJyPg0KJmd0Ozxicj4NCiZndDsg WWVzLCBmb3IgaW5zdGFuY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PSywgc28gJnF1b3Q7 Q0dOJnF1b3Q7IGlzIG5vdCBiZWluZyBwZXJmb3JtZWQgb24gSVB2NiB0cmFmZmljLjxvOnA+PC9v OnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3J0IG9mIENH IGVxdWlwbWVudCB3aWxsIGJlIGFueXdheSBpbiB0aGUgd2F5IGFsc28gZm9yIGR1YWwtc3RhY2sg cmVzaWRlbnRpYWwgY29ubmVjdGlvbnMsIGFuZCBDR04gaXMgc3RpbGwgdXNlZCBvbiBwdXJlIElQ djYgaW1wbGVtZW50YXRpb25zIGFzIHlvdSBuZWVkIHRvIG9mZmVyIGNvbm5lY3Rpdml0eQ0KIHRv IElQdjQtb25seSBob3N0cy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPiZndDtP ciwgdGhleSBoYW5kbGUgY2VydGFpbiBmdW5jdGlvbnMgKGUuZy4gTkFUKSBwdXJlbHkgaW4gdGhl IGRhdGEgcGxhbmUgYXMgdGhleSBhcmUgbG9naWNhbGx5IHNpbXBsZSB0byBiZSBpbXBsZW1lbnRl ZCBpbiBmaXJtd2FyZSwgd2hpbGUgbW9yZSBjb21wbGV4IGZ1bmN0aW9ucyAobGlrZSBpbXBsZW1l bnRpbmcgVUxBIGFkZHJlc3NlcyB0cmFuc2xhdGlvbikgcmVxdWlyZXMgcm91dGluZSBlbmdpbmVz IHRvIGJlIGludm9sdmVkLCB0aGVyZWZvcmUNCiBpbnZvbHZpbmcgZGlmZmVyZW50IGxhdGVuY3kg Zm9yIGV4ZWN1dGlvbi48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5TbyB0aGlzIHNvdW5k cyBsaWtlIGVxdWlwbWVudCBoZXJlIGFkZGl0aW9uYWwgZmVhdHVyZXMgY2Fubm90IGJlIGltcGxl bWVudGVkIGluIGhhcmR3YXJlLCBzbyBpdCBpcyBpbXBsZW1lbnRlZCBpbiBjb250cm9sIHBsYW5l IHNvZnR3YXJlLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBpcyBhbiBleGFtcGxlIG9mIHdoeSBu b3QgdG8gdXNlIE5BVC4gSXQgaXMgdGVjaG5pY2FsbHkgdmVyeSBjb21wbGV4IGNvbXBhcmVkIHRv IHB1cmUgSVB2NCBhbmQgcHVyZSBJUHY2IGZvcndhcmRpbmcuPG86cD48L286cD48L3A+DQo8cD48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVy bWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG8gYWdyZWUgd2l0aCB5b3UuPC9z cGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPkknbSBzdGFydGluZyB0byB3b25kZXIgaWYgcGVvcGxl IHRoaW5rIHRoYXQgaWYgdGhleSB3YW50IHRvIHVzZSBVTEFzIGZvciBzb21lIHJlYXNvbiwgdGhl eSB0aGluayB0aGV5IHRoZW4gbXVzdCBOQVQgdGhlbS4gSWYgdGhleSBkbywgSSB0aGluayB0aGF0 IG1pZ2h0IHNob3cgYSBtaXN1bmRlcnN0YW5kaW5nIG9mIHNvbWV0aGluZyBmdW5kYW1lbnRhbCBh Ym91dCBJUHY2IC0gYSBob3N0IG5hdGl2ZWx5IHN1cHBvcnRzIG11bHRpcGxlIGNvbmN1cnJlbnQN CiBhZGRyZXNzZXMgd2l0aCBkaWZmZXJlbnQgc2NvcGVzLCBhbmQgdHJpZXMgdG8gY2hvb3NlIG9u ZSBvZiBpdHMgc291cmNlIGFkZHJlc3MgdG8gbWF0Y2ggdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3Mu PG86cD48L286cD48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg Y2FuIHJlYWxseSBzZWUgeW91ciBwb2ludCBoZXJlLiZuYnNwOyBJdCBtYXkgd2VsbCBiZSB0aGF0 IOKAnHBlb3BsZeKAnSBjYW4gbWlzdW5kZXJzdGFuZCBJUHY2LiZuYnNwOyBEZXNwaXRlIGl0cyBl eGlzdGVuY2Ugc2luY2UgYSBkZWNhZGUsIGl0IGlzIG5vdCB3aWRlbHkgYWRvcHRlZCBvdXRzaWRl IG9mIGNlcnRhaW4NCiBBc2lhbiBjb3VudHJpZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cD4mZ3Q7IEl0IGlzIHByZXR0eSBjb21tb24gdGhhdCBjdXN0b21lcnMgd2l0aCBJU1Bz IG9mZmVyaW5nIGR1YWwgc3RhY2ssIHRvIGV4cGVyaWVuY2UgYSBoaWdoZXIgbGF0ZW5jeSBmb3Ig dGhlaXIgY29ubmVjdGlvbiBvbmNlIHRoZXkgaW1wbGVtZW50IElQdjYgYWxvbmcgd2l0aCBJUHY0 LiZuYnNwOyAmbmJzcDtUaGlzIGRvZXMgbm90IGFwcGx5IHdoZW4gb25seSBJUHY0IG9yIG9ubHkg SVB2NiBhcmUgdXNlZC48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5JJ2QgbGlrZSBzb21l IGV4YW1wbGVzIG9mIHRoaXMuPG86cD48L286cD48L3A+DQo8cD5JJ3ZlIGJlZW4gbmF0aXZlbHkg ZHVhbCBzdGFja2VkIGF0IGhvbWUgZm9yIHRoZSBwYXN0IG5lYXIgNSB5ZWFycy4gSSBoYXZlIG5v dCBleHBlcmllbmNlZCBhZGRpdGlvbmFsIGFuZCBub3RpY2VhYmxlIGhpZ2hlciBsYXRlbmN5IGZv ciBhbnl0aGluZyBJIGRvLiBJdCBqdXN0IHdvcmtzLCBhbmQgSSBjYW4ndCB0ZWxsIHdoYXQgaXMg Z29pbmcgb3ZlciBJUHY0IG9yIElQdjYgLSBhbmQgSSBrbm93IHRoYXQgbW9zdCBpZiBub3QgYWxs IEdvb2dsZSwNCiBGYWNlYm9vayBhbmQgTmV0ZmxpeCB0cmFmZmljIGNhbiBhbmQgZG9lcyBjb21l IG92ZXIgSVB2Ni48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+WW91IGFyZSBsdWNreS4mbmJzcDsgQWdhaW4sIEkgY2Fubm90IG1ha2UgbmFtZXMs IGJ1dCB5b3UgYXJlIG15IGd1ZXN0IGlmIHlvdSBjb21lIG5lYXIgTXVuaWNoIHNvbWV0aW1lcywg YW5kIEnigJlsbCBzaG93IHlvdSB0aGUgdHlwaWNhbCBFdXJvcGVhbiBkdWFsIHN0YWNrIGltcGxl bWVudGF0aW9uLg0KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPkw8L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+SSBhbHNvIHdvcmtlZCBpbiB0aGUgcmVzaWRlbnRpYWwgZGVwbG95bWVu dCBvZiBJUHY2IGF0IHRoZSBvdGhlciBlbmQgb2YgbXkgY29ubmVjdGlvbiBpbiAyMDA5LzIwMTAs IGFuZCB3ZSBuZXZlciByZWNlaXZlZCBhbnkgSVB2NiBsYXRlbmN5IGNvbXBsYWludHMuIEluIDIw MTIgaXQgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBmb3IgbmV3IGN1c3RvbWVyIGNvbm5lY3Rpb25z LjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGVyZSBhcmUgSVNQcyBpbiBHZXJtYW55IHdoaWNoIG9mZmVyIGJ5IGRlZmF1bHQgSVB2NiwgYW5k IHJlcXVpcmVzIHRvIHBheSBhZGRpdGlvbmFsIGZlZXMgaWYgeW91IHdhbnQgSVB2NCAod2hpY2gg aXMgc29tZXRpbWVzIG5lY2Vzc2FyeSBpZiB5b3VyIGNvbXBhbnkgb25seSBpbXBsZW1lbnRzDQog SVB2NCBhbmQgeW91IG5lZWQgdG8gVlBOIGluLCBhcyBDR04gZnJvbSBJUHY2IHRvIElQdjQgYnJl YWtzIG1vc3QgVlBOIHBsYXRmb3JtcykuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZl ciwgdGhlIEV1cm9wZWFuIG9wZXJhdG9ycyBvZmZlcmluZyBkdWFsIHN0YWNrIGFsbCBzdWZmZXJz IGZyb20gbGF0ZW5jeSBpc3N1ZXMuJm5ic3A7IEl0IGNhbiBhbHNvIGJlIHBhcnRpYWxseSBkdWUg dG8gdGhlIGNsaWVudCBvcGVyYXRpdmUgc3lzdGVtIGFuZCBob3cgaXQgZGV0ZWN0cyB3aGljaA0K IGlzIHRoZSBiZXN0IHBhdGggdG8gdXNlIGZvciBob3N0cyB0aGF0IG9mZmVyIGJvdGggY29ubmVj dGl2aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+SSBoYXZlIGNvbWUgYWNy b3NzIHByZXNlbnRhdGlvbnMgb3ZlciB0aGUgcGFzdCB5ZWFycyB0aGF0IGhhdmUgc2hvd24gdGhh dCBJUHY2IGhhcyByZWR1Y2VkIGxhdGVuY3kgZm9yIGR1YWwgc3RhY2sgc2VydmljZXMsIGJlY2F1 c2UgdGhlIElQdjYgcGF0aCB3YXMgZGlmZmVyZW50IGFuZCBzaW1wbGVyIHRoYW4gdGhlIElQdjQg cGF0aC48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QWdhaW4sIHRoYXQgaXMgaW4gdGhlIGlkZWFsIHdvcmxkLCBidXQgaXQgaXMgbm90IG15IGV4 cGVyaWVuY2Ugd2l0aCBkaWZmZXJlbnQgRXVyb3BlYW4gcmVzaWRlbnRpYWwgc2VydmljZSBwcm92 aWRlcnMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SVB2NiBzaG91bGQgaGF2ZSBiZWVuIHRo ZSB1bHRpbWF0ZSBzb2x1dGlvbiB0byBtYW55IGlzc3VlcywgYnV0IGFwcGFyZW50bHkgaXQgaGFz IG5vdCBiZWVuIHRoYXQgc2lsdmVyIGJ1bGxldCB0aGF0IGV2ZXJ5b25lIHdhcyBob3BpbmcgZm9y Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7IEFub3RoZXIgcmVxdWlyZW1lbnQgaXMg dGhhdCBhIHNwZWNpZmljIGxvZ2dpbmcgb3IgbW9uaXRvcmluZyBzeXN0ZW0gaXMgaW1wbGVtZW50 ZWQgKGVzcGVjaWFsbHkgZm9yIGxlZ2FsIHJlcXVpcmVtZW50cyksIGFuZCB0aGlzIGlzIGRvbmUg dGhyb3VnaCBsb2dnaW5nIE5BVCB0cmFuc2xhdGlvbnMuJm5ic3A7IEFuIElTUCBpbXBsZW1lbnRp bmcgSVB2NiBhbG9uZyB3aXRoIElQdjQgd291bGQgYmUgaW4gdGhhdCBzaXR1YXRpb24uPGJyPg0K Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+Tm8gbmVlZCB0byBkbyBfYWRkcmVzcyB0cmFuc2xhdGlv bl8gdG8gYmUgYWJsZSB0byBwZXJmb3JtIHRoYXQuPG86cD48L286cD48L3A+DQo8cD48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgaWYgeW91IGhhdmUgdGhlIHBv c3NpYmlsaXR5LCB5b3UgY2FuIGFsd2F5cyBkbyB0aGluZ3MgZGlmZmVyZW50bHkgYW5kIGJldHRl ci48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPiZndDsgTHVja2lseSwgcm91dGVy IHZlbmRvcnMgYXJlIG1vdmluZyBhd2F5IGZyb20gdGhlIGFudGlxdWF0ZSBhcmNoaXRlY3R1cmUg d2hpY2ggc2VwYXJhdGVzIGRhdGEgYW5kIG1hbmFnZW1lbnQgcGxhbmUsIGZvciB2YXJpb3VzIHJl YXNvbnMuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+QWN0dWFsbHksIHRoYXQncyBnb2lu ZyB0byBpbmNyZWFzZSB0aGUgY29zdCBvZiBlcXVpcG1lbnQsIGJlY2F1c2UgaXQgaXNuJ3QgZ29p bmcgdG8gYmUgY2hlYXAgdG8gZG8gc29tZXRoaW5nIGNvbXBsZXggZmFzdC48bzpwPjwvbzpwPjwv cD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b TWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXUgY29udHJhaXJlLCBm b3IgZXF1aXBtZW50IHZlbmRvcnMsIG1vdmluZyBmcm9tIGhhdmluZyBoYXJkd2FyZSBhbmQgZGlm ZmVyZW50IHBsYW5lcyB0byBtYW5hZ2UsIHRvIGEgc29mdHdhcmUtb25seSB2ZXJzaW9uIHdoaWNo IGNhbiBiZSBzaGlwcGVkIGFzIGJvdGggaGFyZHdhcmUgYW5kIHZpcnR1YWwNCiBpbWFnZSwgbWVh bnMgbm90YWJsZSByZWR1Y3Rpb24gb2YgY29zdHMgaW4gdGVybXMgb2YgZGV2ZWxvcG1lbnQsIHN1 cHBvcnQsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgb2YgY291cnNlIEkgY29u Y2VkZSB0aGVyZSBtYXkgYmUgZGlmZmVyZW5jZXMgY2FzZSBieSBjYXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPiZndDsgVGhpcyBpcyBhbHNvIHdoeSB3ZSBwdWJsaXNo ZWQgZHJhZnQtZ29udC1vcHNlYy1pcHY2LWZpcmV3YWxsLXJlcXMtMDMudHh0LCB0byBtYWtlIGl0 IGV4cGxpY2l0IHRoYXQgdGhpcyBzaG91bGQgbm90IGhhcHBlbi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAoSSBhbSBhd2FyZSB0aGlzIGlzIG9mZi10b3BpYywganVzdCBtYWtpbmcgbXkgcG9pbnQgOi0p KTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7VW5mb3J0dW5hdGVseSBSRkMgNDg2NCBkb2Vz IG5vdCBtZW50aW9uIHN1Y2ggY2FzZSwgQUZBSUsuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyBJbiBhbnkgY2FzZSwgSSBhbSBoYXBweSB0byBjb25jZWRlIGl0IGNvdWxkIGJlIGFu IGV4dHJlbWUgY2FzZSBhbmQgdGhhdCBpdCBpcyBub3QgbmVjZXNzYXJ5IGFueW1vcmUgaW4gSVB2 NiBmb3IgdGhlIGdyZWF0IG1ham9yaXR5IG9mIHVzZTxicj4NCiZndDsgJmd0OyBjYXNlcy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPa2F5PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSSB3YXMg bm90IHJlYWxseSBtYWtpbmcgYSBzcGVjaWZpYyBjYXNlIGZvciBJUHY2IC0gbXkgb3Bwb3NpdGlv biB3YXMgdG8gdGhlIGNvbmNlcHQgdGhhdCBOQVQgaXMgbm90IHNlY3VyaXR5LCBhbmQgdG8gdGhl IGZhY3QgdGhhdCBpdCBzaG91bGQgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdyaXR0ZW4gYXMgc3Vj aCBpbiB0aGUgUkZDLjxicj4NCiZndDsgJmd0OyBTbyB0aGlzIGRyYWZ0IGlzIHB1cmVseSBhYm91 dCBJUHY2LiBUaGVyZSB3aWxsIGJlIGEgbG90IG9mIElQdjQgc2VjdXJpdHkgbWVhc3VyZXMgdGhh dCBjYW4gYmUgYXBwbGllZCB0byBJUHY2LCBob3dldmVyIHRoZXJlIHdpbGwgYWxzbyBiZSBvdGhl cnM8YnI+DQomZ3Q7ICZndDsgdGhhdCBzaG91bGRuJ3QsIGFuZCBvcHBvcnR1bml0aWVzIHdoZXJl IElQdjYgY2FuIHByb3ZpZGUgYmV0dGVyIHNlY3VyaXR5IHRoYXQgSVB2NCAoZS5nLiBzcGFyc2Ug aG9zdCBhZGRyZXNzaW5nIGluIGEgLzY0IG1ha2VzIGFkZHJlc3MgcHJvYmluZzxicj4NCiZndDsg Jmd0OyB0byBkaXNjb3ZlciBob3N0cyBpbXBvc3NpYmxlIHdpdGhpbiBhIHVzZWZ1bCBhbmQgcHJh Y3RpY2FsIHRpbWVmcmFtZS4pLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9rYXksIEkgaGF2ZSBub3Ro aW5nIHRvIG9iamVjdCBvbiB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBOQVQgKmRvZXMqIHByb3ZpZGUgYSBmb3JtIG9mIHNlY3VyaXR5PGJyPg0KJmd0OyAmZ3Q7 V2hhdCBzcGVjaWZpYyBzZWN1cml0eSBkb2VzIGl0IHByb3ZpZGUgdGhhdCBpcyBkdWUgdG8gdGhl IGFkZHJlc3MgdHJhbnNsYXRpb24gZnVuY3Rpb24/PGJyPg0KJmd0OyAmZ3Q7IElmIHlvdSdyZSB0 aGlua2luZyBhYm91dCB0aGUgcHJvdGVjdGlvbiBwcm92aWRlZCBkdWUgdG8gdGhlIHN0YXRlIGJl aW5nIGNyZWF0ZWQgZHVyaW5nIHRoZSBhZGRyZXNzIHRyYW5zbGF0aW9uIHByb2Nlc3MsIHRoYXQg c3RhdGUgY2FuIGJlPGJyPg0KJmd0OyAmZ3Q7IGNyZWF0ZWQgd2l0aG91dCBwZXJmb3JtaW5nIGFk ZHJlc3MgdHJhbnNsYXRpb24sIHdoaWNoIGlzIHdoYXQgYSBzdGF0ZWZ1bCBmaXJld2FsbCBkb2Vz IGFuZCBkaWQgaW4gSVB2NCBiZWZvcmUgTkFUIGJlY2FtZSB3aWRlbHkgZGVwbG95ZWQuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSSB0b3RhbGx5IGFncmVlIHdpdGggeW91LiZuYnNwOyBJIGFtIGFjdHVh bGx5IHJlZmVycmluZyB0byB0aGUgcG9zc2liaWxpdHkgdG8gaGlkZSB0aGUgc3lzdGVtcyBiZWhp bmQgdGhlIE5BVHRlZCBpbnRlcmZhY2VzIG9mIHRoZSByb3V0ZXIvZmlyZXdhbGwsIG5vdCBqdXN0 IHRoZWlyIGFkZHJlc3NlcyBidXQgYWxzbyBwb3J0cyBhbmQgc2VydmljZXMuJm5ic3A7IElmIHlv dSBvbmx5IGFwcGx5IGZpbHRlcmluZywgeW91IGFyZSBwcm90ZWN0aW5nIC0gYnV0IG5vdA0KIGhp ZGluZy48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8cD5OQVQgaXMgbm8gd2hlcmUgbmVhciBh cyBlZmZlY3RpdmUgYXQgaGlkaW5nIHN5c3RlbXMgYXMgcGVvcGxlIHRoaW5rLiBUb28gbWFueSBh dHRyaWJ1dGVzIG9mIHRoZSBzeXN0ZW0gYmVoaW5kIHRoZSBOQVQgbGVhayBhY3Jvc3MgTkFULCBv ciBjYW4gYmUgZm9yY2VkIHRvIGxlYWsgYWNyb3NzIHRoZSBOQVQuPG86cD48L286cD48L3A+DQo8 cD5JdCBpcyBxdWl0ZSBhIHBvcm91cyBiYXJyaWVyLCBiZWNhdXNlIE5BVCBpcyBub3QgYWN0dWFs bHkgZGVzaWduZWQgdG8gaGlkZSBzeXN0ZW1zLiBBZGRyZXNzIHRyYW5zbGF0aW9uIGluaGVyZW50 bHkgaGlkZXMgc29tZSBvZiB0aGUgYXR0cmlidXRlcyBvZiB0aGUgc3lzdGVtcyAoYWRkcmVzc2Vz KSBidXQgbm90IGFsbCBvZiB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Nb3N0IG9mIHRoZSBOQVQgdnVsbmVyYWJpbGl0aWVzIGNvbWUg ZnJvbSBob21lIHJvdXRlcnMsIHdpdGggdGhlaXIgUG5QIGFuZCBvdGhlciBwcm90b2NvbHMgd2hp Y2ggYXJlIG9mdGVuIGJhZGx5IGltcGxlbWVudGVkLCBhcyB3ZWxsIGFzIHByb3RvY29scyB0aGF0 IGRvIG5vdCBuZWNlc3NhcmlseQ0KIHBsYXkgd2VsbCB3aXRoIE5BVC4mbmJzcDsgSWYgaXQganVz dCBoaWRlcyBJUHMgYW5kIHBvcnRzLCB0aGF0IGlzIGFscmVhZHkgZG9pbmcgc29tZXRoaW5nLjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBkbyBub3QgZ2V0IG1lIHdyb25nLiZuYnNw OyBJIGFtIGFzIG11Y2ggYXMgYW55b25lIGVsc2UgaG9waW5nIHRvIHNlZSB0aGUgZGF5IHRoYXQg TkFUIGlzIHJlbGVnYXRlZCBpbnRvIHRoZSBwbGFjZSBpbiBoaXN0b3J5IHdoZXJlIGl0IHNob3Vs ZCBiZS4mbmJzcDsgQW5kIEkgYW0gKHVuZm9ydHVuYXRlbHkpDQogd2VsbCBhd2FyZSB0aGF0IGFs bCBwcm90b2NvbHMgd2hpY2ggbmVnb3RpYXRlIGFuIGhpZ2ggcG9ydCB0aHJvdWdoIGFuIGVuY3J5 cHRlZCBjaGFubmVsIChGVFAtUywgb3IgY2VydGFpbiB2ZXJzaW9ucyBvZiBNaWNyb3NvZnQgQ29t bXVuaWNhdG9yL0x5bmMsIGNlcnRhaW4gVlBOLCBldGMuKSB3aWxsIG5ldmVyIHdvcmsgd2l0aCBh bnkgTkFUIChJIGVuc3VyZSB5b3UgSSBoYXZlIGxpdmVkIHRoYXQgb24gbXkgc2tpbikuPG86cD48 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXQgdGhlIHNhbWUgdGltZSwgSSBjYW5ub3QgbmVnbGVjdCB0 aGF0IHByYWN0aWNhbGx5IHNwZWFraW5nLCBteSBleHBlcmllbmNlIHdpdGggQ0dOIHdpdGggSVB2 NCBpbiB0ZWxjb3MgaXMgdGhhdCBpdCBpcyBxdWl0ZSBlZmZlY3RpdmUuJm5ic3A7IEZpcmV3YWxs IHZlbmRvcnMgaGF2ZSBzcGVudCBhIGRlY2FkZQ0KIGZpeGluZyBpdCBhbmQgaW1wbGVtZW50aW5n IGV2ZXJ5IHNvcnQgb2YgdmFyaWFudCBzdWNoIGFzIE5BVC1ULCBOQVQtUE1QLCBOQVQgZm9yIFJQ QywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+Jmd0OyBJbiBhIHBlcmZl Y3Qgd29ybGQsIHlvdSBoYXZlIHN1Y2ggZ29vZCBmaWx0ZXJzIHRoYXQgeW91IGNhbiB0cmFuc3Bh cmVudGx5IHByb3ZpZGUgdGhlIHJlYWwgYWRkcmVzc2VzIGFuZCBwb3J0cyBmcm9tIGNsaWVudHMg dG8gdGhlIHJlc3Qgb2YgdGhlIEludGVybmV0DQo8bzpwPjwvbzpwPjwvcD4NCjxwPkl0J3Mgc291 bmRpbmcgbGlrZSB5b3UncmUgbm90IHVwIHRvIGRhdGUgd2l0aCBJUHY2IGZpcmV3YWxsaW5nIGNh cGFiaWxpdGllcyBpbiBkZXZpY2VzLCBhbmQgdGhlcmVmb3JlIG1pZ2h0IGJlIGFzc3VtaW5nIHRo YXQgbm9uZSBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwPkFyZSB5b3UgYXdhcmUgZm9yIGV4YW1w bGUgdGhhdCBXaW5kb3dzIGhhcyBoYWQgYSBzdGF0ZWZ1bCBJUHY2IGZpcmV3YWxsLCBlbmFibGVk IGJ5IGRlZmF1bHQsIHNpbmNlIFdpbmRvd3MgWFAgc2VydmljZSBwYWNrIDIsIHJlbGVhc2VkIG1v cmUgdGhhbiBhIGRlY2FkZSBhZ28/PG86cD48L286cD48L3A+DQo8cD5JJ3ZlIGJlZW4gdXNpbmcg SVB2NiB1bmRlciBMaW51eCB0byBhY2Nlc3MgdGhlIEludGVybmV0IGVpdGhlciB2aWEgdHVubmVs cyBvciBuYXRpdmVseSBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlLCB1c2luZyB0aGUgc3RhdGVmdWwg SVB2NiBmaXJld2FsbCB0aGF0IGhhcyBiZWVuIHBhcnQgb2YgdGhlIExpbnV4IGtlcm5lbCBmb3Ig YXQgbGVhc3QgdGhhdCBsb25nLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBBbmRyb2lkIHBob25l IGhhcyBuYXRpdmUgYW5kIHB1YmxpYyBJUHY2IGFkZHJlc3NlcyBhbmQgaXMgbm90IGJlaGluZCBh bnkgc29ydCBvZiBJUHY2IE5BVC4gSXQncyBiZWhpbmQgYSBkZXZpY2UgdGhhdCBjYW4gcGVyZm9y bSBJUHY2IHN0YXRlZnVsIGZpcmV3YWxsaW5nLCBob3dldmVyIEkgdGhpbmsgSSd2ZSB0dXJuZWQg aXQgb2ZmLCBiZWNhdXNlIEkgdHJ1c3QgdGhhdCBhcyBHb29nbGUgY2FuJ3QgdHJ1c3QgdGhlcmUg aXMgYSBuZXR3b3JrDQogZmlyZXdhbGwgdXBzdHJlYW0gb2YgbXkgcGhvbmUsIHRoZXkgZW5zdXJl IG15IHBob25lIGlzICZxdW90O0ludGVybmV0IHByb29mJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0K PHA+VGhlICZxdW90O3BlcmZlY3QmcXVvdDsgd29ybGQgeW91J3JlIHJlZmVycmluZyB0byBpcyBh bmQgaGFzIGJlZW4gcmVhbGl0eSBmb3IgYSBsb25nIHRpbWUgZm9yIGEgbG90IG9mIHBlb3BsZS48 bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBzb3JyeSwgSSBkbyBub3QgdGhpbmsgYnJpbmdpbmcgdGhlIGRpc2N1c3Npb24gb24gYSBwZXJz b25hbCBsZXZlbCBpcyB1c2VmdWwgdG8gdGhlIGRpc2N1c3Npb24uJm5ic3A7IElmIHRoaXMgaXMg aW50ZXJlc3RpbmcsIEkgYW0gYXdhcmUgdGhhdCBXaW5kb3dzIGhhcyBJUHY2IGFuZCBhIGZpcmV3 YWxsLiZuYnNwOw0KIFRoaXMgaXMgbm90IGEgZGVtb25zdHJhdGlvbiB0aGF0IElQdjYgZmlsdGVy cyBhcmUgbmVhciBhcyBnb29kIGFzIElQdjQgb25lcy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PbiByZXNpZGVudGlhbCByb3V0ZXJzLCB0aGUgbXl0aCB0aGF0IElQdjYgd2lsbCBjb21lIGFu ZCBzb2x2ZSBhbGwgb2YgdGhlIE5BVCBwcm9ibGVtcyBpcywgYW5kIGFsbG93IHViaXF1aXRvdXMg YW5kIHNlY3VyZSBhY2Nlc3MgdG8gYWxsIHRoZSBkZXZpY2VzIGlzLCBpbiBmYWN0LCBhIG15dGgu Jm5ic3A7DQogSVB2NiBicmVha3MgcHJvdG9jb2xzIGFzIG11Y2ggKGlmIG5vdCBtb3JlKSB0aGFu IElQdjQgTkFULiZuYnNwOyBUaGUgbW9zdCB1c2VkIHJlc2lkZW50aWFsIHJvdXRlcnMgaW4gR2Vy bWFueSAoYW5kIHByb3VkbHkgR2VybWFuIGVuZ2luZWVyZWQgcHJvZHVjdCkgcmVxdWlyZXMg4oCc YWR2YW5jZWQgdmlld+KAnSBlbmFibGVkIGp1c3QgdG8gZW5hYmxlIGl0OyBpdCBwcm92aWRlcyBV TEFzIHZpYSBESENQdjYsIGFuZCBwZXJmb3JtcyB0cmFuc2xhdGlvbiB0byByb3V0YWJsZQ0KIElQ djYgYWRkcmVzc2VzLiZuYnNwOyBXaGlsZSBJUHY0IE5BVCBuZWVkcyB0byBwZXJmb3JtIHN0YXRl ZnVsIHRyYW5zbGF0aW9uIG9mIElQcyBhbmQgcG9ydHMsIHJlc2lkZW50aWFsIHJvdXRlcnMgb24g SVB2NiBvbmx5IHRyYW5zbGF0ZSBJUHMg4oCTIGJ1dCB0aGF0IGlzIG5vdCBpbXByb3ZpbmcgYSBs b3QuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdG9wIG9mIGl0LCBub3QgdG8gYnJlYWsg Y2VydGFpbiwgbW9yZSBjb21wbGV4IHByb3RvY29scyB0byB3b3JrIChzdWNoIGFzIEJpdFRvcnJl bnQgb2YgRlRQKSwgdGhleSBuZWVkIHRvIGFjdHVhbGx5IHVuZGVyc3RhbmQgdGhlbSBhdCBMYXll ci03IGxldmVsIHRvIG1ha2UgdGhlbSB3b3JrDQogdGhyb3VnaCB0aGUgdHJhbnNsYXRpb24g4oCT IGFuZCBndWVzcyB3aGF0LCBOQVQgaXMgbXVjaCBtb3JlIHRlc3RlZC4mbmJzcDsgTXkgYWN0dWFs IGNvbXBhbnkgaGFzIHRvIHJlcXVpcmUgdGhlaXIgZW1wbG95ZWVzIHRvIHJlcXVlc3QgSVB2NCBp ZiB0aGV5IHdhbnQgdG8gd29yayBmcm9tIGhvbWUgYW5kIGhhdmUgdGhlaXIgc29mdCBwaG9uZSB3 b3JrIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZmFtb3VzIHZlbmRvciBv ZiBwZXJzb25hbCBjb21wdXRlciB3aGljaCBhbHNvIHByb3ZpZGVzIOKAnFRW4oCdIGFuZCDigJxQ aG9uZeKAnSB2ZXJzaW9uIG9mIHRoZWlyIE9TLCB1c2VzIE5BVCB0byBpbXBsZW1lbnQgdGhlaXIg YXBwbGljYXRpb24gZmlsdGVyaW5nLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgdGhlcmUNCiBpcyBu byBsYXllci03IHN0YXRlZnVsIGZpbHRlciB3aXRob3V0IE5BVCAoc28gZmFyKS48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DZXJ0YWluIGZpcmV3YWxsIHZlbmRvcnMgKEkgYW0gc29ycnksIGFn YWluLCBJIGNhbm5vdCBtYWtlIG5hbWVzLCBidXQgdGhleSBjYW4gYmUgZm91bmQgZWFzaWx5KSBj b21lIHdpdGggSVB2NiBkaXNhYmxlZCBhbmQgd2lsbCBzaW1wbHkgKmlnbm9yZSogYW5kICpsZXQg Y29tZSB0aHJvdWdoKg0KIElQdjYgdHJhZmZpYyBhcnJpdmluZyBvbiB0aGVpciBpbnRlcmZhY2Vz ICpieSBkZWZhdWx0Ki4mbmJzcDsgQW5kIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQg4oCccGVyc29u YWwgZmlyZXdhbGxz4oCdLCBidXQgb2YgTkFTREFRLXF1b3RlZCDigJxuZXh0IGdlbmVyYXRpb27i gJ0gZW50ZXJwcmlzZSB2ZW5kb3Igb2YgYXBwbGlhbmNlcyDigJxHYXJ0bmVyIGxlYWRlciBhZ2Fp bi4gQWdhaW4u4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByYWN0aWNhbGx5IHNwZWFr aW5nLCB0byBicmluZyBJUHY2IHRvIGEgc3RhdGUgd2hlcmUgdGhlIGhvc3RzIGFyZSBhcyBzZWN1 cmUgYXMgdGhleSBhcmUgdG9kYXkgb24gSVB2NCBvbiBsb2NhbCBuZXR3b3JrcyBiZWhpbmQgTkFU LCB5b3UgbmVlZCB3ZWxsLXRob3VnaHQgZmlyZXdhbGwgc2V0dXBzLA0KIG11Y2ggYmV0dGVyIGRl ZmF1bHQsIGltcHJvdmVkIHNvZnR3YXJlIHN0YWNrIGFuZCBhcHBsaWNhdGlvbi11bmRlcnN0YW5k aW5nIGxheWVyLTcgZmlsdGVycy4mbmJzcDsgVGhpcyBpcyBub3QgdGhlIGFjdHVhbCBjYXNlIGdl bmVyYWxseSBvbiBJUHY2IG5ldHdvcmtzIGFuZCBOQVQgZG9lcyBwcm92aWRlIGEgcG9vci1tYW4g 4oCcaGFja+KAnSB0byBhdCBsZWFzdCBwcmV2ZW50IGVhc3kgYWNjZXNzIHRvIHlvdXIgbmV0d29y ay1lbmFibGVkIHJlZnJpZ2VyYXRvcg0KIGFuZCBtaWNyb3dhdmUgYXQgaG9tZSBmcm9tIGludHJ1 ZGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwPiZndDstIGhvd2V2ZXIgd2UgZG9uJ3QgbGl2ZSBpbiBzdWNoIHdvcmxk LCB0aGVyZWZvcmUgaGlkaW5nIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2YgcHJvdGVj dGlvbiBpbiB0aGUgJnF1b3Q7ZGVmZW5jZSBpbiBkZXB0aCZxdW90OyBhcHByb2FjaC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgZmFjdCB0aGF0IHRoaXMgJnF1b3Q7aGlkaW5nJnF1b3Q7IGFjdHVh bGx5IGhpbmRlcnMgdGhlIGRlcGxveW1lbnQgb2YgbWFueSBzZXJ2aWNlcyBhbmQgbWFrZXMgbGlm ZSB3b3JzZSB0byBlbmdpbmVlcnMgaW4gbWFueSBjYXNlcywgaXMgYW5vdGhlciB0b3BpYyBvbiB3 aGljaCB3ZSBhZ3JlZSB0b3RhbGx5IDotKTxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBh bHNvIGNhc2VzIHdoZXJlIE5BVCBvZmZlcnMgYmV0dGVyIChvciBhdCBsZWFzdCBzaW1wbGVyKSBw cm90ZWN0aW9uIHRoYW4gZmlsdGVycy4mbmJzcDsgRm9yIGluc3RhbmNlLCB0aGVyZSBhcmUga25v d24gJnF1b3Q7b3ZlcmJpbGxpbmcgYXR0YWNrcyZxdW90OyBwZXJmb3JtZWQgaW4gdGVsY28gbmV0 d29ya3MsIHdoZXJlIG1vYmlsZSB0ZXJtaW5hbHMgYXJlIHNlbnQgd2l0aCBVRFAgcGFja2V0cyB0 byBrZWVwIHRoZW0gYWxpdmUgZXZlbiBpZiB3b3VsZA0KIGFjdHVhbGx5IGRpc2Nvbm5lY3QsIGNh dXNpbmcgdGhlbSB0byBiZSBleGNlc3NpdmVseSBiaWxsZWQuJm5ic3A7IEZpbHRlcnMgZm9yIHRo b3NlIHNpdHVhdGlvbnMgdGVuZCB0byBiZSBjb21wbGljYXRlZCBhbmQgbmVlZCB0byB1bmRlcnN0 YW5kIHRoZSBMYXllci03IHByb3RvY29sIHJ1bm5pbmcgb3ZlciBVRFAgdG8gcHJvdGVjdCB0aGUg dGVybWluYWxzOyBOQVQgb2ZmZXJzIGEgc3RyYWlnaHRmb3J3YXJkIHByb3RlY3Rpb24sIGluc3Rl YWQuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlcmUgaXMgbm8gbmVlZCB0byBwZXJm b3JtIF9hZGRyZXNzIHRyYW5zbGF0aW9uXyB0byBwZXJmb3JtIHRoaXMgcHJvdGVjdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUg aXMgbm8gdGhlb3JldGljYWwgbmVlZCwgYnV0IHRoaXMgaXMgd2hhdCB3b3Jrcy48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPkNvbnRpbnVpbmcgdG8gc2F5IE5BVCBpbiB0aGVzZSBl eGFtcGxlcyBpcyBhIGJpdCBsaWtlIHNheWluZyAmcXVvdDtJIG5lZWQgbXkgdG9vbGJveCB0byBi YW5nIGluIG5haWxzJnF1b3Q7LiBZb3UgbmVlZCB5b3VyIHRvb2xib3ggYmVjYXVzZSB0aGF0IGlz IHdoZXJlIHlvdXIgaGFtbWVyIGlzLCBob3dldmVyIGl0IGlzIGFjdHVhbGx5IHlvdXIgaGFtbWVy IHRoYXQgeW91IHVzZSB0byBiYW5nIGluIG5haWxzLjxvOnA+PC9vOnA+PC9wPg0KPHA+TkFUIGlz IGFkZHJlc3MgdHJhbnNsYXRpb24gJiM0Mzsgc3RhdGVmdWwgZmlsdGVyaW5nIGluaGVyZW50IGlu IHRoZSBvcGVyYXRpb24gb2YgYWRkcmVzcyB0cmFuc2xhdGlvbi4gUGVvcGxlIHdobyBvYmplY3Qg dG8gTkFUIGluIElQdjYgYXJlIG9iamVjdGluZyB0byB0aGUgaW1wbGllZCBhc3NlcnRpb24gdGhh dCBpdCBpcyBuZWNlc3NhcnkgdG8gcGVyZm9ybSBhZGRyZXNzIHRyYW5zbGF0aW9uIHRvIGFjaGll dmUgc3RhdGVmdWwgZmlsdGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+UGVvcGxlIHdobyBhZHZv Y2F0ZSBOQVQgZm9yIElQdjYgZm9yIHNlY3VyaXR5IHB1cnBvc2VzIGRvbid0IHNlZW0gdG8gdW5k ZXJzdGFuZCB0aGF0IGFkZHJlc3MgdHJhbnNsYXRpb24gaXMgKm5vdCogcmVxdWlyZWQgdG8gYmUg YWJsZSB0byBwZXJmb3JtIHN0YXRlZnVsIGZpbHRlcmluZyAtIG9yIHRoZXkncmUgdXNpbmcgdGhl IHRlcm0gJnF1b3Q7TkFUJnF1b3Q7IHdoZW4gdGhleSBzaG91bGQgcmVhbGx5IGJlIHVzaW5nIHRo ZSB0ZXJtICZxdW90O3N0YXRlZnVsIGZpbHRlcmluZyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxw PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWFyY28g RXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSwgYnV0IG5vIG9uZSBp cyBhZHZvY2F0aW5nIGZvciBOQVQg4oCTIG5vdCBtZSwgY2VydGFpbmx5LiZuYnNwOyBBZ2Fpbiwg SSBhbSBzb3JyeSwgYnV0IEkgYmVsaWV2ZSB0aGVyZSBhcmUgcGVvcGxlIHdobyBhcmUgb3Zlci1z ZW5zaWJsZSBhYm91dCB0aGlzIHRvcGljIGFuZCBoYXZlbuKAmXQgZ290DQogbXkgYXJndW1lbnQg cHJvcGVybHkuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cD4mZ3Q7IFBTLiBJIGFtIGF3YXJlIHRoYXQgbWFqb3IgZmlyZXdh bGwgdmVuZG9ycyBpbXBsZW1lbnQgZmlsdGVycyBhZ2FpbnN0IG92ZXJiaWxsaW5nIGF0dGFja3M7 IEkgd2FzIG9ubHkgbWFraW5nIGFuIG9iamVjdGlvbiB0byB0aGUgc2VtYW50aWMgb2YgdGhlIHNl bnRlbmNlOiBOQVQgKnByb3ZpZGVzKiBzZWN1cml0eSwgc2F5aW5nIHRoZSBjb250cmFyeSBpcyBu b3QgY29ycmVjdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90O1NlY3VyaXR5IGFnYWlu c3Qgd2hhdCZxdW90OyBpcyB0aGUga2V5IHF1ZXN0aW9uLiBZb3UgY2FuJ3QgYWN0dWFsbHkgc2F5 IE5BVCBwcm92aWRlcyBzZWN1cml0eSB3aXRob3V0IGRlZmluaW5nIHRoZSB0aHJlYXQgb3IgY29u dGV4dC4gSWYgeW91IGRvbid0IGRlZmluZSB0aGUgdGhyZWF0LCB0aGUgaW1wbGljYXRpb24gb2Yg c3VjaCBhIHN0YXRlbWVudCBpcyB0aGF0IGl0IHByb3ZpZGVzIHNlY3VyaXR5IGFnYWluc3QgbGl0 ZXJhbGx5IGV2ZXJ5IHRocmVhdC48bzpwPjwvbzpwPjwvcD4NCjxwPklmIGEgYmFuayBpbXBsZW1l bnRzIE5BVCBvbiB0aGVpciBkYXRhIG5ldHdvcmssIGFyZSB0aGV5IG5vdyBzZWN1cmVkIGFnYWlu c3QgYmFuayByb2JiZXJzIGNvbWluZyBpbnRvIGEgYnJhbmNoIHdpdGggZ3Vucz8gT2J2aW91c2x5 IG5vdC48bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90O05BVCAqcHJvdmlkZXMqIHNlY3VyaXR5JnF1 b3Q7IGlzIGdvaW5nIHRvIGJlIHdyb25nIGluIG1hbnkgY2FzZXMgYmVjYXVzZSBOQVQgaXMgYW4g ZW50aXJlbHkgaW5lZmZlY3RpdmUgbWVhc3VyZSBmb3IgYSBsYXJnZSBzZXQgb2YgdGhyZWF0cy48 bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBk byBub3QgYmVsaWV2ZSBzby4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgb24gcHJhY3RpY2FsIGltcGxl bWVudGF0aW9uLCBOQVQgaXMgbXVjaCBzYWZlciB0aGFuIHRoZSBjdXJyZW50IElQdjYgZmlsdGVy cy48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD4m Z3Q7IFdoZXRoZXIgdGhpcyBjb3VsZCBiZSBhY2hpZXZlZCBpbiBzb21lIG90aGVyIHdheXMgaXMg YW5vdGhlciBtYXR0ZXIuPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgaXMgdGhlICpl eGFjdCogbWF0dGVyIGhlcmUuPG86cD48L286cD48L3A+DQo8cD5OQVQgaXMgYmVpbmcgYXNzZXJ0 ZWQgYXMgdGhlIHNlY3VyaXR5IG1lYXN1cmUgdGhhdCBzaG91bGQgYnkgdXNlZCBpbiBJUHY2LCBi ZWNhdXNlIGl0IGhhcyBiZWVuIHVzZWQgaW4gSVB2NCAoYW5kIG5vdCBuZWNlc3NhcmlseSBleGNs dXNpdmVseSBiZWNhdXNlIG9mIHNlY3VyaXR5IC0gbGFjayBvZiBJUHY0IGFkZHJlc3NlcyBpcyBh bm90aGVyIHJlYXNvbiksIHdpdGhvdXQgYW55IGNvbnNpZGVyYXRpb24gb2YgaXRzIGRyYXdiYWNr cyBvciBhbHRlcm5hdGl2ZXMNCiB0aGF0IGRvbid0IGhhdmUgdGhvc2UgZHJhd2JhY2tzIGUuZy4g dGhvc2UgZGVzY3JpYmVkIGluIFJGQzQ4NjQuPG86cD48L286cD48L3A+DQo8cD48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01hcmNvIEVybWluaV0NCjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGFzc2VydGluZyB0aGF0IE5BVCBzaG91 bGQgYmUgdXNlZCBpbiBJUHY2IChub3Qgc3VyZSBpZiB0aGlzIGlzIHJlZmVycmVkIHRvIG1lKS48 L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLSB0aGUg ZmFjdCB0aGF0IGl0IGlzIG5vdCBkZXNpcmFibGUgb3IgaXQgaXMgdW5uZWNlc3NhcnkgdG8gdXNl IGlzIGFub3RoZXIgdG9waWMsIGluIHdoaWNoIEkgYmVsaWV2ZSB3ZSBhbGwgYWdyZWUgKGF0IGxl YXN0IGZvciA5OSUgb2YgdXNlIGNhc2VzIDstKSk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSSBkb24ndCBzZWUgYSBuZWVkIHRvIGRlcGxveSBOQVQgd2l0aCBJUHY2IGFzIHdoYXQgaGFz IGJlZW4gYWNoaWV2ZWQgd2l0aCBJUHY0IE5BVCBjYW4gYmUgYWNoaWV2ZWQgaW4gSVB2NiB3aXRo b3V0IHRoZSBkcmF3YmFja3Mgb2YgTkFULjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgbWVhbiB0aGUg c2FtZSBhcyB5b3UgZG8sIEkgd291bGQganVzdCBwaHJhc2UgaXQgYXMgJnF1b3Q7dGhlIHBvb3Ig SVNQcyB3aGljaCBzdGlsbCBkbyB0aGF0LCBzaG91bGQgY29uc2lkZXIgbWlncmF0aW5nIHRoZWly IGFyY2hpdGVjdHVyZSB0byBiZXR0ZXIgb3B0aW9ucyZxdW90Oy48YnI+DQomZ3Q7PG86cD48L286 cD48L3A+DQo8cD5UaGUgY29zdCBvZiBDR04gY2FwYWNpdHkgdG8gTkFUIHZpZGVvIHRyYWZmaWMg dm9sdW1lcyBmcm9tIHBvcHVsYXIgdmlkZW8gc2l0ZXMgaXMgbGlrZWx5IGdvaW5nIHRvIG1ha2Ug ZGVwbG95aW5nIG5hdGl2ZSBJUHY2IGEgY2hlYXBlciBhbHRlcm5hdGl2ZSB2ZXJ5IHF1aWNrbHku DQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5bTWFyY28gRXJtaW5pXQ0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cD48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCmb3IgaXQgaXMgZ29pbmcgdG8gYm91bmNlIGJhY2sgb25jZSB0aGUgdXN1YWwgSVB2NiBwcm9i bGVtcyBhcmlzZSDigJMgc3RpY2tpbmcgcHVyZWx5IHRvIHRoZSBleGFtcGxlIHlvdSBtYWRlLCBz ZWUgcmVjZW50bHkgaG93IE5ldEZsaXggaGFkIHRvIGJsb2NrIGNlcnRhaW4gSVB2NiBhY2Nlc3Nl cw0KIGJlY2F1c2UgaXQgY2Fu4oCZdCBhcHBseSBpdHMgb3JpZ2luIGZpbHRlcnMuPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+UmVnYXJkcyw8YnI+ DQpNYXJrLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltNYXJjbyBFcm1pbmldDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4mZ3Q7PGJyPg0KJmd0OyBS ZWdhcmRzLDxicj4NCiZndDsgTWFyY288YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7UmVnYXJkcyw8YnI+DQomZ3Q7ICZndDtNYXJrLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyDigIvigIvigIvigIvigIs8YnI+DQomZ3Q7 ICZndDsgTWFyY28gRXJtaW5pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENJU1NQLCBD SVNBLCBDSVNNLCBDRUgsIElUSUwsIE1DUCwgUGhEPGJyPg0KJmd0OyAmZ3Q7IFNlbmlvciBJVCBT ZWN1cml0eSBBbmFseXN0PGJyPg0KJmd0OyAmZ3Q7IEQmbmJzcDsmIzQzOzQ5ICgwKTg5OSA5MDEg MTUyMyAmbmJzcDtNJm5ic3A7JiM0Mzs0OSAoMCkxNzUgNDM5IDU2NDI8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgUmVzTWVkIEdlcm1hbnkgSW5jPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IE1hcmsgU21pdGggW21haWx0bzo8YSBocmVmPSJt YWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbSI+bWFya3p6enNtaXRoQGdtYWlsLmNvbTwvYT5d PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDExOjQzIEFNPGJy Pg0KJmd0OyAmZ3Q7IFRvOiBNYXJjbyBFcm1pbmk8YnI+DQomZ3Q7ICZndDsgQ2M6IEJyaWFuIEUg Q2FycGVudGVyOyBFcmlrIEtsaW5lOyBFcmljIFZ5bmNrZSAoZXZ5bmNrZSk7IDxhIGhyZWY9Im1h aWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20iPg0KZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3JnIj5vcHNlY0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3Bz ZWMtdjZAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bGlua2VkaW5AeG4tLWRlYnJuLW52 YS5kZSI+bGlua2VkaW5AeG4tLWRlYnJuLW52YS5kZTwvYT47DQo8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBbT1BTRUNdIEFza2luZyBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNl Yy12Ni0wODxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAxNiBKdW5lIDIwMTYgYXQg MTk6MTUsIE1hcmNvIEVybWluaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmNvLkVybWluaUByZXNt ZWQuY29tIj5NYXJjby5Fcm1pbmlAcmVzbWVkLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg Jmd0OyAmZ3Q7IFdlbGwsIGFjdHVhbGx5LCBpbmZyYXN0cnVjdHVyZSBoaWRpbmcgSVMgcGFydCBv ZiBzZWN1cml0eS4mbmJzcDsgSXQgaXMgbm90IHRoZSBmdWxsIHBpY3R1cmUsIGJ1dCBpdCBpcyBp bmNvcnJlY3QgdG8gc2F5IHRoYXQgaXQgaXMgbm90Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgSSBwZXJzb25hbGx5IGRvbid0IHN5bXBhdGhpemUgb24gTkFULWhhdGVy cy4mbmJzcDsgTkFUIGhhcyBpdHMgcmVhc29ucyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBlc3BlY2lh bGx5IGZvciBjYXJyaWVyLWdyYWRlIE5BVDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBD R04gaXNuJ3QgbmVjZXNzYXJ5IGluIElQdjYsIGl0J3MgdG8gc29sdmUgdGhlIHByb2JsZW0gb2Yg SVNQcyBydW5uaW5nIG91dCBvZiBJUHY0IGFkZHJlc3Nlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJm5ic3A7YW5kIGVzcGVjaWFsbHkgaW4gdGhlIHRlbGNvIHNjZW5hcmlvLCBhbmQg eWVzLCBpdCBkb2VzIHByb3ZpZGUgc29tZSBsZXZlbCBvZiBzZWN1cml0eSAtIGFnYWluLCBub3Qg dGhlIGNvbXBsZXRlIHBpY3R1cmUsIGJ1dCBpdCBkb2VzLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE5BVCBpcyBub3QgbmVjZXNzYXJ5IGluIElQdjYu IFRoZSBlcXVpdmFsZW50IG9mIE5BVCdzIHBlcmNlaXZlZCBzZWN1cml0eSBjYW4gYmUgcHJvdmlk ZWQgdmlhIGFsdGVybmF0aXZlIG1ldGhvZHMsIGFzIGRlc2NyaWJlZCBpbiBSRkM0ODY0Ljxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBIGZ1cnRoZXIgdGVjaG5pcXVlIHRvIGhpZGUgdG9w b2xvZ3kgdGhhdCBpc24ndCBtZW50aW9uZWQgaW4gUkZDNDg2NCBpcyB0byB1c2Ugc29tZXRoaW5n IGxpa2UgSVNBVEFQIG9yIHNpbWlsYXIsIHRvIGNyZWF0ZSBhIHNpbmdsZSAvNjQgc3VibmV0IG92 ZXIgdGhlIHRvcCBvZiBtdWx0aXBsZSBJUHY0IHN1Ym5ldHMuIEV4dGVybmFsbHksIGFsbCBob3N0 cyB3aWxsIGFwcGVhciB0byBiZWxvbmcgdG8gYSBzaW5nbGUgSVB2NiBzdWJuZXQsIGhpZGluZw0K IHRoZSBpbnRlcm5hbCB0b3BvbG9neS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYg eW91IHRydWx5IHdhbnQgdG8gaGlkZSB0aGUgaWRlbnRpdGllcyBvZiBob3N0cywgTkFUIGRvZXNu J3QgZG8gZW5vdWdoIC0gaXQgaXMgb25seSB0cmFuc2xhdGluZyBhZGRyZXNzZXMsIHdoZXJlIGFz IHRoZXJlIGFyZSBtYW55IG90aGVyIGhvc3QgaWRlbnRpZmllcnMgdGhhdCB0aGUgaG9zdCBpdHNl bGYgc3VwcGxpZXMgb3Igd2lsbCByZWNlaXZlIGFuZCBzdXBwbHkgdGhhdCBjYW4gaWRlbnRpZnkg aG9zdHMgZS5nLiBIVFRQIGNvb2tpZXMuDQogJnF1b3Q7QSBUZWNobmlxdWUgZm9yIENvdW50aW5n IE5BVHRlZCBIb3N0cyZxdW90Ozxicj4NCiZndDsgJmd0OyAoPGEgaHJlZj0iaHR0cHM6Ly93d3cu Y3MuY29sdW1iaWEuZWR1L35zbWIvcGFwZXJzL2ZuYXQucGRmIj5odHRwczovL3d3dy5jcy5jb2x1 bWJpYS5lZHUvfnNtYi9wYXBlcnMvZm5hdC5wZGY8L2E+KSBzaG93ZWQgaG93IGEgZmllbGQgd2l0 aGluIHRoZSBJUHY0IGhlYWRlciB0aGF0IGxlYWtlZCBhY3Jvc3MgYSBOQVQgd2FzIGFibGUgdG8g YmUgdXNlZCB0byBpZGVudGlmeSBob3N0cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg SWYgeW91IHRydWx5IHdhbnQgdG8gaGlkZSBhIGhvc3QgZnJvbSB0aGUgSW50ZXJuZXQsIHlldCBz dGlsbCBhbGxvdyBpdCB0byBhY2Nlc3MgdGhpbmdzIG9uIHRoZSBJbnRlcm5ldCwgdW5kZXIgSVB2 NiB5b3VyIG5ldHdvcmsgd291bGQgdXNlIFVMQSBhZGRyZXNzaW5nLCBhbmQgaGF2ZSBhIHBlci1h cHBsaWNhdGlvbiBwcm90b2NvbCBwcm94eSBzZXJ2ZXIgdGhhdCBtYWtlcyBhbGwgcmVxdWVzdHMg bG9vayBsaWtlIHRoZXkndmUgZW50aXJlbHkNCiBvcmlnaW5hdGVkIGZyb20gdGhlIGFwcGxpY2F0 aW9uIHByb3h5IHNlcnZlciBpdHNlbGYuIFRvIHRoZSBJbnRlcm5ldCBzZXJ2ZXIsIHRoZSBhcHBs aWNhdGlvbiBwcm94eSBzZXJ2ZXIgd291bGQgYXBwZWFyIHRvIGJlIHRoZSBhcHBsaWNhdGlvbiBl bmQgaG9zdCBtYWtpbmcgdGhlIHJlcXVlc3RzLCBwcmV2ZW50aW5nIGFueSBpbnRlcm5hbCBob3N0 IGlkZW50aWZpZXJzIG9yIG90aGVyIGF0dHJpYnV0ZXMgZnJvbSBsZWFraW5nLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0 OyBNYXJrLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IE1hcmNvIEVybWluaTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgQ0lTU1AsIENJU0EsIENJU00sIENFSCwgSVRJTCwgTUNQLCBQaEQgU2VuaW9yIElU IFNlY3VyaXR5IEFuYWx5c3QgRDxicj4NCiZndDsgJmd0OyAmZ3Q7ICYjNDM7NDkgKDApODk5IDkw MSAxNTIzJm5ic3A7IE0gJiM0Mzs0OSAoMCkxNzUgNDM5IDU2NDI8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlc01lZCBHZXJtYW55IEluYzxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IE9QU0VDIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmciPm9wc2VjLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgQnJpYW4gRTxicj4NCiZndDsgJmd0OyAmZ3Q7IENhcnBlbnRl cjxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDE6NDUg QU08YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogRXJpayBLbGluZTsgRXJpYyBWeW5ja2UgKGV2eW5j a2UpPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpmZ29udEBzaTZuZXR3 b3Jrcy5jb20iPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHNl Y0BpZXRmLm9yZyI+DQpvcHNlY0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsaW5rZWRp bkB4bi0tZGVicm4tbnZhLmRlIj5saW5rZWRpbkB4bi0tZGVicm4tbnZhLmRlPC9hPjs8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1vcHNlYy12NkBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1Ympl Y3Q6IFJlOiBbT1BTRUNdIFt2Nm9wc10gQXNraW5nIGZvciBhIHJldmlldyBvZjxicj4NCiZndDsg Jmd0OyAmZ3Q7IGRyYWZ0LWlldGYtb3BzZWMtdjYtMDg8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IE9uIDE2LzA2LzIwMTYgMDc6NDUsIEVyaWsgS2xpbmUgd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlY3Rpb24gMi4xLjIgaXMgZmFyIHRvbyBwZXJtaXNzaXZl IGZvciBteSB0YXN0ZXMuJm5ic3A7IFdlIG5lZWQgdG8gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsgYWJsZSB0byBzYXkgdGhhdCBVTEEmIzQzO0lQdjYgTkFUIGlzIE5PVCBSRUNPTU1FTkRFRCBi eSB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgaGF2 ZSBzdHJvbmcgc3ltcGF0aHkgd2l0aCB0aGF0IHN0YXRlbWVudCwgYnV0IEkgZG9uJ3QgdGhpbmsg dGhpcyBpcyB0aGUgZG9jdW1lbnQgdG8gZG8gaXQ7IHRoZSBwb2ludCBpcyBtYWRlIGluIFJGQzQ4 NjQgdG9vLiBXaGF0IHdlIHNob3VsZCBkbyBoZXJlIGlzIHVuZGVybGluZSB0aGF0IE5BVCAhPSBz ZWN1cml0eS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoaWxlIEkn bSBoZXJlLCBzb21lIG90aGVyIHBvaW50czo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZxdW90OzIuMi4mbmJzcDsgRXh0ZW5zaW9uIEhlYWRlcnM8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBUQkQsIGEgc2hvcnQgc2Vj dGlvbiByZWZlcnJpbmcgdG8gYWxsIEZlcm5hbmRvJ3MgSS1EICZhbXA7IFJGQy4mcXVvdDs8YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYXQncyBub3QgdGhlIHdob2xl IHN0b3J5IDstKS4gRmlyc3RseSwgUkZDIDcwNDUgaGFzIGEgbG90IG9mPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgcmVsZXZhbmNlIHRvIHNlY3VyaXR5IGFzcGVjdHMuIFNlY29uZCwgdGhlcmUgaXMgbm8g cmVhc29uIHRvIHJlZmVyIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbW9zdCBvZiB0aGUgbWF0ZXJp YWwgKEZlcm5hbmRvJ3Mgb3Igbm90KSB1bmxlc3MgaXQncyBkaXJlY3RseSByZWxldmFudDxicj4N CiZndDsgJmd0OyAmZ3Q7IHRvIG9wc2VjLiBJIHRoaW5rIHRoZSByZWZlcmVuY2UgaXMgZHJhZnQt aWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBidXQgb25s eSBpZiB0aGF0IGRvY3VtZW50IGlzIGdvaW5nIGFueXdoZXJlLjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7Mi4zLjMuJm5ic3A7IE5EL1JBIFJhdGUgTGltaXRp bmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAuLi48YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgVGhlIGZvbGxvd2luZyBkcmFmdHMgYXJlIGFjdGl2ZWx5IGRpc2N1c3NpbmcgbWV0aG9kcyB0 bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyByYXRlIGxpbWl0IFJBcyBhbmQgb3Ro ZXIgTkQgbWVzc2FnZXMgb24gd2lmaSBuZXR3b3JrcyBpbiBvcmRlciB0bzxicj4NCiZndDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBhZGRyZXNzIHRoaXMgaXNzdWU6PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBbSS1ELnRodWJlcnQt c2F2aS1yYS10aHJvdHRsZXJdPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBbSS1ELmNoYWtyYWJhcnRpLW5vcmRtYXJrLTZtYW4tZWZm aWNpZW50LW5kXSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg TmVpdGhlciBvZiB0aG9zZSBkcmFmdHMgaXMgaW4gdGhlIGxlYXN0IGFjdGl2ZSAoZnJvbSAyMDEy IGFuZCAyMDE1IHJlc3BlY3RpdmVseSkuIERlYWQgZHJhZnRzIGFyZSBvZiBubyBoZWxwIHRvIHRo ZSByZWFkZXIsIElNSE8uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm cXVvdDs0LjIuJm5ic3A7IFRyYW5zaXRpb24gTWVjaGFuaXNtPGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgU1Agd2lsbCB0eXBpY2FsbHkgdXNlIHRy YW5zaXRpb24gbWVjaGFuaXNtcyBzdWNoIGFzIDZyZCwgNlBFLCBNQVAsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7IERTLUxpdGUgd2hpY2ggaGF2ZSBiZWVuIGFuYWx5emVkIGluIHRo ZSB0cmFuc2l0aW9uIFNlY3Rpb24gMi43LjI8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgc2VjdGlvbi4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 IFNob3VsZG4ndCB5b3UgYWRkIFJGQzY4NzcgNDY0WExBVCBub3c/PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBGaW5hbGx5LCBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBh IFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IFJnZHM8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7QnJpYW48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyBTZWN0aW9uIDIuNi4xLjUgY291bGQgcHVuY2ggdXAgdGhlIFNB Vkkgc3R1ZmYgYSBiaXQgbW9yZSBhcyB3ZWxsLiZuYnNwOyBXZTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyBzaG91bGQsIGluIG15IG9waW5pb24sIG1ha2UgaXQgcGFpbmZ1bGx5IGNsZWFyIHRoYXQg REhDUCAob2YgYW55PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IHByb3RvY29sKSBpbiB0aGUgYWJz ZW5jZSBvZiBsaW5rLWxheWVyIHNlY3VyaXR5L2F1ZGl0YWJpbGl0eSBmZWF0dXJlczxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyBkb2VzIG5vdCBwcm92aWRlIGFueSBzYXRpc2ZhY3Rvcnkgd2F5ICZx dW90O3RvIGVuc3VyZSBhdWRpYmlsaXR5IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB0cmFj ZWFiaWxpdHkmcXVvdDsgW1NlY3Rpb24gMi4xLjZdLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT1BTRUMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOk9QU0VDQGlldGYu b3JnIj5PUFNFQ0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_38465846B6383D4A8688C0A13971900C48DC4AFAge2eml2k1004_-- From nobody Fri Jun 17 06:17: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 9281F12D531; Fri, 17 Jun 2016 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 1wR86jomkrYa; Fri, 17 Jun 2016 06:16:58 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id A021C12D59D; Fri, 17 Jun 2016 06:16:57 -0700 (PDT) Received: from [85.158.136.67] by server-3.bemta-5.messagelabs.com id 36/70-01940-848F3675; Fri, 17 Jun 2016 13:16:56 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRWlGSWpSXmKPExsVy+JUil67Hj+R wg7WT9C2e7rzCYvFh6102i9PH9jI7MHssWfKTKYAxijUzLym/IoE1Y+fcC4wFrfwVk/sWMjYw vuHrYuTiEBJYzyhxftN3ZghnD6PEpXOX2LsYOTnYBHQk/i/fBWaLCChKnGj4xgZSxCwwk0niz osLbCAJYQEvif17W5khirwltt7YzAhhO0mcfn+OFcRmEVCVuH1tApjNK+Assev4VqhtTcwSh7 d9BtvAKaAvseT3MzCbUUBW4kvjarChzALiEreezGcCsSUEBCSW7DnPDGGLSrx8/I8VwlaUuPx 7CksXIwdQvabE+l36EK2KElO6H7JD7BWUODnzCQuILSSgItG+YBlUa7BE78F1LBMYxWYh2TYL YdIsJJNmIZm0gJFlFaNGcWpRWWqRrqGRXlJRZnpGSW5iZo6uoYGpXm5qcXFiempOYlKxXnJ+7 iZGYHQxAMEOxr5ZzocYJTmYlER5555LDhfiS8pPqcxILM6ILyrNSS0+xCjDwaEkwavzHSgnWJ SanlqRlpkDjHOYtAQHj5IIrx5Imre4IDG3ODMdInWK0ZLjzuIba5k4bj17ACQ/TThwjEmIJS8 /L1VKnNccpEEApCGjNA9uHCwVXWKUlRLmZQQ6UIinILUoN7MEVf4VozgHo5IwbxDIFJ7MvBK4 ra+ADmICOkhzHthBJYkIKakGxpm7vVxZPp0XS13gus995asPm9rfPOZSz5B+GyY1N7F8KYOTa dc8FaHvCpOYDHY8/J5TvGmdoKpE3fYXi12+/Xi7KSz4WuRXk8knXkic9ghn3xvTn/zC1G3XtX NmB/c7LNR8eqEr/k8Nf2xc0csLsxQ2PyiqX1mtJbKj2krJif/8nC/mbzUfLlViKc5INNRiLip OBAAvb5CIQAMAAA== X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-15.tower-207.messagelabs.com!1466169416!12213373!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14786 invoked from network); 17 Jun 2016 13:16:56 -0000 Received: from unknown (HELO mx.resmed.de) (195.234.33.10) by server-15.tower-207.messagelabs.com with SMTP; 17 Jun 2016 13:16:56 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mx.resmed.de over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Fri, 17 Jun 2016 15:16:56 +0200 Received: from GE2EML2K1004.corp.resmed.org ([172.17.6.120]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%20]) with mapi id 14.03.0210.002; Fri, 17 Jun 2016 15:16:56 +0200 From: Marco Ermini To: Gert Doering Thread-Topic: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRx7OSZDWt19w1D06Dzoga8sHTvZ/r20RAgAGP3gCAADo8kA== Date: Fri, 17 Jun 2016 13:16:55 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <20160617114732.GK79185@Space.Net> In-Reply-To: <20160617114732.GK79185@Space.Net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2016 13:16:56.0282 (UTC) FILETIME=[859FDBA0:01D1C89A] 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, 17 Jun 2016 13:16:59 -0000 VG8gYWNjZXNzIElQdjQtb25seSBlbmFibGVkIGhvc3RzPw0KDQoNClJlZ2FyZHMsDQrigIvigIvi gIvigIvigIsNCk1hcmNvIEVybWluaQ0KDQpDSVNTUCwgQ0lTQSwgQ0lTTSwgQ0VILCBJVElMLCBN Q1AsIFBoRA0KU2VuaW9yIElUIFNlY3VyaXR5IEFuYWx5c3QNCkTCoCs0OSAoMCk4OTkgOTAxIDE1 MjMgwqBNwqArNDkgKDApMTc1IDQzOSA1NjQyDQoNClJlc01lZCBHZXJtYW55IEluYw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR2VydCBEb2VyaW5nIFttYWlsdG86Z2VydEBz cGFjZS5uZXRdIA0KU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDE6NDggUE0NClRvOiBNYXJj byBFcm1pbmkNCkNjOiBNYXJrIFNtaXRoOyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNl Yy12NkBpZXRmLm9yZzsgb3BzZWNAaWV0Zi5vcmc7IGxpbmtlZGluQHhuLS1kZWJybi1udmEuZGU7 IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KU3ViamVjdDogUmU6IFt2Nm9wc10gW09QU0VDXSBBc2tp bmcgZm9yIGEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzZWMtdjYtMDgNCg0KSGksDQoNCk9uIFRo dSwgSnVuIDE2LCAyMDE2IGF0IDEwOjAzOjI1QU0gKzAwMDAsIE1hcmNvIEVybWluaSB3cm90ZToN Cj4gTkFUIGNhbiBiZSBzdGlsbCBuZWNlc3NhcnkgaW4gSVB2NiBpbiBkdWFsLXN0YWNrIHNjZW5h cmlvLCBmb3IgaW5zdGFuY2UsIHdoZXJlIGV2ZXJ5IGhvc3QgaXMgYXNzaWduZWQgYm90aCBhIElQ djQgYW5kIElQdjYgYWRkcmVzc2VzIGFuZCB0aGUgQ0dOIGVxdWlwbWVudCBjYW4ndCBoYW5kbGUg dGhlbSBkaWZmZXJlbnRseS4gIFVuZm9ydHVuYXRlbHkgUkZDIDQ4NjQgZG9lcyBub3QgbWVudGlv biBzdWNoIGNhc2UsIEFGQUlLLg0KDQpXaHkgd291bGQgYW55b25lIHJvdXRlIHRoZWlyIElQdjYg dHJhZmZpYyB0byB0aGUgSVB2NCBDR04gYm94Pw0KDQpDR04gYm94ZXMgYXJlIHdheSBleHBlbnNp dmUsIHNvIGFueW9uZSB3aXRoIGEgY2FsY3VsYXRvciB3b3VsZCByb3V0ZSBldmVyeXRoaW5nIHRo YXQgZG9lcyBub3QgbmVlZCBOQVQgYXJvdW5kIHRoZSBDR04gYm94Lg0KDQpHZXJ0IERvZXJpbmcN CiAgICAgICAgLS0gTmV0TWFzdGVyDQotLQ0KaGF2ZSB5b3UgZW5hYmxlZCBJUHY2IG9uIHNvbWV0 aGluZyB0b2RheS4uLj8NCg0KU3BhY2VOZXQgQUcgICAgICAgICAgICAgICAgICAgICAgICBWb3Jz dGFuZDogU2ViYXN0aWFuIHYuIEJvbWhhcmQNCkpvc2VwaC1Eb2xsaW5nZXItQm9nZW4gMTQgICAg ICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBBLiBHcnVuZG5lci1DdWxlbWFubg0KRC04MDgwNyBN dWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQpUZWw6 ICs0OSAoMCk4OS8zMjM1Ni00NDQgICAgICAgICAgIFVTdC1JZE5yLjogREU4MTMxODUyNzkNCg== From nobody Fri Jun 17 06:22: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 A5FE012D5AF for ; Fri, 17 Jun 2016 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 JMvcYbEzG5Mq for ; Fri, 17 Jun 2016 06:22:23 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113A312D658 for ; Fri, 17 Jun 2016 06:22:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A39BF880E4 for ; Fri, 17 Jun 2016 06:22:22 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6EC74328081A for ; Fri, 17 Jun 2016 06:22:22 -0700 (PDT) To: v6ops@ietf.org References: <57571D6E.2050102@gont.com.ar> From: Brian Haberman Message-ID: <11ef3b60-d8b7-3fce-703e-db9956eae0d7@innovationslab.net> Date: Fri, 17 Jun 2016 09:22:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KTSDXV67WDhxnGCQ0ldrrCX9SWR9cghnV" Archived-At: Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 17 Jun 2016 13:22:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KTSDXV67WDhxnGCQ0ldrrCX9SWR9cghnV Content-Type: multipart/mixed; boundary="bdMaUAn4kW10qjIVvBgxWJrqgVoaOEwLR" From: Brian Haberman To: v6ops@ietf.org Message-ID: <11ef3b60-d8b7-3fce-703e-db9956eae0d7@innovationslab.net> Subject: Re: [v6ops] Packets with LL src and GUA dst References: <57571D6E.2050102@gont.com.ar> In-Reply-To: --bdMaUAn4kW10qjIVvBgxWJrqgVoaOEwLR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/8/16 1:12 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 7 Jun 2016 21:15:58 +0200, > Fernando Gont wrote: >=20 >>> A device should not forward a packet with LL source or destination ad= dress to any port other than the port on which it arrived. >> >> Actually, it shouldn't forward such packets no matter what. >=20 > Do you mean in your opinion, or per the protocol specification? If > you meant the latter, it's not really correct. See, for example, the > following part of Section 9 of RFC4007: >=20 > [...] if a > router receives a packet with a link-local destination address that > is not one of the router's own link-local addresses on the arrival > link, the router is expected to try to forward the packet to the > destination on that link (subject to successful determination of the= > destination's link-layer address via the Neighbor Discovery protocol= > [9]). The forwarded packet may be transmitted back through the > arrival interface, or through any other interface attached to the > same link. More important to this particular issue is the rule in section 9 of 4007 that says: o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note that Code 2 is currently left as unassigned in [4], but the IANA will re-assign the value for the new purpose, and [4] will be revised with this change. The router should be checking the source address of the packet and the zone of the ingress interface as a part of the forwarding decision. Regards, Brian >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --bdMaUAn4kW10qjIVvBgxWJrqgVoaOEwLR-- --KTSDXV67WDhxnGCQ0ldrrCX9SWR9cghnV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXY/mNAAoJEBOZRqCi7goqctcIALNHkEZccurlxLhrhc4iMy4F miFvibAzHBFoD1+z/V9NjNY2fc68JP5p1mx1EtN7M0xLaoJ294QFHusOJyOKSmXS UiBe0X4XD8Nr6kPszWrOeEmmrQ0ZAwPEZJhDFd8soUzCV151ZW7MNRsTRdsGZpy2 zp8Qtrx3bZvbjCbCUPKo/mW6oWoOQ7sihJbk78cIK5Q4O1hEci0vJvoQ/UgQEEmX mxckLt9pejNENZg9TjCS4M0UG4EtblVFJIv91kKl1CeT9Tp03zQBOwSjh/2n/cUj /4demfC69k8ua/4aEWGIxmhhUSTb/th0yxBstSPFNlx3YunfDiadUstDMGqXGBg= =H4zO -----END PGP SIGNATURE----- --KTSDXV67WDhxnGCQ0ldrrCX9SWR9cghnV-- From nobody Fri Jun 17 08:10: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 4CCA412D5D8 for ; Fri, 17 Jun 2016 08:10:16 -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 M35WQxzu34op for ; Fri, 17 Jun 2016 08:10:14 -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 8B8B312D67A for ; Fri, 17 Jun 2016 08:10:13 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3231760F40 for ; Fri, 17 Jun 2016 17:10:09 +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 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 9F531602FD; Fri, 17 Jun 2016 17:10:08 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8E09734CE6; Fri, 17 Jun 2016 17:10:08 +0200 (CEST) Date: Fri, 17 Jun 2016 17:10:08 +0200 From: Gert Doering To: Marco Ermini Message-ID: <20160617151008.GS79185@Space.Net> References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <20160617114732.GK79185@Space.Net> <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HQGUecSJzcpn1lKh" Content-Disposition: inline In-Reply-To: <38465846B6383D4A8688C0A13971900C48DC4B39@ge2eml2k1004> 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, 17 Jun 2016 15:10:16 -0000 --HQGUecSJzcpn1lKh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jun 17, 2016 at 01:16:55PM +0000, Marco Ermini wrote: > To access IPv4-only enabled hosts? You wouldn't send IPv*6* packets to an IPv4-only host in a dual-stack client situation. CGN for IPv4 is not NAT64. 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 --HQGUecSJzcpn1lKh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXZBLPAAoJEN9WwGXkzn/FTLsQAJIhnNVZSts3JnLzMW5el2uC OFrV2nFUxZ36t3JDYRskODY6klc8BnxiOQQ1pKKGm+6H9WZd9Bds6sCL9BBV+web OP2H6NjD2Z2NFP5smrnst/VZZTkAwCvxZaO4HpVd7Pyfp/61/gAf2ZsUAChVEvkg iNcKQ6AN6JK7jJdNKUalFy+QRkPJIRoobGqj8tTupRE3Ij73zICx661yyQdg5ZFU oog7pzdS/RhtHvvj/autjlitZ+k894DaCs1yvFoNO7ctF7I22uU48ELryE7pywmK en/FmxpQC3xzjiEcVnEJt+hyjHnhJ5dckpQRmoVlc2v+poWE6IVK8Rf7LoIUP30Q b8YdNCj1sxokxAUSejtcircRKJ58KPGGUo62pTX5Y+c64niKvk+tYLNFF1LEeQ6V IOi/nDf1b5UmlN5VSme+xN46PSReLnzYltlJM+t/eWr0yoWsxPG9lkTi6mrL1JuR ipcAI98q8RaoRzYM8wX1LSrsBdPmIliDb/5iYX1F2uU4MtCfcSqGchp4YLoIrCHV fIDji8L0e+wyIoJHtUwGixlInF83e4F0NCrKTP2fZaU268WlZjBw2VleA/XC/eBj yvRk1+WY2S5CqsVXHyC2XVs6HNz+OeSmJ7nY+zmFGncCk62zc3NkR0IgnJQiu2Eu SkSZXVICwdOgX49qljbF =0aAF -----END PGP SIGNATURE----- --HQGUecSJzcpn1lKh-- From nobody Fri Jun 17 13:14: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 D4A0C12D112; Fri, 17 Jun 2016 13:14: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 IffnKXeaLpQU; Fri, 17 Jun 2016 13:14:42 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 8318112DAAB; Fri, 17 Jun 2016 13:14:41 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c2so33843729pfa.2; Fri, 17 Jun 2016 13:14: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=k58vCRAygyXHmWeOMPHIWr6RNXxFVX8zErJ6gNGyPzs=; b=ZVnWxXMKagph+KAKb9qP5NK5Ic7FSG7F58Pu5gRNv5fWNr+9h8M0su/I6/UX8AeWTx l5LTPVlwrM/Vz7Ght5GjYK4s5XFE5BHRCZAlhNjQ3sZGrP5ZEGKk7Li6GVd4IxkSUteM vn1CY5ATNiqAwoWigC4ZIIqJ3LgwU1ItRdApyqa8dSaYoChnQwI9FO6X2GsPOOZqKwUf WY27iKdRRRgQq74ojT8OGkdSiZNFJl9TbjAgEpfqKP7GXSVLnHHKUQwenut0pGBj/FRN B8nu0LdScsLRyuTsnYKzIlEniUz8Ga74ysU/J3fT/qTaCzx1pK/OFecThiZMzVwrchW8 KD5g== 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=k58vCRAygyXHmWeOMPHIWr6RNXxFVX8zErJ6gNGyPzs=; b=nGCw6LY/IVWTkjCudWK6i6XAXevvJtA+FLDPYs12CGPztwUTG7h8oAOtl6rG6aIqj/ cFjx/CVFeW5n9WJ+jKsQSNnEObABNCCjN1ijk67m9aN01yDI1ICVVck3/3HohAUb6J01 YBQvczBqJPIHTvNOgH462UPOBJUiDc+FsjPwFLaAmRLpNfDrim9U5dHMwL97G/Q0kRF3 0tHmk9gEMde7v7yXlTM2gMevQYJ65x56MKeV/OYvtuYkR/feGZpUzLleupyth/nd9W2I eTWacHrhSHe84evvgxdb6eeQTFCrasCnnKtJVqQwYHh7V6tN2eGfGwsbhjeaiEUsZstX OnWA== X-Gm-Message-State: ALyK8tK5cNI2toa0ABonXB7vchXpzZpPUd3G/FL91RKcUGkTSNcSmDn3UiUJhzcg4ybmuQ== X-Received: by 10.98.103.198 with SMTP id t67mr4200582pfj.158.1466194480933; Fri, 17 Jun 2016 13:14:40 -0700 (PDT) Received: from [192.168.178.23] ([118.148.67.217]) by smtp.gmail.com with ESMTPSA id an13sm70368752pac.42.2016.06.17.13.14.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2016 13:14:40 -0700 (PDT) To: Marco Ermini , Erik Kline , "Eric Vyncke (evyncke)" References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> From: Brian E Carpenter Organization: University of Auckland Message-ID: <26aa8d79-7f3c-d05b-15ea-dc11b240a19c@gmail.com> Date: Sat, 18 Jun 2016 08:14:46 +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: <38465846B6383D4A8688C0A13971900C48DC4637@ge2eml2k1004> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "fgont@si6networks.com" , "opsec@ietf.org" , "draft-ietf-opsec-v6@ietf.org" , "linkedin@xn--debrn-nva.de" , "v6ops@ietf.org" 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, 17 Jun 2016 20:14:44 -0000 So, can we agree on "NAT is not required to provide security in IPv6 (see= for example [RFC4864])." I agree that this aspect of IPv6, including the appropriate use of ULAs, is definitely hard to explain to people brought up on common IPv4 practic= e. Regards Brian On 17/06/2016 23:29, Marco Ermini wrote: > I am sorry Brian, I don't think you understood my argument. I am not a= rguing about you mention. I am arguing against the semantic of a phrase = that says "NAT does not provide security". This sentence is semantically= wrong, and usually comes from a priori NAT-haters (I have met a few). >=20 > I am only against stating such sentence in the RFC, not against the fac= t that we don't need NAT. I hope this is clearer now. >=20 > Anyway, I have made my point sufficiently, I believe. >=20 >=20 > Regards, > Marco. >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Friday, June 17, 2016 3:40 AM > To: Marco Ermini; Erik Kline; Eric Vyncke (evyncke) > Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; d= raft-ietf-opsec-v6@ietf.org; v6ops@ietf.org > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6= -08 >=20 > On 16/06/2016 21:15, Marco Ermini wrote: >> Well, actually, infrastructure hiding IS part of security. It is not = the full picture, but it is incorrect to say that it is not. >=20 > Have you read RFC4864 recently? Section 4.4 is all about how you don't = need NAT to hide infrastructure topology in IPv6. >=20 >> I personally don't sympathize on NAT-haters. NAT has its reasons, esp= ecially for carrier-grade NAT and especially in the telco scenario, and y= es, it does provide some level of security - again, not the complete pict= ure, but it does. >=20 > That's IPv4. This is IPv6. >=20 > Brian >=20 >> >> >> Regards, >> =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B >> Marco Ermini >> >> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D=20 >> +49 (0)899 901 1523 M +49 (0)175 439 5642 >> >> ResMed Germany Inc >> >> >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E=20 >> Carpenter >> Sent: Thursday, June 16, 2016 1:45 AM >> To: Erik Kline; Eric Vyncke (evyncke) >> Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; = >> draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org >> Subject: Re: [OPSEC] [v6ops] Asking for a review of=20 >> draft-ietf-opsec-v6-08 >> >> On 16/06/2016 07:45, Erik Kline wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be=20 >>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I have strong sympathy with that statement, but I don't think this is = the document to do it; the point is made in RFC4864 too. What we should d= o here is underline that NAT !=3D security. >> >> While I'm here, some other points: >> >> "2.2. Extension Headers >> >> TBD, a short section referring to all Fernando's I-D & RFC." >> >> That's not the whole story ;-). Firstly, RFC 7045 has a lot of=20 >> relevance to security aspects. Second, there is no reason to refer to = >> most of the material (Fernando's or not) unless it's directly relevant= =20 >> to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,= >> but only if that document is going anywhere. >> >> "2.3.3. ND/RA Rate Limiting >> ... >> The following drafts are actively discussing methods to >> rate limit RAs and other ND messages on wifi networks in order to >> address this issue: >> >> o [I-D.thubert-savi-ra-throttler] >> >> o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >> >> Neither of those drafts is in the least active (from 2012 and 2015 res= pectively). Dead drafts are of no help to the reader, IMHO. >> >> "4.2. Transition Mechanism >> >> SP will typically use transition mechanisms such as 6rd, 6PE, MAP, >> DS-Lite which have been analyzed in the transition Section 2.7.2 >> section." >> >> Shouldn't you add RFC6877 464XLAT now? >> >> Finally, I think there should be a Privacy Considerations section. >> >> Rgds >> Brian >> >>> >>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We= =20 >>> should, in my opinion, make it painfully clear that DHCP (of any >>> protocol) in the absence of link-layer security/auditability features= =20 >>> does not provide any satisfactory way "to ensure audibility and=20 >>> traceability" [Section 2.1.6]. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> >=20 From nobody Fri Jun 17 15:13: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 BFE5812DBC5; Fri, 17 Jun 2016 15:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 haPAOX8pgazh; Fri, 17 Jun 2016 15:13:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 3C77712DBC3; Fri, 17 Jun 2016 15:13:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 43AF01FCAB8; Fri, 17 Jun 2016 22:13:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1F798160055; Fri, 17 Jun 2016 22:13:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0D36C160076; Fri, 17 Jun 2016 22:13:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o-Cz0GieMFGn; Fri, 17 Jun 2016 22:13:24 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 80558160055; Fri, 17 Jun 2016 22:13:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8EF854BB29DF; Sat, 18 Jun 2016 08:13:22 +1000 (EST) To: Marco Ermini From: Mark Andrews References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DBFD81@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC15F5@ge2eml2k1004> <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> In-reply-to: Your message of "Fri, 17 Jun 2016 13:12:09 +0000." <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004> Date: Sat, 18 Jun 2016 08:13:22 +1000 Message-Id: <20160617221322.8EF854BB29DF@rock.dv.isc.org> 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, 17 Jun 2016 22:13:36 -0000 In message <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004>, Marco Ermini writes: > On residential routers, the myth that IPv6 will come and solve all of the > NAT problems is, and allow ubiquitous and secure access to all the > devices is, in fact, a myth. IPv6 breaks protocols as much (if not more) > than IPv4 NAT. The most used residential routers in Germany (and proudly > German engineered product) requires advanced view enabled just to enable > it; it provides ULAs via DHCPv6, and performs translation to routable > IPv6 addresses. While IPv4 NAT needs to perform stateful translation of > IPs and ports, residential routers on IPv6 only translate IPs but that > is not improving a lot. This sounds like the ISP or CPE vendor has not listened to +15 years of advice on how to deploy IPv6. You should be getting a prefix delegation from the ISP which is then redistributed to the inside network. The PD should be at least a /56 and preferably a /48. The prefix delegation can be delivered via 6RD if there isn't native IPv6. ULA is a additional prefix that provides stable internal addressing. NAT66 is not recommended and has even published several RFC that states exactly that opinion. RFC6296 For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. Where translation is implemented, however, this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful Network Address Translator in an IPv6 environment. It also provides a useful alternative to the complexities and costs imposed by multihoming using provider- independent addressing and the routing and network management issues of overlaid ISP address space. Some problems remain, however. The reader should consider the alternatives suggested in [RFC4864] and the considerations of [RFC5902] for improved approaches. If someone thinks NAT66 provides any effective security they need their head read. Internal addresses leak all over the place and once you have one all the internal machines are addressable. The only thing NAT66 provides is the ability to have a single IPv6 address per machine vs multiple IPv6 address internally which comes at a cost of requiring external equipement to be able to determine the effective GUA the machine has and more complicated software at the application level to work around the NAT. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jun 17 15:32: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 1219412DBFC; Fri, 17 Jun 2016 15:32:30 -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 4Ovb3yV5DZPW; Fri, 17 Jun 2016 15:32:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9413D12DBFB; Fri, 17 Jun 2016 15:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1466202748; x=1467412348; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uYO2xMeWPqEl5O8QFyfiGYJRSIDliwUty0PCV7/Tl0E=; b=hfObx0avZoDtz4F/oPcmF7lqVUe5wULPPFs84LX1mbOakoA3tYArdG19 7sPx4pzeuVFXPvj/vB33svrZ7IW6s3YjyOIsNjXHqBfZ+v76lS5rRIJ8Q l7SCv//h8/8DvZyKky8EfNfxOXBt4y5RhvkeNC22SJ/Jxgv8qeDg2BM7z I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDAeWRX/5RdJa1dgz6BUwaCUwsEr?= =?us-ascii?q?DWJc4IPgXqGFwKBJTgUAQEBAQEBAWUnhEsBAQEDAXkFCwIBCBguIRElAgQOBQ6?= =?us-ascii?q?ICAMPCL0HDYNeAQEBAQEBAQEBAQEBAQEBAQEBARAOiB6CVoJDgU8RAQaDQoIvB?= =?us-ascii?q?ZhBNAGDLYFqhxiBeoFTjU+ICodsAR42g3BuiRM2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,485,1459814400"; d="asc'?scan'208";a="116317886" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 22:32:27 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u5HMWRRk006087 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 22:32:27 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 17:32: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.1104.009; Fri, 17 Jun 2016 17:32:26 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 Thread-Index: AQHRyOggeDyqZS3K60Gt+g5HwDkDsw== Date: Fri, 17 Jun 2016 22:32:26 +0000 Message-ID: References: <173d2c6b-4cbf-88da-cf20-710a90e04c7e@gmail.com> <38465846B6383D4A8688C0A13971900C48DBF82F@ge2eml2k1004> In-Reply-To: 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.125] Content-Type: multipart/signed; boundary="Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D"; 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" , Marco Ermini 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, 17 Jun 2016 22:32:30 -0000 --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Jun 16, 2016, at 2:43 AM, Mark Smith wrote: > > If you truly want to hide a host from the Internet, yet still allow it > to access things on the Internet, under IPv6 your network would use > ULA addressing, and have a per-application protocol proxy server that > makes all requests look like they've entirely originated from the > application proxy server itself. To the Internet server, the > application proxy server would appear to be the application end host > making the requests, preventing any internal host identifiers or other > attributes from leaking. Even there, beware the email header. --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D 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 iQIVAwUBV2R6eUayAOS/EQ8MAQIfxxAAx1kxl9FIIKM7XJx0J3m0uOv+snjElwrE v0OyfiJgoYWCyEu4AYonSt+MnmsmSG7CeCmWcKygaYtA9d4mdJE/DD56CjeDhNFY xKAMsN3Pr7QF2rFO95vahudlcm6PMz/0Mr2sdMhOvk6xZgB67D/yx/O950RmaGms VctXAdU51PTfdl3nvGbG2NcrAY+G+aomTl2dFlmnIAULIy2WpYL0QtCRwhP67a7c zFDD4R++HWbOio1E3pQI55SEyzN1Zl0BgQcoo6d8ANPG7kRJYVdCC2k8/VrgK5Qi /WwRU8Fgw6oUJfU7Wu+BO5GWisSFzOsvlWhP+sR8FDTk/pzeBWecKNTLLBREuOGA baHf9nduwAUS9r/LW2tp/ha/eNP34ZRc/J8WLSheHnGncJ5aXm9Ag5E71ZJygmKi 76jHVAG8ZrRkXQi3wWuYZA575DsuFOgkNjHmnaCdDZwefMEVg7sE16GlzScM/jIB TaAGe2q1Y4hTd86H3v6cJtXmEq3Q2jvUxSV1EFy3lSIXkPtNPuMDlOHFfAvVHCpw pUryZvff9T0RoIGhoNqGTqPS3pHmIUF3efgFo8rw/ILEWHHhHvXpXR0aRV1T+SsF qIUMm4jS94nk/2oJdDg63ixgAFXXPuNmW+lXeRlPCWJ3DJyA0uo3rKWaRMXgW9hj GagE4wE2C3M= =eafK -----END PGP SIGNATURE----- --Apple-Mail=_696219FF-1835-49DD-A1B9-D7283FFD114D-- From nobody Sun Jun 19 12:47: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 DFD0C12D799 for ; Sun, 19 Jun 2016 12:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.526 X-Spam-Level: X-Spam-Status: No, score=-7.526 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.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 gL3uW8H1tpVw for ; Sun, 19 Jun 2016 12:47:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8512D77D for ; Sun, 19 Jun 2016 12:47:01 -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 u5JJjwEq024849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Jun 2016 12:45:58 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_756533F1-0059-4895-A45D-BC40242A745C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <5218533c-6853-55e4-bab7-34ffecb2feb3@gmail.com> Date: Sun, 19 Jun 2016 12:45:57 -0700 Message-Id: <76E49E82-018C-461D-8F85-414F4E98801B@delong.com> References: <57571D6E.2050102@gont.com.ar> <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> 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]); Sun, 19 Jun 2016 12:45:59 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 19 Jun 2016 19:47:06 -0000 --Apple-Mail=_756533F1-0059-4895-A45D-BC40242A745C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 17, 2016, at 05:53 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 17/06/2016 =C3=A0 06:16, Owen DeLong a =C3=A9crit : >>=20 >>> On Jun 16, 2016, at 03:00 , Alexandre Petrescu >>> wrote: >>>=20 >>>=20 >>>=20 >>> Le 15/06/2016 =C3=A0 21:28, Musa Stephen Honlue a =C3=A9crit : >>>> This is bad behaviour both for the source device(LL should not be >>>> used for off-link destinations), and for intermediary >>>> routers(they should not forward packet sourced with LLA). >>>>=20 >>>> It is clear enough that responses to such packets won't be able >>>> to make their way back. >>>=20 >>> I agree - but sometimes there is no need for response - protocols >>> such as OSPF or ICMP Router Advertisements, not to mention UDP >>> video streaming, dont need responses. >>=20 >> Um=E2=80=A6 So just to make sure I understand correctly=E2=80=A6 >>=20 >> Other than virtual links, OSPF route announcements shouldn=E2=80=99t = have GUA >> destinations. In the case of a virtual link, an OSPF route >> announcement shouldn=E2=80=99t have LL source. >=20 > Ah, no, I did not mean of virtual links. >=20 > Simply an IPv6 OSPF router must be able to send an LSA (link-state > advertisement) to a multicast group beyond the link. Outside of Virtual Links, this is not correct. An OSPF router should = never send an LSA beyond a directly connected link except in the case of a = virtual link. In the case of a virtual link, the routers must use GUA or ULA on both = sides, LL is not permitted. > And it is not for that need that it must have a GUA/ULA. That need does not exist. > A network of OSPF routers must be able to work without any GUA/ULA nor > IPv4 on any of the routers. Correct, but it does this entirely with LINK SCOPED multicast packets = using IPv6 Link Local addresses. Of course without ULA or GUA, it doesn=E2=80=99t have anything to = advertise in the LSAs, but it cat at least establish neighborship and DR status. > Because it is easy to set up same network with static routes, without > OSPF, and without GUA/ULA on them (just the LLs). I=E2=80=99m not sure what prefix a static route would provide next hop = information for if not GUA or ULA. You are making less and less sense with each iteration = of this conversation. >> In the case you seem to be proposing, virtual link with LL source and >> GUA destination, you would be sending a route announcement that >> effectively sets an un-reachable next-hop to the remote router. I=E2=80= =99m >> not sure I see any possible benefit of this action under any >> circumstances. I can, however, see several problematic outcomes >> (network singularities anyone?). >=20 > I would agree with you if I proposed virtual links. >=20 > But not in this case. Outside of that case, your proposal is utterly and completely = nonsensical and is not supported by any of the OSPF RFCs. > A network of routers is able to forward packets even though it has not > GUA or ULA on any of the routers. This simply is not true. At least not in any valid configuration. I=E2=80=99m not saying you can=E2=80=99t somehow force it to work on = some platforms, though I certainly wouldn=E2=80=99t expect you to be able to do so and any = platform that allows it is pretty much broken by definition. >> Similarly, an ICMP RA should have either an LL destination or a >> multicast (link scoped) destination. I cannot see any valid case for >> sending an RA off-link. >>=20 >> So that leaves us with only UDP video streaming as your remaining >> theoretical case. >>=20 >> Can you please elaborate on what possible useful case of a video >> streaming source would not have a GUA or ULA and would attempt to >> transmit said video stream off-link? >=20 > In IoT infratructure-less mobility settings there can be cases where > it's hard to form and keep a GUA (I am not talking ULA) for a > Thing-class device. For example a wifi point-of-view miniature mobile > camera attached on the windshield wiper, but without cellular modem, > may IP stream what it sees. Other vehicles hear it, display and = further > forward. You keep saying this without actually substantiating it. Where would it stream that to? By what mechanism would it be doing so? Sure, there=E2=80=99s no wireless modem, but it=E2=80=99s got to have = some sort of association with an AP or it has to be creating an ad-hoc network. If it=E2=80=99s = creating an ad-hoc network, then how do the other cars decide to connect to it? Again, your description of the application is nonsensical on multiple = levels, so it is difficult to understand your expectations. >> I realize that ULA may not be able to reach the intended destination, >> but at least that packet won=E2=80=99t make it past the border of the = network >> administrative boundary that has agreed to accept this cruft >> (hopefully) which I would argue is a very desirable property of >> whatever it is you are proposing to do here. >=20 > I think I can agree with the ULA usefulness here, because it may > be forbidden from leaking to the Internet core (although I dont quite > understand the fear of ULAs or LLs -sourced packets showing up in the > DFZ - it doesnt look at it anyways because it wants to be fast). It=E2=80=99s not fear, it=E2=80=99s a desire not to have this bizarre = anonymous cruft running around the internet because of the potential for it=E2=80=99s use by = miscreants. You=E2=80=99re making a number of invalid assumptions. You=E2=80=99re = then compounding them with multiple impractical ideas and expressing the sum of these as an = assertion of how the protocol should behave which turns out to be exactly the = opposite of any sanely desirable behavior. >=20 >>> For network control (ICMP), yes there is need to have ability to >>> reply back always, but some software uses ICMP for network control >>> and UDP for video streaming. >>>=20 >>> One should mpt use the LL src if ICMP is expected, but one could >>> very well use LL src for UDP for video streaming (video is just an >>> example app). >>=20 >> Again, I do not see a valid use case for LL Source if the destination >> is not on-link. >=20 > Assuming we have a common understanding of on-link. >=20 > I suspect your assumption of 'link' is not what many people in = mobility > settings think a link can be. A link is the set of all things which can be reached from a given = interface without having to traverse a router. That is the IPv6 definition of a link. = Since we are talking about IPv6 here, the idea of people in mobility settings if it = is different is simply wrong for the context of IPv6. If you are attempting to impose a different definition, you are also = wrong. >> This is the entire point of scoped addresses and what you are >> wanting to do discards virtually all meaning of scope. >=20 > The whole meaning of scope is new in IPv6 vs IPv4. Yes. > And it's not easy: ULAs, scoped multicast groups and networks > disconnected from the Internet are all scope complications to > implementers wondering which additional rules to add (or not) to an > otherwise very simple forwarding implementation. It=E2=80=99s very easy. Quite simple, actually. There are, essentially two scopes that really matter and a host of = scopes for multicast which can be administratively defined. The two that matter have exactly the same meaning for unicast and = multicast. They are: 1. Link Local No packet containing a Link Local Scope or Link Local = Scoped Address should traverse a router such that it is forwarded to an = interface which is not on the same link as the arrival interface. (In other words, for the definition of link that applies = to IPv6, as noted above, the packet cannot be forwarded off of that = link no matter what.) 2. Global Packets which are global in Scope or contain only global = scoped addresses may be forwarded anywhere on the internet as permitted = by local policies to reach their destination. > It's easy to enunciate and implement that each packet must have same > scope in src and dst. This is not a requirement. > But it's harder to say which non-equal scope packets can be forwarded > between interfaces of a router. No, it isn=E2=80=99t. You simply apply the most restrictive scope of the = {src,dst} scope attributes. > One would not forward a src LL dst GUA because they are different > scopes. Yet one _would_ forward a src GUA dst ULA even though they = are > different scopes too. In the first case, the packets are different scopes. But GUA and ULA are = both global scope. Perhaps this is where you are getting confused. ULA = is NOT A SCOPE. ULA is a convention. It=E2=80=99s one of the reasons I = argued that ULA was a terrible idea=E2=80=A6 I figured this confusion = about global scoped =E2=80=9Clocal=E2=80=9D addresses would be = inevitable. Sure enough, you are here to prove my point. ULA packets are the same scope as GUA. GLOBAL SCOPE. Any locality in ULA is strictly a matter of administrative convention. = If Parties A, B, C, D, E, F, G, H, and I all agree to manage their ULA = space so as to avoid conflicts and to route it, then they can form = whatever conglomeration of networks they wish and route their ULA around = as far as they like. It=E2=80=99s global scoped. Link Local, OTOH, is _NOT_ global scoped. One would _NOT_ forward a src GUA dst LL packet any more than one would = forward a src LL dst GUA. > Moreover, one _would_ forward a src ULA dst site-local multicast = group > (the ULA scope is almost the same scope as the site-scope) and, worse, > an across-subnets site-local multicast group could contain only LL > addresses if the subscribers decided to use their LLs (the = subscription > operation is a link-local operation - MLD). Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one would = forward the packet, because the scopes overlap, but one would not = forward it outside of the site (whatever administrator has defined as = site for multicast purposes). Sure, technically the subscriptions can be LL, but nobody can send a = packet to the group with their LL source and expect it to get forwarded = off of the local link. You should NOT forward a packet with src LL and dst Site-Local Multicast = group to a different link. > I would also like to mention the difficulty in understanding scopes > being 'larger' than others, or scopes 'containing' scopes as they are > found in many RFCs. 'Larger' and 'containing' may be intuitive to = many > readers (e.g. global scope is larger than link scope, the global scope > contains all links scopes), but can be hard to implementation (wifi > 'overlapping' models dont contain each other and are sometimes > disconnected from the Internet). In reality, address SCOPES and Multicast Group SCOPES are completely = separate entities and attempting to conflate them will only lead to = pain. Once you understand that, then you need to understand that address = SCOPES only come in two varieties=E2=80=A6 Link Local and Global. There=E2=80=99s no issue in terms of address scopes with overlap or = containing. Multicast scopes are stranger because they have a lot of flexibility. = Thus an administrator can actually in some cases define scopes which = overlap but are not strictly hierarchical. For example, a site may have = elements of multiple organizations, but not contain the entirety of any = or all of those organizations. Let=E2=80=99s consider, for example, a fictitious site ZZYZX which = contains all of company A, a branch office of company B, and a research = lab for company C. The multicast scopes at that site would include: Multicast Scope Company Scope Name Organization A Org-A Site A, B, C Site-ZZYZX Organization B Org-B Organization C Org-C Site-ZZYZX would technically contain Org-A and overlap, but not contain = Org-B and Org-C. The difficulty of implementing this conceptually in your software = doesn=E2=80=99t matter because each router has to be configured as to = what Organization boundaries apply and what site boundaries apply if one = intends to use those group definitions. Just send the packet to the appropriate (ideally user configured) scope = and trust that the routing system will do the right thing. >>>> Therefore, if the path of such packets can be traced, it is >>>> necessary to report a bug to various vendors concerned for them >>>> to deal with this issue in accordance with specifications as per >>>> https://tools.ietf.org/html/rfc4291#section-2.5.6. >>>=20 >>> I am not sure we must build in a capability to always trace back to >>> originators. This is may be way beyond pure packet data >>> communications. >>=20 >> That=E2=80=99s not what he is saying. What he is saying is that in = the case >> A->B->C->D->E->F->G->H->I where A sends a packet with LL src and I >> dst and I receives the packet, one should make a best effort to >> identify {H, G, F, E, D, C, B, A} and report bugs to the vendors >> responsible for the IPv6 stack implementation on each and every one >> of them because each and every one of them did something bad. >>=20 >> He is absolutely right in saying this. >=20 > By the specs, yes, he's right. Thanks to the WG members for having > provided the refs to the specs. OK, so is there anything else left to discuss? Owen --Apple-Mail=_756533F1-0059-4895-A45D-BC40242A745C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 17, 2016, at 05:53 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 17/06/2016 =C3=A0 06:16, Owen DeLong a = =C3=A9crit :

On Jun 16, 2016, at = 03:00 , Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:



Le 15/06/2016 =C3=A0 21:28, = Musa Stephen Honlue a =C3=A9crit :
This is bad behaviour both for the source device(LL should = not be
used for off-link destinations), and for = intermediary
routers(they should not forward packet = sourced with LLA).

It is clear enough that = responses to such packets won't be able
to make their way = back.

I agree - but sometimes = there is no need for response - protocols
such as OSPF or = ICMP Router Advertisements, not to mention UDP
video = streaming, dont need responses.

Um=E2=80=A6 So just to make sure I understand correctly=E2=80=A6=

Other than virtual links, OSPF route = announcements shouldn=E2=80=99t have GUA
destinations. In = the case of a virtual link, an OSPF route
announcement = shouldn=E2=80=99t have LL source.

Ah, no, I did not mean of = virtual links.

Simply an IPv6 OSPF router = must be able to send an LSA (link-state
advertisement) to a multicast group = beyond the link.

Outside of = Virtual Links, this is not correct. An OSPF router should = never
send an LSA beyond a directly connected link except in = the case of a virtual
link.

In the case of a virtual link, the routers must = use GUA or ULA on both sides,
LL is not = permitted.

And it is not for that = need that it must have a GUA/ULA.

That need does = not exist.

A network of OSPF routers = must be able to work without any GUA/ULA nor
IPv4 on any of the = routers.

Correct, but it = does this entirely with LINK SCOPED multicast packets = using
IPv6 Link Local addresses.

Of course without ULA or GUA, it doesn=E2=80=99t = have anything to advertise in the LSAs,
but it cat at least = establish neighborship and DR status.

Because it is easy to set up same network = with static routes, without
OSPF, and without GUA/ULA on them (just = the LLs).

I=E2=80=99m not = sure what prefix a static route would provide next hop information for = if
not GUA or ULA. You are making less and less sense with = each iteration of this
conversation.

In the case you seem to be proposing, virtual link with LL = source and
GUA destination, you would be sending a route = announcement that
effectively sets an un-reachable = next-hop to the remote router. I=E2=80=99m
not sure I see = any possible benefit of this action under any
circumstances.= I can, however, see several problematic outcomes
(network = singularities anyone?).

I would agree with you if = I proposed virtual links.

But not in this case.

Outside of that case, your proposal is utterly and = completely nonsensical and
is not supported by any of the OSPF = RFCs.

A network of routers is able to forward = packets even though it has not
GUA or ULA on any of the = routers.

This simply is = not true. At least not in any valid configuration.

I=E2=80=99m not saying you can=E2=80=99t somehow = force it to work on some platforms, though
I certainly = wouldn=E2=80=99t expect you to be able to do so and any platform = that
allows it is pretty much broken by = definition.

Similarly, an ICMP RA should have either an LL destination or = a
multicast (link scoped) destination. I cannot see any = valid case for
sending an RA off-link.

So that leaves us with only UDP video streaming as your = remaining
theoretical case.

Can= you please elaborate on what possible useful case of a video
streaming source would not have a GUA or ULA and would = attempt to
transmit said video stream off-link?

In IoT infratructure-less mobility settings = there can be cases where
it's hard to form and keep a GUA (I am = not talking ULA) for a
Thing-class device.  For example a = wifi point-of-view miniature mobile
camera attached on the windshield wiper, = but without cellular modem,
may IP stream what it sees.  Other = vehicles hear it, display and further
forward.

You keep saying = this without actually substantiating it.

Where would it stream that to? By what mechanism = would it be doing so?
Sure, there=E2=80=99s no wireless modem, = but it=E2=80=99s got to have some sort of association
with an = AP or it has to be creating an ad-hoc network. If it=E2=80=99s creating = an
ad-hoc network, then how do the other cars decide to = connect to it?

Again, your = description of the application is nonsensical on multiple = levels,
so it is difficult to understand your = expectations.

I realize that ULA may not be able to reach the intended = destination,
but at least that packet won=E2=80=99t make = it past the border of the network
administrative boundary = that has agreed to accept this cruft
(hopefully) which I = would argue is a very desirable property of
whatever it is = you are proposing to do here.

I think I can agree with = the ULA usefulness here, because it may
be forbidden from leaking to the Internet = core (although I dont quite
understand the fear of ULAs or LLs = -sourced packets showing up in the
DFZ - it doesnt look at it anyways = because it wants to be fast).

It=E2=80=99s not = fear, it=E2=80=99s a desire not to have this bizarre anonymous cruft = running
around the internet because of the potential for = it=E2=80=99s use by miscreants.

You=E2=80=99re making a number of invalid = assumptions. You=E2=80=99re then compounding them
with = multiple impractical ideas and expressing the sum of these as an = assertion
of how the protocol should behave which turns out to = be exactly the opposite
of any sanely desirable = behavior.


For network control = (ICMP), yes there is need to have ability to
reply back = always, but some software uses ICMP for network control
and = UDP for video streaming.

One should mpt use = the LL src if ICMP is expected, but one could
very well = use LL src for UDP for video streaming (video is just an
example app).

Again, = I do not see a valid use case for LL Source if the destination
is not on-link.

Assuming we have a common = understanding of on-link.

I suspect your assumption of 'link' is not what = many people in mobility
settings think a link can be.

A link is the set of all things which can be reached = from a given interface without
having to traverse a router. = That is the IPv6 definition of a link. Since we are
talking = about IPv6 here, the idea of people in mobility settings if it is = different
is simply wrong for the context of = IPv6.

If you are attempting to = impose a different definition, you are also wrong.

This is the entire point of scoped addresses and what you = are
wanting to do discards virtually all meaning of = scope.

The whole meaning of scope is new in IPv6 = vs IPv4.

Yes.
And it's not easy: ULAs, scoped multicast groups = and networks
disconnected from the Internet are all scope = complications to
implementers wondering which additional rules to = add (or not) to an
otherwise very simple forwarding = implementation.

It=E2=80=99s = very easy. Quite simple, actually.

There are, essentially two scopes that really = matter and a host of scopes
for multicast which can be = administratively defined.

The two = that matter have exactly the same meaning for unicast and = multicast.

They are:

1. Link Local
= No packet containing a  Link Local Scope or Link Local = Scoped Address
should traverse a router = such that it is forwarded to an interface which
= is not on the same link as the arrival interface.

(In other words, for the = definition of link that applies to IPv6, as
= noted above, the packet cannot be forwarded off of that link no = matter what.)

2. = Global
Packets which are global = in Scope or contain only global scoped addresses
= may be forwarded anywhere on the internet as permitted by local = policies to reach their
= destination.

It's easy to enunciate and = implement that each packet must have same
scope in src and dst.

This is not a requirement.

But it's harder to say which non-equal scope = packets can be forwarded
between interfaces of a router.

No, it isn=E2=80=99t. You simply apply the most = restrictive scope of the {src,dst} scope attributes.

One would not forward a src LL dst GUA because = they are different
scopes.  Yet one _would_ forward a src GUA = dst ULA even though they are
different scopes too.

In the first case, the packets are different scopes. = But GUA and ULA are both global scope. Perhaps this is where you are = getting confused. ULA is NOT A SCOPE. ULA is a convention. It=E2=80=99s = one of the reasons I argued that ULA was a terrible idea=E2=80=A6 I = figured this confusion about global scoped =E2=80=9Clocal=E2=80=9D = addresses would be inevitable. Sure enough, you are here to prove my = point.

ULA packets are the same = scope as GUA. GLOBAL SCOPE.

Any = locality in ULA is strictly a matter of administrative convention. If = Parties A, B, C, D, E, F, G, H, and I all agree to manage their ULA = space so as to avoid conflicts and to route it, then they can form = whatever conglomeration of networks they wish and route their ULA around = as far as they like. It=E2=80=99s global scoped.

Link Local, OTOH, is _NOT_ global = scoped.

One would _NOT_ forward a = src GUA dst LL packet any more than one would forward a src LL dst = GUA.

Moreover, one _would_ =  forward a src ULA dst site-local multicast group
(the ULA scope is almost = the same scope as the site-scope) and, worse,
an across-subnets = site-local multicast group could contain only LL
addresses if the = subscribers decided to use their LLs (the subscription
operation is a link-local = operation - MLD).

Again, you are = incorrect here. The ULA scope is GLOBAL. Yes, one would forward the = packet, because the scopes overlap, but one would not forward it outside = of the site (whatever administrator has defined as site for multicast = purposes).

Sure, technically the = subscriptions can be LL, but nobody can send a packet to the group with = their LL source and expect it to get forwarded off of the local = link.

You should NOT forward a = packet with src LL and dst Site-Local Multicast group to a different = link.

I would also like to = mention the difficulty in understanding scopes
being 'larger' than = others, or scopes 'containing' scopes as they are
found in many RFCs. =  'Larger' and 'containing' may be intuitive to many
readers (e.g. global scope = is larger than link scope, the global scope
contains all links = scopes), but can be hard to implementation (wifi
'overlapping' models dont = contain each other and are sometimes
disconnected from the = Internet).

In reality, = address SCOPES and Multicast Group SCOPES are completely separate = entities and attempting to conflate them will only lead to = pain.

Once you understand that, then = you need to understand that address SCOPES only come in two = varieties=E2=80=A6
Link Local and Global.

There=E2=80=99s no issue in terms of address = scopes with overlap or containing.

Multicast scopes are stranger because they have a = lot of flexibility. Thus an administrator can actually in some cases = define scopes which overlap but are not strictly hierarchical. For = example, a site may have elements of multiple organizations, but not = contain the entirety of any or all of those organizations.

Let=E2=80=99s consider, for example, a fictitious = site ZZYZX which contains all of company A, a branch office of company = B, and a research lab for company C.

The multicast scopes at that site would = include:

Multicast = Scope = Company = Scope Name
Organization = A = Org-A
Site A, B, C = Site-ZZYZX
Organization = B = Org-B
Organization = C = Org-C


Site-ZZYZX would technically contain Org-A and = overlap, but not contain Org-B and Org-C.

The difficulty of implementing this conceptually = in your software doesn=E2=80=99t matter because each router has to be = configured as to what Organization boundaries apply and what site = boundaries apply if one intends to use those group = definitions.

Just send the packet to = the appropriate (ideally user configured) scope and trust that the = routing system will do the right thing.

Therefore, if the path of such packets can be traced, it = is
necessary to report a bug to various vendors concerned = for them
to deal with this issue in accordance with = specifications as per
https://tools.ietf.org/html/rfc4291#section-2.5.6.

I am not sure we must build in a = capability to always trace back to
originators.  This = is may be way beyond pure packet data
communications.

That=E2=80=99s not what he is = saying. What he is saying is that in the case
A->B->C->D->E->F->G->H->I where A = sends a packet with LL src and I
dst and I receives the = packet, one should make a best effort to
identify {H, G, = F, E, D, C, B, A} and report bugs to the vendors
responsible= for the IPv6 stack implementation on each and every one
of = them because each and every one of them did something bad.

He is absolutely right in saying this.

By the specs, yes, he's right.  Thanks to = the WG members for having
provided the refs to the specs.

OK, so is there anything else left to = discuss?

Owen

= --Apple-Mail=_756533F1-0059-4895-A45D-BC40242A745C-- From nobody Mon Jun 20 23:46: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 B6B0412D111 for ; Mon, 20 Jun 2016 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, 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 ZE0lycDobBmd for ; Mon, 20 Jun 2016 23:46:17 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C825128E19 for ; Mon, 20 Jun 2016 23:46:17 -0700 (PDT) Received: from [2a02:fe0:c420:f008::8b1] (port=58946 helo=envy.e1.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bFFRu-0003iC-AN; Tue, 21 Jun 2016 08:46:14 +0200 Date: Tue, 21 Jun 2016 08:46:11 +0200 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20160621084611.40c55c3d@envy.e1.y.home> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.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, 21 Jun 2016 06:46:19 -0000 Hello WG, I have just posted a new version of I-D.anderson-v6ops-v4v6-xlat-prefix. The only change since -00 is to introduce the following paragraph in section 5, based on a suggestion by Holger Metschulat (thank you!) that was seconded by Alejandro Acosta: By default, IPv6 nodes and applications must not treat IPv6 addresses within 64::/16 and outside 64:ff9b::/96 different from other globally scoped IPv6 addresses. In particular, they must not make any assumptions regarding the syntax or properties of those addresses (e.g., the existence and location of embedded IPv4 addresses), or the type of associated translation mechanism (e.g., whether it is stateful or stateless). Details and links from the IETF Secretariat's announcement: Name: draft-anderson-v6ops-v4v6-xlat-prefix Revision: 01 Title: 64::/16: An IPv4/IPv6 translation prefix Document date: 2016-06-21 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-anderson-v6ops-v4v6-xlat-prefix-01.txt Status: https://datatracker.ietf.org/doc/draft-anderson-v6ops-v4v6-xlat-prefix/ Htmlized: https://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-v4v6-xlat-prefix-01 Abstract: This document reserves the IPv6 prefix 64::/16 for use with IPv4/IPv6 translation mechanisms. Tore From nobody Tue Jun 21 11:46: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 4026412DC7F for ; Tue, 21 Jun 2016 11:46:52 -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 FL38HTlap0mf for ; Tue, 21 Jun 2016 11:46:49 -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 B521012D8E6 for ; Tue, 21 Jun 2016 11:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30456; q=dns/txt; s=iport; t=1466534808; x=1467744408; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a/SHT3zK23RdD+LCNSLtIor24jeqCLkOmZfY64o1F3w=; b=UQiujyGcu5L8izMvbP/JVpLPSBc/mVhO4fNLRIpdS9d+7DQY21f1cezd 10vpZXA2gE/fPXvQt16XgiaalZBZnoasKCjf1WVFZUiGkgkPgWiO3IRmC 8tw60oSeYe49lAedOeuKfDC0KIDa4SUtp+OF8KtY67CqH1RvqeVrDoA+B g=; X-Files: ff9b-documents.txt, signature.asc : 26645, 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDKimlX/5ldJa1dgz5WfQa6b4F6I?= =?us-ascii?q?oV1AoE3OBQBAQEBAQEBZSeESwEBAQMBGg1NAwIFCwIBCBguMiUCBA4FDg2IDQg?= =?us-ascii?q?OwlkBAQEBAQEBAQEBAQEBAQEBAQEBAQEODogeglaEKkISgm6CLwWIEoVjiwQBg?= =?us-ascii?q?y2BbG6CNESFLIFpToxshlGJJgEeNoIDAh8XgTVuiQYrGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,505,1459814400"; d="asc'?txt'?scan'208";a="288391852" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2016 18:46:47 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5LIklJp026670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jun 2016 18:46:47 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 21 Jun 2016 13:46:46 -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.1104.009; Tue, 21 Jun 2016 13:46:46 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.txt Thread-Index: AQHRy+1D12+V4EVyRkeB31fG/an9Ew== Date: Tue, 21 Jun 2016 18:46:46 +0000 Message-ID: References: <20160621084611.40c55c3d@envy.e1.y.home> In-Reply-To: <20160621084611.40c55c3d@envy.e1.y.home> 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.125] Content-Type: multipart/signed; boundary="Apple-Mail=_624CA449-7C4E-4170-A26D-DA0DC899CBFF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.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, 21 Jun 2016 18:46:52 -0000 --Apple-Mail=_624CA449-7C4E-4170-A26D-DA0DC899CBFF Content-Type: multipart/mixed; boundary="Apple-Mail=_1E5ABBBA-884A-49AB-8C1D-AF3374D35F99" --Apple-Mail=_1E5ABBBA-884A-49AB-8C1D-AF3374D35F99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Take a look at the attachment; it identifies a number of RFCs and three = internet drafts (including yours) that comment on 64:ff9b::/96. I = suspect that your draft updates all, or at least several, of those RFCs, = and that it might be worthwhile corresponding with the authors of the = other two drafts. I thought about section 3.3 of RFC 6724, which says in effect that any = source address that does not imply a translator should be preferred over = a source address that does. However, that is *as*a*source*address*, and = the host would be using 64:ff9b::/32 as a destination address = (responding to a session that came in, and it has no reason to think = about whether it was through a translator). So I guess it doesn't update = that. > On Jun 20, 2016, at 11:46 PM, Tore Anderson wrote: >=20 > Hello WG, >=20 > I have just posted a new version of = I-D.anderson-v6ops-v4v6-xlat-prefix. >=20 > The only change since -00 is to introduce the following paragraph in > section 5, based on a suggestion by Holger Metschulat (thank you!) = that > was seconded by Alejandro Acosta: >=20 > By default, IPv6 nodes and applications must not treat IPv6 addresses > within 64::/16 and outside 64:ff9b::/96 different from other globally > scoped IPv6 addresses. In particular, they must not make any > assumptions regarding the syntax or properties of those addresses > (e.g., the existence and location of embedded IPv4 addresses), or the > type of associated translation mechanism (e.g., whether it is > stateful or stateless). --Apple-Mail=_1E5ABBBA-884A-49AB-8C1D-AF3374D35F99 Content-Disposition: attachment; filename=ff9b-documents.txt Content-Type: text/plain; name="ff9b-documents.txt" Content-Transfer-Encoding: 7bit https://tools.ietf.org/html/rfc6052 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) 64:ff9b::/96 +-------------------+--------------+----------------------------+ | Well-Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | +-------------------+--------------+----------------------------+ | 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 | +-------------------+--------------+----------------------------+ The prefix that we recommend has the particularity of being "checksum neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is "ffff", i.e., a value equal to zero in one's complement arithmetic. An IPv4-embedded IPv6 address constructed with this prefix will have the same one's complement checksum as the embedded IPv4 address. [6] The "Well-Known Prefix" 64:ff9b::/96 used in an algorithmic mapping between IPv4 to IPv6 addresses is defined out of the 0000::/8 address block, per RFC 6052. https://tools.ietf.org/html/rfc6146 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6146) A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 uses the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address space and a single IPv4 address 203.0.113.1 assigned to its IPv4 interface. The routing is configured in such a way that the IPv6 packets addressed to a destination address in 64:ff9b::/96 are routed to the IPv6 interface of the NAT64 device. Also shown is a local name server with DNS64 functionality. The local name server uses the Well-Known Prefix 64:ff9b::/96 to create the IPv6 addresses in the synthetic RRs. 1. H1 performs a DNS query for h2.example.com and receives the synthetic AAAA RR from the local name server that implements the DNS64 functionality. The AAAA record contains an IPv6 address formed by the Well-Known Prefix and the IPv4 address of H2 (i.e., 64:ff9b::192.0.2.1). 2. H1 sends a TCP SYN packet to H2. The packet is sent from a source transport address of (2001:db8::1,1500) to a destination transport address of (64:ff9b::192.0.2.1,80), where the ports are set by H1. * The NAT64 includes (2001:db8::1,1500) as the destination transport address in the packet and (64:ff9b::192.0.2.1,80) as the source transport address in the packet. Note that 192.0.2.1 is extracted directly from the source IPv4 address of the received IPv4 packet that is being translated. The source port 80 of the translated packet is the same as the source port of the received IPv4 packet. It is important to note that the translation still works if the IPv6 initiator H1 learns the IPv6 representation of H2's IPv4 address (i.e., 64:ff9b::192.0.2.1) through some scheme other than a DNS lookup. This is because the DNS64 processing does NOT result in any state being installed in the NAT64 and because the mapping of the IPv4 address into an IPv6 address is the result of concatenating the Well-Known Prefix to the original IPv4 address. If we note n the length of the prefix Pref64::/n, then n MUST be less than or equal to 96. If a Pref64::/n is configured through any means in the NAT64 (such as manually configured, or other automatic means not specified in this document), the default algorithm MUST use this prefix. If no prefix is available, the algorithm SHOULD use the Well-Known Prefix (64:ff9b::/96) defined in [RFC6052]. https://tools.ietf.org/html/rfc6147 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT=75103 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6147) o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved by [RFC6052] for the purpose of representing IPv4 addresses in IPv6 address space. * For each prefix Pref64::/n, n MUST be less than or equal to 96. If one or more Pref64::/n are configured in the DNS64 through any means (such as manual configuration, or other automatic means not specified in this document), the default algorithm MUST use these prefixes (and not use the Well-Known Prefix). If no prefix is available, the algorithm MUST use the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent the IPv4 unicast address range. 1. The first option is for the DNS64 server to respond authoritatively for its prefixes. If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the query using locally appropriate RDATA. The DNS64 server MAY use the same RDATA for all answers. Note that the requirement is to match any Pref64::/n used at the site, and not merely the locally configured Pref64::/n. This is because end clients could ask for a PTR record matching an address received through a different (site-provided) DNS64, and if this strategy is in effect, those queries should never be sent to the global DNS. The advantage of this strategy is that it makes plain to the querying client that the prefix is one operated by the (DNS64) site, and that the answers the client is getting are generated by DNS64. The disadvantage is that any useful reverse-tree information that might be in the global DNS is unavailable to the clients querying the DNS64. The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server. 3. The recursive name server performs an A-record query for H2 and gets back an RRSet containing a single A record with the IPv4 address 192.0.2.1. The name server then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits and the received IPv4 address in the lower 32 bits; i.e., the resulting IPv6 address is 64:ff9b::192.0.2.1. 4. H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 64:ff9b:: 192.0.2.1. The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in H1. 3. The stub resolver at H1 then queries for an A record for H2 and gets back an A record containing the IPv4 address 192.0.2.1. The DNS64 function within H1 then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits, then the received IPv4 address in the lower 32 bits; the resulting IPv6 address is 64:ff9b::192.0.2.1. 4. H1 sends a packet towards H2. The packet is sent to the destination address 64:ff9b::192.0.2.1. https://tools.ietf.org/html/rfc6346 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage. R. Bush, Ed.. August 2011. (Format: TXT=89553 bytes) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6346) * Default or Well-Known Prefix (i.e., 64:ff9b::/96) that was provisioned statically or dynamically; https://tools.ietf.org/html/rfc6890 6890 Special-Purpose IP Address Registries. M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman. April 2013. (Format: TXT=48326 bytes) (Obsoletes RFC4773, RFC5156, RFC5735, RFC5736) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6890) +----------------------+---------------------+ | Attribute | Value | +----------------------+---------------------+ | Address Block | 64:ff9b::/96 | | Name | IPv4-IPv6 Translat. | | RFC | [RFC6052] | | Allocation Date | October 2010 | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | True | | Reserved-by-Protocol | False | +----------------------+---------------------+ https://tools.ietf.org/html/rfc6992 6992 Routing for IPv4-Embedded IPv6 Packets. D. Cheng, M. Boucadair, A. Retana. July 2013. (Format: TXT=34703 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6992) The IPv6 prefix can either be the IPv6 well-known prefix (WKP) 64: ff9b::/96 or a network-specific prefix that is unique to the organization; for the latter case, the IPv6 prefix length may be 32, 40, 48, 56, or 64. In either case, this IPv6 prefix is used during the address translation between an IPv4 address and an IPv4-embedded IPv6 address, as described in [RFC6052]. The classification of an IPv4-embedded IPv6 packet is done according to the IPv6 prefix of the destination address, which is either the WKP (i.e., 64:ff9b::/96) or locally allocated as defined in [RFC6052]. https://tools.ietf.org/html/rfc7050 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. T. Savolainen, J. Korhonen, D. Wing. November 2013. (Format: TXT=50097 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7050) A node MUST look through all of the received AAAA resource records to collect one or more Pref64::/n. The Pref64::/n list might include the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network- Specific Prefixes. In the case of NSPs, the node SHALL determine the used address format by searching the received IPv6 addresses for the WKN's well-known IPv4 addresses. The node SHALL assume the well- known IPv4 addresses might be found at the locations specified by [RFC6052], Section 2.2. The node MUST check on octet boundaries to ensure a 32-bit well-known IPv4 address value is present only once in an IPv6 address. In case another instance of the value is found inside the IPv6 address, the node SHALL repeat the search with the other well-known IPv4 address. In this example, three Pref64::/n prefixes are provided by the DNS64 server. The first Pref64::/n is using an NSP, in this example, "2001:db8:42::/96". The second Pref64::/n is using an NSP, in this example, "2001:db8:43::/96". The third Pref64::/n is using the WKP. Hence, when the Pref64::/n prefixes are combined with the WKA to form Pref64::WKA, the synthetic IPv6 addresses returned by the DNS64 server are "2001:db8:42::192.0.0.170", "2001:db8:43::192.0.0.170", and "64:ff9b::192.0.0.170". The DNS64 server could also return synthetic addresses containing the IPv4 address 192.0.0.171. Node DNS64 server | | | "AAAA" query for "ipv4only.arpa." | |----------------------------------------------->|"A" query for | |"ipv4only.arpa." | |---------------> | | | | "A" response: | | "192.0.0.170" | | "192.0.0.171" | |<--------------- | +----------------------------+ | | "AAAA" synthesis using | | | three Pref64::/n. | | +----------------------------+ | "AAAA" response with: | | "2001:db8:42::192.0.0.170" | | "2001:db8:43::192.0.0.170" | | "64:ff9b::192.0.0.170" | |<-----------------------------------------------| | | +----------------------------------------------+ | | If Pref64::/n validation is not performed, a | | | node can fetch prefixes from AAAA responses | | | at this point and skip the steps below. | | +----------------------------------------------+ | | | | "PTR" query #1 for "2001:db8:42::192.0.0.170 | |----------------------------------------------->| | "PTR" query #2 for "2001:db8:43::192.0.0.170 | |----------------------------------------------->| | | | "PTR" response #1 "nat64_1.example.com" | |<-----------------------------------------------| | "PTR" response #2 "nat64_2.example.com" | |<-----------------------------------------------| | | +----------------------------------------------+ | | Compare received domains to a trusted domain | | | list and if matches are found, continue. | | +----------------------------------------------+ | | | | "AAAA" query #1 for "nat64_1.example.com" | |----------------------------------------------->| | "AAAA" query #2 for "nat64_2.example.com" | |----------------------------------------------->| https://tools.ietf.org/html/rfc7051 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix. J. Korhonen, Ed., T. Savolainen, Ed.. November 2013. (Format: TXT=55248 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7051) Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and configured by a network administrator for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace. https://tools.ietf.org/html/rfc7225 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT=40239 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7225) o Prefix64: This field identifies the IPv6 unicast prefix to be used for constructing an IPv4-converted IPv6 address from an IPv4 address as specified in Section 2.2 of [RFC6052]. This prefix can be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network- Specific Prefix. The address synthesis MUST follow the guidelines documented in [RFC6052]. https://tools.ietf.org/html/rfc7755 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT=54648 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7755) Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix (WKP) 64:ff9b::/96 may be used. From a technical point of view, both work equally well. However, only a single WKP exists, so if a provider would like to deploy more than one instance of SIIT-DC in his network, or another translation technology such as Stateful NAT64 [RFC6146], the operator will be forced to use an NSP for all but one of those deployments. https://tools.ietf.org/html/rfc7757 7757 Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT=40938 bytes) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) +---+----------------+----------------------+ | # | IPv4 Prefix | IPv6 Prefix | +---+----------------+----------------------+ | 1 | 192.0.2.1 | 2001:db8:aaaa:: | | 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 | | 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 | | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 | | 5 | 192.0.2.192/29 | 2001:db8:eeee:8::/62 | | 6 | 192.0.2.224/31 | 64:ff9b::/127 | +---+----------------+----------------------+ Assume that a stateless translator is configured with a translation prefix of 64:ff9b::/96 (per [RFC6052]) and the EAMT shown in Figure 1. The IPv6 node 2001:db8:aaaa:: transmits an IPv6 packet towards 64:ff9b::192.0.2.2, which reaches the translator and is translated into an IPv4 packet with source address 192.0.2.1 and destination address 192.0.2.2. This destination address is found in the EAMT, so the packet loops back into the translation function and is translated back to an IPv6 packet with source address 2001:db8:aaaa:: and destination address 2001:db8:bbbb::b. While this packet will reach its destination just fine, a problem will occur when 2001:db8:bbbb::b responds to it. The response packet will have a source address of 2001:db8:bbbb::b and a destination address of 2001:db8:aaaa:: and will be routed directly to its destination without being subjected to any form of translation. Because the source address of this response packet (2001:db8:bbbb::b) is not equal to the destination address of the initial outgoing packet (64:ff9b::192.0.2.2), the packet will most likely be discarded by 2001:db8:aaaa::, and bidirectional communication will most likely fail. When one or both of the address fields in an IP/ICMP packet are translated according to the EAM algorithm, the translation cannot be relied upon to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is used. This consideration is discussed in more detail in Section 4.1 of [RFC6052]. It is also assumed that the translation prefix is configured to be 64:ff9b::/96 (per [RFC6052]). +--------------+------------------------+-----------------------+ | IPv4 Address | IPv6 Address | Comment | +--------------+------------------------+-----------------------+ | 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 | | 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 | | 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 | | 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 | | 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 | | 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 | | 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 | | 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 | | 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 | | 192.0.2.195 | 2001:db8:eeee:9:8000:: | According to EAM #5 | | 192.0.2.225 | 64:ff9b::1 | According to EAM #6 | | 192.0.2.248 | 64:ff9b::c000:2f8 | According to RFC 6052 | +--------------+------------------------+-----------------------+ The following examples show how hairpinned IPv6 packets between the IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated according to Section 4. As in Appendix B, the EAMT in Figure 1 is used, and the translation prefix is 64:ff9b::/96 (per [RFC6052]). In addition, the [RFC6791] pool is assumed to contain only the single address 198.51.100.1. +--------------+--------------------+---------------------+ | XLAT Stage | Source Address | Destination Address | +--------------+--------------------+---------------------+ | Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | +--------------+--------------------+---------------------+ | Intermediate | 192.0.2.1 | 192.0.2.2 | +--------------+--------------------+---------------------+ | Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | +--------------+--------------------+---------------------+ Figure 8 illustrates how a normal (i.e., not an ICMP error) IPv6 packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is hairpinned. In this example, rule #1 in Section 4.2.1 was applied in order to disable the EAM algorithm when translating the intermediate IPv4 source address to IPv6. +--------------+-------+-----------------------+--------------------+ | XLAT Stage | Loc. | Source Address | Destination Addr. | +--------------+-------+-----------------------+--------------------+ | Initial | Outer | 2001:db8::1234 | 64:ff9b::192.0.2.1 | | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | +--------------+-------+-----------------------+--------------------+ | Intermediate | Outer | 198.51.100.1 | 192.0.2.1 | | | Inner | 192.0.2.1 | 192.0.2.2 | +--------------+-------+-----------------------+--------------------+ | Final | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: | | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | +--------------+-------+-----------------------+--------------------+ +--------------+-------+--------------------+--------------------+ | XLAT Stage | Loc. | Source Address | Destination Addr. | +--------------+-------+--------------------+--------------------+ | Initial | Outer | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | +--------------+-------+--------------------+--------------------+ | Intermediate | Outer | 192.0.2.2 | 192.0.2.1 | | | Inner | 192.0.2.1 | 192.0.2.2 | +--------------+-------+--------------------+--------------------+ | Final | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | +--------------+-------+--------------------+--------------------+ +--------------+--------------------+---------------------+ | XLAT Stage | Source Address | Destination Address | +--------------+--------------------+---------------------+ | Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | +--------------+--------------------+---------------------+ | Intermediate | 192.0.2.2 | 192.0.2.1 | +--------------+--------------------+---------------------+ | Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | +--------------+--------------------+---------------------+ https://datatracker.ietf.org/doc/draft-anderson-v6ops-v4v6-xlat-prefix https://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix "64::/16: An IPv4/IPv6 translation prefix", Tore Anderson, 2016-06-20, [RFC6052] reserves the IPv6 prefix 64:ff9b::/96 for use with IPv4/ IPv6 translation mechanisms using the stateless IP address translation algorithm specified in the same document. Well-Known Prefix (WKP) The prefix 64:ff9b::/96, which is reserved for use with the [RFC6052] IPv4/IPv6 address translation algorithm. Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new IPv4/IPv6 translation mechanisms have been defined by the IETF. These target various different use cases. An operator might therefore wish to make use of several of them simultaneously. By default, IPv6 nodes and applications must not treat IPv6 addresses within 64::/16 and outside 64:ff9b::/96 different from other globally scoped IPv6 addresses. In particular, they must not make any assumptions regarding the syntax or properties of those addresses (e.g., the existence and location of embedded IPv4 addresses), or the 64:ff9b::/96 may only be used according to [RFC6052]. https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast "Softwire Mesh Multicast", Mingwei Xu, Yong Cui, Jianping Wu, Shu Yang, Chris Metz, Greg Shepherd, 2016-05-23, In this address format, the "prefix" field contains a "Well-Known" prefix or an ISP-defined prefix. An existing "Well-Known" prefix is 64:ff9b, which is defined in [RFC6052]; "v4" field is the IP address of one of upstream AFBR's E-IPv4 interfaces; "u" field is defined in [RFC4291], and MUST be set to zero; "suffix" field is reserved for future extensions and SHOULD be set to zero; "source address" field stores the original S. We call the overall /96 prefix ("prefix" field and "v4" field and "u" field and "suffix" field altogether) "uPrefix46". In this address format, the "uPrefix64" field starts with a "Well- Known" prefix or an ISP-defined prefix. An existing "Well-Known" prefix is 64:ff9b/32, which is defined in [RFC6052]; "source address" field is the corresponding I-IPv4 source address. https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat https://tools.ietf.org/html/draft-sivakumar-yang-nat "YANG Data Model for Network Address Translation (NAT)", Senthil Sivakumar, Mohamed Boucadair, Suresh leaf nat64-prefix { type inet:ipv6-prefix; default "64:ff9b::/96"; description "A NAT64 prefix. Can be NSP or WKP [RFC6052]."; } --Apple-Mail=_1E5ABBBA-884A-49AB-8C1D-AF3374D35F99-- --Apple-Mail=_624CA449-7C4E-4170-A26D-DA0DC899CBFF 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 iQIVAwUBV2mLlUayAOS/EQ8MAQKGNQ//Yxf6LU4mjPYBBaO2nBQ3L13wUAluVhXL d1/sGNjKa6ZJVFt5a+fqEuDXK3w7ugqGgVhjr3yE10okhf0+O3W6QS7DNrqdn9yB 1afzrVOAUpvmH+IXhILHFlMhG5K841c+IlqxRkmSYInd2Ph7d3KNS25yyKoDxx08 Dve3321s1uTGJekjXqE42+lts1VseTGyzIPVnoTTcL7dzIB/dKWY78JxnzSGmw1L RagWjc7/CKjKeOCso8nDgml0i4xl9bwPu+Mr0EnY37lGoKnb1eEGP0MqYw6661ix 28zSdi4ddUES+vGLiwN8AsbshUHCQxm0M48Qs1GPt00CjEd5zG1TikSuClglEaYl MzvqG1cDt8nROzdfMm4jP+/iw9C0r/ATZOxOAla/gLAIqxOXlBzO16rJiAISkRw8 IqltaPf5H4z3HMzXUnFG9HxieAcQDB8WBmUcM63NWIxcRDtLG52UyzUSYWVmd3vo 0jZH2dhv59NqTViXFeAhwZZqfPSG/BPegZHVIRvz+cYGhZvbv8uTNLPDDL1ukX26 aAw+W0c57kD0k5QZ4jtf+scOJNEHo0ofm7FVAEqJdSq81FEmBbUYvySK0t78GlBl LFLZov4T672UkxvIEDzo89z9D5VXTlgA9Z5YdkNpmB9SvMYb8GBgUSxZB5W7Fs6w rgg5u2Kfa90= =Lc5i -----END PGP SIGNATURE----- --Apple-Mail=_624CA449-7C4E-4170-A26D-DA0DC899CBFF-- From nobody Tue Jun 21 16:57: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 E339612DA6C; Tue, 21 Jun 2016 16:57:37 -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 lPc9Lws725nW; Tue, 21 Jun 2016 16:57:36 -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 C43FC12D85D; Tue, 21 Jun 2016 16:57:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BDFFDB80D0B; Tue, 21 Jun 2016 16:57:35 -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: <20160621235735.BDFFDB80D0B@rfc-editor.org> Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World 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, 21 Jun 2016 23:57:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox: fgont@si6networks.com, furry@google.com, tim.chown@jisc.ac.uk, liushucheng@huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL: https://www.rfc-editor.org/info/rfc7872 DOI: http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Tue Jun 21 22:43: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 2DE9E12D181 for ; Tue, 21 Jun 2016 22:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FGqMy-Prohd0 for ; Tue, 21 Jun 2016 22:43:25 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E1912D1DD for ; Tue, 21 Jun 2016 22:43:24 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=46918 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bFawb-0002fK-Jo; Wed, 22 Jun 2016 07:43:21 +0200 Date: Wed, 22 Jun 2016 07:43:21 +0200 From: Tore Anderson To: "Fred Baker (fred)" Message-ID: <20160622074321.3b8a623b@echo.ms.redpill-linpro.com> In-Reply-To: References: <20160621084611.40c55c3d@envy.e1.y.home> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.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, 22 Jun 2016 05:43:27 -0000 Hi Fred, and thanks for your feedback! > Take a look at the attachment; it identifies a number of RFCs and > three internet drafts (including yours) that comment on 64:ff9b::/96. > I suspect that your draft updates all, or at least several, of those > RFCs, and that it might be worthwhile corresponding with the authors > of the other two drafts. The draft states that =C2=AB64:ff9b::/96 may only be used according to [RFC6052]=C2=BB. My reasoning for this is that any code or standard that assumes 64:ff9b::/96 has the precise properties and restrictions described in RFC6052 should be able to continue to do so without modifications. Anyone happily using 64:ff9b::/96 today can safely ignore this draft, for them nothing changes. The gist of what the draft does, on the other hand, is to legitimise the use of all the *other* prefixes in 64::/16 for generic IPv4/IPv6 translation mechanisms. That is, allow operators to configure their NAT64 or IVI or SIIT-DC or $whatever translation boxes with prefixes such as 64::/96, 64:46::/32 or whatever. IFF the technology is using RFC6052 mapping, then such usage essentially amounts to the prefix being used as a RFC6052 =C2=ABNetwork-Specific Prefix=C2=BB. However I'd also like for it to cater = to technologies that do not use RFC6052 mapping (such as RFC6219 section 3.1-style IVI or whatever new stuff someone invents in the future). > I thought about section 3.3 of RFC 6724, which says in effect that > any source address that does not imply a translator should be > preferred over a source address that does. However, that is > *as*a*source*address*, and the host would be using 64:ff9b::/32 as a > destination address (responding to a session that came in, and it has > no reason to think about whether it was through a translator). So I > guess it doesn't update that. Ack. Also note that the -01 version of the document does not demand that the 64::/16 addresses embed IPv4 addresses (except for 64:ff9b::/96 as described above), which is what section 3.3 of RFC 6724 talks about. So in summary I think the only document my draft do need to update from the list you sent is RFC6890. 64::/16 would clearly be special-purpose. Tore From nobody Wed Jun 22 00:01: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 7F8E212D1A2 for ; Wed, 22 Jun 2016 00:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECLeu7F6raSf for ; Wed, 22 Jun 2016 00:01:01 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 F423812B060 for ; Wed, 22 Jun 2016 00:01:00 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 520C0676 for ; Wed, 22 Jun 2016 07:01:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IXL1d_VdI6P for ; Wed, 22 Jun 2016 02:01:00 -0500 (CDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.161.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 28C8A647 for ; Wed, 22 Jun 2016 02:01:00 -0500 (CDT) Received: by mail-yw0-f200.google.com with SMTP id i12so77791108ywa.0 for ; Wed, 22 Jun 2016 00:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Vsz7OfStNf0SNV1H8J5Q8IDw1Z999vmx7TeRKEbDVSY=; b=sdtCB5rK0uoNISBxZIVbgMITN862NTJJkLYdXxNw+IQB0gOP2yaDr3cBzAO4fCBCSq ymkvLkNqnLPeKbEpgEuwdgmt8FSBgz5z8dNLkTVAKOu/LYAnyTBcHtqp2wgSbnLFTpsr 4s8v4+fS+A5KmcYLiXn4COI7s4Sq1BkF4xRL8= 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=Vsz7OfStNf0SNV1H8J5Q8IDw1Z999vmx7TeRKEbDVSY=; b=auMIeFoJdtzIuEbW92PKkpXs3YG5yKbSaP36rg9wT0Q1SCxXdonbALmYciFrsE8ClY uGhxejKONhn+3JgFoluZRFeq14t9kxiZKEqPUUS5g0lxAHb2TLGgFsMibf79JLX2NvwF QfqXsNUss1/8/BxG1gKI/N9QN1YyHDo+KWc7dyznMNX3gv5IShmm/4NZRWUyvnehXYy1 Hx4tesd4anRe/DBnc/jeu6JSnakBpsC/u114zu8h57O8DMF68g5Qxw2nNI4Q0EKtwIqL 2GqebWcS5h2sXDgIBf1WKHKafCA4a9f2HQ/kpdTv33Z3WvQmEosXZdxk7pxwuSGZ+MNt zmHg== X-Gm-Message-State: ALyK8tLACRIY5rXIkNsGl/paZ2i9+An+nmcEoAR+EBWuCChuYNEk4EUaWq3Ri6rt8y5Vxw9AmSxSMO5crE1z1RTH4Zc82riu6egf+greU6lov4ppjvx+BE75FzjWEPQIzSoOtqgs4UDmzeSRqjBZ X-Received: by 10.200.48.207 with SMTP id w15mr35035252qta.50.1466578859506; Wed, 22 Jun 2016 00:00:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.200.48.207 with SMTP id w15mr35035233qta.50.1466578859294; Wed, 22 Jun 2016 00:00:59 -0700 (PDT) Received: by 10.237.45.39 with HTTP; Wed, 22 Jun 2016 00:00:59 -0700 (PDT) In-Reply-To: <20160621084611.40c55c3d@envy.e1.y.home> References: <20160621084611.40c55c3d@envy.e1.y.home> Date: Wed, 22 Jun 2016 02:00:59 -0500 Message-ID: From: David Farmer To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.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, 22 Jun 2016 07:01:02 -0000 I like this idea, however, before we completely shred all of 64::/16 maybe we should consider reserving part of it for future standards actions. Would we ever want to designate another WKP different than 64:ff9b::/96? Maybe reserve 64:ff00::/24 from 64::/16 requiring standards action for use. Just a thought. ;) Also, the IANA considerations sections should designate the boolean values to go in the IANA IPv6 Special-Purpose Address Registry, just so there isn't any disagreements. On Tue, Jun 21, 2016 at 1:46 AM, Tore Anderson wrote: > Hello WG, > > I have just posted a new version of I-D.anderson-v6ops-v4v6-xlat-prefix. > > The only change since -00 is to introduce the following paragraph in > section 5, based on a suggestion by Holger Metschulat (thank you!) that > was seconded by Alejandro Acosta: > > By default, IPv6 nodes and applications must not treat IPv6 addresses > within 64::/16 and outside 64:ff9b::/96 different from other globally > scoped IPv6 addresses. In particular, they must not make any > assumptions regarding the syntax or properties of those addresses > (e.g., the existence and location of embedded IPv4 addresses), or the > type of associated translation mechanism (e.g., whether it is > stateful or stateless). -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From nobody Wed Jun 22 00:21: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 76F8612D17A for ; Wed, 22 Jun 2016 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9Rk1V1hBK6BZ for ; Wed, 22 Jun 2016 00:21:27 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D37B12D14D for ; Wed, 22 Jun 2016 00:21:24 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=53142 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1bFcTS-00059E-Dk; Wed, 22 Jun 2016 09:21:22 +0200 Date: Wed, 22 Jun 2016 09:21:22 +0200 From: Tore Anderson To: David Farmer Message-ID: <20160622092122.18155bd2@echo.ms.redpill-linpro.com> In-Reply-To: References: <20160621084611.40c55c3d@envy.e1.y.home> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: V6 Ops List Subject: Re: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.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, 22 Jun 2016 07:21:29 -0000 Hi David, * David Farmer > I like this idea, however, before we completely shred all of 64::/16 > maybe we should consider reserving part of it for future standards > actions. Would we ever want to designate another WKP different than > 64:ff9b::/96? Maybe reserve 64:ff00::/24 from 64::/16 requiring > standards action for use. Just a thought. ;) That makes sense to me, and fits well with the already specified WKP from RFC 6052 falling within that range. I'll include that in -02 unless anyone objects. > Also, the IANA considerations sections should designate the boolean > values to go in the IANA IPv6 Special-Purpose Address Registry, just > so there isn't any disagreements. Noted. Will include that in -02. Thanks for your input! Tore From nobody Wed Jun 22 06:29:58 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 84EA412D159 for ; Wed, 22 Jun 2016 06:29:56 -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 a5hD4zv9lsbK for ; Wed, 22 Jun 2016 06:29:53 -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 9442312D15E for ; Wed, 22 Jun 2016 06:29:52 -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 u5MDTjU1015933; Wed, 22 Jun 2016 15:29:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05B9E204D1C; Wed, 22 Jun 2016 15:30:37 +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 E94B5204AFE; Wed, 22 Jun 2016 15:30:36 +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 u5MDTjhX013344; Wed, 22 Jun 2016 15:29:46 +0200 To: Owen DeLong References: <57571D6E.2050102@gont.com.ar> <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@delong.com> From: Alexandre Petrescu Message-ID: <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> Date: Wed, 22 Jun 2016 15:29:45 +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: <76E49E82-018C-461D-8F85-414F4E98801B@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 22 Jun 2016 13:29:56 -0000 Owen, There seem to be some misunderstanding that I would like to clarify. Le 19/06/2016 à 21:45, Owen DeLong a écrit : > >> On Jun 17, 2016, at 05:53 , Alexandre Petrescu >> > > wrote: >> >> >> >> Le 17/06/2016 à 06:16, Owen DeLong a écrit : >>> >>>> On Jun 16, 2016, at 03:00 , Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> >>>> >>>> Le 15/06/2016 à 21:28, Musa Stephen Honlue a écrit : >>>>> This is bad behaviour both for the source device(LL should >>>>> not be used for off-link destinations), and for intermediary >>>>> routers(they should not forward packet sourced with LLA). >>>>> >>>>> It is clear enough that responses to such packets won't be >>>>> able to make their way back. >>>> >>>> I agree - but sometimes there is no need for response - >>>> protocols such as OSPF or ICMP Router Advertisements, not to >>>> mention UDP video streaming, dont need responses. >>> >>> Um… So just to make sure I understand correctly… >>> >>> Other than virtual links, OSPF route announcements shouldn’t have >>> GUA destinations. In the case of a virtual link, an OSPF route >>> announcement shouldn’t have LL source. >> >> Ah, no, I did not mean of virtual links. >> >> Simply an IPv6 OSPF router must be able to send an LSA (link-state >> advertisement) to a multicast group beyond the link. > > Outside of Virtual Links, this is not correct. An OSPF router should > never send an LSA beyond a directly connected link except in the case > of a virtual link. I may have misunderstood this, I was wrongly under the impression that OSPF sends the LSAs to all routers in the domain, not only the directly connected. > In the case of a virtual link, the routers must use GUA or ULA on > both sides, LL is not permitted. > >> And it is not for that need that it must have a GUA/ULA. > > That need does not exist. > >> A network of OSPF routers must be able to work without any GUA/ULA >> nor IPv4 on any of the routers. > > Correct, but it does this entirely with LINK SCOPED multicast packets > using IPv6 Link Local addresses. > > Of course without ULA or GUA, it doesn’t have anything to advertise > in the LSAs, (sure it has: the prefixes in the LSAs can be globally reachable, or ULA prefixes, even if the associated next-hop addresses are addresses with scope link-local only.) > but it cat at least establish neighborship and DR status. > >> Because it is easy to set up same network with static routes, >> without OSPF, and without GUA/ULA on them (just the LLs). > > I’m not sure what prefix a static route would provide next hop > information for if not GUA or ULA. I think one should be sure that the next hop information can very well be an address with link scope even if the associated prefix is of a global scope (or ULA). You are making less and less sense with each iteration > of this conversation. > >>> In the case you seem to be proposing, virtual link with LL source >>> and GUA destination, you would be sending a route announcement >>> that effectively sets an un-reachable next-hop to the remote >>> router. I’m not sure I see any possible benefit of this action >>> under any circumstances. I can, however, see several problematic >>> outcomes (network singularities anyone?). >> >> I would agree with you if I proposed virtual links. >> >> But not in this case. > > Outside of that case, your proposal is utterly and completely > nonsensical and is not supported by any of the OSPF RFCs. I looked at the OSPF RFC and I tend to agree. I wonder though whether IPv4 OSPF routers do send LSAs over to other OSPF routers across links, or not. >> A network of routers is able to forward packets even though it has >> not GUA or ULA on any of the routers. > > This simply is not true. At least not in any valid configuration. I think we completely disagree - I claim the exact opposite: routers do forward for global prefixes even though the next-hops are link-local addresses. You can have arbitrarily large IP networks with global prefixes only at thin edges, and in the core only link-local addresses. > I’m not saying you can’t somehow force it to work on some platforms, > though I certainly wouldn’t expect you to be able to do so and any > platform that allows it is pretty much broken by definition. I read but I do not comment, because I said it above. >>> Similarly, an ICMP RA should have either an LL destination or a >>> multicast (link scoped) destination. I cannot see any valid case >>> for sending an RA off-link. >>> >>> So that leaves us with only UDP video streaming as your >>> remaining theoretical case. >>> >>> Can you please elaborate on what possible useful case of a video >>> streaming source would not have a GUA or ULA and would attempt >>> to transmit said video stream off-link? >> >> In IoT infratructure-less mobility settings there can be cases >> where it's hard to form and keep a GUA (I am not talking ULA) for >> a Thing-class device. For example a wifi point-of-view miniature >> mobile camera attached on the windshield wiper, but without >> cellular modem, may IP stream what it sees. Other vehicles hear >> it, display and further forward. > > You keep saying this without actually substantiating it. > > Where would it stream that to? By what mechanism would it be doing > so? I am not substantiating it simply because it is difficult to substantiate. Nobody has done this before so I dont want to say something stupid. In all cases, the need is there: in some widespread vehicular communications there is no unicast nature of communication semantics (a car can't unicast a packet to another car) - it is all 'broadcast'. Each car broadcasts data every 1/30th seconds (30Hz) and each other car hears everybody else. The ESSID and the dst MAC address is ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address. In addition to being broadcast-only, there is no request-response kind of messages. Although the 'broadcast' nature allows each car to independently decide how far it is from other cars (and take some action like braking), there is no possibility to effectively authorize each other, or to ask other useful things in a more peer-to-peer manner. Not to mention that the broadcast-only way of communicating between many entities has obvious scalability issues: not too many cars can be around without generating much noise. In this situation, one would like to make IP work. This is difficult to substantiate. > Sure, there’s no wireless modem, but it’s got to have some sort of > association with an AP or it has to be creating an ad-hoc network. If > it’s creating an ad-hoc network, then how do the other cars decide to > connect to it? For clarification, in many vehicular networks there is no AP and no ad-hoc mode either: the mode it's called Outside the Context of a BSSID, which works by supprssing all WiFi management frames (and hence no AP no ad-hoc mode). In some other vehicular networks there are some APs along the road, or some cars are the AP (in some platooning the lead car can be AP, but not all platoons). > Again, your description of the application is nonsensical on > multiple levels, so it is difficult to understand your expectations. > >>> I realize that ULA may not be able to reach the intended >>> destination, but at least that packet won’t make it past the >>> border of the network administrative boundary that has agreed to >>> accept this cruft (hopefully) which I would argue is a very >>> desirable property of whatever it is you are proposing to do >>> here. >> >> I think I can agree with the ULA usefulness here, because it may be >> forbidden from leaking to the Internet core (although I dont quite >> understand the fear of ULAs or LLs -sourced packets showing up in >> the DFZ - it doesnt look at it anyways because it wants to be >> fast). > > It’s not fear, it’s a desire not to have this bizarre anonymous > cruft running around the internet because of the potential for it’s > use by miscreants. > > You’re making a number of invalid assumptions. You’re then > compounding them with multiple impractical ideas and expressing the > sum of these as an assertion of how the protocol should behave which > turns out to be exactly the opposite of any sanely desirable > behavior. You may come up with better idea about how IP should run in vehicular networks which are currently broadcast-only. How? >>>> For network control (ICMP), yes there is need to have ability >>>> to reply back always, but some software uses ICMP for network >>>> control and UDP for video streaming. >>>> >>>> One should mpt use the LL src if ICMP is expected, but one >>>> could very well use LL src for UDP for video streaming (video >>>> is just an example app). >>> >>> Again, I do not see a valid use case for LL Source if the >>> destination is not on-link. >> >> Assuming we have a common understanding of on-link. >> >> I suspect your assumption of 'link' is not what many people in >> mobility settings think a link can be. > > A link is the set of all things which can be reached from a given > interface without having to traverse a router. That is the IPv6 > definition of a link. Since we are talking about IPv6 here, the idea > of people in mobility settings if it is different is simply wrong for > the context of IPv6. No no, we should think that IPv6 should be applied in as many settings as possible, including wireless (mobility). The IPv6 idea of a link as 'all things which can be reached from a given interface' carries the wire Ethernet baggage along: the furthest who can be 'reached' from one interface can no longer reach anyone further - it's the 'furthest', end of cable limit. This idea does not reflect what's happening in wireless: one who can be reached on an interface can further reach others which are invisible to the first - there is no cable limit. The IPv6 idea is that somebody can 'reached' because there is a cable. To reach further there is a need of a router at a precise point: the end of the cable. In wireless there is no fixed cable and it's hard to decide where to place the routers. > If you are attempting to impose a different definition, you are also > wrong. > >>> This is the entire point of scoped addresses and what you are >>> wanting to do discards virtually all meaning of scope. >> >> The whole meaning of scope is new in IPv6 vs IPv4. > > Yes. > >> And it's not easy: ULAs, scoped multicast groups and networks >> disconnected from the Internet are all scope complications to >> implementers wondering which additional rules to add (or not) to >> an otherwise very simple forwarding implementation. > > It’s very easy. Quite simple, actually. > > There are, essentially two scopes that really matter and a host of > scopes for multicast which can be administratively defined. > > The two that matter have exactly the same meaning for unicast and > multicast. > > They are: > > 1.Link Local No packet containing a Link Local Scope or Link Local > Scoped Address should traverse a router such that it is forwarded to > an interface which is not on the same link as the arrival interface. > > (In other words, for the definition of link that applies to IPv6, as > noted above, the packet cannot be forwarded off of that link no > matter what.) > > 2.Global Packets which are global in Scope or contain only global > scoped addresses may be forwarded anywhere on the internet as > permitted by local policies to reach their destination. It's hard to define link-local scope in a setting where it's hard to define a link altogether. WiFi with AP indulges us into believing the link is everybody in that ESSID. But there is no link in WiFi w/o AP and OCB (outsid the...) >> It's easy to enunciate and implement that each packet must have >> same scope in src and dst. > > This is not a requirement. > >> But it's harder to say which non-equal scope packets can be >> forwarded between interfaces of a router. > > No, it isn’t. You simply apply the most restrictive scope of the > {src,dst} scope attributes. If it were that simple then src-based routing were already there. >> One would not forward a src LL dst GUA because they are different >> scopes. Yet one _would_ forward a src GUA dst ULA even though they >> are different scopes too. > > In the first case, the packets are different scopes. But GUA and ULA > are both global scope. Perhaps this is where you are getting > confused. ULA is NOT A SCOPE. ULA is a convention. It’s one of the > reasons I argued that ULA was a terrible idea… I figured this > confusion about global scoped “local†addresses would be inevitable. > Sure enough, you are here to prove my point. > > ULA packets are the same scope as GUA. GLOBAL SCOPE. Yet it's strange to call 'L' in ULA Global scope... > Any locality in ULA is strictly a matter of administrative > convention. If Parties A, B, C, D, E, F, G, H, and I all agree to > manage their ULA space so as to avoid conflicts and to route it, then > they can form whatever conglomeration of networks they wish and route > their ULA around as far as they like. It’s global scoped. > > Link Local, OTOH, is _NOT_ global scoped. > > One would _NOT_ forward a src GUA dst LL packet any more than one > would forward a src LL dst GUA. But one would not forward by looking at src, unless the operation were called "rewind". >> Moreover, one _would_ forward a src ULA dst site-local multicast >> group (the ULA scope is almost the same scope as the site-scope) >> and, worse, an across-subnets site-local multicast group could >> contain only LL addresses if the subscribers decided to use their >> LLs (the subscription operation is a link-local operation - MLD). > > Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one > would forward the packet, because the scopes overlap, but one would > not forward it outside of the site (whatever administrator has > defined as site for multicast purposes). > > Sure, technically the subscriptions can be LL, but nobody can send a > packet to the group with their LL source and expect it to get > forwarded off of the local link. > > You should NOT forward a packet with src LL and dst Site-Local > Multicast group to a different link. I get this 'no' from you. I would like to ask you how would you see vehicular networks work without this operation. >> I would also like to mention the difficulty in understanding >> scopes being 'larger' than others, or scopes 'containing' scopes as >> they are found in many RFCs. 'Larger' and 'containing' may be >> intuitive to many readers (e.g. global scope is larger than link >> scope, the global scope contains all links scopes), but can be hard >> to implementation (wifi 'overlapping' models dont contain each >> other and are sometimes disconnected from the Internet). > > In reality, address SCOPES and Multicast Group SCOPES are completely > separate entities and attempting to conflate them will only lead to > pain. > > Once you understand that, then you need to understand that address > SCOPES only come in two varieties… Link Local and Global. > > There’s no issue in terms of address scopes with overlap or > containing. > > Multicast scopes are stranger because they have a lot of > flexibility. Thus an administrator can actually in some cases define > scopes which overlap but are not strictly hierarchical. For example, > a site may have elements of multiple organizations, but not contain > the entirety of any or all of those organizations. > > Let’s consider, for example, a fictitious site ZZYZX which contains > all of company A, a branch office of company B, and a research lab > for company C. > > The multicast scopes at that site would include: > > Multicast ScopeCompanyScope Name OrganizationAOrg-A SiteA, B, > CSite-ZZYZX OrganizationBOrg-B OrganizationCOrg-C (figure in original message). The scopes as you depict them are frozen: they dont change. There is a god-like administrator who decides who belongs to what scope and then configures the routers. This scheme is hard to implement in vehicular networks: movements of various speeds make and de-make what's possible to be in-scope and out of scope. There is no more potent entity (like a fixed router) to which one can send subscriptions. Alex > > > Site-ZZYZX would technically contain Org-A and overlap, but not > contain Org-B and Org-C. > > The difficulty of implementing this conceptually in your software > doesn’t matter because each router has to be configured as to what > Organization boundaries apply and what site boundaries apply if one > intends to use those group definitions. > > Just send the packet to the appropriate (ideally user configured) > scope and trust that the routing system will do the right thing. > >>>>> Therefore, if the path of such packets can be traced, it is >>>>> necessary to report a bug to various vendors concerned for >>>>> them to deal with this issue in accordance with >>>>> specifications as per >>>>> https://tools.ietf.org/html/rfc4291#section-2.5.6. >>>> >>>> I am not sure we must build in a capability to always trace >>>> back to originators. This is may be way beyond pure packet >>>> data communications. >>> >>> That’s not what he is saying. What he is saying is that in the >>> case A->B->C->D->E->F->G->H->I where A sends a packet with LL src >>> and I dst and I receives the packet, one should make a best >>> effort to identify {H, G, F, E, D, C, B, A} and report bugs to >>> the vendors responsible for the IPv6 stack implementation on each >>> and every one of them because each and every one of them did >>> something bad. >>> >>> He is absolutely right in saying this. >> >> By the specs, yes, he's right. Thanks to the WG members for >> having provided the refs to the specs. > > OK, so is there anything else left to discuss? > > Owen > From nobody Wed Jun 22 15:49: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 1144E12D7AB for ; Wed, 22 Jun 2016 15:49:05 -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 VgNJfatLPr1N for ; Wed, 22 Jun 2016 15:49:01 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3512D7F8 for ; Wed, 22 Jun 2016 15:49:01 -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 u5MMlv4R025796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2016 15:47:58 -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: <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> Date: Wed, 22 Jun 2016 15:47:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> References: <57571D6E.2050102@gont.com.ar> <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> 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]); Wed, 22 Jun 2016 15:47:58 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 22 Jun 2016 22:49:05 -0000 > On Jun 22, 2016, at 06:29 , Alexandre Petrescu = wrote: >=20 > Owen, >=20 > There seem to be some misunderstanding that I would like to clarify. >=20 > Le 19/06/2016 =C3=A0 21:45, Owen DeLong a =C3=A9crit : >>=20 >>> On Jun 17, 2016, at 05:53 , Alexandre Petrescu >>> >> > wrote: >>>=20 >>>=20 >>>=20 >>> Le 17/06/2016 =C3=A0 06:16, Owen DeLong a =C3=A9crit : >>>>=20 >>>>> On Jun 16, 2016, at 03:00 , Alexandre Petrescu >>>>> >>>> > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Le 15/06/2016 =C3=A0 21:28, Musa Stephen Honlue a =C3=A9crit : >>>>>> This is bad behaviour both for the source device(LL should >>>>>> not be used for off-link destinations), and for intermediary >>>>>> routers(they should not forward packet sourced with LLA). >>>>>>=20 >>>>>> It is clear enough that responses to such packets won't be >>>>>> able to make their way back. >>>>>=20 >>>>> I agree - but sometimes there is no need for response - >>>>> protocols such as OSPF or ICMP Router Advertisements, not to >>>>> mention UDP video streaming, dont need responses. >>>>=20 >>>> Um=E2=80=A6 So just to make sure I understand correctly=E2=80=A6 >>>>=20 >>>> Other than virtual links, OSPF route announcements shouldn=E2=80=99t = have >>>> GUA destinations. In the case of a virtual link, an OSPF route >>>> announcement shouldn=E2=80=99t have LL source. >>>=20 >>> Ah, no, I did not mean of virtual links. >>>=20 >>> Simply an IPv6 OSPF router must be able to send an LSA (link-state >>> advertisement) to a multicast group beyond the link. >>=20 >> Outside of Virtual Links, this is not correct. An OSPF router should >> never send an LSA beyond a directly connected link except in the case >> of a virtual link. >=20 > I may have misunderstood this, I was wrongly under the impression that > OSPF sends the LSAs to all routers in the domain, not only the = directly > connected. Nope=E2=80=A6 AIUI, only to the neighbor routers who then flood them to = their neighbors, etc. >=20 >> In the case of a virtual link, the routers must use GUA or ULA on >> both sides, LL is not permitted. >>=20 >>> And it is not for that need that it must have a GUA/ULA. >>=20 >> That need does not exist. >>=20 >>> A network of OSPF routers must be able to work without any GUA/ULA >>> nor IPv4 on any of the routers. >>=20 >> Correct, but it does this entirely with LINK SCOPED multicast packets >> using IPv6 Link Local addresses. >>=20 >> Of course without ULA or GUA, it doesn=E2=80=99t have anything to = advertise >> in the LSAs, >=20 > (sure it has: the prefixes in the LSAs can be globally reachable, or = ULA > prefixes, even if the associated next-hop addresses are addresses with > scope link-local only.) But if they are working without any GUA or ULA, then they don=E2=80=99t = have any GUA or ULA to advertise in those LSAs. (Unless you and I have very different definitions of =E2=80=9Cworking without any=E2=80=A6=E2=80=9D= . True, the routers don=E2=80=99t need to possess any GUA or ULA addresses = themselves, but I don=E2=80=99t see this as relevant to the discussion. >=20 >> but it cat at least establish neighborship and DR status. >>=20 >>> Because it is easy to set up same network with static routes, >>> without OSPF, and without GUA/ULA on them (just the LLs). >>=20 >> I=E2=80=99m not sure what prefix a static route would provide next = hop >> information for if not GUA or ULA. >=20 > I think one should be sure that the next hop information can very well > be an address with link scope even if the associated prefix is of a > global scope (or ULA). Of course, but the link scoped next-hop address has to be on a directly = attached link and next-hop addresses never appear in IP headers. >=20 > You are making less and less sense with each iteration >> of this conversation. >>=20 >>>> In the case you seem to be proposing, virtual link with LL source >>>> and GUA destination, you would be sending a route announcement >>>> that effectively sets an un-reachable next-hop to the remote >>>> router. I=E2=80=99m not sure I see any possible benefit of this = action >>>> under any circumstances. I can, however, see several problematic >>>> outcomes (network singularities anyone?). >>>=20 >>> I would agree with you if I proposed virtual links. >>>=20 >>> But not in this case. >>=20 >> Outside of that case, your proposal is utterly and completely >> nonsensical and is not supported by any of the OSPF RFCs. >=20 > I looked at the OSPF RFC and I tend to agree. >=20 > I wonder though whether IPv4 OSPF routers do send LSAs over to other > OSPF routers across links, or not. No. Only to direct neighbors. This is no different from OSPFv2 to OSPFv3. >=20 >>> A network of routers is able to forward packets even though it has >>> not GUA or ULA on any of the routers. >>=20 >> This simply is not true. At least not in any valid configuration. >=20 > I think we completely disagree - I claim the exact opposite: routers = do > forward for global prefixes even though the next-hops are link-local > addresses. You can have arbitrarily large IP networks with global > prefixes only at thin edges, and in the core only link-local = addresses. Sure, but in this case, you are not forwarding packets which have LL source or destination across links. You are forwarding packets which = have GUA and/or ULA src/dest headers across links which happen to have only = LL addresses on those links. That is valid. What is not valid is having a packet with an LL source or destination in the IP header forward from one link to a different link. >> I=E2=80=99m not saying you can=E2=80=99t somehow force it to work on = some platforms, >> though I certainly wouldn=E2=80=99t expect you to be able to do so = and any >> platform that allows it is pretty much broken by definition. >=20 > I read but I do not comment, because I said it above. Your new example has to have GUA on at least the edge routers of the scenario you describe, so I argue that it does not fall within the scope of my previous statements. >>>> Similarly, an ICMP RA should have either an LL destination or a >>>> multicast (link scoped) destination. I cannot see any valid case >>>> for sending an RA off-link. >>>>=20 >>>> So that leaves us with only UDP video streaming as your >>>> remaining theoretical case. >>>>=20 >>>> Can you please elaborate on what possible useful case of a video >>>> streaming source would not have a GUA or ULA and would attempt >>>> to transmit said video stream off-link? >>>=20 >>> In IoT infratructure-less mobility settings there can be cases >>> where it's hard to form and keep a GUA (I am not talking ULA) for >>> a Thing-class device. For example a wifi point-of-view miniature >>> mobile camera attached on the windshield wiper, but without >>> cellular modem, may IP stream what it sees. Other vehicles hear >>> it, display and further forward. >>=20 >> You keep saying this without actually substantiating it. >>=20 >> Where would it stream that to? By what mechanism would it be doing >> so? >=20 > I am not substantiating it simply because it is difficult to > substantiate. Nobody has done this before so I dont want to say > something stupid. There are IMHO many reasons nobody has done this before. As to your last sentence, I will refrain from comment so as to avoid the potential of ad hominem. > In all cases, the need is there: in some widespread vehicular > communications there is no unicast nature of communication semantics = (a > car can't unicast a packet to another car) - it is all 'broadcast'. > Each car broadcasts data every 1/30th seconds (30Hz) and each other = car > hears everybody else. The ESSID and the dst MAC address is > ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's = address. Then perhaps you should get a reserved multicast group number for =E2=80=9C= all cars=E2=80=9D. Then, you can use =E2=80=9Call cars on link=E2=80=9D for link scoped = communications where a LL source address would be valid and =E2=80=9Call cars within ORG=E2=80=9D= for an ORG scoped communication using a ULA source, etc. There are clean ways to do this, but the proposals you have put forth so = far, however, are not. There is no concept of broadcast in IPv6, so you can=E2=80=99t do = =E2=80=9Cbroadcast-only=E2=80=9D. You have to use multicast. > In addition to being broadcast-only, there is no request-response kind > of messages. Although the 'broadcast' nature allows each car to > independently decide how far it is from other cars (and take some = action > like braking), there is no possibility to effectively authorize each > other, or to ask other useful things in a more peer-to-peer manner. So you want to put passenger safety in the hands of unauthenticated = multicast packets=E2=80=A6 What could possibly go wrong? Please let me know which = manufacturers you are working with so as I can avoid purchasing their products. I suggest you look at TCAS from the aviation world and rethink your = ideas here. There is much more data available and it can be used in much = better ways. To make matters worse, if you use open broadcasts and no authentication, = then all I have to do to commit a pretty gross DDOS is build an autoresponder = that will always tell each car from which it hears an announcement that I = have suddenly appeared directly in front of it at close range. Everyone in the car gets the maximum braking experience for no reason = and likely receives the rear-end experience in something like 5% of cases. That=E2=80=99s just lovely. > Not to mention that the broadcast-only way of communicating between = many > entities has obvious scalability issues: not too many cars can be = around > without generating much noise. So why would you possibly ever consider such a thing. > In this situation, one would like to make IP work. This is difficult = to > substantiate. In this situation, I think one needs to completely rethink their system. = The model has so many fundamental flaws that I think it is a nightmare = waiting to happen if it ever achieves anything remotely approaching widespread = implementation. I would never knowingly buy a car which implements such a thing in such = a terribly flawed way. >> Sure, there=E2=80=99s no wireless modem, but it=E2=80=99s got to have = some sort of >> association with an AP or it has to be creating an ad-hoc network. If >> it=E2=80=99s creating an ad-hoc network, then how do the other cars = decide to >> connect to it? >=20 > For clarification, in many vehicular networks there is no AP and no > ad-hoc mode either: the mode it's called Outside the Context of a = BSSID, > which works by supprssing all WiFi management frames (and hence no AP = no > ad-hoc mode). This seems like an inherently bad idea on multiple levels. > In some other vehicular networks there are some APs along the road, or > some cars are the AP (in some platooning the lead car can be AP, but = not > all platoons). Right, well, regardless of the underlying L2 structure, I hope I=E2=80=99v= e been able to show you why the restrictions you attempt to put forward as inherent = in design decisions already made are fundamentally flawed in terms of even = making your system work even _IF_ IP could somehow cope with these poor = choices, which I believe it most likely cannot. >> Again, your description of the application is nonsensical on >> multiple levels, so it is difficult to understand your expectations. >>=20 >>>> I realize that ULA may not be able to reach the intended >>>> destination, but at least that packet won=E2=80=99t make it past = the >>>> border of the network administrative boundary that has agreed to >>>> accept this cruft (hopefully) which I would argue is a very >>>> desirable property of whatever it is you are proposing to do >>>> here. >>>=20 >>> I think I can agree with the ULA usefulness here, because it may be >>> forbidden from leaking to the Internet core (although I dont quite >>> understand the fear of ULAs or LLs -sourced packets showing up in >>> the DFZ - it doesnt look at it anyways because it wants to be >>> fast). >>=20 >> It=E2=80=99s not fear, it=E2=80=99s a desire not to have this bizarre = anonymous >> cruft running around the internet because of the potential for it=E2=80= =99s >> use by miscreants. >>=20 >> You=E2=80=99re making a number of invalid assumptions. You=E2=80=99re = then >> compounding them with multiple impractical ideas and expressing the >> sum of these as an assertion of how the protocol should behave which >> turns out to be exactly the opposite of any sanely desirable >> behavior. >=20 > You may come up with better idea about how IP should run in vehicular = networks which are currently broadcast-only. How? First of all, you need to recognize that you=E2=80=99re going to need = more security than is possible with your proposed design. Go back and rethink the fundamental communications model and think in terms of what bad things can happen if someone wants to inject false information into the = network. You need to either mitigate ALL of those events or better still, prevent false information from being injected. Since prevention of injection = will require some form of authentication and authorization, I think you have to move beyond all-broadcast anyway. Frankly, I worry about this with the design of ADS-B and modern TCAS today for aircraft, but there=E2=80=99s at least some level of = mitigation there. Your proposed network is significantly weaker than that one and offers a much larger target base that is much easier for miscreants to attack. >>>>> For network control (ICMP), yes there is need to have ability >>>>> to reply back always, but some software uses ICMP for network >>>>> control and UDP for video streaming. >>>>>=20 >>>>> One should mpt use the LL src if ICMP is expected, but one >>>>> could very well use LL src for UDP for video streaming (video >>>>> is just an example app). >>>>=20 >>>> Again, I do not see a valid use case for LL Source if the >>>> destination is not on-link. >>>=20 >>> Assuming we have a common understanding of on-link. >>>=20 >>> I suspect your assumption of 'link' is not what many people in >>> mobility settings think a link can be. >>=20 >> A link is the set of all things which can be reached from a given >> interface without having to traverse a router. That is the IPv6 >> definition of a link. Since we are talking about IPv6 here, the idea >> of people in mobility settings if it is different is simply wrong for >> the context of IPv6. >=20 > No no, we should think that IPv6 should be applied in as many settings = as possible, including wireless (mobility). That=E2=80=99s not my point. I=E2=80=99m saying that in the context of = IPv6, their definition of the term =E2=80=9Clink=E2=80=9D is wrong. Not = that it is wrong to use IPv6. > The IPv6 idea of a link as 'all things which can be reached from a = given interface' carries the wire Ethernet baggage along: the furthest = who can be 'reached' from one interface can no longer reach anyone = further - it's the 'furthest', end of cable limit. This idea does not = reflect what's happening in wireless: one who can be reached on an = interface can further reach others which are invisible to the first - = there is no cable limit. Once they are invisible and require forwarding, they are OFF LINK and = MUST BE FORWARDED. At that point, you can=E2=80=99t use LL. > The IPv6 idea is that somebody can 'reached' because there is a cable. = To reach further there is a need of a router at a precise point: the end = of the cable. No, the IPv6 idea is that there are two kinds of hosts. Those that can = be directly reached (ON LINK) and those which require forwarding (OFF = LINK). It doesn=E2=80=99t matter whether this is cable or wireless. If = you can directly reach it from your own local interface, then it is ON = LINK. If you need to depend on another host to forward the packet from = you to the other host you want to talk to, then that host in the middle = is called a router and the other host is OFF LINK. > In wireless there is no fixed cable and it's hard to decide where to = place the routers. Every form of deployment has its own challenges. It doesn=E2=80=99t = change the definition of what is on or off of a LINK. >=20 >> If you are attempting to impose a different definition, you are also >> wrong. >>=20 >>>> This is the entire point of scoped addresses and what you are >>>> wanting to do discards virtually all meaning of scope. >>>=20 >>> The whole meaning of scope is new in IPv6 vs IPv4. >>=20 >> Yes. >>=20 >>> And it's not easy: ULAs, scoped multicast groups and networks >>> disconnected from the Internet are all scope complications to >>> implementers wondering which additional rules to add (or not) to >>> an otherwise very simple forwarding implementation. >>=20 >> It=E2=80=99s very easy. Quite simple, actually. >>=20 >> There are, essentially two scopes that really matter and a host of >> scopes for multicast which can be administratively defined. >>=20 >> The two that matter have exactly the same meaning for unicast and >> multicast. >>=20 >> They are: >>=20 >> 1.Link Local No packet containing a Link Local Scope or Link Local >> Scoped Address should traverse a router such that it is forwarded to >> an interface which is not on the same link as the arrival interface. >>=20 >> (In other words, for the definition of link that applies to IPv6, as >> noted above, the packet cannot be forwarded off of that link no >> matter what.) >>=20 >> 2.Global Packets which are global in Scope or contain only global >> scoped addresses may be forwarded anywhere on the internet as >> permitted by local policies to reach their destination. >=20 > It's hard to define link-local scope in a setting where it's hard to = define a link altogether. But it=E2=80=99s NOT hard to define a link. A link is well defined. What = is hard is that you don=E2=80=99t like the definition of a link and you = want to somehow apply some magical definition that doesn=E2=80=99t = actually work. > WiFi with AP indulges us into believing the link is everybody in that = ESSID. It doesn=E2=80=99t indulge us to believe, it makes that the case. > But there is no link in WiFi w/o AP and OCB (outsid the=E2=80=A6) Sure there is=E2=80=A6 It=E2=80=99s limited to the vehicles that can = directly see your packets because you don=E2=80=99t have an L2 forwarder = (AP) specifically responsible for forwarding those packets. If you come up with a somewhat reliable mechanism for L2 forwarding of = these datagrams, then you can extend your idea of a link farther, but = you=E2=80=99re going to quickly run into scaling issues with traffic = saturation as your broadcast domain grows. >>> It's easy to enunciate and implement that each packet must have >>> same scope in src and dst. >>=20 >> This is not a requirement. It _IS_ a requirement in IPv6. >>> But it's harder to say which non-equal scope packets can be >>> forwarded between interfaces of a router. >>=20 >> No, it isn=E2=80=99t. You simply apply the most restrictive scope of = the >> {src,dst} scope attributes. >=20 > If it were that simple then src-based routing were already there. That=E2=80=99s like saying =E2=80=9CIf apples, then space ships.=E2=80=9D It makes literally no sense whatsoever to me. Source routing has nothing to do with this and isn=E2=80=99t applicable = to IPv6. If a router receives a packet with different scoped addresses, then it must apply the forwarding policy applicable to the most restrictive = scope present. Thus, LL,ULA =3D=3D LL, LL,GUA =3D=3D LL, ULA,GUA =3D=3D Global, GUA,GUA = =3D=3D Global ULA, ULA =3D=3D Global. >>> One would not forward a src LL dst GUA because they are different >>> scopes. Yet one _would_ forward a src GUA dst ULA even though they >>> are different scopes too. >>=20 >> In the first case, the packets are different scopes. But GUA and ULA >> are both global scope. Perhaps this is where you are getting >> confused. ULA is NOT A SCOPE. ULA is a convention. It=E2=80=99s one = of the >> reasons I argued that ULA was a terrible idea=E2=80=A6 I figured this >> confusion about global scoped =E2=80=9Clocal=E2=80=9D addresses would = be inevitable. >> Sure enough, you are here to prove my point. >>=20 >> ULA packets are the same scope as GUA. GLOBAL SCOPE. >=20 > Yet it's strange to call 'L' in ULA Global scope=E2=80=A6 ULA isn=E2=80=99t a scope. It=E2=80=99s a convention. The problem here is that you keep confusing yourself by thinking of the L in ULA as being a scope definition. It=E2=80=99s not. It=E2=80=99s = just a convention. >> Any locality in ULA is strictly a matter of administrative >> convention. If Parties A, B, C, D, E, F, G, H, and I all agree to >> manage their ULA space so as to avoid conflicts and to route it, then >> they can form whatever conglomeration of networks they wish and route >> their ULA around as far as they like. It=E2=80=99s global scoped. >>=20 >> Link Local, OTOH, is _NOT_ global scoped. >>=20 >> One would _NOT_ forward a src GUA dst LL packet any more than one >> would forward a src LL dst GUA. >=20 > But one would not forward by looking at src, unless the operation were = called "rewind=E2=80=9D. In IPv6, the way the protocol is designed, you must look at the scope of = the source address before forwarding it to an interface other than one on the same = link as the interface where the packet arrived. It is a requirement documented in = the RFCs. So your above claim is patently false. You are wrong. It=E2=80=99s as = simple as that. You are required to look at the src before forwarding the packet. You don=E2=80=99= t necessarily use the src in determining where to forward the packet, but you must = consider the scope of the source address in deciding whether or not to forward the packet. >>> Moreover, one _would_ forward a src ULA dst site-local multicast >>> group (the ULA scope is almost the same scope as the site-scope) >>> and, worse, an across-subnets site-local multicast group could >>> contain only LL addresses if the subscribers decided to use their >>> LLs (the subscription operation is a link-local operation - MLD). >>=20 >> Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one >> would forward the packet, because the scopes overlap, but one would >> not forward it outside of the site (whatever administrator has >> defined as site for multicast purposes). >>=20 >> Sure, technically the subscriptions can be LL, but nobody can send a >> packet to the group with their LL source and expect it to get >> forwarded off of the local link. >>=20 >> You should NOT forward a packet with src LL and dst Site-Local >> Multicast group to a different link. >=20 > I get this 'no' from you. >=20 > I would like to ask you how would you see vehicular networks work = without this operation. Presumably with something other than LL addresses. >>> I would also like to mention the difficulty in understanding >>> scopes being 'larger' than others, or scopes 'containing' scopes as >>> they are found in many RFCs. 'Larger' and 'containing' may be >>> intuitive to many readers (e.g. global scope is larger than link >>> scope, the global scope contains all links scopes), but can be hard >>> to implementation (wifi 'overlapping' models dont contain each >>> other and are sometimes disconnected from the Internet). >>=20 >> In reality, address SCOPES and Multicast Group SCOPES are completely >> separate entities and attempting to conflate them will only lead to >> pain. >>=20 >> Once you understand that, then you need to understand that address >> SCOPES only come in two varieties=E2=80=A6 Link Local and Global. >>=20 >> There=E2=80=99s no issue in terms of address scopes with overlap or >> containing. >>=20 >> Multicast scopes are stranger because they have a lot of >> flexibility. Thus an administrator can actually in some cases define >> scopes which overlap but are not strictly hierarchical. For example, >> a site may have elements of multiple organizations, but not contain >> the entirety of any or all of those organizations. >>=20 >> Let=E2=80=99s consider, for example, a fictitious site ZZYZX which = contains >> all of company A, a branch office of company B, and a research lab >> for company C. >>=20 >> The multicast scopes at that site would include: >>=20 >> Multicast ScopeCompanyScope Name OrganizationAOrg-A SiteA, B, >> CSite-ZZYZX OrganizationBOrg-B OrganizationCOrg-C >=20 > (figure in original message). >=20 > The scopes as you depict them are frozen: they dont change. There is = a god-like administrator who decides who belongs to what scope and then = configures the routers. As is the case in the vast majority of implementations and as is the = case in the IPv6 protocol design. > This scheme is hard to implement in vehicular networks: movements of = various speeds make and de-make what's possible to be in-scope and out = of scope. There is no more potent entity (like a fixed router) to which = one can send subscriptions. Hosts come and go from Mobile networks and from WiFi networks all the = time. There=E2=80=99s constant flux on which hosts are ON-LINK or not ON-LINK = from any given perspective. Sure, this could be a particularly challenging aspect of your particular = use case. That=E2=80=99s your challenge to solve, but you don=E2=80=99t get to = change IPv6 in a way that is detrimental to all other users in order to solve it, nor do you get to = simply pretend that IPv6 behaves (or should behave) differently because it is = convenient to your application. The problem you are trying not to solve is frankly not one you will be = able to avoid solving anyway. You=E2=80=99re going to have to solve that problem in order to have any = reasonable measure of security in=20 your application. Owen From nobody Thu Jun 23 06:39: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 391CD12B006 for ; Thu, 23 Jun 2016 06:39:48 -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 Y_eDbysTHQeL for ; Thu, 23 Jun 2016 06:39:45 -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 9F80612B018 for ; Thu, 23 Jun 2016 06:39:44 -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 u5NDdbYf016762; Thu, 23 Jun 2016 15:39:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B4C2F2092FD; Thu, 23 Jun 2016 15:40:29 +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 A40252094AF; Thu, 23 Jun 2016 15:40:29 +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 u5NDdbgG020848; Thu, 23 Jun 2016 15:39:37 +0200 To: 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> From: Alexandre Petrescu Message-ID: Date: Thu, 23 Jun 2016 15:39:37 +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: <4A552EFF-B16E-4872-933B-9244F7057DA0@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 23 Jun 2016 13:39:48 -0000 Le 23/06/2016 à 00:47, Owen DeLong a écrit : [...] >> In all cases, the need is there: in some widespread vehicular >> communications there is no unicast nature of communication semantics (a >> car can't unicast a packet to another car) - it is all 'broadcast'. >> Each car broadcasts data every 1/30th seconds (30Hz) and each other car >> hears everybody else. The ESSID and the dst MAC address is >> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address. > > Then perhaps you should get a reserved multicast group number for “all carsâ€. Well I wonder about the name. The too familiar 'cars' could be more pedantic 'vehicles' or 'light vehicles'. But 'vehicles' would look strange in the current list of nodes, routers, servers or agents http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > Then, you can use “all cars on link†for link scoped communications where > a LL source address would be valid and “all cars within ORG†for an ORG scoped > communication using a ULA source, etc. 'ORG' - 'organization' is obviously not the right word for something ephemeral happening between a few cars on a highway none of which being more entitled than another. > There are clean ways to do this, but the proposals you have put forth so far, > however, are not. I am looking for clean ways dealing with situations where it's hard to say who is the 'owner' or the control entity which keeps track of multicast registrations in some scope. > There is no concept of broadcast in IPv6, so you can’t do “broadcast-onlyâ€. > You have to use multicast. The word 'broadcast' can be ambiguous in this discussion. In vehicular communications 'broadcasting' means to send in the ether, as opposed to sending on a wired Ethernet; and it also means there is no return path - a little bit like in 'TV broadcast'. In a particular report, they say "DSRC operates in constant broadcast-and-receive mode": you periodically broadcast to everyone else and always receive from everyone else, but you can not send to just one entity. This 'broadcast' concept of vehicles is independent of the fact that the MAC dst address is ff:ff:ff:ff:ff:ff (MAC broadcast address). But yes I agree with you when it comes to IPv6 it should use multicast addressing, not broadcast addressing. 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. Alex > >> In addition to being broadcast-only, there is no request-response kind >> of messages. Although the 'broadcast' nature allows each car to >> independently decide how far it is from other cars (and take some action >> like braking), there is no possibility to effectively authorize each >> other, or to ask other useful things in a more peer-to-peer manner. > > So you want to put passenger safety in the hands of unauthenticated multicast > packets… What could possibly go wrong? Please let me know which manufacturers > you are working with so as I can avoid purchasing their products. > > I suggest you look at TCAS from the aviation world and rethink your ideas > here. There is much more data available and it can be used in much better > ways. > > To make matters worse, if you use open broadcasts and no authentication, then > all I have to do to commit a pretty gross DDOS is build an autoresponder that > will always tell each car from which it hears an announcement that I have > suddenly appeared directly in front of it at close range. > > Everyone in the car gets the maximum braking experience for no reason and > likely receives the rear-end experience in something like 5% of cases. > > That’s just lovely. > >> Not to mention that the broadcast-only way of communicating between many >> entities has obvious scalability issues: not too many cars can be around >> without generating much noise. > > So why would you possibly ever consider such a thing. > >> In this situation, one would like to make IP work. This is difficult to >> substantiate. > > In this situation, I think one needs to completely rethink their system. The > model has so many fundamental flaws that I think it is a nightmare waiting to > happen if it ever achieves anything remotely approaching widespread implementation. > > I would never knowingly buy a car which implements such a thing in such a terribly > flawed way. > >>> Sure, there’s no wireless modem, but it’s got to have some sort of >>> association with an AP or it has to be creating an ad-hoc network. If >>> it’s creating an ad-hoc network, then how do the other cars decide to >>> connect to it? >> >> For clarification, in many vehicular networks there is no AP and no >> ad-hoc mode either: the mode it's called Outside the Context of a BSSID, >> which works by supprssing all WiFi management frames (and hence no AP no >> ad-hoc mode). > > This seems like an inherently bad idea on multiple levels. > >> In some other vehicular networks there are some APs along the road, or >> some cars are the AP (in some platooning the lead car can be AP, but not >> all platoons). > > Right, well, regardless of the underlying L2 structure, I hope I’ve been able > to show you why the restrictions you attempt to put forward as inherent in > design decisions already made are fundamentally flawed in terms of even making > your system work even _IF_ IP could somehow cope with these poor choices, which > I believe it most likely cannot. > >>> Again, your description of the application is nonsensical on >>> multiple levels, so it is difficult to understand your expectations. >>> >>>>> I realize that ULA may not be able to reach the intended >>>>> destination, but at least that packet won’t make it past the >>>>> border of the network administrative boundary that has agreed to >>>>> accept this cruft (hopefully) which I would argue is a very >>>>> desirable property of whatever it is you are proposing to do >>>>> here. >>>> >>>> I think I can agree with the ULA usefulness here, because it may be >>>> forbidden from leaking to the Internet core (although I dont quite >>>> understand the fear of ULAs or LLs -sourced packets showing up in >>>> the DFZ - it doesnt look at it anyways because it wants to be >>>> fast). >>> >>> It’s not fear, it’s a desire not to have this bizarre anonymous >>> cruft running around the internet because of the potential for it’s >>> use by miscreants. >>> >>> You’re making a number of invalid assumptions. You’re then >>> compounding them with multiple impractical ideas and expressing the >>> sum of these as an assertion of how the protocol should behave which >>> turns out to be exactly the opposite of any sanely desirable >>> behavior. >> >> You may come up with better idea about how IP should run in vehicular networks which are currently broadcast-only. How? > > First of all, you need to recognize that you’re going to need more security > than is possible with your proposed design. Go back and rethink the > fundamental communications model and think in terms of what bad things > can happen if someone wants to inject false information into the network. > > You need to either mitigate ALL of those events or better still, prevent > false information from being injected. Since prevention of injection will > require some form of authentication and authorization, I think you have > to move beyond all-broadcast anyway. > > Frankly, I worry about this with the design of ADS-B and modern TCAS > today for aircraft, but there’s at least some level of mitigation there. > Your proposed network is significantly weaker than that one and offers > a much larger target base that is much easier for miscreants to attack. > >>>>>> For network control (ICMP), yes there is need to have ability >>>>>> to reply back always, but some software uses ICMP for network >>>>>> control and UDP for video streaming. >>>>>> >>>>>> One should mpt use the LL src if ICMP is expected, but one >>>>>> could very well use LL src for UDP for video streaming (video >>>>>> is just an example app). >>>>> >>>>> Again, I do not see a valid use case for LL Source if the >>>>> destination is not on-link. >>>> >>>> Assuming we have a common understanding of on-link. >>>> >>>> I suspect your assumption of 'link' is not what many people in >>>> mobility settings think a link can be. >>> >>> A link is the set of all things which can be reached from a given >>> interface without having to traverse a router. That is the IPv6 >>> definition of a link. Since we are talking about IPv6 here, the idea >>> of people in mobility settings if it is different is simply wrong for >>> the context of IPv6. >> >> No no, we should think that IPv6 should be applied in as many settings as possible, including wireless (mobility). > > That’s not my point. I’m saying that in the context of IPv6, their definition of the term “link†is wrong. Not that it is wrong to use IPv6. > >> The IPv6 idea of a link as 'all things which can be reached from a given interface' carries the wire Ethernet baggage along: the furthest who can be 'reached' from one interface can no longer reach anyone further - it's the 'furthest', end of cable limit. This idea does not reflect what's happening in wireless: one who can be reached on an interface can further reach others which are invisible to the first - there is no cable limit. > > Once they are invisible and require forwarding, they are OFF LINK and MUST BE FORWARDED. At that point, you can’t use LL. > >> The IPv6 idea is that somebody can 'reached' because there is a cable. To reach further there is a need of a router at a precise point: the end of the cable. > > No, the IPv6 idea is that there are two kinds of hosts. Those that can be directly reached (ON LINK) and those which require forwarding (OFF LINK). It doesn’t matter whether this is cable or wireless. If you can directly reach it from your own local interface, then it is ON LINK. If you need to depend on another host to forward the packet from you to the other host you want to talk to, then that host in the middle is called a router and the other host is OFF LINK. > >> In wireless there is no fixed cable and it's hard to decide where to place the routers. > > Every form of deployment has its own challenges. It doesn’t change the definition of what is on or off of a LINK. > >> >>> If you are attempting to impose a different definition, you are also >>> wrong. >>> >>>>> This is the entire point of scoped addresses and what you are >>>>> wanting to do discards virtually all meaning of scope. >>>> >>>> The whole meaning of scope is new in IPv6 vs IPv4. >>> >>> Yes. >>> >>>> And it's not easy: ULAs, scoped multicast groups and networks >>>> disconnected from the Internet are all scope complications to >>>> implementers wondering which additional rules to add (or not) to >>>> an otherwise very simple forwarding implementation. >>> >>> It’s very easy. Quite simple, actually. >>> >>> There are, essentially two scopes that really matter and a host of >>> scopes for multicast which can be administratively defined. >>> >>> The two that matter have exactly the same meaning for unicast and >>> multicast. >>> >>> They are: >>> >>> 1.Link Local No packet containing a Link Local Scope or Link Local >>> Scoped Address should traverse a router such that it is forwarded to >>> an interface which is not on the same link as the arrival interface. >>> >>> (In other words, for the definition of link that applies to IPv6, as >>> noted above, the packet cannot be forwarded off of that link no >>> matter what.) >>> >>> 2.Global Packets which are global in Scope or contain only global >>> scoped addresses may be forwarded anywhere on the internet as >>> permitted by local policies to reach their destination. >> >> It's hard to define link-local scope in a setting where it's hard to define a link altogether. > > But it’s NOT hard to define a link. A link is well defined. What is hard is that you don’t like the definition of a link and you want to somehow apply some magical definition that doesn’t actually work. > >> WiFi with AP indulges us into believing the link is everybody in that ESSID. > > It doesn’t indulge us to believe, it makes that the case. > >> But there is no link in WiFi w/o AP and OCB (outsid the…) > > Sure there is… It’s limited to the vehicles that can directly see your packets because you don’t have an L2 forwarder (AP) specifically responsible for forwarding those packets. > > If you come up with a somewhat reliable mechanism for L2 forwarding of these datagrams, then you can extend your idea of a link farther, but you’re going to quickly run into scaling issues with traffic saturation as your broadcast domain grows. > >>>> It's easy to enunciate and implement that each packet must have >>>> same scope in src and dst. >>> >>> This is not a requirement. > > It _IS_ a requirement in IPv6. > >>>> But it's harder to say which non-equal scope packets can be >>>> forwarded between interfaces of a router. >>> >>> No, it isn’t. You simply apply the most restrictive scope of the >>> {src,dst} scope attributes. >> >> If it were that simple then src-based routing were already there. > > That’s like saying “If apples, then space ships.†> > It makes literally no sense whatsoever to me. > > Source routing has nothing to do with this and isn’t applicable to IPv6. > > If a router receives a packet with different scoped addresses, then it > must apply the forwarding policy applicable to the most restrictive scope > present. > > Thus, LL,ULA == LL, LL,GUA == LL, ULA,GUA == Global, GUA,GUA == Global > ULA, ULA == Global. > >>>> One would not forward a src LL dst GUA because they are different >>>> scopes. Yet one _would_ forward a src GUA dst ULA even though they >>>> are different scopes too. >>> >>> In the first case, the packets are different scopes. But GUA and ULA >>> are both global scope. Perhaps this is where you are getting >>> confused. ULA is NOT A SCOPE. ULA is a convention. It’s one of the >>> reasons I argued that ULA was a terrible idea… I figured this >>> confusion about global scoped “local†addresses would be inevitable. >>> Sure enough, you are here to prove my point. >>> >>> ULA packets are the same scope as GUA. GLOBAL SCOPE. >> >> Yet it's strange to call 'L' in ULA Global scope… > > ULA isn’t a scope. It’s a convention. > > The problem here is that you keep confusing yourself by thinking of > the L in ULA as being a scope definition. It’s not. It’s just a convention. > >>> Any locality in ULA is strictly a matter of administrative >>> convention. If Parties A, B, C, D, E, F, G, H, and I all agree to >>> manage their ULA space so as to avoid conflicts and to route it, then >>> they can form whatever conglomeration of networks they wish and route >>> their ULA around as far as they like. It’s global scoped. >>> >>> Link Local, OTOH, is _NOT_ global scoped. >>> >>> One would _NOT_ forward a src GUA dst LL packet any more than one >>> would forward a src LL dst GUA. >> >> But one would not forward by looking at src, unless the operation were called "rewindâ€. > > In IPv6, the way the protocol is designed, you must look at the scope of the source > address before forwarding it to an interface other than one on the same link as the > interface where the packet arrived. It is a requirement documented in the RFCs. > > So your above claim is patently false. You are wrong. It’s as simple as that. You are > required to look at the src before forwarding the packet. You don’t necessarily use > the src in determining where to forward the packet, but you must consider the scope > of the source address in deciding whether or not to forward the packet. > >>>> Moreover, one _would_ forward a src ULA dst site-local multicast >>>> group (the ULA scope is almost the same scope as the site-scope) >>>> and, worse, an across-subnets site-local multicast group could >>>> contain only LL addresses if the subscribers decided to use their >>>> LLs (the subscription operation is a link-local operation - MLD). >>> >>> Again, you are incorrect here. The ULA scope is GLOBAL. Yes, one >>> would forward the packet, because the scopes overlap, but one would >>> not forward it outside of the site (whatever administrator has >>> defined as site for multicast purposes). >>> >>> Sure, technically the subscriptions can be LL, but nobody can send a >>> packet to the group with their LL source and expect it to get >>> forwarded off of the local link. >>> >>> You should NOT forward a packet with src LL and dst Site-Local >>> Multicast group to a different link. >> >> I get this 'no' from you. >> >> I would like to ask you how would you see vehicular networks work without this operation. > > Presumably with something other than LL addresses. > >>>> I would also like to mention the difficulty in understanding >>>> scopes being 'larger' than others, or scopes 'containing' scopes as >>>> they are found in many RFCs. 'Larger' and 'containing' may be >>>> intuitive to many readers (e.g. global scope is larger than link >>>> scope, the global scope contains all links scopes), but can be hard >>>> to implementation (wifi 'overlapping' models dont contain each >>>> other and are sometimes disconnected from the Internet). >>> >>> In reality, address SCOPES and Multicast Group SCOPES are completely >>> separate entities and attempting to conflate them will only lead to >>> pain. >>> >>> Once you understand that, then you need to understand that address >>> SCOPES only come in two varieties… Link Local and Global. >>> >>> There’s no issue in terms of address scopes with overlap or >>> containing. >>> >>> Multicast scopes are stranger because they have a lot of >>> flexibility. Thus an administrator can actually in some cases define >>> scopes which overlap but are not strictly hierarchical. For example, >>> a site may have elements of multiple organizations, but not contain >>> the entirety of any or all of those organizations. >>> >>> Let’s consider, for example, a fictitious site ZZYZX which contains >>> all of company A, a branch office of company B, and a research lab >>> for company C. >>> >>> The multicast scopes at that site would include: >>> >>> Multicast ScopeCompanyScope Name OrganizationAOrg-A SiteA, B, >>> CSite-ZZYZX OrganizationBOrg-B OrganizationCOrg-C >> >> (figure in original message). >> >> The scopes as you depict them are frozen: they dont change. There is a god-like administrator who decides who belongs to what scope and then configures the routers. > > As is the case in the vast majority of implementations and as is the case > in the IPv6 protocol design. > >> This scheme is hard to implement in vehicular networks: movements of various speeds make and de-make what's possible to be in-scope and out of scope. There is no more potent entity (like a fixed router) to which one can send subscriptions. > > Hosts come and go from Mobile networks and from WiFi networks all the time. > > There’s constant flux on which hosts are ON-LINK or not ON-LINK from any given perspective. > > Sure, this could be a particularly challenging aspect of your particular use case. > > That’s your challenge to solve, but you don’t get to change IPv6 in a way that is > detrimental to all other users in order to solve it, nor do you get to simply pretend > that IPv6 behaves (or should behave) differently because it is convenient to your > application. > > The problem you are trying not to solve is frankly not one you will be able to avoid solving anyway. > > You’re going to have to solve that problem in order to have any reasonable measure of security in > your application. > > Owen > > From nobody Thu Jun 23 08:02:14 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 741EF12D17B for ; Thu, 23 Jun 2016 08:02:12 -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 OZIZDzbBFvc2 for ; Thu, 23 Jun 2016 08:02:07 -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 2686512D162 for ; Thu, 23 Jun 2016 08:02:07 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id h14so29583808pfe.1 for ; Thu, 23 Jun 2016 08:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:to:mime-version; bh=N5PXzePbci+eIcLdJ1T2NPMERn3k+j7CkUXJTpcYJ38=; b=mwb9UxAurVETeLsNvy08F6fW/ASwblbo78VcfWEC/ua65d7je/jFqXFTju+Chfw9de wXSThFlW9XHGbUTcMWWx0C3/kFeWVIc4QqXp++F7v1hMy7Bjqho/FZTpstWpTSX1vRYH zOf1qICQ4fWuFVxu1FeFYjG1De9NwC+5/U/b+yIeT2hgT/guOb0BlAF5PMfhNu73HuzJ XxiqXZVEWDjb2V78VIiV+JK5BrXl4WwXlK5r5a0QC5wd1swO5guRAnl4sbVqpe0A+k+i UZAkCjLL8FWxvpzype6O3afE4HcoyuEXfWMCQ4W+UftxKz81RT0sDNltQoSOcb5temQX fPZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:to:mime-version; bh=N5PXzePbci+eIcLdJ1T2NPMERn3k+j7CkUXJTpcYJ38=; b=ltWirRhzMvZ4fNH9MhAnhWbATy4yp1wr9IXU3XtieLUSp4zPcbYGQUKw2jJCMY43bl +hfkoS9iagz7yRv9oLFgtP6MDNPWKcoZsBlTebZLB3Kb6VOxsiY/w+eySrR1HGtLXk1X fN8aOppVobmQ8RhX53oLl7qKKZspcexClyzGLvR+TnHKnSAO24QQWr0Lmsikzs1ZwOAv R7c/Cq9+wQ7kCN91QRheIAITNfffgUV4oHBfF30/R1vms65I3zeXsKUeGB/w/EpFDzPB lDk8F0ypjEXPyY5xpZRnZQtj+zsspZ2E8RSHgE0qvbQV6vNkhjNqv/EzNIPyh2iLaBVU N0OQ== X-Gm-Message-State: ALyK8tKcyyW9t/r4fpLK50D6lVG7vdNAWWhMMxP1qkQPSUsTgSupDIqzO9stniUxbkDGiA== X-Received: by 10.98.46.70 with SMTP id u67mr43030172pfu.134.1466694126561; Thu, 23 Jun 2016 08:02:06 -0700 (PDT) Received: from ?IPv6:2001:420:701:32:b519:87c8:5685:b495? ([2001:420:701:32:b519:87c8:5685:b495]) by smtp.gmail.com with ESMTPSA id 81sm771696pfo.74.2016.06.23.08.02.05 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Jun 2016 08:02:05 -0700 (PDT) From: Fred Baker X-Google-Original-From: Fred Baker X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_E1376369-8C7D-4B05-8583-4CA095CD8432"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Thu, 23 Jun 2016 08:02:03 -0700 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [v6ops] IETF 96 BOFs and new topics 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, 23 Jun 2016 15:02:12 -0000 --Apple-Mail=_E1376369-8C7D-4B05-8583-4CA095CD8432 Content-Type: multipart/alternative; boundary="Apple-Mail=_D61D991A-FFA3-4609-8DE1-9D71A681F4E8" --Apple-Mail=_D61D991A-FFA3-4609-8DE1-9D71A681F4E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just so people are aware of things you may not already be tracking ... =46rom Jari: = https://www.ietf.org/blog/2016/06/new-topics-at-the-berlin-meeting/ = See you in Berlin, Fred --Apple-Mail=_D61D991A-FFA3-4609-8DE1-9D71A681F4E8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Just so people are aware of things you may not already be tracking ...


See you in Berlin,

Fred
--Apple-Mail=_D61D991A-FFA3-4609-8DE1-9D71A681F4E8-- --Apple-Mail=_E1376369-8C7D-4B05-8583-4CA095CD8432 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 iQIVAwUBV2v560ayAOS/EQ8MAQLVYRAAo1p27EtoMC3ScB37SMtpHQCqcJ1r47py cr9Onlohqg3P6kUz5ANRgXie9q59wKUcYHE2sXeQU66zo/qAMtigNrg1F8x3TZfx PsdCsADp9P20C8Hs8YsMzFSBaUKIGpWtjitJ/xppj3p/2TyrAo3nEQdCQV+eIPbe NzHUHfcf9MVuhkZ6XnyQ3ROgTQNw55BteR/ueATH9BCWtXX8WrmVFTLLdXKrMQcO CBWunZRhAJ9FnBO2y40CTLQTC6yVGvDK9FSVCFmqAm/rBGPfgtwNi7WMYjc1wyzz JGT90YYiRyxPowbLdtjtH3GgEhaNsxhobiuW2Yev2/djdy+1iGnPIG+HzihtjU1r FtzUKyqdzTz7FHfJpNlb4sw5HpyNwJZefuFcbIV+XQsjhfAR8KQNaaeu44vYH92l 6jA5zgUmUpjuFhShRWlw4BqsmI8Olk4C4ZqMqbkLMBAy1KbJrKX2fKppyRaMMcPN Fk4vw57FPEWf+pmgW+/gJs3i32s4ypxEAKLefU7pbCI7lU9NLU92ErfXY+ItacLU zd0JBvQaUuIh/9guKPVu6N4chFRT65U57zVu+g1qGOJ7Pg0Oura7mvvRF6oYbrYS JKmMk3crP39sXurUCg4TAweu9PePwg4pTljyXwfCarEWML/hHu1rzzd45EdkfKxr oAcuPFHiVZg= =ew+u -----END PGP SIGNATURE----- --Apple-Mail=_E1376369-8C7D-4B05-8583-4CA095CD8432-- From nobody Thu Jun 23 08:29: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 94EC112D0D9 for ; Thu, 23 Jun 2016 08:29:33 -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 XDJZNvzxl8Y0 for ; Thu, 23 Jun 2016 08:29:31 -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 ED90712D0A7 for ; Thu, 23 Jun 2016 08:29:30 -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 u5NFSbEh004957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jun 2016 08:28:47 -0700 (PDT) To: Alexandre Petrescu , 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> From: Joe Touch Message-ID: <576C0024.4060406@isi.edu> Date: Thu, 23 Jun 2016 08:28:36 -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: 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] Packets with LL src and GUA dst 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, 23 Jun 2016 15:29:33 -0000 On 6/23/2016 6:39 AM, Alexandre Petrescu wrote: > > > Le 23/06/2016 à 00:47, Owen DeLong a écrit : > [...] >>> In all cases, the need is there: in some widespread vehicular >>> communications there is no unicast nature of communication semantics (a >>> car can't unicast a packet to another car) - it is all 'broadcast'. >>> Each car broadcasts data every 1/30th seconds (30Hz) and each other car >>> hears everybody else. The ESSID and the dst MAC address is >>> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's >>> address. >> >> Then perhaps you should get a reserved multicast group number for >> “all carsâ€. > > Well I wonder about the name. > > The too familiar 'cars' could be more pedantic 'vehicles' or 'light > vehicles'. > > But 'vehicles' would look strange in the current list of nodes, > routers, servers or agents > http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > The list includes types of: - components in the Internet architecture (hosts, which source/sink datagrams and routers, which also relay) - components that speak a particular protocol that uses multicast Cars or vehicles are neither. Physical locations are neither. If there's a candidate, it really ought to describe something in terms of the network, not in terms of where the device happens to be deployed - because whatever deployment assumptions are made today WILL be wrong. > The word 'broadcast' can be ambiguous in this discussion. In > vehicular communications 'broadcasting' means to send in the ether, as > opposed to sending on a wired Ethernet; and it also means there is no > return path - a little bit like in 'TV broadcast'. Michelson and Morley proved there is no "ether" in 1887. IP runs over many different link layers that could be used here, including RF (WiFi, 4G, etc.), photonic (headlight and other lamp modulation), etc. And many of these have been around since the origin of the Internet. And unidirectional links are just called "half duplex", and have been part of the Internet since its origin too - including encodings over idle periods in broadcast TV signals or radio. > > But yes I agree with you when it comes to IPv6 it should use multicast > addressing, not broadcast addressing. IMO, the doc needs to be cast in terms of using multicast, not merely replace the term for broadcast and assume they are interchangeable. > > 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. Can you explain where this comes from? It's not how IPv6 multicast typically interacts with MAC addresses. You probably can just explain what you need in terms of IPv6 and let the link decide what MAC is appropriate for a given IPv6 multicat. Joe From nobody Thu Jun 23 08:39:55 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 02AF312D1AC for ; Thu, 23 Jun 2016 08:39:54 -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 HqQv_rT6IJHV for ; Thu, 23 Jun 2016 08:39: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 4F6D612B05D for ; Thu, 23 Jun 2016 08:39:52 -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 u5NFdDnA008794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jun 2016 08:39:24 -0700 (PDT) To: Alexandre Petrescu , 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> <576C0024.4060406@isi.edu> From: Joe Touch Message-ID: <576C02A1.7000606@isi.edu> Date: Thu, 23 Jun 2016 08:39:13 -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: <576C0024.4060406@isi.edu> 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] Packets with LL src and GUA dst 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, 23 Jun 2016 15:39:54 -0000 On 6/23/2016 8:28 AM, Joe Touch wrote: > And unidirectional links are just called "half duplex", and have been > part of the Internet since its origin too - including encodings over > idle periods in broadcast TV signals or radio. Before anyone jumps, it's half-duplex if the other end can't reply while you're talking, which seemed to match the discussion. If what you meant was simplex (no return path is possible at all), then just say that. True simplex wasn't covered in RFC3819, I suspect because very few protocols are useful if there is no return path at all (one could easily argue that a node reachable only by one simplex link is the proverbial "tree that falls in the forest" that nobody hears, i.e., there's no difference between that and a node that simply isn't there). Joe From nobody Thu Jun 23 13:34: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 001AC12D731 for ; Thu, 23 Jun 2016 13:34:33 -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 0TclQM8LV2-4 for ; Thu, 23 Jun 2016 13:34:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2412D7B7 for ; Thu, 23 Jun 2016 13:34:30 -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 u5NKXRRj003092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2016 13:33:27 -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: Date: Thu, 23 Jun 2016 13:33:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.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> <76E49E82-018C-461D-8F85-414F4E98801B@del! ong.com> <6c8ba45c-2fca-0b8c-4159-877bcf0a16f4@gmail.com> <4A552EFF-B16E-4872-933B-9244F7057DA0@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]); Thu, 23 Jun 2016 13:33:28 -0700 (PDT) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Packets with LL src and GUA dst 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, 23 Jun 2016 20:34:34 -0000 > On Jun 23, 2016, at 06:39 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 23/06/2016 =C3=A0 00:47, Owen DeLong a =C3=A9crit : > [...] >>> In all cases, the need is there: in some widespread vehicular >>> communications there is no unicast nature of communication semantics = (a >>> car can't unicast a packet to another car) - it is all 'broadcast'. >>> Each car broadcasts data every 1/30th seconds (30Hz) and each other = car >>> hears everybody else. The ESSID and the dst MAC address is >>> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's = address. >>=20 >> Then perhaps you should get a reserved multicast group number for = =E2=80=9Call cars=E2=80=9D. >=20 > Well I wonder about the name. >=20 > The too familiar 'cars' could be more pedantic 'vehicles' or 'light = vehicles'. >=20 > But 'vehicles' would look strange in the current list of nodes, = routers, servers or agents > = http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-ad= dresses.xhtml I don=E2=80=99t care what you name it as long as it makes sense and is = properly descriptive. Cars was just an example for the sake of discussion, not an actual = recommendation. >> Then, you can use =E2=80=9Call cars on link=E2=80=9D for link scoped = communications where >> a LL source address would be valid and =E2=80=9Call cars within = ORG=E2=80=9D for an ORG scoped >> communication using a ULA source, etc. >=20 > 'ORG' - 'organization' is obviously not the right word for something = ephemeral happening between a few cars on a highway none of which being = more entitled than another. Depends. if it=E2=80=99s all the vehicles that belong to e.g. DHL that = you are trying to reach, that could be a perfectly legitimate use of = ORG. There are lots of other scopes to choose from as well. Point is that with ULA SRC, agreement among the participants to forward = ULA network numbers, and a proper multicast scope, you can do what you = want without breaking half the RFCs to do it. Sure, your forwarding is now forwarding at layer 3, but that=E2=80=99s = better in most cases anyway. Ad-Hoc random layer 2 forwarding DOES NOT SCALE. >=20 >> There are clean ways to do this, but the proposals you have put forth = so far, >> however, are not. >=20 > I am looking for clean ways dealing with situations where it's hard to = say who is the 'owner' or the control entity which keeps track of = multicast registrations in some scope. That=E2=80=99s the beauty of having a registered multicast group. The scope is a choice made at packet creation time, but the semantics of = the group number remain the same regardless of scope. So, for example, All Nodes multicast is always ALL Nodes. You can make = it All Nodes on Link, All Nodes within ORG, All Nodes Globally, or = whatever. That=E2=80=99s why the group ID and the Scope are separate = fields in the IPv6 Multicast address and why there=E2=80=99s a flag to = indicate whether the Group ID is permanent/global or valid only within = the current context. (chances of real world forwarding of multicast obviously diminish with = increasing scope choice, but that=E2=80=99s a separate matter). >> There is no concept of broadcast in IPv6, so you can=E2=80=99t do = =E2=80=9Cbroadcast-only=E2=80=9D. >> You have to use multicast. >=20 > The word 'broadcast' can be ambiguous in this discussion. In = vehicular communications 'broadcasting' means to send in the ether, as = opposed to sending on a wired Ethernet; and it also means there is no = return path - a little bit like in 'TV broadcast'. In a particular = report, they say "DSRC operates in constant broadcast-and-receive mode": = you periodically broadcast to everyone else and always receive from = everyone else, but you can not send to just one entity. This = 'broadcast' concept of vehicles is independent of the fact that the MAC = dst address is ff:ff:ff:ff:ff:ff (MAC broadcast address). That=E2=80=99s a simply stupid definition of the term and can only lead = to confusion when you talk to people involved in networking. > But yes I agree with you when it comes to IPv6 it should use multicast = addressing, not broadcast addressing. Exactly. And it should limit the Multicast to a group assigned to the = particular purpose. You might need multiple multicast group numbers for = different applications to do this right. > 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. Owen From nobody Thu Jun 23 13:52: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 7FA7412D7ED for ; Thu, 23 Jun 2016 13:52:04 -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 rDFpmnZU45l5 for ; Thu, 23 Jun 2016 13:52:03 -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 027B712D7E0 for ; Thu, 23 Jun 2016 13:52:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5NKpDlw009263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jun 2016 13:51:14 -0700 (PDT) To: Owen DeLong , 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> <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> From: Joe Touch Message-ID: <310dfb5e-dc65-777f-6bf5-77e8fbf5da79@isi.edu> Date: Thu, 23 Jun 2016 13:51:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <801C4630-FF52-4E92-AB1C-CD314BFD72ED@delong.com> Content-Type: multipart/alternative; boundary="------------E0789394658B86FDF6E24BD1" 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] Packets with LL src and GUA dst 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, 23 Jun 2016 20:52:05 -0000 This is a multi-part message in MIME format. --------------E0789394658B86FDF6E24BD1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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. Joe --------------E0789394658B86FDF6E24BD1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



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.

Joe

--------------E0789394658B86FDF6E24BD1-- From nobody Fri Jun 24 09:01:06 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 6869312DC51; Fri, 24 Jun 2016 09:00:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160038.10933.23295.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:38 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] v6ops - Requested session has been scheduled for IETF 96 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, 24 Jun 2016 16:00:38 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Potsdam I size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg sunset4 tsvwg Second Priority: tsvarea intarea lmap softwire Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 10:42: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 A5FB012D144 for ; Fri, 24 Jun 2016 10:42:45 -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 zY8OuihwLS8Y for ; Fri, 24 Jun 2016 10:42:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E78712D13E for ; Fri, 24 Jun 2016 10:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2667; q=dns/txt; s=iport; t=1466790164; x=1467999764; h=from:to:subject:date:message-id:references:mime-version; bh=a7xcALP7S7TemZe+1IwGz+Kko7azcyw+T4haEHss3TM=; b=A5e6fT2oOJ7tpZDi3To6jqKcPaB1L2vVXTmZnrTE1TI4uht2lk2BwPt1 mJC092+H/hPf/RbmlL+WXtfrn/AuWJArbZdqCFKObKPV/S6plH5QiW2w5 fXL/1ibogP+q1x4HKqLNp3+GCEsmVGR3JLeDZRYZ3i0bJU3bh0ab38KIl M=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBCcG1X/5tdJa1cgz6BUwa4E4IPg?= =?us-ascii?q?XuGGAKBNTgUAQEBAQEBAWUcC4RMAQEEAX4LAgEZAwECLzIbAggCBBMOiBoIxxw?= =?us-ascii?q?BAQEBAQEBAwEBAQEBAQEBARAOiB8Igk6EYIMMgi8FiBaFZIsGAYMtgWyJGo8jj?= =?us-ascii?q?30BHjaDcG6IMX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,522,1459814400"; d="asc'?scan'208";a="122385718" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 17:42:43 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5OHghTp027361 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Jun 2016 17:42:43 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.1104.5; Fri, 24 Jun 2016 12:42:42 -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.1104.009; Fri, 24 Jun 2016 12:42:42 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: v6ops - Requested session has been scheduled for IETF 96 Thread-Index: AQHRzj/P9ZXmEqYKSkicliVSoseTPA== Date: Fri, 24 Jun 2016 17:42:42 +0000 Message-ID: References: <20160624160038.10933.23295.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.125] Content-Type: multipart/signed; boundary="Apple-Mail=_E0178A5B-B7C4-42D3-9DCC-E295C4D1043C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: v6ops - Requested session has been scheduled for IETF 96 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, 24 Jun 2016 17:42:46 -0000 --Apple-Mail=_E0178A5B-B7C4-42D3-9DCC-E295C4D1043C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested session has been scheduled for IETF 96 > Date: June 24, 2016 at 9:00:38 AM PDT > To: , > Cc: , > Resent-From: > Resent-To: , >=20 > Dear Fred Baker, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. >=20 > v6ops Session 1 (2:00:00) > Thursday, Afternoon Session I 1400-1600 > Room Name: Potsdam I size: 300 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: 6man aqm dnsop mtgvenue opsawg opsec ospf pcp rtgwg = sunset4 tsvwg > Second Priority: tsvarea intarea lmap softwire >=20 >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 --Apple-Mail=_E0178A5B-B7C4-42D3-9DCC-E295C4D1043C 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 iQIVAwUBV21xEUayAOS/EQ8MAQIDixAAqB9q6TzkmCZ3CnU7Zl92we3fpAwnbd7d XTaD05N/y83YfGO6mernGsItm3EwVCfPprJovKXVC6d34BfWLgNWQI0smintF7MX BZu2qwquv0nTVP3RwBD1EBPEYl/7/iI5+MOjBndxWnlwaJenPmLS04i1yctAPNka vpfFKEmqzOX6yJ+uTrZBDhOv+NTkqxxS70aBpUU5W9S5S6sI70Dk9jvJ90BJJ+lb u9MR1xQDAAvIZE+HlqlH+L8AhbElrmvfv1wgdOhqEZj/LgOvgpIr7ZWUWSrn/lKz oapdX15NFKAI4HhL7xxJJtzAsdJ1hW5+A8bzwWdY8SvirX0DaAhKTuX5ex67VWhA RUpcUrsAR579fh1PO006EWNY2rp4cU6uWG3ZcwFk6R763d3ui8U/ksrndxIHae8j h119vZue70rbxnQnupHD7mwzrJGYVVSAER66lsTArAeebHqykt/lmhdwPHOvU0E1 GetA8rrbVMeLOCzhpludO1cuiuwQ2QnLlWzc/0ra+F4+topHarHXLmcTq4Q0ir5k zpPCzjs6zLVkD1Kh9I+gt/bGSg6Ca68eFKd6hUisUpyeS8NLqAVHsv4uwQ2/ITVZ xWeVnhXbOYh2T+crtVA8tDwioPglxqjlbtIi5ap55xWlIl8w3pMz5cPmxNTbXD1T b1alK1zy5xY= =O1Kc -----END PGP SIGNATURE----- --Apple-Mail=_E0178A5B-B7C4-42D3-9DCC-E295C4D1043C-- From nobody Mon Jun 27 13:04: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 6B4A412D85D for ; Mon, 27 Jun 2016 13:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q6ugJcih8kEL for ; Mon, 27 Jun 2016 13:03:57 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 9106D12D819 for ; Mon, 27 Jun 2016 13:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u5RK3uZm006402; Mon, 27 Jun 2016 13:03:56 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u5RK3o0k006313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 27 Jun 2016 13:03:50 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Jun 2016 13:03:49 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 27 Jun 2016 13:03:49 -0700 From: "Templin, Fred L" To: v6ops list Thread-Topic: I-D Action: draft-templin-v6ops-pdhost-02.txt Thread-Index: AQHR0KzaEx4cRiyqykmw0FBNtQzSSJ/9uKGQ Date: Mon, 27 Jun 2016 20:03:49 +0000 Message-ID: References: <20160627194755.5379.11699.idtracker@ietfa.amsl.com> In-Reply-To: <20160627194755.5379.11699.idtracker@ietfa.amsl.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: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] FW: I-D Action: draft-templin-v6ops-pdhost-02.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, 27 Jun 2016 20:03:59 -0000 See below for an updated draft titled: "IPv6 Prefix Delegation for Hosts" t= hat documents=20 a concept that was discussed on the list earlier this year. Whereas RFC7084= is about routers that act a little bit like a host, this document is about hosts that act a = little bit like a router. The host can receive a DHCPv6 Prefix Delegation (PD), and assign addresses = taken from the prefix to the same interface over which the PD was received. In this wa= y, the host looks like a requesting router from the standpoint of DHCPv6 PD, but acts l= ike a simple host under the strong end system model from the standpoint of its hosted ap= plications. Please review and comment on the list. Please refer to list archives in the= January 2016 timeframe for more context. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, June 27, 2016 12:48 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation for Hosts Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-02.txt Pages : 6 Date : 2016-06-27 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. The requesting router then acts as a router between the downstream- attached hosts and the upstream provider network, and can also act as a host under the weak end system model. This document considers the case when the "requesting router" is actually a simple host, and receives a delegated prefix that it can use for multi-addressing purposes. The host does not connect any downstream-attached networks, and uses the prefix solely for its own multi-addressing purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From linkedin@xn--debrn-nva.de Wed Jun 15 06:05: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 1365A12D677; Wed, 15 Jun 2016 06:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 4P3EJKojH9Ed; Wed, 15 Jun 2016 06:05:28 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB2312D60D; Wed, 15 Jun 2016 06:05:02 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1465995895129657.7123757883129; Wed, 15 Jun 2016 06:04:55 -0700 (PDT) Date: Wed, 15 Jun 2016 15:04:54 +0200 From: Markus deBruen To: "Eric Vyncke (evyncke)" Message-ID: <155542a20aa.f178b1d213436.8516278435436621650@xn--debrn-nva.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_31302_6541596.1465995894976" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: X-Mailman-Approved-At: Tue, 28 Jun 2016 11:30:35 -0700 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: Wed, 15 Jun 2016 13:19:10 -0000 ------=_Part_31302_6541596.1465995894976 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi Eric, the draft is very well written and contains useful guidance/recommendations. Sections 2.4 and 2.5 do not contain much IPv6-specific information and sections 2.7.2.* do not give much guidance. However, these three sections together amount to ~11 pages (1/3 of the document). If you could shorten these sections, the document would become more manageable. Some minor comments and nits: 2.1.2 "... The latter would be problematic." I suspect by "latter" you mean NPTv6. Better make that explicit. "A typical argument is that there are too many mistakes made with filters and ULAs make things easier to hide machines." Why "to hide machienes"? I would suggest "to set filters". 2.1.4 "... privacy extension addresses should be used" Punctuation mark is missing. 2.2 still TBD 2.3.2 "... for protecting hosts connected against..." "Connected hosts" maybe!? 2.3.4 "RFC6980 [RFC6980] aims to update RFC4861 [RFC4861]" "[RFC6980] updates [RFC4861]" 2.7.2 "embeb" -> embed 2.7.2.4 "... operational problems" Punctuation mark is missing. 2.7.2.8 The second "MAP-E" should be "MAP-T". 2.8 "device to authenticated" -> "device authenticated" 3.1 "bogon and reserved space" Some links might be helpful (e.g. to IANA). 5 "[RFC7084] (which obsoletes [RFC6204]" Missing ")" "[RFC7084] states that a clear choice must be given to the user to select one of those two policies." Does it? I did not find the corresponding passage. Throughout the document there are some "IPV6", "DOS" and " ", which should be replaced with "IPv6", "DoS" and " ". I hope these comments are helpful. Cheers, Markus ---- Ein Mi, 15 Jun 2016 12:50:29 +0200 Eric Vyncke (evyncke)<evyncke@cisco.com> hat geschrieben ---- The authors (and OPSEC WG chairs) would really appreciate if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-08 is done in the coming days/weeks (in time to submit a -09 in case it needs to be amended). This I-D is about the operation security considerations when operating an IPv6 network (both as Service Provider and enterprise/subscriber). Thanks a lot in advance for your review and be sure to include opsec@ietf.org in your reply. - the authors (Merike, KK and Eric) - the chairmen (Gunter and Eric) PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review it during IETF-95, I also put your names ;-) ------=_Part_31302_6541596.1465995894976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Eric, = ;

th= e draft is very well written and contains useful guidance/recommendations. Sections 2.4 and 2.5 do not contain= much IPv6-specific information and sections 2.7.2.* do not give much guidance. However, t= hese three sect= ions together amount to ~11 pages (1/3 of the document). If you could shorten these sectio= ns, the document would become more manageable. 

Some minor comments and nits: 
2.1.= 2 
"... The latter would be problematic."&nbs= p;
I suspect by "latter" you mean NPTv6. Better ma= ke that explicit. 

"A typical argument is that there are too many mistakes= made with filters and 
ULAs make things easi= er to hide machines." 
Why "to hide machienes= "? I would suggest "to set filters". 

2.1.4 
"... privacy extension addresses should be used" 
Punctuation mark is missing. 

2.2 
sti= ll TBD 

2.3.2 
<= span style=3D"font-family: Verdana, arial, Helvetica, sans-serif; font-size= : 12px; background-color: rgb(255, 255, 255);">"... for protecting hosts co= nnected against..." 
"Connected hosts" maybe!= ? 

2.3.4 
"RFC6980 [RFC6980] aims to update = RFC4861 [RFC4861]" 
"[RFC6980] updates [RFC48= 61]" 

2.7.2 
"embeb" -> embed 

2.7.2.4&n= bsp;
"... operational problems" 
Punctuation mark is missing. 

2.7.2.8 
The second "MAP-E" should be "MAP-T". 

2.8 
"device to authenticated" -> "device authenticated" 

3.1 = ;
"bogon and reserved space" 
Some links might be helpful (e.g. to IANA). 

5 
"[RFC7084] (which obsoletes [RFC6204]" 
Missing ")" 

"[RFC7084] states that a clear choice must be given= to the user to select one 
of those two poli= cies." 
Does it? I did not find the correspon= ding passage. 
Throughout the document there are some "IPV6", "DOS" and " = ", which should be 
replaced with "IPv6", "Do= S" and " ". 

I hope these comments are helpful. 

Cheers, 
Markus 

<= div>
<= br>---- Ein Mi, 15 Jun 2016 12:50:29 +0200 Eric Vyncke (evyncke)<evyn= cke@cisco.com> hat geschrieben ----
=
The authors (and OPSEC WG chairs) would really appreciate= if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-= 08 is done in the coming days/weeks (in time to submit a -09 in ca= se it needs to be amended).

This I-D is about = the operation security considerations when operating an IPv6 network (both = as Service Provider and enterprise/subscriber).

Thanks a lot in advance for your review and be sure to include opsec@ietf.org in your reply.

- the a= uthors (Merike, KK and Eric)
- the chairmen (Gunter and Eric)

PS: Markus, Fred, Fernando and Lee, as you kindly= volunteered to review it during IETF-95, I also put your names ;-)
<= div>



=

------=_Part_31302_6541596.1465995894976-- From nobody Tue Jun 28 11:43: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 6D10B12D550 for ; Tue, 28 Jun 2016 11:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.946 X-Spam-Level: X-Spam-Status: No, score=-115.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, 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 DuOexGF6_tdG for ; Tue, 28 Jun 2016 11:43:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B2512D098 for ; Tue, 28 Jun 2016 11:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4756; q=dns/txt; s=iport; t=1467139380; x=1468348980; h=from:to:subject:date:message-id:mime-version; bh=3eXY1BWSstCT1V1rC04g1ixPr1UPvxm981iRv1A/7Io=; b=iefjGBoxVRrNc9UZ/GXJv7+Nm16mcC4yPQTTk/VeaTbycdRM1Hc4a3Pf I7TFioo8Mh3vLAlTR9aiezYfyhyYQoauI7XRR9uuzAfkHZDETnyFXrHrN y4Qi4WyLnGT3NRr2TuPv7bu2zOP7eiixhXqlLI+THF2kXAfXUxtN1/8TM Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcBQDPxHJX/4wNJK1bgnBOVn0GtSqCc?= =?us-ascii?q?oIPgXsihyw6EgEBAQEBAQFlHAuEU4ELAQx0JwQhiCIOpAOgGAEBAQEBAQEDAQE?= =?us-ascii?q?BAQEBAQEBAQ8JBYgfikKCLwWZAgGDLYFsiSCBaY05AoZUiSoBJQItg3BuAYgwf?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,542,1459814400"; d="asc'?scan'208,217";a="119989256" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 18:42:47 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5SIglCU023773 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 18:42:47 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; Tue, 28 Jun 2016 13:42:46 -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; Tue, 28 Jun 2016 13:42:46 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: [OPSEC] IETF96 - Update your drafts & slots requests Thread-Index: AQHR0WzdMxL0YotVWk2FA8dlfgMkVw== Date: Tue, 28 Jun 2016 18:42:46 +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=_A91875AC-55ED-4511-8312-7DACBC862B99"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] [OPSEC] IETF96 - Update your drafts & slots requests 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, 28 Jun 2016 18:43:02 -0000 --Apple-Mail=_A91875AC-55ED-4511-8312-7DACBC862B99 Content-Type: multipart/alternative; boundary="Apple-Mail=_516D7D24-E303-4C97-B5B6-72F45D388298" --Apple-Mail=_516D7D24-E303-4C97-B5B6-72F45D388298 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, IETF96 is approaching quickly. The first important date is Friday 8 = July, by which drafts need to be updated for consumption during IETF96, = according to https://www.ietf.org/meeting/important-dates-2016.html#ietf96 To help plan for the IETF96 v6ops slot agenda, can we ask if you want to = discuss a topic or draft during the OPSEC WG meeting. Fred and Lee --Apple-Mail=_516D7D24-E303-4C97-B5B6-72F45D388298 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hi All,

 

IETF96 is approaching quickly. The first important date is Friday 8 July, by which drafts need to be updated for consumption during IETF96, according to

https://www.ietf.org/meeting/important-dates-2016.html#ietf96

 

To help plan for the IETF96 v6ops slot agenda, can we ask if you want to discuss a topic or draft during the OPSEC WG meeting.


Fred and Lee

--Apple-Mail=_516D7D24-E303-4C97-B5B6-72F45D388298-- --Apple-Mail=_A91875AC-55ED-4511-8312-7DACBC862B99 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 iQIVAwUBV3LFJkayAOS/EQ8MAQLbvw//XkM44lxpnIHeS8n8pkCmQ+E9uW4GKmaq nqv6vizqQDKElh9wv7vfCfzieI1k/io4T4bjAo6jv4PESseUZiN7OjtZqsm6V8In tZDog76cEWEf/3R9SNxuFQHPhWPZHYZnecxo8LnUp+XY0lu30YbDBkuzyzFW/cz/ AKGJ3lpP2EMB45hsZlIdmAmkHWR834CTKpSKIUpuwvUhFxqq4uiU1wsl3xjq2F5j xj2NUWZfPnS8RaOL/F5he9rjZUkUdQX1LqYDTD5knu72sL0uXqGI5Nm4K51FG30H t+XK1h639tuMzkSwvblWbKZjuYMVNXnz2nuZBdXyS5XbRtSHm0pzF9a9YNQcFn0/ dTyqWLK1ThMe/f44+P+UjrwYgxYvSoVXsS+InhcURnwxPQfCtIP0zxRru4DWpaCY AdsCkSsZxJwQbib28mousfgskpyiEtS55JWMOvRFHefdFpRrL+K0+O56CMsfNV4J DtqB7zedM8JDIbP1VDxapDZl4UKNKfhmLVWEN3OImhEnfA+sLIwxK3LCbzrCXZAF qBYptgVBSPwAlLmAfHbLhm+6/alJ2o/2QZiEyXYpdr3snpBxBfB5sM0zfz9f2/xe gd9CFrQYyj3kPvrBRv/C/r66LQGY0r9as2L8cpqcqiLbUdZO3aw/VZOGgY/u7zGv a94xyaZCE+M= =3aOg -----END PGP SIGNATURE----- --Apple-Mail=_A91875AC-55ED-4511-8312-7DACBC862B99-- From nobody Wed Jun 29 02:27: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 74B5E12DADA for ; Wed, 29 Jun 2016 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 JjNqOi71n6_9 for ; Wed, 29 Jun 2016 02:27:07 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) (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 78BAD12DADD for ; Wed, 29 Jun 2016 02:27:05 -0700 (PDT) Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 22/F1-13025-76493775; Wed, 29 Jun 2016 09:27:03 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRWlGSWpSXmKPExsUy9d9HH920KcX hBr/W21hMuOlhceLWUWaL08f2Mjswe2w9+YPN4+2u08weS5b8ZApgjmLNzEvKr0hgzfgw9QBz wZeVjBVNW46yNzCeWc7YxcjJISSwiVHiWIdhFyMXkH2AUeLo2kYmCOcEo8TCc0/ZQarYBHQl2 metYgaxRQQ8JW7/mwpkc3AwC6hKzP7DDxIWFnCVeH51O1SJm8S5R9tYIGwjia51l8DGsACVH1 3xDizOKxAq0XT5BzvEEfkSGw8cZQWxOQXsJJrvrmACsRkFZCW+NK4Gm8ksIC5x68l8sLiEgID Ekj3nmSFsUYmXj/+xQtgKEpcWdbFC1OdJbGg8zQaxS1Di5MwnLBMYRWYhGTULSdksJGWzwD7T lFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGDWKU4vKUot0jcz1kooy0zNKchMzc3QNDUz1c lOLixPTU3MSk4r1kvNzNzEC47CegYFxB+PVLX6HGCU5mJREefXzisOF+JLyUyozEosz4otKc1 KLDzHKcHAoSfBumgyUEyxKTU+tSMvMASYEmLQEB4+SCK/LJKA0b3FBYm5xZjpE6hSjLsePjvt rmYRY8vLzUqXEebNAZgiAFGWU5sGNgCWnS4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJWEeU+A TOHJzCuB2/QK6AgmoCOYS8GOKElESEk1MHJofipU380hqZhz4CNvu1nPi+MlcezeRhk/e1e7Z 23oMojK6ZKVmh9exDfL1Xb1u8QX8t9unaguURe0n/z+5la+0Dmfv81p1rFp/ZhefsOwkmeXyJ LiO7k50VPO1hbc85a/bFUu0PjjkHuD9L+QxbYHn825MsGUx/Lmoigtoce3bfy+HSouUWIpzkg 01GIuKk4EAEgQdRRJAwAA X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-12.tower-206.messagelabs.com!1467192422!11159608!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.46; banners=-,-,- X-VirusChecked: Checked Received: (qmail 60101 invoked from network); 29 Jun 2016 09:27:02 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jun 2016 09:27:02 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Wed, 29 Jun 2016 10:27:00 +0100 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0941.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Wed, 29 Jun 2016 10:27:02 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0279.002; Wed, 29 Jun 2016 10:27:01 +0100 From: "Heatley, Nick" To: Ross Chandler , David Schinazi Thread-Topic: [v6ops] Apple and IPv6 - new NAT64 address synthesis API Thread-Index: AQHRuyVEtOQrPlyu+kmW9M9V79iEsqAAUcrQ Date: Wed, 29 Jun 2016 09:27:01 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21317183DEC@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <4C80D4B8-0230-4E1F-A577-93E63C9D053E@eircom.net> In-Reply-To: <4C80D4B8-0230-4E1F-A577-93E63C9D053E@eircom.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21317183DECUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Apple and IPv6 - new NAT64 address synthesis API 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, 29 Jun 2016 09:27:09 -0000 --_000_6536E263028723489CCD5B6821D4B21317183DECUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQpJIGFtIHJlYWxseSBwbGVhc2VkIHdpdGggdGhlIHByb2dyZXNzIG9uIGhhbmRs aW5nIGxpdGVyYWxzIG9uIHRoZSBkZXZpY2UsIHRoYW5rcy4NCknigJltIGFsc28gdmVyeSBpbnRl cmVzdGVkIGluIHRoaXMgcXVlc3Rpb24gb24gdGV0aGVyaW5nIHVzZS1jYXNlLCBkaWRu4oCZdCBz ZWUgYW55IHJlcGx5LCBvciBhbnl0aGluZyBpbiBXV0RDMTYuDQoNClRvIGFkZCB0byBSb3Nz4oCZ cyBxdWVzdGlvbjoNCk5vdCBzdXBwbHlpbmcgSVB2NCB3aGVuIHRldGhlcmluZyBzdGlsbCBsZWF2 ZXMgbWFueSBvcGVyYXRvcnMgd2l0aCBhIHByb2JsZW0g4oCTIGN1c3RvbWVycyB3aWxsIG5vdCBh Y2NlcHQgSVBzZWMgVlBOIGNsaWVudHMgb24gdGV0aGVyZWQgZGV2aWNlcyBmYWlsaW5nIHRvIGNv bm5lY3QgdG8gSVB2NCBWUE4gZ2F0ZXdheXMgKGUuZy4gYSB2ZXJ5IHBvcHVsYXIgVlBOIGNsaWVu dCB3aWxsIGZhaWwpOyB0aGVzZSB2NCBlbnRlcnByaXNlIFZQTiBnYXRld2F5cyB3aWxsIG5vdCBi ZSB1cGRhdGVkIHRvIHN1cHBvcnQgSVB2NiBpbiBhbnkgcmVhc29uYWJsZSB0aW1lIGZyYW1lLg0K DQpBbiBvcGVyYXRvciBjaXJjdW12ZW50aW5nIHRoaXMsIGJ5IHJld29ya2luZyB0aGUgaGFuZHNl dCBBUE5zIGFuZCBidXNpbmVzcyBsb2dpYyAoZS5nLiByZXdvcmtpbmcgdGhlaXIg4oCcdGFsayBw bGFuc+KAnSBmb3IgbXVsdGlwbGUgQVBOcykgaW5jdXJzIGxhcmdlIGNvc3RzIOKAkyBpdCBpcyBi ZWNhdXNlIEFwcGxlIGRldmljZXMgYXJlIG5vdCB1c2VkIHNpbXBsZSBieSB0aGUgb3BlcmF0b3Jz IG93biBjb25zdW1lcnMsIGJ1dCBhbHNvIGJ5IGJpZyBhbmQgc21hbGwgd2hvbGVzYWxlIHBhcnRu ZXJzOyBhbnkgY2lyY3VtdmVudGlvbiBvbiBoYW5kc2V0IGNhdXNlcyBpbXBhY3QgdG8gc29tZSBw YXJ0bmVycyB3aG8gZGlkbuKAmXQgd2FudC9uZWVkIElQdjYuIE91Y2guDQpTb21lIG9wZXJhdG9y cyBhbHJlYWR5IGJpbGwgZm9yIHRldGhlcmluZyBzZXBhcmF0ZWx5IOKAkyBOb3J0aCBBbWVyaWNh IC0gbWF5YmUgdGhleSBhcmUgb2suIEhhdmluZyBsb29rZWQgYWNyb3NzIEV1cm9wZWFuIE9wZXJh dG9ycyBhdCBsZWFzdCwgSeKAmW0gd29ycmllZCB0aGF0IG1hbnkgZG8gbm90IHRvZGF5Lg0KVGhh bmtzLA0KTmljaw0KDQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUm9zcyBDaGFuZGxlcg0KU2VudDogMzEgTWF5IDIwMTYgMTE6MDcN ClRvOiBEYXZpZCBTY2hpbmF6aQ0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2 b3BzXSBBcHBsZSBhbmQgSVB2NiAtIG5ldyBOQVQ2NCBhZGRyZXNzIHN5bnRoZXNpcyBBUEkNCg0K SGkgRGF2aWQsDQoNCkNhbiBJIGFzayB3aGF0IEFwcGxl4oCZcyBpbnRlbnRpb25zIGFyZSBmb3Ig c3VwcG9ydGluZyB0ZXRoZXJlZCBkZXZpY2VzPyBJbiBwYXJ0aWN1bGFyIGluIHRoZSBjYXNlIHdo ZXJlIHRoZSBpT1MgZGV2aWNlIG9ubHkgaGFzIElQdjYtb25seSBQRFAvUEROIGNvbm5lY3Rpb25z IG9yIGEgc2hhcmVkIGhhbmRzZXQgJiB0ZXRoZXJpbmcgSVB2Ni1vbmx5IEFQTj8NCklmIHRoZSB0 ZXRoZXJpbmcgaW50ZXJmYWNlIG9mIHRoZSBpT1MgZGV2aWNlIGNhbiBvbmx5IHByb3ZpZGUgNjRz aGFyZSAoUkZDIDcyNzgpIHdpdGhvdXQgc3VwcG9ydCBmb3IgSVB2NCAoZS5nLiB2aWEgYW4gUkZD IDY4NzcgY2xhdCkgdGhlbiB0ZXRoZXJlZCBkZXZpY2VzIHdpbGwgYmUgcmVzdHJpY3RlZCB0byB0 aG9zZSBzdXBwb3J0aW5nIElQdjYtb25seSBjb25uZWN0aXZpdHkgdXNpbmcgRE5TNjQvTkFUNjQu DQoNClRoYW5rcw0KUm9zcw0KDQoNCg0KT24gMzAgT2N0IDIwMTUsIGF0IDA0OjUxLCBEYXZpZCBT Y2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNvbTxtYWlsdG86ZHNjaGluYXppQGFwcGxlLmNvbT4+ IHdyb3RlOg0KDQpIaSBldmVyeW9uZSwNCg0KVGhpcyB3ZWVrIEFwcGxlIHJlbGVhc2VkIHRoZSBm aXJzdCBiZXRhcyBvZiBpT1MgOS4yIGFuZCBPUyBYIDEwLjExLjIuDQpXaXRoIGl0LCB3ZeKAmXZl IGludHJvZHVjZWQgYSBuZXcgQVBJIHRvIGFsbG93IGRldmVsb3BlcnMgdG8gc3ludGhlc2l6ZSBO QVQ2NCBJUHY2IGFkZHJlc3NlcyBmcm9tIElQdjQgbGl0ZXJhbHMuDQpXZeKAmXJlIGhvcGluZyB0 aGF0IHRoaXMgd2lsbCBoZWxwIG1vcmUgYXBwbGljYXRpb25zIHN1cHBvcnQgTkFUNjQgbmV0d29y a3MgY29ycmVjdGx5IHdoaWxlIHRoZXkgd29yayBvbiBnZXR0aW5nIHNlcnZlciBzdXBwb3J0IGZv ciBJUHY2Lg0KQXMgdXN1YWwsIHdl4oCZZCBsb3ZlIGZlZWRiYWNrIGZyb20gdGhlIElFVEYgY29t bXVuaXR5Lg0KDQpUaGUgQVBJIGlzIHZlcnkgc2ltcGxlOiB3ZSBhc2sgZGV2ZWxvcGVycyB0byBh bHdheXMgYGByZXNvbHZlJ+KAmSB0aGVpciBJUHY0IGxpdGVyYWxzIHVzaW5nIGdldGFkZHJpbmZv KCkgYnkgdHJlYXRpbmcgdGhlaXIgSVB2NCBsaXRlcmFsIGFzIGEgaG9zdG5hbWUgc3RyaW5nIChl LmcuIGBgMTkyLjAuMi4xJycpLCBhbmQgd2Ugd2lsbCB0YWtlIGNhcmUgb2YgcmV0dXJuaW5nIGFu IElQdjQgc29ja2FkZHIgb24gSVB2NCBuZXR3b3JrcyBhbmQgYW4gYXBwcm9wcmlhdGVseSBzeW50 aGVzaXplZCBOQVQ2NCBJUHY2IHNvY2thZGRyIHdoZW4gdGhlIG5ldHdvcmsgc3VwcG9ydHMgSVB2 NiwgTkFUNjQgYW5kIEROUzY0IGJ1dCBub3QgSVB2NC4gVGhpcyBpcyBhY2NvbXBsaXNoZWQgdXNp bmcgUkZDIDYwNTIgYW5kIFJGQyA3MDUwLg0KDQpPdXIgdGFyZ2V0IGF1ZGllbmNlIGlzIGFwcGxp Y2F0aW9uIGRldmVsb3BlcnMgdGhhdCBuZWVkIHRvIGNvbW11bmljYXRlIHRvIGFuIElQdjQtb25s eSBob3N0IGZvciB3aGljaCB0aGV5IGRvIG5vdCBoYXZlIGEgaG9zdG5hbWUuIEFuIGV4YW1wbGUg aXMgYSBQMlAgc2VydmljZSB0cmFuc21pdHRpbmcgSVB2NCBsaXRlcmFscyBvdmVyIHRoZSB3aXJl LiBXZSBkbyBhZ3JlZSB0aGF0IHRoZSBjb3JyZWN0IGxvbmctdGVybSBzb2x1dGlvbiBpcyBJUHY2 IHN1cHBvcnQgZm9yIGFsbCBob3N0cyBhbmQgcHJvdG9jb2xzIGJ1dCB0aGlzIGlzIGFuIGVmZm9y dCB0byBlYXNlIHRoZSB0cmFuc2l0aW9uLiBXZSBiZWxpZXZlIHRoaXMgd2lsbCBoZWxwIGZpeCBh bnkgcmVtYWluaW5nIGFwcHMgdGhhdCBkbyBub3Qgc3VwcG9ydCBJUHY2IGJlZm9yZSB3ZSBzdGFy dCByZWplY3RpbmcgdGhlbSBmcm9tIHRoZSBBcHAgU3RvcmUgaW4gZWFybHkgMjAxNi4NCg0KTW9y ZSBkZXRhaWxzIGFuZCBhIGNvZGUgc2FtcGxlIGNhbiBiZSBmb3VuZCBvbiB0aGUgQXBwbGUgZG9j dW1lbnRhdGlvbiB3ZWJzaXRlOg0KDQpodHRwczovL2RldmVsb3Blci5hcHBsZS5jb20vbGlicmFy eS9wcmVyZWxlYXNlL3R2b3MvZG9jdW1lbnRhdGlvbi9OZXR3b3JraW5nSW50ZXJuZXRXZWIvQ29u Y2VwdHVhbC9OZXR3b3JraW5nT3ZlcnZpZXcvVW5kZXJzdGFuZGluZ2FuZFByZXBhcmluZ2ZvcnRo ZUlQdjZUcmFuc2l0aW9uL1VuZGVyc3RhbmRpbmdhbmRQcmVwYXJpbmdmb3J0aGVJUHY2VHJhbnNp dGlvbi5odG1sIy8vYXBwbGVfcmVmL2RvYy91aWQvVFA0MDAxMDIyMC1DSDIxMy1Eb250TGlua0Vs ZW1lbnRJRF80DQoNClRoYW5rcywNCkRhdmlkIFNjaGluYXppDQpBcHBsZSBDb3JlT1MgTmV0d29y a2luZyBFbmdpbmVlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoN Ck5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlv biwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50IG9u bHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gDQpJZiB5b3Un cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBjb3B5 aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVk LiANCklmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0IG1l IGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4N Cg0KV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWls cy4NCg0KRUUgTGltaXRlZCANClJlZ2lzdGVyZWQgb2ZmaWNlOlRyaWRlbnQgUGxhY2UsIE1vc3F1 aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm86IDAyMzgyMTYxDQoNCkVFIExpbWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQgc3Vi c2lkaWFyeSBvZjoNCg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdpc3RlcmVk IG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgbm86IDE4MDAwMDANCg== --_000_6536E263028723489CCD5B6821D4B21317183DECUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRGF2 aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gcmVhbGx5IHBsZWFzZWQgd2l0 aCB0aGUgcHJvZ3Jlc3Mgb24gaGFuZGxpbmcgbGl0ZXJhbHMgb24gdGhlIGRldmljZSwgdGhhbmtz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBhbHNvIHZlcnkgaW50ZXJlc3Rl ZCBpbiB0aGlzIHF1ZXN0aW9uIG9uIHRldGhlcmluZyB1c2UtY2FzZSwgZGlkbuKAmXQgc2VlIGFu eSByZXBseSwgb3IgYW55dGhpbmcgaW4gV1dEQzE2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gYWRkIHRvIFJvc3Pi gJlzIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3Qgc3VwcGx5aW5n IElQdjQgd2hlbiB0ZXRoZXJpbmcgc3RpbGwgbGVhdmVzIG1hbnkgb3BlcmF0b3JzIHdpdGggYSBw cm9ibGVtIOKAkyBjdXN0b21lcnMgd2lsbCBub3QgYWNjZXB0IElQc2VjIFZQTiBjbGllbnRzIG9u IHRldGhlcmVkIGRldmljZXMgZmFpbGluZyB0byBjb25uZWN0DQogdG8gSVB2NCBWUE4gZ2F0ZXdh eXMgKGUuZy4gYSB2ZXJ5IHBvcHVsYXIgVlBOIGNsaWVudCB3aWxsIGZhaWwpOyB0aGVzZSB2NCBl bnRlcnByaXNlIFZQTiBnYXRld2F5cyB3aWxsIG5vdCBiZSB1cGRhdGVkIHRvIHN1cHBvcnQgSVB2 NiBpbiBhbnkgcmVhc29uYWJsZSB0aW1lIGZyYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW4gb3BlcmF0b3IgY2ly Y3VtdmVudGluZyB0aGlzLCBieSByZXdvcmtpbmcgdGhlIGhhbmRzZXQgQVBOcyBhbmQgYnVzaW5l c3MgbG9naWMgKGUuZy4gcmV3b3JraW5nIHRoZWlyIOKAnHRhbGsgcGxhbnPigJ0gZm9yIG11bHRp cGxlIEFQTnMpIGluY3VycyBsYXJnZSBjb3N0cyDigJMNCiBpdCBpcyBiZWNhdXNlIEFwcGxlIGRl dmljZXMgYXJlIG5vdCB1c2VkIHNpbXBsZSBieSB0aGUgb3BlcmF0b3JzIG93biBjb25zdW1lcnMs IGJ1dCBhbHNvIGJ5IGJpZyBhbmQgc21hbGwgd2hvbGVzYWxlIHBhcnRuZXJzOyBhbnkgY2lyY3Vt dmVudGlvbiBvbiBoYW5kc2V0IGNhdXNlcyBpbXBhY3QgdG8gc29tZSBwYXJ0bmVycyB3aG8gZGlk buKAmXQgd2FudC9uZWVkIElQdjYuIE91Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvbWUgb3BlcmF0b3JzIGFscmVhZHkgYmlsbCBmb3IgdGV0aGVyaW5nIHNlcGFyYXRlbHkg4oCT IE5vcnRoIEFtZXJpY2EgLSBtYXliZSB0aGV5IGFyZSBvay4gSGF2aW5nIGxvb2tlZCBhY3Jvc3Mg RXVyb3BlYW4gT3BlcmF0b3JzIGF0IGxlYXN0LCBJ4oCZbSB3b3JyaWVkIHRoYXQNCiBtYW55IGRv IG5vdCB0b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9zcyBDaGFuZGxlcjxicj4NCjxi PlNlbnQ6PC9iPiAzMSBNYXkgMjAxNiAxMTowNzxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2NoaW5h emk8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdjZvcHNdIEFwcGxlIGFuZCBJUHY2IC0gbmV3IE5BVDY0IGFkZHJlc3Mgc3ludGhlc2lzIEFQ STxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERhdmlk LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIEkgYXNr IHdoYXQgQXBwbGXigJlzIGludGVudGlvbnMgYXJlIGZvciBzdXBwb3J0aW5nIHRldGhlcmVkIGRl dmljZXM/IEluIHBhcnRpY3VsYXIgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGlPUyBkZXZpY2Ugb25s eSBoYXMgSVB2Ni1vbmx5IFBEUC9QRE4gY29ubmVjdGlvbnMgb3IgYSBzaGFyZWQgaGFuZHNldCAm YW1wOyB0ZXRoZXJpbmcgSVB2Ni1vbmx5IEFQTj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB0ZXRoZXJpbmcgaW50ZXJmYWNlIG9mIHRo ZSBpT1MgZGV2aWNlIGNhbiBvbmx5IHByb3ZpZGUgNjRzaGFyZSAoUkZDIDcyNzgpIHdpdGhvdXQg c3VwcG9ydCBmb3IgSVB2NCAoZS5nLiB2aWEgYW4gUkZDIDY4NzcgY2xhdCkgdGhlbiB0ZXRoZXJl ZCBkZXZpY2VzIHdpbGwgYmUgcmVzdHJpY3RlZCB0byB0aG9zZSBzdXBwb3J0aW5nIElQdjYtb25s eSBjb25uZWN0aXZpdHkgdXNpbmcgRE5TNjQvTkFUNjQuDQogJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9zczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMwIE9j dCAyMDE1LCBhdCAwNDo1MSwgRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9Im1haWx0bzpkc2No aW5hemlAYXBwbGUuY29tIj5kc2NoaW5hemlAYXBwbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgZXZlcnlv bmUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgd2VlayBBcHBsZSByZWxlYXNlZCB0aGUgZmlyc3QgYmV0YXMgb2YgaU9TIDkuMiBhbmQg T1MgWCAxMC4xMS4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2l0aCBpdCwgd2XigJl2ZSBpbnRyb2R1Y2VkIGEgbmV3IEFQSSB0byBhbGxvdyBk ZXZlbG9wZXJzIHRvIHN5bnRoZXNpemUgTkFUNjQgSVB2NiBhZGRyZXNzZXMgZnJvbSBJUHY0IGxp dGVyYWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2XigJlyZSBob3BpbmcgdGhhdCB0aGlzIHdpbGwgaGVscCBtb3JlIGFwcGxpY2F0aW9ucyBz dXBwb3J0IE5BVDY0IG5ldHdvcmtzIGNvcnJlY3RseSB3aGlsZSB0aGV5IHdvcmsgb24gZ2V0dGlu ZyBzZXJ2ZXIgc3VwcG9ydCBmb3IgSVB2Ni48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHVzdWFsLCB3ZeKAmWQgbG92ZSBmZWVkYmFjayBmcm9t IHRoZSBJRVRGIGNvbW11bml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIEFQSSBpcyB2ZXJ5IHNpbXBsZTogd2UgYXNrIGRldmVsb3Bl cnMgdG8gYWx3YXlzIGBgcmVzb2x2ZSfigJkgdGhlaXIgSVB2NCBsaXRlcmFscyB1c2luZyBnZXRh ZGRyaW5mbygpIGJ5IHRyZWF0aW5nIHRoZWlyIElQdjQgbGl0ZXJhbCBhcyBhIGhvc3RuYW1lIHN0 cmluZyAoZS5nLiBgYDE5Mi4wLjIuMScnKSwgYW5kIHdlIHdpbGwgdGFrZSBjYXJlIG9mIHJldHVy bmluZyBhbiBJUHY0IHNvY2thZGRyIG9uIElQdjQNCiBuZXR3b3JrcyBhbmQgYW4gYXBwcm9wcmlh dGVseSBzeW50aGVzaXplZCBOQVQ2NCBJUHY2IHNvY2thZGRyIHdoZW4gdGhlIG5ldHdvcmsgc3Vw cG9ydHMgSVB2NiwgTkFUNjQgYW5kIEROUzY0IGJ1dCBub3QgSVB2NC4gVGhpcyBpcyBhY2NvbXBs aXNoZWQgdXNpbmcgUkZDIDYwNTIgYW5kIFJGQyA3MDUwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdXIgdGFyZ2V0IGF1ZGllbmNlIGlzIGFw cGxpY2F0aW9uIGRldmVsb3BlcnMgdGhhdCBuZWVkIHRvIGNvbW11bmljYXRlIHRvIGFuIElQdjQt b25seSBob3N0IGZvciB3aGljaCB0aGV5IGRvIG5vdCBoYXZlIGEgaG9zdG5hbWUuIEFuIGV4YW1w bGUgaXMgYSBQMlAgc2VydmljZSB0cmFuc21pdHRpbmcgSVB2NCBsaXRlcmFscyBvdmVyIHRoZSB3 aXJlLiBXZSBkbyBhZ3JlZSB0aGF0IHRoZSBjb3JyZWN0IGxvbmctdGVybQ0KIHNvbHV0aW9uIGlz IElQdjYgc3VwcG9ydCBmb3IgYWxsIGhvc3RzIGFuZCBwcm90b2NvbHMgYnV0IHRoaXMgaXMgYW4g ZWZmb3J0IHRvIGVhc2UgdGhlIHRyYW5zaXRpb24uIFdlIGJlbGlldmUgdGhpcyB3aWxsIGhlbHAg Zml4IGFueSByZW1haW5pbmcgYXBwcyB0aGF0IGRvIG5vdCBzdXBwb3J0IElQdjYgYmVmb3JlIHdl IHN0YXJ0IHJlamVjdGluZyB0aGVtIGZyb20gdGhlIEFwcCBTdG9yZSBpbiBlYXJseSAyMDE2Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3Jl IGRldGFpbHMgYW5kIGEgY29kZSBzYW1wbGUgY2FuIGJlIGZvdW5kIG9uIHRoZSBBcHBsZSBkb2N1 bWVudGF0aW9uIHdlYnNpdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9saWJy YXJ5L3ByZXJlbGVhc2UvdHZvcy9kb2N1bWVudGF0aW9uL05ldHdvcmtpbmdJbnRlcm5ldFdlYi9D b25jZXB0dWFsL05ldHdvcmtpbmdPdmVydmlldy9VbmRlcnN0YW5kaW5nYW5kUHJlcGFyaW5nZm9y dGhlSVB2NlRyYW5zaXRpb24vVW5kZXJzdGFuZGluZ2FuZFByZXBhcmluZ2ZvcnRoZUlQdjZUcmFu c2l0aW9uLmh0bWwjLy9hcHBsZV9yZWYvZG9jL3VpZC9UUDQwMDEwMjIwLUNIMjEzLURvbnRMaW5r RWxlbWVudElEXzQiPmh0dHBzOi8vZGV2ZWxvcGVyLmFwcGxlLmNvbS9saWJyYXJ5L3ByZXJlbGVh c2UvdHZvcy9kb2N1bWVudGF0aW9uL05ldHdvcmtpbmdJbnRlcm5ldFdlYi9Db25jZXB0dWFsL05l dHdvcmtpbmdPdmVydmlldy9VbmRlcnN0YW5kaW5nYW5kUHJlcGFyaW5nZm9ydGhlSVB2NlRyYW5z aXRpb24vVW5kZXJzdGFuZGluZ2FuZFByZXBhcmluZ2ZvcnRoZUlQdjZUcmFuc2l0aW9uLmh0bWwj Ly9hcHBsZV9yZWYvZG9jL3VpZC9UUDQwMDEwMjIwLUNIMjEzLURvbnRMaW5rRWxlbWVudElEXzQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRhdmlkIFNjaGluYXppPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BcHBsZSBDb3JlT1MgTmV0d29ya2luZyBFbmdpbmVlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCg0KPFA+Tk9USUNFIEFO RCBESVNDTEFJTUVSPEJSPlRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNo IG1heSBiZSANCnByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9y IHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSANCm5hbWVkIGFib3ZlLiA8QlI+SWYgeW91J3Jl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RlIHRoYXQgZGlzY2xvc2luZywgDQpjb3B5 aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVk LiA8QlI+SWYgeW91J3ZlIA0KcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGxl dCBtZSBrbm93IGltbWVkaWF0ZWx5IG9uIHRoZSBlbWFpbCANCmFkZHJlc3MgYWJvdmUuIFRoYW5r IHlvdS48L1A+DQo8UD5XZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3Jk IHlvdXIgZW1haWxzLjwvUD4NCjxQPkVFIExpbWl0ZWQgPEJSPlJlZ2lzdGVyZWQgb2ZmaWNlOlRy aWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIA0KSGVydGZvcmRzaGlyZSwgQUwx MCA5Qlc8QlI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIG5vOiAwMjM4MjE2MTwvUD4NCjxQPkVFIExp bWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQgc3Vic2lkaWFyeSBvZjo8L1A+DQo8UD5Ccml0aXNoIFRl bGVjb21tdW5pY2F0aW9ucyBwbGM8QlI+UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3Ry ZWV0IExvbmRvbiANCkVDMUEgN0FKPEJSPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMTgwMDAw MDwvUD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6536E263028723489CCD5B6821D4B21317183DECUK30S005EXS06EE_--