From nobody Wed Apr 1 01:14:55 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02821A8A71; Wed, 1 Apr 2015 01:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwUeU1zNTF6Y; Wed, 1 Apr 2015 01:14:51 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8511A8A68; Wed, 1 Apr 2015 01:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1774; q=dns/txt; s=iport; t=1427876091; x=1429085691; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=neWwtskqYwqj1nE8gcB5njzUv7UmG/+SfHOqy8n4cGs=; b=cOOeNV+P70V+ABEjeVIhiNHLkYpFwKjzTFKcvPca7tkI9jDwcOCG+kgw eFtggqitcEFtEfpBs65Yg4sNhiTzEnqaTmgeY/95o6IrH6N962w7/gEE4 3mq/4o0zNF2iCNdSAuEB5LcQ9Jc5vwmt3qu0q7O6KkTAQaC7Q4Nu3HKaE c=; X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208,217";a="406697298" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Apr 2015 08:14:49 +0000 Received: from [10.55.98.183] (ams-stbryant-8816.cisco.com [10.55.98.183]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t318Emb9028843; Wed, 1 Apr 2015 08:14:48 GMT Message-ID: <551BA8F8.1080706@cisco.com> Date: Wed, 01 Apr 2015 09:14:48 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> In-Reply-To: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> Content-Type: multipart/alternative; boundary="------------000907070101040308030708" Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 08:14:52 -0000 This is a multi-part message in MIME format. --------------000907070101040308030708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption. SB> It is subject to corruption whether or not it has a checksum. SB> The point is that there may be undetected corruption. However SB> detection in only probabilistic even with a checksum. So SB> I think that that this text should be: Because the IPv6 delivery header does not include a checksum of its own, it is subject to higher probability of undetected corruption. - Stewart --------------000907070101040308030708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Because the IPv6 delivery header does not include a checksum of its
own, it is subject to corruption. 

SB> It is subject to corruption whether or not it has a checksum.
SB> The point is that there may be undetected corruption. However
SB> detection in only probabilistic even with a checksum. So
SB> I think that that this text should be:

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to higher probability of undetected corruption. 

- Stewart



--------------000907070101040308030708-- From nobody Wed Apr 1 01:24:25 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC481A8A7C; Wed, 1 Apr 2015 01:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTYyCF0eUpiA; Wed, 1 Apr 2015 01:24:22 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FC71A895B; Wed, 1 Apr 2015 01:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17026; q=dns/txt; s=iport; t=1427876661; x=1429086261; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=pA/CumBDrP033Lcg8wv6YR08bIA/4HaK6ffx15GrZsI=; b=T38JS0cxzouWEj8XUgId/e0n5CppMeZbDbIr8JB+NeNsnglQdSsiNQmV mpKs1jG5lH0dCYtPHag1XDQTRkuOcVIFAd4VntMAmShyovBiqWnglZaJo ss6uN5KvDeYbv0UhfusFcCqZEivUTGdSkBTYFlB3/BwIldFCv0YF4ttn7 0=; X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208,217";a="407115803" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 01 Apr 2015 08:24:18 +0000 Received: from [10.55.98.183] (ams-stbryant-8816.cisco.com [10.55.98.183]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t318OHLb024287; Wed, 1 Apr 2015 08:24:18 GMT Message-ID: <551BAB31.40204@cisco.com> Date: Wed, 01 Apr 2015 09:24:17 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , Lucy yong , "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040003030408000300090408" Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 08:24:23 -0000 This is a multi-part message in MIME format. --------------040003030408000300090408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 30/03/2015 22:49, Ronald Bonica wrote: > > Lucy, > > Would the following text work? > > OLD> > > Because the IPv6 delivery header does not include a checksum of its > > own, it is subject to corruption. However, even if the delivery > > header is corrupted, to likelihood of that corruption resulting in > > misdelivery of the payload is extremely low. > > > NEW> > > Because the IPv6 delivery header does not include a checksum of its > > own, the destination address in the delivery header is subject to > > corruption. If the destination address in the deliver header is > corrupted, > > the following outcomes are possible: > > 1)The delivery packet is dropped because the new destination address > is unreachable > > 2)The delivery packet is dropped because the new destination address > is reachable, but that node is not configured to process GRE delivery > packets from the ingress > > 3)The delivery packet is processed by a GRE egress other than that > which was originally specified by the GRE ingress. Processing options are: > > a.The payload packet is dropped because the payload destination is > unreachable from the node that processed the delivery packet > > b.The payload packet is delivered to its intended destination because > the payload destination is reachable from the node that processed the > delivery packet > > All of these outcomes are acceptable. > > > Ron > Ron, maybe I am missing a caveat, but suppose the payload is a packet with a non-globally unique address space (for example 10.x.x.x, but not limited to IP) then there is a case 3 c which is that the packet was delivered to a node that it was not the intended ultimate destination and one has to hope that there is sufficient resilency in the system receiving the packet that this is of no consequence. Stewart --------------040003030408000300090408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 30/03/2015 22:49, Ronald Bonica wrote:

Lucy,

 

Would the following text work?

 

OLD>

   Because the IPv6 delivery header does not include a checksum of its

   own, it is subject to corruption.  However, even if the delivery

   header is corrupted, to likelihood of that corruption resulting in

   misdelivery of the payload is extremely low.

<OLD

 

NEW>

   Because the IPv6 delivery header does not include a checksum of its

   own,  the destination address in the delivery header is subject to

   corruption. If the destination address in the deliver header is corrupted,

   the following outcomes are possible:

 

1)      The delivery packet is dropped because the new destination address is unreachable

2)      The delivery packet is dropped because the new destination address is reachable, but that node is not configured to process GRE delivery packets from the ingress

3)      The delivery packet is processed by a GRE egress other than that which was originally specified by the GRE ingress. Processing options are:

a.       The payload packet is dropped because the payload destination is unreachable from the node that processed the delivery packet

b.      The payload packet is delivered to its intended destination because the payload destination is reachable from the node that processed the delivery packet

 

All of these outcomes are acceptable.

 

<NEW

 

                          Ron

Ron, maybe I am missing a caveat, but suppose the payload is a packet with a non-globally unique address space (for example 10.x.x.x, but not limited to IP) then there is a case 3 c which is that the packet was delivered to a node that it was not the intended ultimate destination and one has to hope that there is sufficient resilency in the system receiving the packet that this is of no consequence.

Stewart
--------------040003030408000300090408-- From nobody Wed Apr 1 01:30:57 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64421A8AB9; Wed, 1 Apr 2015 01:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrMsO9-N9keD; Wed, 1 Apr 2015 01:30:50 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43DE1A1A06; Wed, 1 Apr 2015 01:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36356; q=dns/txt; s=iport; t=1427877050; x=1429086650; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=KVQMpnAluwF/mJw+i8HFp0eiFBLTq0Iby7KHtBVa3Dk=; b=JnmjuBSNhiq+qhHi0jkoSDhx31HipubUDgb6EzhXTRZiGMz0sExAShCt Uo7yyOafmI+UBT/ovpwqeMH/5o8ePOo9RN2tCjaBHwYYksxW5wC7m4A+q srV6uVxYwRqQjU7q7C8O5uvUr5bP6U0uSHG6F5hUzu5KH/H4J6g14ZFjB I=; X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208,217";a="411330505" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Apr 2015 08:30:48 +0000 Received: from [10.55.98.183] (ams-stbryant-8816.cisco.com [10.55.98.183]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t318UlwU005909; Wed, 1 Apr 2015 08:30:47 GMT Message-ID: <551BACB7.1030203@cisco.com> Date: Wed, 01 Apr 2015 09:30:47 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , Lucy yong , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D5715558D@dfweml701-chm> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000600020004090509080805" Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 08:30:53 -0000 This is a multi-part message in MIME format. --------------000600020004090509080805 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Isn't systematic rather than random corruption more likely? Stewart On 31/03/2015 23:04, Ronald Bonica wrote: > > Lucy, David, > > The proposed text says that outcome 3c) is unacceptable but highly > unlikely. For example, assume the following: > > -That an IPv6 address is assigned to every milligram of matter on > earth, including every drop of water. (2**95 IPv6 addresses are assigned) > > -That every minute, the destination address on a delivery packet is > corrupted > > -The pattern of corruption is random > > Every time a destination address is corrupted, the odds are 1 / > 8,589,934,592 that the result will be an assigned address. This should > happen one ever 16, 331 years. > > Now, assume that only 1% of those of those 2**95 IPv6 addresses are > configured on devices that de-encapsulate GRE. In this case, outcomes > 3a), 3b) and 3c) will occur only once every 1,633,100 years! > > So, practically speaking, we don’t have much to worry about. But for > the purposes of the pedantry, we may need to say that GRE over IPv6 is > only practical when operators can deal with that risk. > > David, what is the minimum text that we can import to satisfy the > requirement. > > Ron > > *From:* Lucy yong [mailto:lucy.yong@huawei.com] > *Sent:* Tuesday, March 31, 2015 3:21 PM > *To:* Ronald Bonica; Black, David; int-area@ietf.org; ipv6@ietf.org > *Cc:* draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Hi Ron, > > 3c) may happen for a VPN or non-VPN case. The payload can be in > non-IPv6 space. Is “Outcome 3c) is not acceptable, but it extremely > unlikely.” for particular network/usage in your mind? > > Is the goal here to prove such corruption is acceptable or extreme > unlikely? > > Regards, > > Lucy > > *From:*Int-area [mailto:int-area-bounces@ietf.org] *On Behalf Of > *Ronald Bonica > *Sent:* Tuesday, March 31, 2015 1:43 PM > *To:* Black, David; int-area@ietf.org ; > ipv6@ietf.org > *Cc:* draft-ietf-intarea-gre-ipv6@tools.ietf.org > ; > intarea-chairs@ietf.org > *Subject:* Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 > > Resend… > > *From:* Ronald Bonica > *Sent:* Tuesday, March 31, 2015 2:23 PM > *To:* 'Black, David'; int-area@ietf.org ; > ipv6@ietf.org > *Cc:* draft-ietf-intarea-gre-ipv6@tools.ietf.org > ; > intarea-chairs@ietf.org > *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > David, Lucy, > > You are correct. Maybe the following text will address the issue: > > OLD> > > Because the IPv6 delivery header does not include a checksum of its > > own, it is subject to corruption. However, even if the delivery > > header is corrupted, to likelihood of that corruption resulting in > > misdelivery of the payload is extremely low. > > > NEW> > > Because the IPv6 delivery header does not include a checksum of its > > own, the destination address in the delivery header is subject to > > corruption. If the destination address in the deliver header is > corrupted, > > the following outcomes are possible: > > 1)The delivery packet is dropped because the new destination address > is unreachable > > 2)The delivery packet is dropped because the new destination address > is reachable, but that node is not configured to process GRE delivery > packets from the ingress > > 3)The delivery packet is processed by a GRE egress other than that > which was originally specified by the GRE ingress. Processing options are: > > a.The payload packet is dropped because the payload destination is > unreachable from the node that processed the delivery packet > > b.The payload packet is delivered to its intended destination > > c.The payload packet is erroneously delivered to a node other than its > intended destination. The intended destination and the node to which > the payload is actually delivered are numbered identically, but reside > in different VPNs. > > Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not > acceptable, but it extremely unlikely. Because IPv6 address space is > so large and so sparsely populated, outcome 1) is by far the most > probable. Therefore, the combined likelihood of all acceptable > outcomes by far exceeds the likelihood of the one unacceptable outcome. > > Furthermore, even if the payload is erroneously delivered to a node > other than its intended destination, that node will discard the packet > if the payload is also corrupted or if there are no applications > waiting to consume the packet. > > > Ron > > *From:* Black, David [mailto:david.black@emc.com] > *Sent:* Monday, March 30, 2015 7:48 PM > *To:* Ronald Bonica; int-area@ietf.org ; > ipv6@ietf.org > *Cc:* draft-ietf-intarea-gre-ipv6@tools.ietf.org > ; > intarea-chairs@ietf.org ; Black, David > *Subject:* RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 > > > Also, why would you object to 3b? The packet ends up at the right > node, just via an unexpected route. > > That assertion is based on the assumption that the payload destination > address is worldwide unique. > > There are lots of counterexamples that void the assumption, e.g., > 10.0.0.0/8. > > Thanks, > --David > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000600020004090509080805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Isn't systematic rather than random corruption more likely?

Stewart

On 31/03/2015 23:04, Ronald Bonica wrote:

Lucy, David,

 

The proposed text says that outcome 3c) is unacceptable but highly unlikely. For example, assume the following:

 

-          That an IPv6 address is assigned to every milligram of matter on earth, including every drop of water. (2**95 IPv6 addresses are assigned)

-          That every minute, the destination address on a delivery packet is corrupted

-          The pattern of corruption is random

 

Every time a destination address is corrupted, the odds are 1 / 8,589,934,592 that the result will be an assigned address. This should happen one ever 16, 331 years.

 

Now, assume that only 1% of those of those 2**95 IPv6 addresses are configured on devices that de-encapsulate GRE. In this case, outcomes 3a), 3b) and 3c) will occur only once every 1,633,100 years!

 

So, practically speaking, we don’t have much to worry about. But for the purposes of the pedantry, we may need to say that GRE over IPv6 is only practical when operators can deal with that risk.

 

David, what is the minimum text that we can import to satisfy the requirement.

 

                                                             Ron

 

 

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, March 31, 2015 3:21 PM
To: Ronald Bonica; Black, David; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

 

Hi Ron,

 

3c) may happen for a VPN or non-VPN case. The payload can be in non-IPv6 space.  Is “Outcome 3c) is not acceptable, but it extremely unlikely.” for particular network/usage in your mind?

 

Is the goal here to prove such corruption is acceptable or extreme unlikely?   

 

Regards,

Lucy

 

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, March 31, 2015 1:43 PM
To: Black, David; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

 

Resend…

 

From: Ronald Bonica
Sent: Tuesday, March 31, 2015 2:23 PM
To: 'Black, David'; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

 

David, Lucy,

 

You are correct.  Maybe the following text will address the issue:

 

OLD>

   Because the IPv6 delivery header does not include a checksum of its

   own, it is subject to corruption.  However, even if the delivery

   header is corrupted, to likelihood of that corruption resulting in

   misdelivery of the payload is extremely low.

<OLD

 

NEW>

   Because the IPv6 delivery header does not include a checksum of its

   own,  the destination address in the delivery header is subject to

   corruption. If the destination address in the deliver header is corrupted,

   the following outcomes are possible:

 

1)      The delivery packet is dropped because the new destination address is unreachable

2)      The delivery packet is dropped because the new destination address is reachable, but that node is not configured to process GRE delivery packets from the ingress

3)      The delivery packet is processed by a GRE egress other than that which was originally specified by the GRE ingress. Processing options are:

a.       The payload packet is dropped because the payload destination is unreachable from the node that processed the delivery packet

b.      The payload packet is delivered to its intended destination

c.       The payload packet is erroneously delivered to a node other than its intended destination. The intended destination and the node to which the payload is actually delivered are numbered identically, but reside in different VPNs.

 

Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not acceptable, but it extremely unlikely. Because IPv6 address space is so large and so sparsely populated, outcome 1) is by far the most probable. Therefore, the combined likelihood of all acceptable outcomes by far exceeds the likelihood of the one unacceptable outcome.

 

Furthermore, even if the payload is erroneously delivered to a node other than its intended destination, that node will discard the packet if the payload is also corrupted or if there are no applications waiting to consume the packet.

 

<NEW

 

                                   Ron

 

 

From: Black, David [mailto:david.black@emc.com]
Sent: Monday, March 30, 2015 7:48 PM
To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org; Black, David
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

 

> Also, why would you object to 3b? The packet ends up at the right node, just via an unexpected route.

 

That assertion is based on the assumption that the payload destination address is worldwide unique.

 

There are lots of counterexamples that void the assumption, e.g., 10.0.0.0/8.

 

Thanks,
--David

 

 



_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--------------000600020004090509080805-- From nobody Wed Apr 1 07:13:35 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653431A9237; Wed, 1 Apr 2015 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjrHehiEOJ_6; Wed, 1 Apr 2015 07:13:28 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F291A89FA; Wed, 1 Apr 2015 07:13:28 -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 t31EDR3l012257; Wed, 1 Apr 2015 07:13:27 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t31EDMwA011971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 1 Apr 2015 07:13:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.107]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 07:13:22 -0700 From: "Templin, Fred L" To: "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72A Date: Wed, 1 Apr 2015 14:13:20 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:13:32 -0000 Hi David, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Tuesday, March 31, 2015 7:06 PM > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org; = Black, David > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration >=20 > So, I talked to Ron off-list and it looks like something is missing from > this discussion. >=20 > The "alternative configuration" is not motivated by a desire to allow > implementation flexibility or bless broken implementations. It's motivat= ed > by consideration of networks with operational practices wherein a GMTU of > less than 1280 octets is evidence that something is seriously wrong. Tha= t > something might be misconfiguration (quoting RFC 5706, "Anything that > can be configured can be misconfigured."), or an attack on the GRE > ingress's PMTU estimation. >=20 > So, in the situation of interest (GMTU < 1280) something is wrong, and > the operator may be faced with a Hobson's choice: either blackhole the > traffic that can no longer be sent without fragmentation, or fragment a > lot of traffic, causing problems at the GRE egress by overwhelming its > reassembly code - there may be good operational and/or security reasons > to not want to do the latter. All of this ought to be explained in the > draft. No, that's is not right. GMTU < 1280 is not necessarily an indication that something is wrong, as explained in Section 7 of RFC2473. The same considerations apply here. Thanks - Fred fred.l.templin@boeing.com > Thanks, > --David >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin,= Fred L > > Sent: Tuesday, March 31, 2015 6:39 PM > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > intarea-chairs@ietf.org > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 > > > > > > Fred, > > > > > > It appears that we disagree and have taken to repeating ourselves. > > > > This is not a disagreement; this is a case in which the text is actuall= y > > broken > > which you have more or less acknowledged. You can fix the text in quest= ion > > as follows: > > > > OLD: > > **** > > In its default configuration, the GRE ingress router MUST: > > > > o encapsulate the entire IPv6 packet in a single GRE header and IP > > delivery header > > > > o fragment the delivery header, so that it can be reassembled by th= e > > GRE egress > > > > However, in an alternative configuration, the GRE ingress MAY: > > > > o discard the IPv6 packet > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 > > packet source. The MTU field in the ICMPv6 PTB message is set to > > the GMTU. > > > > NEW: > > **** > > The GRE ingress router MUST: > > > > o if the IPv6 payload packet includes a fragment header, fragment t= he > > payload packet into fragments no larger than the GMTU and encaps= ulate > > each fragment in a single GRE header and IP delivery header. Othe= rwise: > > > > o encapsulate the entire IPv6 packet in a single GRE header and I= P > > delivery header > > > > o fragment the delivery packet, so that it can be reassembled by = the > > GRE egress > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IP= v6 > > packet source, subject to rate limiting. The MTU field in the= ICMPv6 > > PTB > > message is set to the GMTU. > > > > > So, why don't we solicit opinions from the rest of the WG and defer t= o their > > will. > > > > We can't do that for broken text. Ram-rodding broken text through the > > process based on popular opinion does not make it good. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > > Ron > > > > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org= ; > > intarea- > > > > chairs@ietf.org > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ip= v6 > > > > > > > > Hi Ron, > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes and s= o the > > > > design must account for tunnel paths that include links with such a= small > > > > MTU. The design must also account for nested tunnels-within-tunnels= , > > > > where the MTU seen by the first tunnel ingress may be reduced by > > > > potentially many layers of additional encapsulation. > > > > > > > > But again, the point is that the tunnel ingress cannot legitimately= send > > PTBs > > > > that report a size smaller than 1280 *and* perpetually drop packets > > smaller > > > > than 1280 which is exactly the behavior your text is permitting. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.o= rg; > > > > > intarea-chairs@ietf.org > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-= ipv6 > > > > > > > > > > Fred, > > > > > > > > > > In the last network that I operated, all interior links had MTU > > > > > greater than 9k. If I configured a GRE tunnel between two points = in that > > > > network and detected a GMTU less than 1280, it would have indicated= one of > > > > the following: > > > > > > > > > > - Phenomenal brokenness > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > In such cases, operators need some flexibility in how their netwo= rks > > > > > would behave. Why deny them this flexibility by taking away the > > > > configuration option? > > > > > > > > > > Isn't it an operator's prerogative to discard any packet that mig= ht > > degrade > > > > network performance? > > > > > > > > > > > > > > > Ron > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf= .org; > > > > > > intarea- chairs@ietf.org > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > intarea-chairs@ietf.org > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > Some (if not most) operators maintain networks in which all l= inks > > > > > > > have MTU greater than or equal to 1500. In those networks, th= e > > > > > > > very detection of a GMTU smaller than 1280 indicates brokenne= ss. > > > > > > > Those > > > > > > operators, the alternative behavior may be preferable to the de= fault. > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the link m= ust > > > > > > deliver no matter what. A GMTU smaller than 1280 does not indic= ate > > > > > > brokennesss; it can naturally happen if 1) there is a link with= a > > > > > > small MTU in the path, or > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 is a no-n= o, > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > intarea- chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, the GRE i= ngress > > MAY: > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] mes= sage > > > > > > > > > > to the > > > > > > IPv6 > > > > > > > > > > packet source. The MTU field in the ICMPv6 PTB m= essage > > is set > > > > to > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when the GRE > > > > > > > > > > ingress sends a PTB reporting a size less than 1280. > > > > > > > > > > According to RFC2460, Section 5, the standard behavior = for a > > > > > > > > > > host that receives > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > is not required to reduce the size of subsequent pack= ets to > > less > > > > than > > > > > > > > > > 1280, but must include a Fragment header in those pa= ckets? > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a perpet= ual > > > > > > > > > > black hole if the GMTU is smaller than 1280 which is > > > > > > > > > > probably not what we > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > All true. This is why the WG decided to make this the > > > > > > > > > alternative behavior > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless of wheth= er it > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide guid= ance > > > > > > > > > > to hosts on how to react to PTB messages that report a = small > > size. > > > > > > > > > > But, as of right now, > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in Section 5= or > > > > > > > > > RFC > > > > > > > > > 246 are > > > > > > > > normative. > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision regarding t= he > > > > > > > > > current > > > > > > draft. > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether alternativ= e or > > > > default. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 08:43:53 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5511ACDEF; Wed, 1 Apr 2015 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQzDLSKgEkQz; Wed, 1 Apr 2015 08:43:47 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 09C4E1ACDAC; Wed, 1 Apr 2015 08:43:46 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31Fharl011769 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2015 11:43:42 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t31Fharl011769 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427903022; bh=wWg/U0alBvZjqqwyLh0d8xtpGdg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=g10yRQ1TiNt1yKICcMSPyt3JbgTAJE3EAgpyTafMsuQNTvnklzajIvj5MQt9lb2+v ARRSMoR5tbOi2/pW90p8r9oHNrg9g0gKJUv+RrlwevJtYlJIvMR7dZh2HJNqhYdVUz TbRFC/hyaLvfQEwX8yS36LA0OMEAH/JHWJ/X2J3k= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t31Fharl011769 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 1 Apr 2015 11:43:18 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31FhLiX003540 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 11:43:23 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub18.corp.emc.com (10.254.93.47) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 1 Apr 2015 11:43:21 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 11:43:21 -0400 From: "Black, David" To: "Templin, Fred L" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0A= Date: Wed, 1 Apr 2015 15:43:19 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:43:51 -0000 Fred, > No, that's is not right. GMTU < 1280 is not necessarily an indication > that something is wrong, as explained in Section 7 of RFC2473. The > same considerations apply here. I agree with the text quoted above, but what I'm observing is that there are networks for which GMTU is an indication that something is wrong (this is a consequence of operator decisions that are specific to such a network). The alternative configuration is intended for such networks, but is not intended for all networks, and would need to be qualified with words making it applicable primarily or only (or suggest some other words) to such networks. Upshot: the use of "necessarily" in the text quoted above is correct, but misses the point. Thanks, --David > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, April 01, 2015 10:13 AM > To: Black, David; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Hi David, >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Tuesday, March 31, 2015 7:06 PM > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org= ; > Black, David > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuratio= n > > > > So, I talked to Ron off-list and it looks like something is missing fro= m > > this discussion. > > > > The "alternative configuration" is not motivated by a desire to allow > > implementation flexibility or bless broken implementations. It's motiv= ated > > by consideration of networks with operational practices wherein a GMTU = of > > less than 1280 octets is evidence that something is seriously wrong. T= hat > > something might be misconfiguration (quoting RFC 5706, "Anything that > > can be configured can be misconfigured."), or an attack on the GRE > > ingress's PMTU estimation. > > > > So, in the situation of interest (GMTU < 1280) something is wrong, and > > the operator may be faced with a Hobson's choice: either blackhole the > > traffic that can no longer be sent without fragmentation, or fragment a > > lot of traffic, causing problems at the GRE egress by overwhelming its > > reassembly code - there may be good operational and/or security reasons > > to not want to do the latter. All of this ought to be explained in the > > draft. >=20 > No, that's is not right. GMTU < 1280 is not necessarily an indication > that something is wrong, as explained in Section 7 of RFC2473. The > same considerations apply here. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templi= n, > Fred L > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 > > > > > > Hi Ron, > > > > > > > -----Original Message----- > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.org= ; > > > intarea-chairs@ietf.org > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ip= v6 > > > > > > > > Fred, > > > > > > > > It appears that we disagree and have taken to repeating ourselves. > > > > > > This is not a disagreement; this is a case in which the text is actua= lly > > > broken > > > which you have more or less acknowledged. You can fix the text in que= stion > > > as follows: > > > > > > OLD: > > > **** > > > In its default configuration, the GRE ingress router MUST: > > > > > > o encapsulate the entire IPv6 packet in a single GRE header and I= P > > > delivery header > > > > > > o fragment the delivery header, so that it can be reassembled by = the > > > GRE egress > > > > > > However, in an alternative configuration, the GRE ingress MAY: > > > > > > o discard the IPv6 packet > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IP= v6 > > > packet source. The MTU field in the ICMPv6 PTB message is set = to > > > the GMTU. > > > > > > NEW: > > > **** > > > The GRE ingress router MUST: > > > > > > o if the IPv6 payload packet includes a fragment header, fragment= the > > > payload packet into fragments no larger than the GMTU and > encapsulate > > > each fragment in a single GRE header and IP delivery header. > Otherwise: > > > > > > o encapsulate the entire IPv6 packet in a single GRE header and= IP > > > delivery header > > > > > > o fragment the delivery packet, so that it can be reassembled b= y the > > > GRE egress > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the = IPv6 > > > packet source, subject to rate limiting. The MTU field in t= he > ICMPv6 > > > PTB > > > message is set to the GMTU. > > > > > > > So, why don't we solicit opinions from the rest of the WG and defer= to > their > > > will. > > > > > > We can't do that for broken text. Ram-rodding broken text through the > > > process based on popular opinion does not make it good. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.o= rg; > > > intarea- > > > > > chairs@ietf.org > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-= ipv6 > > > > > > > > > > Hi Ron, > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes and= so > the > > > > > design must account for tunnel paths that include links with such= a > small > > > > > MTU. The design must also account for nested tunnels-within-tunne= ls, > > > > > where the MTU seen by the first tunnel ingress may be reduced by > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > But again, the point is that the tunnel ingress cannot legitimate= ly > send > > > PTBs > > > > > that report a size smaller than 1280 *and* perpetually drop packe= ts > > > smaller > > > > > than 1280 which is exactly the behavior your text is permitting. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf= .org; > > > > > > intarea-chairs@ietf.org > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gr= e- > ipv6 > > > > > > > > > > > > Fred, > > > > > > > > > > > > In the last network that I operated, all interior links had MTU > > > > > > greater than 9k. If I configured a GRE tunnel between two point= s in > that > > > > > network and detected a GMTU less than 1280, it would have indicat= ed > one of > > > > > the following: > > > > > > > > > > > > - Phenomenal brokenness > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > In such cases, operators need some flexibility in how their net= works > > > > > > would behave. Why deny them this flexibility by taking away the > > > > > configuration option? > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packet that m= ight > > > degrade > > > > > network performance? > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > ipv6@tools.ietf.org; > > > > > > > intarea- chairs@ietf.org > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > intarea-chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in which all > links > > > > > > > > have MTU greater than or equal to 1500. In those networks, = the > > > > > > > > very detection of a GMTU smaller than 1280 indicates broken= ness. > > > > > > > > Those > > > > > > > operators, the alternative behavior may be preferable to the > default. > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the link= must > > > > > > > deliver no matter what. A GMTU smaller than 1280 does not ind= icate > > > > > > > brokennesss; it can naturally happen if 1) there is a link wi= th a > > > > > > > small MTU in the path, or > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 is a no= -no, > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, the GRE > ingress > > > MAY: > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] > message > > > > > > > > > > > to the > > > > > > > IPv6 > > > > > > > > > > > packet source. The MTU field in the ICMPv6 PTB > message > > > is set > > > > > to > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when the G= RE > > > > > > > > > > > ingress sends a PTB reporting a size less than 1280. > > > > > > > > > > > According to RFC2460, Section 5, the standard behavio= r for > a > > > > > > > > > > > host that receives > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > is not required to reduce the size of subsequent pa= ckets > to > > > less > > > > > than > > > > > > > > > > > 1280, but must include a Fragment header in those > packets? > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a perp= etual > > > > > > > > > > > black hole if the GMTU is smaller than 1280 which is > > > > > > > > > > > probably not what we > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > All true. This is why the WG decided to make this the > > > > > > > > > > alternative behavior > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless of whe= ther > it > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide > guidance > > > > > > > > > > > to hosts on how to react to PTB messages that report = a > small > > > size. > > > > > > > > > > > But, as of right now, > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in Section= 5 or > > > > > > > > > > RFC > > > > > > > > > > 246 are > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision regarding= the > > > > > > > > > > current > > > > > > > draft. > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether alternat= ive > or > > > > > default. > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 08:47:59 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD451ACDF0; Wed, 1 Apr 2015 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BArg6lFPaWCf; Wed, 1 Apr 2015 08:47:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5C91ACDFA; Wed, 1 Apr 2015 08:47:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQY42582; Wed, 01 Apr 2015 15:47:52 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Apr 2015 16:47:51 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 1 Apr 2015 08:47:46 -0700 From: Lucy yong To: "Black, David" , Ronald Bonica , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes Thread-Index: AdBsC0O9ImygMEJJSjuvdoFVvO3XwAACaYSQAABqGzAAHuWoQA== Date: Wed, 1 Apr 2015 15:47:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57155BE6@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.159] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57155BE6dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:47:58 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57155BE6dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGggcHJvcG9zZWQgd29yayBhcm91bmQgdG8gU2VjdGlvbiAyLjIgYnV0IHRo YXQgZG9lcyBub3QgcmVzb2x2ZSB0aGUgdGV4dCBpbiBTZWN0aW9uIDQuMS4gSWYgdGhpcyBkb2N1 bWVudCBpcyBqdXN0IHRvIGRvY3VtZW50IGV4aXN0aW5nIGltcGxlbWVudGF0aW9uLCBpdCBuZWVk cyBwb2ludCBvdXQgdGhlIHVzYWdlIGNvbnN0cmFpbnRzIHdoZW4gSVB2NiBpcyBhcyBkZWxpdmVy eSBuZXR3b3JrLiBJIHByb3Bvc2VkIHRoZSBkcmFmdCB0ZXh0LCBUb20gaGFkIHRoZSByZXZpc2Vk IHRleHQuIERvIHlvdSBhZ3JlZSB0aGF0IHN1Y2ggdGV4dCBpcyBuZWNlc3Nhcnk/DQoNCkx1Y3kN Cg0KRnJvbTogSW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQmxhY2ssIERhdmlkDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAxNSA3OjU5 IFBNDQpUbzogUm9uYWxkIEJvbmljYTsgaW50LWFyZWFAaWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmcN CkNjOiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc7IGludGFyZWEt Y2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBXR0xDIGZvciBkcmFmdC1p ZXRmLWludGFyZWEtZ3JlLWlwdjYgLSBFdGhlcnR5cGVzDQoNClRoYXQgc2VlbXMgcmVhc29uYWJs ZSAtIHRoZSBwcm92ZXJiaWFsIOKAnHJpZ2h0IHRoaW5nIHRvIGRv4oCdIHdvdWxkIGJlIHRvIHVw ZGF0ZSAyNzg0IHRvIGFwcGx5IHRoaXMgcmVjb21tZW5kYXRpb24gYWNyb3NzIHRoZSBib2FyZCwg YnV0IEnigJltIG9rIHdpdGggc2ltcGx5IHJlbW92aW5nIHRoZSBTZWN0aW9uIDIuMiB0ZXh0IGFu ZCBsZWF2aW5nIHRoaW5ncyBhcyB0aGV5IGFyZSBpbiAyNzg0Lg0KDQpUaGFua3MsDQotLURhdmlk DQoNCkZyb206IFJvbmFsZCBCb25pY2EgW21haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0XQ0KU2Vu dDogVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgODo1MyBQTQ0KVG86IEJsYWNrLCBEYXZpZDsgWnVu aWdhLCBKdWFuIENhcmxvczsgaW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGlldGYu b3JnPjsgaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRm LWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaW50YXJl YS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZz47IGludGFyZWEtY2hhaXJzQGlldGYub3JnPG1haWx0 bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBXR0xDIGZvciBkcmFmdC1p ZXRmLWludGFyZWEtZ3JlLWlwdjYgLSBFdGhlcnR5cGVzDQoNCkRhdmlkLA0KDQpPbmUgd2F5IHRv IGFkZHJlc3MgdGhpcyBwcm9ibGVtIHdvdWxkIGJlIHRvIHJlbW92ZSBTZWN0aW9uIDIuMiBlbnRp cmVseS4gU2luY2UgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIHRoZSBQcm90b2NvbCBUeXBl IGZpZWxkIGlzIHVuY2hhbmdlZCBmcm9tIFJGQyAyNzg0LCB0aGUgb21pc3Npb24gb2YgU2VjdGlv biAyLjIgZG9lc27igJl0IGNoYW5nZSB0aGUgbWVhbmluZyBvZiB0aGUgZHJhZnQgYXQgYWxsLg0K DQpXb3VsZCB0aGF0IHNvbHV0aW9uIHdvcmsgZm9yIHlvdT8NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoN Cg0KRnJvbTogQmxhY2ssIERhdmlkIFttYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDMxLCAyMDE1IDc6MzUgUE0NClRvOiBadW5pZ2EsIEp1YW4gQ2FybG9z OyBpbnQtYXJlYUBpZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+OyBpcHY2QGlldGYu b3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2 NkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xz LmlldGYub3JnPjsgaW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmludGFyZWEtY2hhaXJz QGlldGYub3JnPjsgQmxhY2ssIERhdmlkDQpTdWJqZWN0OiBXR0xDIGZvciBkcmFmdC1pZXRmLWlu dGFyZWEtZ3JlLWlwdjYgLSBFdGhlcnR5cGVzDQoNClNlY3Rpb24gMi4yIHNheXM6DQoNCiAgIFRo ZSBQcm90b2NvbCBUeXBlIGZpZWxkIGNvbnRhaW5zIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBw YXlsb2FkDQogICBwYWNrZXQuICBQcm90b2NvbCBUeXBlcyBhcmUgZGVmaW5lZCBpbiBbRVRZUEVT XS4gIEFuIGltcGxlbWVudGF0aW9uDQogICByZWNlaXZpbmcgYSBwYWNrZXQgY29udGFpbmluZyBh IFByb3RvY29sIFR5cGUgd2hpY2ggaXMgbm90IGxpc3RlZCBpbg0KICAgW0VUWVBFU10gU0hPVUxE IGRpc2NhcmQgdGhlIHBhY2tldC4NCg0KVGhhdCBsYXR0ZXIgc2VudGVuY2UgaXMgYWxtb3N0IHBv aW50bGVzcywgYW5kIG1vcmVvdmVyLCBpdOKAmXMgYW4NCnVuaW1wbGVtZW50YWJsZSBtb3Zpbmcg dGFyZ2V0Lg0KDQpDb3VsZCB3ZSBzYXkgdGhhdCBhbnkgR1JFIGltcGxlbWVudGF0aW9uIFNIT1VM RCBiZSBjb25maWd1cmVkIHdpdGgNCnRoZSBQcm90b2NvbCBUeXBlcyB0aGF0IGFyZSBleHBlY3Rl ZCBhbmQgU0hPVUxEIGRpc2NhcmQgYW55IHBhY2tldA0KdGhhdCBhcnJpdmVzIHdpdGggYW4gdW5l eHBlY3RlZCBwcm90b2NvbCB0eXBlPw0KDQpJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIG51bWJlciBv ZiBleHBlY3RlZCBwcm90b2NvbCB0eXBlcyBpcyB0eXBpY2FsbHkNCmEgc21hbGwgbnVtYmVyLCBh bmQgdGhhdCBjaGVjayBwcm90ZWN0cyBhZ2FpbnN0IG1pc2ludGVycHJldGluZyBhIGhlYWRlcg0K Zm9yIGVuY2Fwc3VsYXRlZCBwcm90b2NvbCBBIGFzIGEgaGVhZGVyIGZvciBlbmNhcHN1bGF0ZWQg cHJvdG9jb2wgQiwNCndoaWNoIHVzdWFsbHkgd29u4oCZdCBhY2NvbXBsaXNoIG11Y2gsIGJ1dCBj b3VsZCBvY2Nhc2lvbmFsbHkgY2F1c2UNCnJhdGhlciB1bmRlc2lyYWJsZSByZXN1bHRzLg0KSSBy ZWFsaXplIHRoYXQgdGhpcyB0ZXh0IHdhcyBjb3BpZWQgZnJvbSBSRkMgMjc4NCwgYW5kIHRoYXQg Y291bGQgYmUNCmEgcmVhc29uIHRvIG5vdCBtYWtlIHRoaXMgY2hhbmdlLg0KDQpUaGFua3MsDQot LURhdmlkDQoNCkZyb206IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFp1bmlnYSwgSnVhbiBDYXJsb3MNClNlbnQ6IE1vbmRheSwgTWFyY2gg MzAsIDIwMTUgNDoyNyBQTQ0KVG86IGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJlYUBp ZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpDYzogZHJhZnQt aWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlu dGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc+OyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzxt YWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSW50LWFyZWFdIFN0YXJ0 IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ng0KDQoNCkRlYXIgSW50LUFy ZWEgYW5kIDZtYW4gV0dzLA0KDQoNCg0KQXQgdGhlIEludC1BcmVhIFdHIG1lZXRpbmcgaW4gRGFs bGFzIHRoZXJlIHdlcmUgc29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlw djYuIEl0IHdhcyBkZWNpZGVkIHRvIHN1Ym1pdCB0aGUgZG9jdW1lbnQgZm9yIFdHIExhc3QgQ2Fs bCB0byB0aGUgSW50LUFyZWEgJiA2bWFuIFdHcyBhcyBzb29uIGFzIHRoZSBhZ3JlZWQgY2hhbmdl cyB3ZXJlIG1hZGUuDQoNCg0KDQpUaGUgZG9jdW1lbnQgaGFzIG5vdyBiZWVuIHVwZGF0ZWQgYWNj b3JkaW5nbHksIHNvIHRoaXMgZW1haWwgc3RhcnRzIGFuIEludC1BcmVhLzZtYW4gV0dzIExhc3Qg Q2FsbCBvbjoNCg0KDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaW50 YXJlYS1ncmUtaXB2Ni0wNA0KDQoNCg0KUGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB0byBz dXBwb3J0IHRoZSBkb2N1bWVudCBhbmQvb3Igc2VuZCBjb21tZW50cyBieSAyMDE1LTA0LTA2Lg0K DQoNCg0KSW4gYWRkaXRpb24sIHRvIHNhdGlzZnkgUkZDIDY3MDIgIlByb21vdGluZyBDb21wbGlh bmNlIHdpdGggSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyAoSVBSKSI6DQoNCkFyZSB5b3Ug cGVyc29uYWxseSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLWlu dGFyZWEtZ3JlLWlwdjY/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPw0KDQooU2VlIFJGQ3MgMzk3OSwgNDg3OSwg MzY2OSwgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscy4pDQoNCg0KDQpCZXN0LA0KDQoNCg0KSnVh biBDYXJsb3MgWnVuaWdhDQooYXMgSW50LUFyZWEgV0cgY28tY2hhaXIpDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D57155BE6dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRp di5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnAuaW1wcmludHVuaXF1ZWlkLCBsaS5pbXByaW50dW5pcXVl aWQsIGRpdi5pbXByaW50dW5pcXVlaWQNCgl7bXNvLXN0eWxlLW5hbWU6aW1wcmludHVuaXF1ZWlk Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYW0gZmluZSB3aXRoIHByb3Bvc2VkIHdvcmsgYXJvdW5kIHRv IFNlY3Rpb24gMi4yIGJ1dCB0aGF0IGRvZXMgbm90IHJlc29sdmUgdGhlIHRleHQgaW4gU2VjdGlv biA0LjEuIElmIHRoaXMgZG9jdW1lbnQgaXMganVzdCB0byBkb2N1bWVudCBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbiwgaXQgbmVlZHMgcG9pbnQgb3V0IHRoZSB1c2FnZSBjb25zdHJhaW50cyB3aGVu DQogSVB2NiBpcyBhcyBkZWxpdmVyeSBuZXR3b3JrLiBJIHByb3Bvc2VkIHRoZSBkcmFmdCB0ZXh0 LCBUb20gaGFkIHRoZSByZXZpc2VkIHRleHQuIERvIHlvdSBhZ3JlZSB0aGF0IHN1Y2ggdGV4dCBp cyBuZWNlc3Nhcnk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MdWN5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gSW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5CbGFjaywgRGF2aWQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2gg MzEsIDIwMTUgNzo1OSBQTTxicj4NCjxiPlRvOjwvYj4gUm9uYWxkIEJvbmljYTsgaW50LWFyZWFA aWV0Zi5vcmc7IGlwdjZAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtaW50YXJl YS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzsgaW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtJbnQtYXJlYV0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVh LWdyZS1pcHY2IC0gRXRoZXJ0eXBlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0IHNlZW1zIHJlYXNvbmFibGUg LSB0aGUgcHJvdmVyYmlhbCDigJxyaWdodCB0aGluZyB0byBkb+KAnSB3b3VsZCBiZSB0byB1cGRh dGUgMjc4NCB0byBhcHBseSB0aGlzIHJlY29tbWVuZGF0aW9uIGFjcm9zcyB0aGUgYm9hcmQsIGJ1 dCBJ4oCZbSBvayB3aXRoIHNpbXBseSByZW1vdmluZyB0aGUgU2VjdGlvbg0KIDIuMiB0ZXh0IGFu ZCBsZWF2aW5nIHRoaW5ncyBhcyB0aGV5IGFyZSBpbiAyNzg0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPGJyPg0KLS1EYXZpZDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uYWxkIEJvbmljYSBbPGEgaHJl Zj0ibWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQiPm1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0 PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAxNSA4OjUzIFBN PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ7IFp1bmlnYSwgSnVhbiBDYXJsb3M7IDxhIGhy ZWY9Im1haWx0bzppbnQtYXJlYUBpZXRmLm9yZyI+DQppbnQtYXJlYUBpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5p ZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnPC9hPjsN CjxhIGhyZWY9Im1haWx0bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZyI+aW50YXJlYS1jaGFpcnNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBXR0xDIGZvciBkcmFmdC1pZXRm LWludGFyZWEtZ3JlLWlwdjYgLSBFdGhlcnR5cGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhdmlkLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T25lIHdheSB0byBhZGRyZXNzIHRo aXMgcHJvYmxlbSB3b3VsZCBiZSB0byByZW1vdmUgU2VjdGlvbiAyLjIgZW50aXJlbHkuIFNpbmNl IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiB0aGUgUHJvdG9jb2wgVHlwZSBmaWVsZCBpcyB1 bmNoYW5nZWQgZnJvbSBSRkMgMjc4NCwgdGhlIG9taXNzaW9uIG9mIFNlY3Rpb24gMi4yIGRvZXNu 4oCZdCBjaGFuZ2UgdGhlIG1lYW5pbmcNCiBvZiB0aGUgZHJhZnQgYXQgYWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V291bGQgdGhhdCBzb2x1dGlvbiB3b3JrIGZvciB5 b3U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBCbGFjaywgRGF2aWQg WzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIj5tYWlsdG86ZGF2aWQuYmxhY2tA ZW1jLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUg NzozNSBQTTxicj4NCjxiPlRvOjwvYj4gWnVuaWdhLCBKdWFuIENhcmxvczsgPGEgaHJlZj0ibWFp bHRvOmludC1hcmVhQGlldGYub3JnIj5pbnQtYXJlYUBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJt YWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmci PmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVm PSJtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmciPmludGFyZWEtY2hhaXJzQGlldGYub3Jn PC9hPjsgQmxhY2ssIERhdmlkPGJyPg0KPGI+U3ViamVjdDo8L2I+IFdHTEMgZm9yIGRyYWZ0LWll dGYtaW50YXJlYS1ncmUtaXB2NiAtIEV0aGVydHlwZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TZWN0aW9uIDIuMiBzYXlzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBQcm90b2NvbCBUeXBlIGZp ZWxkIGNvbnRhaW5zIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSBwYXlsb2FkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBwYWNrZXQuJm5ic3A7IFByb3RvY29sIFR5cGVzIGFyZSBkZWZpbmVkIGluIFtF VFlQRVNdLiZuYnNwOyBBbiBpbXBsZW1lbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVj ZWl2aW5nIGEgcGFja2V0IGNvbnRhaW5pbmcgYSBQcm90b2NvbCBUeXBlIHdoaWNoIGlzIG5vdCBs aXN0ZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFtFVFlQRVNdIFNIT1VMRCBkaXNjYXJkIHRo ZSBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0IGxhdHRlciBzZW50ZW5jZSBp cyBhbG1vc3QgcG9pbnRsZXNzLCBhbmQgbW9yZW92ZXIsIGl04oCZcyBhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj51bmlt cGxlbWVudGFibGUgbW92aW5nIHRhcmdldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNvdWxk IHdlIHNheSB0aGF0IGFueSBHUkUgaW1wbGVtZW50YXRpb24gU0hPVUxEIGJlIGNvbmZpZ3VyZWQg d2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj50aGUgUHJvdG9jb2wgVHlwZXMgdGhhdCBhcmUgZXhwZWN0ZWQgYW5kIFNI T1VMRCBkaXNjYXJkIGFueSBwYWNrZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+dGhhdCBhcnJpdmVzIHdpdGggYW4gdW5l eHBlY3RlZCBwcm90b2NvbCB0eXBlPyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J IHdvdWxkIHRoaW5rIHRoYXQgdGhlIG51bWJlciBvZiBleHBlY3RlZCBwcm90b2NvbCB0eXBlcyBp cyB0eXBpY2FsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+YSBzbWFsbCBudW1iZXIsIGFuZCB0aGF0IGNoZWNrIHByb3Rl Y3RzIGFnYWluc3QgbWlzaW50ZXJwcmV0aW5nIGEgaGVhZGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmZvciBlbmNhcHN1 bGF0ZWQgcHJvdG9jb2wgQSBhcyBhIGhlYWRlciBmb3IgZW5jYXBzdWxhdGVkIHByb3RvY29sIEIs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPndoaWNoIHVzdWFsbHkgd29u4oCZdCBhY2NvbXBsaXNoIG11Y2gsIGJ1dCBjb3Vs ZCBvY2Nhc2lvbmFsbHkgY2F1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5yYXRoZXIgdW5kZXNpcmFibGUgcmVzdWx0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SSByZWFsaXplIHRoYXQgdGhp cyB0ZXh0IHdhcyBjb3BpZWQgZnJvbSBSRkMgMjc4NCwgYW5kIHRoYXQgY291bGQgYmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+YSByZWFzb24gdG8gbm90IG1ha2UgdGhpcyBjaGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQotLURhdmlkPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJbnQtYXJlYSBbPGEgaHJlZj0ibWFp bHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppbnQtYXJlYS1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WnVuaWdhLCBKdWFuIENhcmxvczxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDQ6MjcgUE08YnI+DQo8Yj5Ubzo8 L2I+IDxhIGhyZWY9Im1haWx0bzppbnQtYXJlYUBpZXRmLm9yZyI+aW50LWFyZWFAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+DQppcHY2QGlldGYub3JnPC9hPjxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2 NkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYu b3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZyI+aW50YXJl YS1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJbnQtYXJlYV0gU3Rh cnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVhciBJbnQtQXJlYSBhbmQgNm1h biBXR3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkF0IHRoZSBJbnQtQXJlYSBXRyBt ZWV0aW5nIGluIERhbGxhcyB0aGVyZSB3ZXJlIHNvbWUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1p bnRhcmVhLWdyZS1pcHY2LiBJdCB3YXMgZGVjaWRlZCB0byBzdWJtaXQgdGhlIGRvY3VtZW50IGZv ciBXRyBMYXN0IENhbGwgdG8gdGhlIEludC1BcmVhICZhbXA7IDZtYW4gV0dzIGFzIHNvb24gYXMg dGhlIGFncmVlZCBjaGFuZ2VzIHdlcmUgbWFkZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+VGhlIGRvY3VtZW50IGhhcyBub3cgYmVlbiB1cGRhdGVkIGFjY29yZGluZ2x5LCBzbyB0aGlz IGVtYWlsIHN0YXJ0cyBhbiBJbnQtQXJlYS82bWFuIFdHcyBMYXN0IENhbGwgb246PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni0wNCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2LTA0PC9hPg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgdG8gc3VwcG9ydCB0aGUg ZG9jdW1lbnQgYW5kL29yIHNlbmQgY29tbWVudHMgYnkgMjAxNS0wNC0wNi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SW4gYWRkaXRpb24sIHRvIHNhdGlzZnkgUkZDIDY3MDIgJnF1b3Q7 UHJvbW90aW5nIENvbXBsaWFuY2Ugd2l0aCBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIChJ UFIpJnF1b3Q7OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXJlIHlv dSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYt aW50YXJlYS1ncmUtaXB2Nj8mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4oU2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSwgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cy4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJlc3QsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkp1YW4gQ2FybG9zIFp1bmlnYSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPihhcyBJbnQtQXJlYSBXRyBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D57155BE6dfweml701chm_-- From nobody Wed Apr 1 09:12:08 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB031AD065; Wed, 1 Apr 2015 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l75FTxEEKMC8; Wed, 1 Apr 2015 09:11:54 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E26E1ACED0; Wed, 1 Apr 2015 09:11:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t31GBpUq032131; Wed, 1 Apr 2015 09:11:51 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t31GBgR5031622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 1 Apr 2015 09:11:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-410.sw.nos.boeing.com ([169.254.10.42]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 09:11:42 -0700 From: "Templin, Fred L" To: "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0A== Date: Wed, 1 Apr 2015 16:11:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:11:58 -0000 Hi David, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 01, 2015 8:43 AM > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org; = Black, David > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Fred, >=20 > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > that something is wrong, as explained in Section 7 of RFC2473. The > > same considerations apply here. >=20 > I agree with the text quoted above, OK, then this document should cite Section 7 of RFC2473 normatively. > but what I'm observing is that there > are networks for which GMTU is an indication that something is wrong > (this is a consequence of operator decisions that are specific to such > a network). The alternative configuration is intended for such networks, > but is not intended for all networks, and would need to be qualified > with words making it applicable primarily or only (or suggest some > other words) to such networks. If there is operational assurance that all links in the tunnel path configu= re a sufficiently large MTU, and there will never be a nesting of tunnels that would result in a too-small MTU, then tunnel fragmentation would not need to be invoked and there is no need to talk about sending PTBs with GMTU less than 1280. Or, if you did want to include text that would tell what to do in the case of misconfigurations, then this document would need to update RFC2473 since the same considerations apply to generic encapsulation over IPv6 and not just GRE encapsulation over IPv6. Thanks - Fred fred.l.templin@boeing.com > Upshot: the use of "necessarily" in the text quoted above is correct, but > misses the point. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, April 01, 2015 10:13 AM > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > Hi David, > > > > > -----Original Message----- > > > From: Black, David [mailto:david.black@emc.com] > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg; > > Black, David > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion > > > > > > So, I talked to Ron off-list and it looks like something is missing f= rom > > > this discussion. > > > > > > The "alternative configuration" is not motivated by a desire to allow > > > implementation flexibility or bless broken implementations. It's mot= ivated > > > by consideration of networks with operational practices wherein a GMT= U of > > > less than 1280 octets is evidence that something is seriously wrong. = That > > > something might be misconfiguration (quoting RFC 5706, "Anything that > > > can be configured can be misconfigured."), or an attack on the GRE > > > ingress's PMTU estimation. > > > > > > So, in the situation of interest (GMTU < 1280) something is wrong, an= d > > > the operator may be faced with a Hobson's choice: either blackhole th= e > > > traffic that can no longer be sent without fragmentation, or fragment= a > > > lot of traffic, causing problems at the GRE egress by overwhelming it= s > > > reassembly code - there may be good operational and/or security reaso= ns > > > to not want to do the latter. All of this ought to be explained in t= he > > > draft. > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > that something is wrong, as explained in Section 7 of RFC2473. The > > same considerations apply here. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Temp= lin, > > Fred L > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ip= v6 > > > > > > > > Hi Ron, > > > > > > > > > -----Original Message----- > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf.o= rg; > > > > intarea-chairs@ietf.org > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-= ipv6 > > > > > > > > > > Fred, > > > > > > > > > > It appears that we disagree and have taken to repeating ourselves= . > > > > > > > > This is not a disagreement; this is a case in which the text is act= ually > > > > broken > > > > which you have more or less acknowledged. You can fix the text in q= uestion > > > > as follows: > > > > > > > > OLD: > > > > **** > > > > In its default configuration, the GRE ingress router MUST: > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header and= IP > > > > delivery header > > > > > > > > o fragment the delivery header, so that it can be reassembled b= y the > > > > GRE egress > > > > > > > > However, in an alternative configuration, the GRE ingress MAY: > > > > > > > > o discard the IPv6 packet > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the = IPv6 > > > > packet source. The MTU field in the ICMPv6 PTB message is se= t to > > > > the GMTU. > > > > > > > > NEW: > > > > **** > > > > The GRE ingress router MUST: > > > > > > > > o if the IPv6 payload packet includes a fragment header, fragme= nt the > > > > payload packet into fragments no larger than the GMTU and > > encapsulate > > > > each fragment in a single GRE header and IP delivery header. > > Otherwise: > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header a= nd IP > > > > delivery header > > > > > > > > o fragment the delivery packet, so that it can be reassembled= by the > > > > GRE egress > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to th= e IPv6 > > > > packet source, subject to rate limiting. The MTU field in= the > > ICMPv6 > > > > PTB > > > > message is set to the GMTU. > > > > > > > > > So, why don't we solicit opinions from the rest of the WG and def= er to > > their > > > > will. > > > > > > > > We can't do that for broken text. Ram-rodding broken text through t= he > > > > process based on popular opinion does not make it good. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf= .org; > > > > intarea- > > > > > > chairs@ietf.org > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gr= e-ipv6 > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes a= nd so > > the > > > > > > design must account for tunnel paths that include links with su= ch a > > small > > > > > > MTU. The design must also account for nested tunnels-within-tun= nels, > > > > > > where the MTU seen by the first tunnel ingress may be reduced b= y > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot legitima= tely > > send > > > > PTBs > > > > > > that report a size smaller than 1280 *and* perpetually drop pac= kets > > > > smaller > > > > > > than 1280 which is exactly the behavior your text is permitting= . > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ie= tf.org; > > > > > > > intarea-chairs@ietf.org > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-= gre- > > ipv6 > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > In the last network that I operated, all interior links had M= TU > > > > > > > greater than 9k. If I configured a GRE tunnel between two poi= nts in > > that > > > > > > network and detected a GMTU less than 1280, it would have indic= ated > > one of > > > > > > the following: > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > In such cases, operators need some flexibility in how their n= etworks > > > > > > > would behave. Why deny them this flexibility by taking away t= he > > > > > > configuration option? > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packet that= might > > > > degrade > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > ipv6@tools.ietf.org; > > > > > > > > intarea- chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in which a= ll > > links > > > > > > > > > have MTU greater than or equal to 1500. In those networks= , the > > > > > > > > > very detection of a GMTU smaller than 1280 indicates brok= enness. > > > > > > > > > Those > > > > > > > > operators, the alternative behavior may be preferable to th= e > > default. > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the li= nk must > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does not i= ndicate > > > > > > > > brokennesss; it can naturally happen if 1) there is a link = with a > > > > > > > > small MTU in the path, or > > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 is a = no-no, > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com= ] > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, the G= RE > > ingress > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] > > message > > > > > > > > > > > > to the > > > > > > > > IPv6 > > > > > > > > > > > > packet source. The MTU field in the ICMPv6 P= TB > > message > > > > is set > > > > > > to > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when the= GRE > > > > > > > > > > > > ingress sends a PTB reporting a size less than 1280= . > > > > > > > > > > > > According to RFC2460, Section 5, the standard behav= ior for > > a > > > > > > > > > > > > host that receives > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > is not required to reduce the size of subsequent = packets > > to > > > > less > > > > > > than > > > > > > > > > > > > 1280, but must include a Fragment header in thos= e > > packets? > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a pe= rpetual > > > > > > > > > > > > black hole if the GMTU is smaller than 1280 which i= s > > > > > > > > > > > > probably not what we > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > All true. This is why the WG decided to make this the > > > > > > > > > > > alternative behavior > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless of w= hether > > it > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provide > > guidance > > > > > > > > > > > > to hosts on how to react to PTB messages that repor= t a > > small > > > > size. > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in Secti= on 5 or > > > > > > > > > > > RFC > > > > > > > > > > > 246 are > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision regardi= ng the > > > > > > > > > > > current > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether altern= ative > > or > > > > > > default. > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Int-area mailing list > > > > Int-area@ietf.org > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 10:35:20 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9BD1A1A43; Wed, 1 Apr 2015 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-nD6a7ol87T; Wed, 1 Apr 2015 10:35:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349711A19F0; Wed, 1 Apr 2015 10:35:17 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t31HYjIX026043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 10:34:45 -0700 (PDT) Message-ID: <551C2C35.1070502@isi.edu> Date: Wed, 01 Apr 2015 10:34:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , "Black, David" , "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:35:19 -0000 On 3/31/2015 5:53 PM, Ronald Bonica wrote: > David, > > > > One way to address this problem would be to remove Section 2.2 entirely. > Since the syntax and semantics of the Protocol Type field is unchanged > from RFC 2784, the omission of Section 2.2 doesnt change the meaning of > the draft at all. Yes, but it might still be useful to point out that IPv6 (unfortunately, and undermining the whole point of the IP version number) uses a different ethertype than IPv4. (this is what happens when we let temporary hardware optimizations influence long-term protocol design) Joe From nobody Wed Apr 1 10:39:18 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6651A01C6; Wed, 1 Apr 2015 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41MjXRt9LVw8; Wed, 1 Apr 2015 10:39:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD601A01AE; Wed, 1 Apr 2015 10:39:15 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t31HcLkQ026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 10:38:21 -0700 (PDT) Message-ID: <551C2D0E.5040303@isi.edu> Date: Wed, 01 Apr 2015 10:38:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stbryant@cisco.com, "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <551BA8F8.1080706@cisco.com> In-Reply-To: <551BA8F8.1080706@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:39:16 -0000 On 4/1/2015 1:14 AM, Stewart Bryant wrote: > Because the IPv6 delivery header does not include a checksum of its > own, it is subject to corruption. > > SB> It is subject to corruption whether or not it has a checksum. > SB> The point is that there may be undetected corruption. However > SB> detection in only probabilistic even with a checksum. So > SB> I think that that this text should be: > > Because the IPv6 delivery header does not include a checksum of its > own, it is subject to higher probability of undetected corruption. The probability of undetected corruption is 100%. And a checksum isn't the only way to detect errors. IMO: Because the IPv6 delivery header does not include error detection, it is subject to undetected corruption. Joe From nobody Wed Apr 1 10:41:40 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8691A0419; Wed, 1 Apr 2015 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvygiEDN7GnI; Wed, 1 Apr 2015 10:41:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049A11A00B2; Wed, 1 Apr 2015 10:41:35 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t31Hf9Vd027093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 10:41:10 -0700 (PDT) Message-ID: <551C2DB6.1040906@isi.edu> Date: Wed, 01 Apr 2015 10:41:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , Ronald Bonica , "int-area@ietf.org" , "ipv6@ietf.org" References: <2134F8430051B64F815C691A62D9831832E2EA83@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E2EA83@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:41:37 -0000 +1 On 3/31/2015 10:29 AM, Templin, Fred L wrote: > Broken behavior should not be specified, whether alternative or default. From nobody Wed Apr 1 11:05:19 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79FC1A1AAE; Wed, 1 Apr 2015 11:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHnBUw6ksjWy; Wed, 1 Apr 2015 11:05:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190E61A6F0A; Wed, 1 Apr 2015 11:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3340; q=dns/txt; s=iport; t=1427911503; x=1429121103; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=rW7L0P8r1QzyhhS909yiXbTYllc0FWft/5+t/VSEJdo=; b=QFE/ahzYQuy6jAEB8jObow57fMicJgnRGb2Z7gIJGM0D+EOnvKD4i725 +xaqPXyfk+0i+9EXtFYZnB94Qc/sJK52m3nsTyP/QyQ5gOskvh9qUp+py LQWVJbO90rY82vZWo7ZXJ1TmnTdkFXyrfn3o49e/x7eM8hPvvskZ+fX8p k=; X-IronPort-AV: E=Sophos;i="5.11,505,1422921600"; d="scan'208,217";a="407751813" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 01 Apr 2015 18:05:01 +0000 Received: from [10.55.98.183] (ams-stbryant-8816.cisco.com [10.55.98.183]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t31I512q006431; Wed, 1 Apr 2015 18:05:01 GMT Message-ID: <551C334C.6000503@cisco.com> Date: Wed, 01 Apr 2015 19:05:00 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Joe Touch , "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <551BA8F8.1080706@cisco.com> <551C2D0E.5040303@isi.edu> In-Reply-To: <551C2D0E.5040303@isi.edu> Content-Type: multipart/alternative; boundary="------------050003000909060305060003" Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:05:16 -0000 This is a multi-part message in MIME format. --------------050003000909060305060003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 01/04/2015 18:38, Joe Touch wrote: > > On 4/1/2015 1:14 AM, Stewart Bryant wrote: >> Because the IPv6 delivery header does not include a checksum of its >> own, it is subject to corruption. >> >> SB> It is subject to corruption whether or not it has a checksum. >> SB> The point is that there may be undetected corruption. However >> SB> detection in only probabilistic even with a checksum. So >> SB> I think that that this text should be: >> >> Because the IPv6 delivery header does not include a checksum of its >> own, it is subject to higher probability of undetected corruption. > The probability of undetected corruption is 100%. And a checksum isn't > the only way to detect errors. > > IMO: > > Because the IPv6 delivery header does not include error detection, it is > subject to undetected corruption. > > Joe > . > I accept that there are other possible error checking technique, but the original text is talking about checksum. However no check is perfect so I still think it needs to be: Because the IPv6 delivery header does not include error detection, it is subject to a higher probability of undetected corruption. - Stewart --------------050003000909060305060003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 01/04/2015 18:38, Joe Touch wrote:

On 4/1/2015 1:14 AM, Stewart Bryant wrote:
Because the IPv6 delivery header does not include a checksum of its
own, it is subject to corruption. 

SB> It is subject to corruption whether or not it has a checksum.
SB> The point is that there may be undetected corruption. However
SB> detection in only probabilistic even with a checksum. So
SB> I think that that this text should be:

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to higher probability of undetected corruption. 
The probability of undetected corruption is 100%. And a checksum isn't
the only way to detect errors.

IMO:

Because the IPv6 delivery header does not include error detection, it is
subject to undetected corruption.

Joe
.

I accept that there are other possible error checking technique, but
the original text is talking about checksum. However no check is
perfect so I still think it needs to be:

Because the IPv6 delivery header does not include error detection,
it is subject to a higher probability of undetected corruption.

- Stewart


--------------050003000909060305060003-- From nobody Wed Apr 1 11:28:36 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EFA1A8830; Wed, 1 Apr 2015 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdMx2b4Ho63E; Wed, 1 Apr 2015 11:28:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7F51A8AEB; Wed, 1 Apr 2015 11:28:32 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t31ISIa5005281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 11:28:18 -0700 (PDT) Message-ID: <551C38C2.1040006@isi.edu> Date: Wed, 01 Apr 2015 11:28:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: stbryant@cisco.com, "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <551BA8F8.1080706@cisco.com> <551C2D0E.5040303@isi.edu> <551C334C.6000503@cisco.com> In-Reply-To: <551C334C.6000503@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:28:34 -0000 On 4/1/2015 11:05 AM, Stewart Bryant wrote: > On 01/04/2015 18:38, Joe Touch wrote: >> >> On 4/1/2015 1:14 AM, Stewart Bryant wrote: >>> Because the IPv6 delivery header does not include a checksum of its >>> own, it is subject to corruption. >>> >>> SB> It is subject to corruption whether or not it has a checksum. >>> SB> The point is that there may be undetected corruption. However >>> SB> detection in only probabilistic even with a checksum. So >>> SB> I think that that this text should be: >>> >>> Because the IPv6 delivery header does not include a checksum of its >>> own, it is subject to higher probability of undetected corruption. >> The probability of undetected corruption is 100%. And a checksum isn't >> the only way to detect errors. >> >> IMO: >> >> Because the IPv6 delivery header does not include error detection, it is >> subject to undetected corruption. >> >> Joe >> . >> > I accept that there are other possible error checking technique, but > the original text is talking about checksum. However no check is > perfect so I still think it needs to be: > > Because the IPv6 delivery header does not include error detection, > it is subject to a higher probability of undetected corruption. Point taken. Better. Joe From nobody Wed Apr 1 13:27:06 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DECC1AC3BE; Wed, 1 Apr 2015 13:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49wTtxHC3S8O; Wed, 1 Apr 2015 13:27:00 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 4B49F1A9173; Wed, 1 Apr 2015 13:26:20 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31KQE5U015137 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2015 16:26:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t31KQE5U015137 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427919977; bh=QGQcnoV2blk2t3fFYHAfEUwBeQU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IhfmKz2EZDGzaGqexRkeQlqCBDfUtYTvgy3vl6aDiRNUyTJHpkX4J2cCwy1L/91vp Dv547xAM5jvs3zBXx0/K2iqoIDOtluP6vjKImHRfhwYmwPKGjEVhqIS59dCjqEdwfa ISMTNbwb7L8Xs6q3Cs+QzLm+OSHBgnkyvKxpeXjs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t31KQE5U015137 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 1 Apr 2015 16:25:47 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31KQ1CX016694 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 16:26:03 -0400 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 1 Apr 2015 16:26:00 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 16:26:00 -0400 From: "Black, David" To: "Templin, Fred L" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYg Date: Wed, 1 Apr 2015 20:26:00 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 20:27:04 -0000 Fred, > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > same considerations apply here. > > > > I agree with the text quoted above, Adding the rest of the sentence ... > > but what I'm observing is that there > > are networks for which GMTU is an indication that something is wrong > > (this is a consequence of operator decisions that are specific to such > > a network). > OK, then this document should cite Section 7 of RFC2473 normatively. I think it would be better to directly explain the GRE situation here, and add an informative citation of RFC 2473 as providing additional explanation= , particularly for situations in which different operational practices are us= ed. > If there is operational assurance that all links in the tunnel path confi= gure > a sufficiently large MTU, and there will never be a nesting of tunnels th= at > would result in a too-small MTU, then tunnel fragmentation would not > need to be invoked and there is no need to talk about sending PTBs with > GMTU less than 1280. Never say "never" ... quoting RFC 5706, "Anything that can be configured ca= n be misconfigured." ;-). I'll leave the rationale for sending PTBs to Ron, but keep in mind that "running code" (i.e., existing implementations) is(are) an important consideration - see the second sentence in the Introduction. > Or, if you did want to include text that would tell > what to do in the case of misconfigurations, then this document would > need to update RFC2473 since the same considerations apply to generic > encapsulation over IPv6 and not just GRE encapsulation over IPv6. It's more than misconfigurations - attacks on PMTU monitoring can have similar effects. Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not cite RFC 2473); I think a separate draft would be more appropriate. Thanks, --David > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, April 01, 2015 12:12 PM > To: Black, David; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Hi David, >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Wednesday, April 01, 2015 8:43 AM > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org= ; > Black, David > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > Fred, > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > same considerations apply here. > > > > I agree with the text quoted above, >=20 > OK, then this document should cite Section 7 of RFC2473 normatively. >=20 > > but what I'm observing is that there > > are networks for which GMTU is an indication that something is wrong > > (this is a consequence of operator decisions that are specific to such > > a network). The alternative configuration is intended for such network= s, > > but is not intended for all networks, and would need to be qualified > > with words making it applicable primarily or only (or suggest some > > other words) to such networks. >=20 > If there is operational assurance that all links in the tunnel path confi= gure > a sufficiently large MTU, and there will never be a nesting of tunnels th= at > would result in a too-small MTU, then tunnel fragmentation would not > need to be invoked and there is no need to talk about sending PTBs with > GMTU less than 1280. Or, if you did want to include text that would tell > what to do in the case of misconfigurations, then this document would > need to update RFC2473 since the same considerations apply to generic > encapsulation over IPv6 and not just GRE encapsulation over IPv6. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Upshot: the use of "necessarily" in the text quoted above is correct, b= ut > > misses the point. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > Hi David, > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:david.black@emc.com] > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org; > > > Black, David > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > > > > > So, I talked to Ron off-list and it looks like something is missing= from > > > > this discussion. > > > > > > > > The "alternative configuration" is not motivated by a desire to all= ow > > > > implementation flexibility or bless broken implementations. It's > motivated > > > > by consideration of networks with operational practices wherein a G= MTU > of > > > > less than 1280 octets is evidence that something is seriously wrong= . > That > > > > something might be misconfiguration (quoting RFC 5706, "Anything th= at > > > > can be configured can be misconfigured."), or an attack on the GRE > > > > ingress's PMTU estimation. > > > > > > > > So, in the situation of interest (GMTU < 1280) something is wrong, = and > > > > the operator may be faced with a Hobson's choice: either blackhole = the > > > > traffic that can no longer be sent without fragmentation, or fragme= nt a > > > > lot of traffic, causing problems at the GRE egress by overwhelming = its > > > > reassembly code - there may be good operational and/or security rea= sons > > > > to not want to do the latter. All of this ought to be explained in= the > > > > draft. > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indication > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > same considerations apply here. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > Templin, > > > Fred L > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > chairs@ietf.org > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-= ipv6 > > > > > > > > > > Hi Ron, > > > > > > > > > > > -----Original Message----- > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ietf= .org; > > > > > intarea-chairs@ietf.org > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gr= e- > ipv6 > > > > > > > > > > > > Fred, > > > > > > > > > > > > It appears that we disagree and have taken to repeating ourselv= es. > > > > > > > > > > This is not a disagreement; this is a case in which the text is > actually > > > > > broken > > > > > which you have more or less acknowledged. You can fix the text in > question > > > > > as follows: > > > > > > > > > > OLD: > > > > > **** > > > > > In its default configuration, the GRE ingress router MUST: > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header a= nd IP > > > > > delivery header > > > > > > > > > > o fragment the delivery header, so that it can be reassembled= by > the > > > > > GRE egress > > > > > > > > > > However, in an alternative configuration, the GRE ingress MAY: > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to th= e > IPv6 > > > > > packet source. The MTU field in the ICMPv6 PTB message is = set > to > > > > > the GMTU. > > > > > > > > > > NEW: > > > > > **** > > > > > The GRE ingress router MUST: > > > > > > > > > > o if the IPv6 payload packet includes a fragment header, frag= ment > the > > > > > payload packet into fragments no larger than the GMTU and > > > encapsulate > > > > > each fragment in a single GRE header and IP delivery header= . > > > Otherwise: > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header= and > IP > > > > > delivery header > > > > > > > > > > o fragment the delivery packet, so that it can be reassembl= ed by > the > > > > > GRE egress > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to = the > IPv6 > > > > > packet source, subject to rate limiting. The MTU field = in > the > > > ICMPv6 > > > > > PTB > > > > > message is set to the GMTU. > > > > > > > > > > > So, why don't we solicit opinions from the rest of the WG and d= efer > to > > > their > > > > > will. > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text through= the > > > > > process based on popular opinion does not make it good. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > ipv6@tools.ietf.org; > > > > > intarea- > > > > > > > chairs@ietf.org > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-= gre- > ipv6 > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 bytes= and > so > > > the > > > > > > > design must account for tunnel paths that include links with = such > a > > > small > > > > > > > MTU. The design must also account for nested tunnels-within- > tunnels, > > > > > > > where the MTU seen by the first tunnel ingress may be reduced= by > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot > legitimately > > > send > > > > > PTBs > > > > > > > that report a size smaller than 1280 *and* perpetually drop > packets > > > > > smaller > > > > > > > than 1280 which is exactly the behavior your text is permitti= ng. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > ipv6@tools.ietf.org; > > > > > > > > intarea-chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intare= a- > gre- > > > ipv6 > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > In the last network that I operated, all interior links had= MTU > > > > > > > > greater than 9k. If I configured a GRE tunnel between two p= oints > in > > > that > > > > > > > network and detected a GMTU less than 1280, it would have > indicated > > > one of > > > > > > > the following: > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in how their > networks > > > > > > > > would behave. Why deny them this flexibility by taking away= the > > > > > > > configuration option? > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packet th= at > might > > > > > degrade > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > ipv6@tools.ietf.org; > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in which= all > > > links > > > > > > > > > > have MTU greater than or equal to 1500. In those networ= ks, > the > > > > > > > > > > very detection of a GMTU smaller than 1280 indicates > brokenness. > > > > > > > > > > Those > > > > > > > > > operators, the alternative behavior may be preferable to = the > > > default. > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much the = link > must > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does not > indicate > > > > > > > > > brokennesss; it can naturally happen if 1) there is a lin= k > with a > > > > > > > > > small MTU in the path, or > > > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 is = a no- > no, > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.c= om] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, the= GRE > > > ingress > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC444= 3] > > > message > > > > > > > > > > > > > to the > > > > > > > > > IPv6 > > > > > > > > > > > > > packet source. The MTU field in the ICMPv6= PTB > > > message > > > > > is set > > > > > > > to > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when t= he > GRE > > > > > > > > > > > > > ingress sends a PTB reporting a size less than 12= 80. > > > > > > > > > > > > > According to RFC2460, Section 5, the standard beh= avior > for > > > a > > > > > > > > > > > > > host that receives > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > is not required to reduce the size of subsequen= t > packets > > > to > > > > > less > > > > > > > than > > > > > > > > > > > > > 1280, but must include a Fragment header in th= ose > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see a > perpetual > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280 which= is > > > > > > > > > > > > > probably not what we > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > All true. This is why the WG decided to make this t= he > > > > > > > > > > > > alternative behavior > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless of > whether > > > it > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to provid= e > > > guidance > > > > > > > > > > > > > to hosts on how to react to PTB messages that rep= ort a > > > small > > > > > size. > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in Sec= tion > 5 or > > > > > > > > > > > > RFC > > > > > > > > > > > > 246 are > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision regar= ding > the > > > > > > > > > > > > current > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether > alternative > > > or > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Int-area mailing list > > > > > Int-area@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 14:13:09 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D351AC3E6; Wed, 1 Apr 2015 14:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czTOeYitUf7O; Wed, 1 Apr 2015 14:13:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6B41AC3BA; Wed, 1 Apr 2015 14:13:03 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 1 Apr 2015 21:13:01 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Wed, 1 Apr 2015 21:13:01 +0000 From: Ronald Bonica To: Joe Touch , "Black, David" , "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes Thread-Index: AdBsC0O9ImygMEJJSjuvdoFVvO3XwAACaYSQACNOuYAAB4U9QA== Date: Wed, 1 Apr 2015 21:13:01 +0000 Message-ID: References: <551C2C35.1070502@isi.edu> In-Reply-To: <551C2C35.1070502@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: isi.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(479174004)(51704005)(377454003)(13464003)(24454002)(33656002)(77156002)(230783001)(62966003)(87936001)(2656002)(19580395003)(2171001)(76576001)(19580405001)(102836002)(66066001)(92566002)(2501003)(2201001)(99286002)(74316001)(86362001)(50986999)(54356999)(76176999)(2950100001)(46102003)(122556002)(40100003)(2900100001)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 053315510E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2015 21:13:01.0498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:13:08 -0000 Joe, The reminder that you mention is already in Section 3. Text is included at = the bottom of this message. Ron TEXT ------ 3. IPv6 as a GRE Payload When the GRE payload is IPv6, the Protocol Type field in the GRE header MUS= T be set to Ether Type [ETYPES] 0x86DD. > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, April 01, 2015 1:35 PM > To: Ronald Bonica; Black, David; Zuniga, Juan Carlos; int-area@ietf.org; > ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes >=20 >=20 >=20 > On 3/31/2015 5:53 PM, Ronald Bonica wrote: > > David, > > > > > > > > One way to address this problem would be to remove Section 2.2 entirely= . > > Since the syntax and semantics of the Protocol Type field is unchanged > > from RFC 2784, the omission of Section 2.2 doesn't change the meaning > > of the draft at all. >=20 > Yes, but it might still be useful to point out that IPv6 (unfortunately, = and > undermining the whole point of the IP version number) uses a different > ethertype than IPv4. >=20 > (this is what happens when we let temporary hardware optimizations > influence long-term protocol design) >=20 > Joe From nobody Wed Apr 1 14:25:46 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48111A1ACA; Wed, 1 Apr 2015 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzz7BHE7ghk6; Wed, 1 Apr 2015 14:25:42 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1FB1A1A79; Wed, 1 Apr 2015 14:25:42 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t31LNNrM021791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 14:23:23 -0700 (PDT) Message-ID: <551C61CC.1000006@isi.edu> Date: Wed, 01 Apr 2015 14:23:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , "Black, David" , "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <551C2C35.1070502@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:25:44 -0000 Ahh - thanks. I don't think it matters in what section it appears. Joe On 4/1/2015 2:13 PM, Ronald Bonica wrote: > Joe, > > The reminder that you mention is already in Section 3. Text is included at the bottom of this message. > > Ron > > TEXT > ------ > 3. IPv6 as a GRE Payload > > When the GRE payload is IPv6, the Protocol Type field in the GRE header MUST be set to Ether Type [ETYPES] 0x86DD. > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Wednesday, April 01, 2015 1:35 PM >> To: Ronald Bonica; Black, David; Zuniga, Juan Carlos; int-area@ietf.org; >> ipv6@ietf.org >> Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org >> Subject: Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes >> >> >> >> On 3/31/2015 5:53 PM, Ronald Bonica wrote: >>> David, >>> >>> >>> >>> One way to address this problem would be to remove Section 2.2 entirely. >>> Since the syntax and semantics of the Protocol Type field is unchanged >>> from RFC 2784, the omission of Section 2.2 doesn't change the meaning >>> of the draft at all. >> >> Yes, but it might still be useful to point out that IPv6 (unfortunately, and >> undermining the whole point of the IP version number) uses a different >> ethertype than IPv4. >> >> (this is what happens when we let temporary hardware optimizations >> influence long-term protocol design) >> >> Joe From nobody Wed Apr 1 14:33:49 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE51A01E2; Wed, 1 Apr 2015 14:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V32Boq5XUx4F; Wed, 1 Apr 2015 14:33:42 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F2B1A1BD4; Wed, 1 Apr 2015 14:33:42 -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 t31LXfI1005211; Wed, 1 Apr 2015 14:33:41 -0700 Received: from XCH-BLV-408.nw.nos.boeing.com (xch-blv-408.nw.nos.boeing.com [130.247.25.166]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t31LXZNR005166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 1 Apr 2015 14:33:36 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.179]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 14:33:35 -0700 From: "Templin, Fred L" To: "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCA= Date: Wed, 1 Apr 2015 21:33:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:33:48 -0000 Hi David, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 01, 2015 1:26 PM > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org; = Black, David > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Fred, >=20 > > > > No, that's is not right. GMTU < 1280 is not necessarily an indicati= on > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > I agree with the text quoted above, >=20 > Adding the rest of the sentence ... >=20 > > > but what I'm observing is that there > > > are networks for which GMTU is an indication that something is wrong > > > (this is a consequence of operator decisions that are specific to suc= h > > > a network). >=20 > > OK, then this document should cite Section 7 of RFC2473 normatively. >=20 > I think it would be better to directly explain the GRE situation here, an= d > add an informative citation of RFC 2473 as providing additional explanati= on, > particularly for situations in which different operational practices are = used. How is the GRE situation any different than for any generic encapsulation in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific use cases"? Section 7 of RFC2473 already provides guidance that applies also to GRE in any use case.=20 > > If there is operational assurance that all links in the tunnel path con= figure > > a sufficiently large MTU, and there will never be a nesting of tunnels = that > > would result in a too-small MTU, then tunnel fragmentation would not > > need to be invoked and there is no need to talk about sending PTBs with > > GMTU less than 1280. >=20 > Never say "never" ... quoting RFC 5706, "Anything that can be configured = can > be misconfigured." ;-). Right, that's what I said (having used that phrase many times in the past myself). > I'll leave the rationale for sending PTBs to Ron, but keep in mind that > "running code" (i.e., existing implementations) is(are) an important > consideration - see the second sentence in the Introduction. Sending PTB with MTU<1280 is supposed to have an effect as described in Section 5 of RFC. Namely, the original source is supposed to start including IPv6 fragment headers in subsequent packets and the network is supposed to find some way to get them through. What Ron's text is suggesting is that the original source lives up to its part of the barga= in but then the network dumps the packets into a black hole. > > Or, if you did want to include text that would tell > > what to do in the case of misconfigurations, then this document would > > need to update RFC2473 since the same considerations apply to generic > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. >=20 > It's more than misconfigurations - attacks on PMTU monitoring can have > similar effects. If you want to start talking about PTB forgery, then we should also talk about PTB filtering and how the mechanisms work when PTBs are lost. RFC2473 itself is imperfect in that regard, and this draft is not proposing anything different than RFC2473. > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not > cite RFC 2473); I think a separate draft would be more appropriate. OK, then have this draft simply cite RFC2473, Section 7 normatively and break the exception cases out into a separate document like intarea-tunnels. The exception cases are not limited to GRE in particular, and apply also to any generic tunneling in IPv6. Thanks - Fred fred.l.templin@boeing.com > Thanks, > --David >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, April 01, 2015 12:12 PM > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > Hi David, > > > > > -----Original Message----- > > > From: Black, David [mailto:david.black@emc.com] > > > Sent: Wednesday, April 01, 2015 8:43 AM > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg; > > Black, David > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative config= uration > > > > > > Fred, > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indicati= on > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > I agree with the text quoted above, > > > > OK, then this document should cite Section 7 of RFC2473 normatively. > > > > > but what I'm observing is that there > > > are networks for which GMTU is an indication that something is wrong > > > (this is a consequence of operator decisions that are specific to suc= h > > > a network). The alternative configuration is intended for such netwo= rks, > > > but is not intended for all networks, and would need to be qualified > > > with words making it applicable primarily or only (or suggest some > > > other words) to such networks. > > > > If there is operational assurance that all links in the tunnel path con= figure > > a sufficiently large MTU, and there will never be a nesting of tunnels = that > > would result in a too-small MTU, then tunnel fragmentation would not > > need to be invoked and there is no need to talk about sending PTBs with > > GMTU less than 1280. Or, if you did want to include text that would tel= l > > what to do in the case of misconfigurations, then this document would > > need to update RFC2473 since the same considerations apply to generic > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Upshot: the use of "necessarily" in the text quoted above is correct,= but > > > misses the point. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > configuration > > > > > > > > Hi David, > > > > > > > > > -----Original Message----- > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ie= tf.org; > > > > Black, David > > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative config= uration > > > > > > > > > > So, I talked to Ron off-list and it looks like something is missi= ng from > > > > > this discussion. > > > > > > > > > > The "alternative configuration" is not motivated by a desire to a= llow > > > > > implementation flexibility or bless broken implementations. It's > > motivated > > > > > by consideration of networks with operational practices wherein a= GMTU > > of > > > > > less than 1280 octets is evidence that something is seriously wro= ng. > > That > > > > > something might be misconfiguration (quoting RFC 5706, "Anything = that > > > > > can be configured can be misconfigured."), or an attack on the GR= E > > > > > ingress's PMTU estimation. > > > > > > > > > > So, in the situation of interest (GMTU < 1280) something is wrong= , and > > > > > the operator may be faced with a Hobson's choice: either blackhol= e the > > > > > traffic that can no longer be sent without fragmentation, or frag= ment a > > > > > lot of traffic, causing problems at the GRE egress by overwhelmin= g its > > > > > reassembly code - there may be good operational and/or security r= easons > > > > > to not want to do the latter. All of this ought to be explained = in the > > > > > draft. > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indicati= on > > > > that something is wrong, as explained in Section 7 of RFC2473. The > > > > same considerations apply here. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > -----Original Message----- > > > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of > > Templin, > > > > Fred L > > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > chairs@ietf.org > > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gr= e-ipv6 > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre-ipv6@tools.ie= tf.org; > > > > > > intarea-chairs@ietf.org > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-= gre- > > ipv6 > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > It appears that we disagree and have taken to repeating ourse= lves. > > > > > > > > > > > > This is not a disagreement; this is a case in which the text is > > actually > > > > > > broken > > > > > > which you have more or less acknowledged. You can fix the text = in > > question > > > > > > as follows: > > > > > > > > > > > > OLD: > > > > > > **** > > > > > > In its default configuration, the GRE ingress router MUST: > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE header= and IP > > > > > > delivery header > > > > > > > > > > > > o fragment the delivery header, so that it can be reassembl= ed by > > the > > > > > > GRE egress > > > > > > > > > > > > However, in an alternative configuration, the GRE ingress MA= Y: > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to = the > > IPv6 > > > > > > packet source. The MTU field in the ICMPv6 PTB message i= s set > > to > > > > > > the GMTU. > > > > > > > > > > > > NEW: > > > > > > **** > > > > > > The GRE ingress router MUST: > > > > > > > > > > > > o if the IPv6 payload packet includes a fragment header, fr= agment > > the > > > > > > payload packet into fragments no larger than the GMTU an= d > > > > encapsulate > > > > > > each fragment in a single GRE header and IP delivery head= er. > > > > Otherwise: > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE head= er and > > IP > > > > > > delivery header > > > > > > > > > > > > o fragment the delivery packet, so that it can be reassem= bled by > > the > > > > > > GRE egress > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message t= o the > > IPv6 > > > > > > packet source, subject to rate limiting. The MTU fiel= d in > > the > > > > ICMPv6 > > > > > > PTB > > > > > > message is set to the GMTU. > > > > > > > > > > > > > So, why don't we solicit opinions from the rest of the WG and= defer > > to > > > > their > > > > > > will. > > > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text throu= gh the > > > > > > process based on popular opinion does not make it good. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > ipv6@tools.ietf.org; > > > > > > intarea- > > > > > > > > chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intare= a-gre- > > ipv6 > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 byt= es and > > so > > > > the > > > > > > > > design must account for tunnel paths that include links wit= h such > > a > > > > small > > > > > > > > MTU. The design must also account for nested tunnels-within= - > > tunnels, > > > > > > > > where the MTU seen by the first tunnel ingress may be reduc= ed by > > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot > > legitimately > > > > send > > > > > > PTBs > > > > > > > > that report a size smaller than 1280 *and* perpetually drop > > packets > > > > > > smaller > > > > > > > > than 1280 which is exactly the behavior your text is permit= ting. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > ipv6@tools.ietf.org; > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-inta= rea- > > gre- > > > > ipv6 > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > In the last network that I operated, all interior links h= ad MTU > > > > > > > > > greater than 9k. If I configured a GRE tunnel between two= points > > in > > > > that > > > > > > > > network and detected a GMTU less than 1280, it would have > > indicated > > > > one of > > > > > > > > the following: > > > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in how the= ir > > networks > > > > > > > > > would behave. Why deny them this flexibility by taking aw= ay the > > > > > > > > configuration option? > > > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packet = that > > might > > > > > > degrade > > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com= ] > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > ipv6@tools.ietf.org; > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in whi= ch all > > > > links > > > > > > > > > > > have MTU greater than or equal to 1500. In those netw= orks, > > the > > > > > > > > > > > very detection of a GMTU smaller than 1280 indicates > > brokenness. > > > > > > > > > > > Those > > > > > > > > > > operators, the alternative behavior may be preferable t= o the > > > > default. > > > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much th= e link > > must > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does n= ot > > indicate > > > > > > > > > > brokennesss; it can naturally happen if 1) there is a l= ink > > with a > > > > > > > > > > small MTU in the path, or > > > > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280 i= s a no- > > no, > > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing= .com] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration, t= he GRE > > > > ingress > > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4= 443] > > > > message > > > > > > > > > > > > > > to the > > > > > > > > > > IPv6 > > > > > > > > > > > > > > packet source. The MTU field in the ICMP= v6 PTB > > > > message > > > > > > is set > > > > > > > > to > > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances when= the > > GRE > > > > > > > > > > > > > > ingress sends a PTB reporting a size less than = 1280. > > > > > > > > > > > > > > According to RFC2460, Section 5, the standard b= ehavior > > for > > > > a > > > > > > > > > > > > > > host that receives > > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > > is not required to reduce the size of subsequ= ent > > packets > > > > to > > > > > > less > > > > > > > > than > > > > > > > > > > > > > > 1280, but must include a Fragment header in = those > > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will see = a > > perpetual > > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280 whi= ch is > > > > > > > > > > > > > > probably not what we > > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > All true. This is why the WG decided to make this= the > > > > > > > > > > > > > alternative behavior > > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardless = of > > whether > > > > it > > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to prov= ide > > > > guidance > > > > > > > > > > > > > > to hosts on how to react to PTB messages that r= eport a > > > > small > > > > > > size. > > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in S= ection > > 5 or > > > > > > > > > > > > > RFC > > > > > > > > > > > > > 246 are > > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision reg= arding > > the > > > > > > > > > > > > > current > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether > > alternative > > > > or > > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Int-area mailing list > > > > > > Int-area@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 16:08:04 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65991AC82C; Wed, 1 Apr 2015 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVOE6dwkvFKt; Wed, 1 Apr 2015 16:07:57 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 F08C41AC446; Wed, 1 Apr 2015 16:07:56 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31N7pxD024301 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2015 19:07:52 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t31N7pxD024301 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427929673; bh=dSWDbqyX2IKLrpOrJyvmqlz/4Gk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ZwF4/dW5Yzy2rdVC1QMdcEjcSapRtGjrw4jb+vIsYADPpra5ngcQ/Sl3WtBTUHQMK M6I4k24WUSZRFeoVJwVYLeUHM7rhXvw9C3EUiT4KRAqFXLC5yOdnf8qOsgENKe05P0 8R/i/18O2fWSEqYfY/CekxRPvnT71ZDasIeh2LBc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t31N7pxD024301 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 1 Apr 2015 19:07:43 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31N7ivf003683 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 19:07:45 -0400 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 1 Apr 2015 19:07:43 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 19:07:44 -0400 From: "Black, David" To: "Templin, Fred L" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCAAAhGi8A== Date: Wed, 1 Apr 2015 23:07:43 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:08:03 -0000 > > I think it would be better to directly explain the GRE situation here, = and > > add an informative citation of RFC 2473 as providing additional explana= tion, > > particularly for situations in which different operational practices ar= e > > used. > > How is the GRE situation any different than for any generic encapsulation > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific use > cases"? Yes, specifically networks where a GMTU < 1280 always indicates a problem. > Section 7 of RFC2473 already provides guidance that applies also > to GRE in any use case. Ok, as previously noted - the text here is specific to GRE and certain networks. > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not > > cite RFC 2473); I think a separate draft would be more appropriate. > > OK, then have this draft simply cite RFC2473, Section 7 normatively > and break the exception cases out into a separate document like > intarea-tunnels. The exception cases are not limited to GRE in > particular, and apply also to any generic tunneling in IPv6. Right now, the exception case is proposed as GRE-only, and hence is appropriate for this draft. I hesitate to generalize it to all IPv6 tunnels or have the GRE provisions await that being done. Thanks, --David > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, April 01, 2015 5:34 PM > To: Black, David; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Hi David, >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Wednesday, April 01, 2015 1:26 PM > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org= ; > Black, David > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > Fred, > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indica= tion > > > > > that something is wrong, as explained in Section 7 of RFC2473. Th= e > > > > > same considerations apply here. > > > > > > > > I agree with the text quoted above, > > > > Adding the rest of the sentence ... > > > > > > but what I'm observing is that there > > > > are networks for which GMTU is an indication that something is wron= g > > > > (this is a consequence of operator decisions that are specific to s= uch > > > > a network). > > > > > OK, then this document should cite Section 7 of RFC2473 normatively. > > > > I think it would be better to directly explain the GRE situation here, = and > > add an informative citation of RFC 2473 as providing additional explana= tion, > > particularly for situations in which different operational practices ar= e > used. >=20 > How is the GRE situation any different than for any generic encapsulation > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific use > cases"? Section 7 of RFC2473 already provides guidance that applies also > to GRE in any use case. >=20 > > > If there is operational assurance that all links in the tunnel path > configure > > > a sufficiently large MTU, and there will never be a nesting of tunnel= s > that > > > would result in a too-small MTU, then tunnel fragmentation would not > > > need to be invoked and there is no need to talk about sending PTBs wi= th > > > GMTU less than 1280. > > > > Never say "never" ... quoting RFC 5706, "Anything that can be configure= d can > > be misconfigured." ;-). >=20 > Right, that's what I said (having used that phrase many times in > the past myself). >=20 > > I'll leave the rationale for sending PTBs to Ron, but keep in mind that > > "running code" (i.e., existing implementations) is(are) an important > > consideration - see the second sentence in the Introduction. >=20 > Sending PTB with MTU<1280 is supposed to have an effect as described > in Section 5 of RFC. Namely, the original source is supposed to start > including IPv6 fragment headers in subsequent packets and the network > is supposed to find some way to get them through. What Ron's text > is suggesting is that the original source lives up to its part of the bar= gain > but then the network dumps the packets into a black hole. >=20 > > > Or, if you did want to include text that would tell > > > what to do in the case of misconfigurations, then this document would > > > need to update RFC2473 since the same considerations apply to generic > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > It's more than misconfigurations - attacks on PMTU monitoring can have > > similar effects. >=20 > If you want to start talking about PTB forgery, then we should also talk > about PTB filtering and how the mechanisms work when PTBs are lost. > RFC2473 itself is imperfect in that regard, and this draft is not proposi= ng > anything different than RFC2473. >=20 > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped draft > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does not > > cite RFC 2473); I think a separate draft would be more appropriate. >=20 > OK, then have this draft simply cite RFC2473, Section 7 normatively > and break the exception cases out into a separate document like > intarea-tunnels. The exception cases are not limited to GRE in > particular, and apply also to any generic tunneling in IPv6. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Wednesday, April 01, 2015 12:12 PM > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > Hi David, > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:david.black@emc.com] > > > > Sent: Wednesday, April 01, 2015 8:43 AM > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org; > > > Black, David > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > > > Fred, > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indica= tion > > > > > that something is wrong, as explained in Section 7 of RFC2473. Th= e > > > > > same considerations apply here. > > > > > > > > I agree with the text quoted above, > > > > > > OK, then this document should cite Section 7 of RFC2473 normatively. > > > > > > > but what I'm observing is that there > > > > are networks for which GMTU is an indication that something is wron= g > > > > (this is a consequence of operator decisions that are specific to s= uch > > > > a network). The alternative configuration is intended for such > networks, > > > > but is not intended for all networks, and would need to be qualifie= d > > > > with words making it applicable primarily or only (or suggest some > > > > other words) to such networks. > > > > > > If there is operational assurance that all links in the tunnel path > configure > > > a sufficiently large MTU, and there will never be a nesting of tunnel= s > that > > > would result in a too-small MTU, then tunnel fragmentation would not > > > need to be invoked and there is no need to talk about sending PTBs wi= th > > > GMTU less than 1280. Or, if you did want to include text that would t= ell > > > what to do in the case of misconfigurations, then this document would > > > need to update RFC2473 since the same considerations apply to generic > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > Upshot: the use of "necessarily" in the text quoted above is correc= t, > but > > > > misses the point. > > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > chairs@ietf.org > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > configuration > > > > > > > > > > Hi David, > > > > > > > > > > > -----Original Message----- > > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > chairs@ietf.org; > > > > > Black, David > > > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > > > > > > > So, I talked to Ron off-list and it looks like something is mis= sing > from > > > > > > this discussion. > > > > > > > > > > > > The "alternative configuration" is not motivated by a desire to > allow > > > > > > implementation flexibility or bless broken implementations. It= 's > > > motivated > > > > > > by consideration of networks with operational practices wherein= a > GMTU > > > of > > > > > > less than 1280 octets is evidence that something is seriously w= rong. > > > That > > > > > > something might be misconfiguration (quoting RFC 5706, "Anythin= g > that > > > > > > can be configured can be misconfigured."), or an attack on the = GRE > > > > > > ingress's PMTU estimation. > > > > > > > > > > > > So, in the situation of interest (GMTU < 1280) something is wro= ng, > and > > > > > > the operator may be faced with a Hobson's choice: either blackh= ole > the > > > > > > traffic that can no longer be sent without fragmentation, or > fragment a > > > > > > lot of traffic, causing problems at the GRE egress by overwhelm= ing > its > > > > > > reassembly code - there may be good operational and/or security > reasons > > > > > > to not want to do the latter. All of this ought to be explaine= d in > the > > > > > > draft. > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indica= tion > > > > > that something is wrong, as explained in Section 7 of RFC2473. Th= e > > > > > same considerations apply here. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > Thanks, > > > > > > --David > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf O= f > > > Templin, > > > > > Fred L > > > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > > chairs@ietf.org > > > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-= gre- > ipv6 > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > ipv6@tools.ietf.org; > > > > > > > intarea-chairs@ietf.org > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-intare= a- > gre- > > > ipv6 > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > It appears that we disagree and have taken to repeating > ourselves. > > > > > > > > > > > > > > This is not a disagreement; this is a case in which the text = is > > > actually > > > > > > > broken > > > > > > > which you have more or less acknowledged. You can fix the tex= t in > > > question > > > > > > > as follows: > > > > > > > > > > > > > > OLD: > > > > > > > **** > > > > > > > In its default configuration, the GRE ingress router MUST: > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE head= er > and IP > > > > > > > delivery header > > > > > > > > > > > > > > o fragment the delivery header, so that it can be reassem= bled > by > > > the > > > > > > > GRE egress > > > > > > > > > > > > > > However, in an alternative configuration, the GRE ingress = MAY: > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message t= o the > > > IPv6 > > > > > > > packet source. The MTU field in the ICMPv6 PTB message= is > set > > > to > > > > > > > the GMTU. > > > > > > > > > > > > > > NEW: > > > > > > > **** > > > > > > > The GRE ingress router MUST: > > > > > > > > > > > > > > o if the IPv6 payload packet includes a fragment header, > fragment > > > the > > > > > > > payload packet into fragments no larger than the GMTU = and > > > > > encapsulate > > > > > > > each fragment in a single GRE header and IP delivery he= ader. > > > > > Otherwise: > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE he= ader > and > > > IP > > > > > > > delivery header > > > > > > > > > > > > > > o fragment the delivery packet, so that it can be > reassembled by > > > the > > > > > > > GRE egress > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message= to > the > > > IPv6 > > > > > > > packet source, subject to rate limiting. The MTU fi= eld > in > > > the > > > > > ICMPv6 > > > > > > > PTB > > > > > > > message is set to the GMTU. > > > > > > > > > > > > > > > So, why don't we solicit opinions from the rest of the WG a= nd > defer > > > to > > > > > their > > > > > > > will. > > > > > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text thr= ough > the > > > > > > > process based on popular opinion does not make it good. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > ipv6@tools.ietf.org; > > > > > > > intarea- > > > > > > > > > chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-inta= rea- > gre- > > > ipv6 > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280 b= ytes > and > > > so > > > > > the > > > > > > > > > design must account for tunnel paths that include links w= ith > such > > > a > > > > > small > > > > > > > > > MTU. The design must also account for nested tunnels-with= in- > > > tunnels, > > > > > > > > > where the MTU seen by the first tunnel ingress may be red= uced > by > > > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot > > > legitimately > > > > > send > > > > > > > PTBs > > > > > > > > > that report a size smaller than 1280 *and* perpetually dr= op > > > packets > > > > > > > smaller > > > > > > > > > than 1280 which is exactly the behavior your text is > permitting. > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > ipv6@tools.ietf.org; > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf- > intarea- > > > gre- > > > > > ipv6 > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > In the last network that I operated, all interior links= had > MTU > > > > > > > > > > greater than 9k. If I configured a GRE tunnel between t= wo > points > > > in > > > > > that > > > > > > > > > network and detected a GMTU less than 1280, it would have > > > indicated > > > > > one of > > > > > > > > > the following: > > > > > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in how t= heir > > > networks > > > > > > > > > > would behave. Why deny them this flexibility by taking = away > the > > > > > > > > > configuration option? > > > > > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any packe= t > that > > > might > > > > > > > degrade > > > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.c= om] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > > ipv6@tools.ietf.org; > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.o= rg > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in w= hich > all > > > > > links > > > > > > > > > > > > have MTU greater than or equal to 1500. In those > networks, > > > the > > > > > > > > > > > > very detection of a GMTU smaller than 1280 indicate= s > > > brokenness. > > > > > > > > > > > > Those > > > > > > > > > > > operators, the alternative behavior may be preferable= to > the > > > > > default. > > > > > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how much = the > link > > > must > > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 does= not > > > indicate > > > > > > > > > > > brokennesss; it can naturally happen if 1) there is a= link > > > with a > > > > > > > > > > > small MTU in the path, or > > > > > > > > > > > 2) there are multiple tunnel nesting levels, or both. > > > > > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 1280= is a > no- > > > no, > > > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Templin, Fred L > [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.o= rg > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net= ] > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuration,= the > GRE > > > > > ingress > > > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) > [RFC4443] > > > > > message > > > > > > > > > > > > > > > to the > > > > > > > > > > > IPv6 > > > > > > > > > > > > > > > packet source. The MTU field in the IC= MPv6 > PTB > > > > > message > > > > > > > is set > > > > > > > > > to > > > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances wh= en > the > > > GRE > > > > > > > > > > > > > > > ingress sends a PTB reporting a size less tha= n > 1280. > > > > > > > > > > > > > > > According to RFC2460, Section 5, the standard > behavior > > > for > > > > > a > > > > > > > > > > > > > > > host that receives > > > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > > > is not required to reduce the size of subse= quent > > > packets > > > > > to > > > > > > > less > > > > > > > > > than > > > > > > > > > > > > > > > 1280, but must include a Fragment header i= n > those > > > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will se= e a > > > perpetual > > > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280 w= hich > is > > > > > > > > > > > > > > > probably not what we > > > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > All true. This is why the WG decided to make th= is > the > > > > > > > > > > > > > > alternative behavior > > > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardles= s of > > > whether > > > > > it > > > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to pr= ovide > > > > > guidance > > > > > > > > > > > > > > > to hosts on how to react to PTB messages that > report a > > > > > small > > > > > > > size. > > > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior. > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described in > Section > > > 5 or > > > > > > > > > > > > > > RFC > > > > > > > > > > > > > > 246 are > > > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision > regarding > > > the > > > > > > > > > > > > > > current > > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whether > > > alternative > > > > > or > > > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Int-area mailing list > > > > > > > Int-area@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 16:17:42 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF74B1ACC81; Wed, 1 Apr 2015 16:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-JSLN-R0qOn; Wed, 1 Apr 2015 16:17:33 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D121ACC7F; Wed, 1 Apr 2015 16:17:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t31NHW74009537; Wed, 1 Apr 2015 16:17:32 -0700 Received: from XCH-BLV-302.nw.nos.boeing.com (xch-blv-302.nw.nos.boeing.com [130.247.25.214]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t31NHTIr009064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 1 Apr 2015 16:17:29 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.195]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 16:17:28 -0700 From: "Templin, Fred L" To: "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCAAAhGi8AAB9x+Q Date: Wed, 1 Apr 2015 23:17:27 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:17:39 -0000 Hi David, > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 01, 2015 4:08 PM > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > > > I think it would be better to directly explain the GRE situation here= , and > > > add an informative citation of RFC 2473 as providing additional expla= nation, > > > particularly for situations in which different operational practices = are > > > used. > > > > How is the GRE situation any different than for any generic encapsulati= on > > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific us= e > > cases"? >=20 > Yes, specifically networks where a GMTU < 1280 always indicates a problem= . OK, for specific use cases then, i.e., the same as for any generic IPv6 encapsulation in specific use cases and not only for GRE. > > Section 7 of RFC2473 already provides guidance that applies also > > to GRE in any use case. >=20 > Ok, as previously noted - the text here is specific to GRE and certain > networks. Specific to certain networks, perhaps, but not specific to GRE. > > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped dra= ft > > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does no= t > > > cite RFC 2473); I think a separate draft would be more appropriate. > > > > OK, then have this draft simply cite RFC2473, Section 7 normatively > > and break the exception cases out into a separate document like > > intarea-tunnels. The exception cases are not limited to GRE in > > particular, and apply also to any generic tunneling in IPv6. >=20 > Right now, the exception case is proposed as GRE-only, and hence is > appropriate for this draft. I hesitate to generalize it to all IPv6 > tunnels or have the GRE provisions await that being done. This is where we differ - there is nothing in this recommendation that is specific to GRE - the recommendation applies to any generic IPv6 encapsulation and is appropriate to only those use cases where shutting down the tunnel altogether is preferable to allowing the tunnel to fragment. This is a generic IPv6 encapsulation consideration; not a GRE consideration. Thanks - Fred fred.l.templin@boeing.com > Thanks, > --David >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, April 01, 2015 5:34 PM > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > Hi David, > > > > > -----Original Message----- > > > From: Black, David [mailto:david.black@emc.com] > > > Sent: Wednesday, April 01, 2015 1:26 PM > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg; > > Black, David > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative config= uration > > > > > > Fred, > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indi= cation > > > > > > that something is wrong, as explained in Section 7 of RFC2473. = The > > > > > > same considerations apply here. > > > > > > > > > > I agree with the text quoted above, > > > > > > Adding the rest of the sentence ... > > > > > > > > but what I'm observing is that there > > > > > are networks for which GMTU is an indication that something is wr= ong > > > > > (this is a consequence of operator decisions that are specific to= such > > > > > a network). > > > > > > > OK, then this document should cite Section 7 of RFC2473 normatively= . > > > > > > I think it would be better to directly explain the GRE situation here= , and > > > add an informative citation of RFC 2473 as providing additional expla= nation, > > > particularly for situations in which different operational practices = are > > used. > > > > How is the GRE situation any different than for any generic encapsulati= on > > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific us= e > > cases"? Section 7 of RFC2473 already provides guidance that applies als= o > > to GRE in any use case. > > > > > > If there is operational assurance that all links in the tunnel path > > configure > > > > a sufficiently large MTU, and there will never be a nesting of tunn= els > > that > > > > would result in a too-small MTU, then tunnel fragmentation would no= t > > > > need to be invoked and there is no need to talk about sending PTBs = with > > > > GMTU less than 1280. > > > > > > Never say "never" ... quoting RFC 5706, "Anything that can be configu= red can > > > be misconfigured." ;-). > > > > Right, that's what I said (having used that phrase many times in > > the past myself). > > > > > I'll leave the rationale for sending PTBs to Ron, but keep in mind th= at > > > "running code" (i.e., existing implementations) is(are) an important > > > consideration - see the second sentence in the Introduction. > > > > Sending PTB with MTU<1280 is supposed to have an effect as described > > in Section 5 of RFC. Namely, the original source is supposed to start > > including IPv6 fragment headers in subsequent packets and the network > > is supposed to find some way to get them through. What Ron's text > > is suggesting is that the original source lives up to its part of the b= argain > > but then the network dumps the packets into a black hole. > > > > > > Or, if you did want to include text that would tell > > > > what to do in the case of misconfigurations, then this document wou= ld > > > > need to update RFC2473 since the same considerations apply to gener= ic > > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > > > It's more than misconfigurations - attacks on PMTU monitoring can hav= e > > > similar effects. > > > > If you want to start talking about PTB forgery, then we should also tal= k > > about PTB filtering and how the mechanisms work when PTBs are lost. > > RFC2473 itself is imperfect in that regard, and this draft is not propo= sing > > anything different than RFC2473. > > > > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped dra= ft > > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does no= t > > > cite RFC 2473); I think a separate draft would be more appropriate. > > > > OK, then have this draft simply cite RFC2473, Section 7 normatively > > and break the exception cases out into a separate document like > > intarea-tunnels. The exception cases are not limited to GRE in > > particular, and apply also to any generic tunneling in IPv6. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Wednesday, April 01, 2015 12:12 PM > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > configuration > > > > > > > > Hi David, > > > > > > > > > -----Original Message----- > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > Sent: Wednesday, April 01, 2015 8:43 AM > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ie= tf.org; > > > > Black, David > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > configuration > > > > > > > > > > Fred, > > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indi= cation > > > > > > that something is wrong, as explained in Section 7 of RFC2473. = The > > > > > > same considerations apply here. > > > > > > > > > > I agree with the text quoted above, > > > > > > > > OK, then this document should cite Section 7 of RFC2473 normatively= . > > > > > > > > > but what I'm observing is that there > > > > > are networks for which GMTU is an indication that something is wr= ong > > > > > (this is a consequence of operator decisions that are specific to= such > > > > > a network). The alternative configuration is intended for such > > networks, > > > > > but is not intended for all networks, and would need to be qualif= ied > > > > > with words making it applicable primarily or only (or suggest som= e > > > > > other words) to such networks. > > > > > > > > If there is operational assurance that all links in the tunnel path > > configure > > > > a sufficiently large MTU, and there will never be a nesting of tunn= els > > that > > > > would result in a too-small MTU, then tunnel fragmentation would no= t > > > > need to be invoked and there is no need to talk about sending PTBs = with > > > > GMTU less than 1280. Or, if you did want to include text that would= tell > > > > what to do in the case of misconfigurations, then this document wou= ld > > > > need to update RFC2473 since the same considerations apply to gener= ic > > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > Upshot: the use of "necessarily" in the text quoted above is corr= ect, > > but > > > > > misses the point. > > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > chairs@ietf.org > > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > > configuration > > > > > > > > > > > > Hi David, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > chairs@ietf.org; > > > > > > Black, David > > > > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > configuration > > > > > > > > > > > > > > So, I talked to Ron off-list and it looks like something is m= issing > > from > > > > > > > this discussion. > > > > > > > > > > > > > > The "alternative configuration" is not motivated by a desire = to > > allow > > > > > > > implementation flexibility or bless broken implementations. = It's > > > > motivated > > > > > > > by consideration of networks with operational practices where= in a > > GMTU > > > > of > > > > > > > less than 1280 octets is evidence that something is seriously= wrong. > > > > That > > > > > > > something might be misconfiguration (quoting RFC 5706, "Anyth= ing > > that > > > > > > > can be configured can be misconfigured."), or an attack on th= e GRE > > > > > > > ingress's PMTU estimation. > > > > > > > > > > > > > > So, in the situation of interest (GMTU < 1280) something is w= rong, > > and > > > > > > > the operator may be faced with a Hobson's choice: either blac= khole > > the > > > > > > > traffic that can no longer be sent without fragmentation, or > > fragment a > > > > > > > lot of traffic, causing problems at the GRE egress by overwhe= lming > > its > > > > > > > reassembly code - there may be good operational and/or securi= ty > > reasons > > > > > > > to not want to do the latter. All of this ought to be explai= ned in > > the > > > > > > > draft. > > > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an indi= cation > > > > > > that something is wrong, as explained in Section 7 of RFC2473. = The > > > > > > same considerations apply here. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > Thanks, > > > > > > > --David > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf= Of > > > > Templin, > > > > > > Fred L > > > > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > > > chairs@ietf.org > > > > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-intare= a-gre- > > ipv6 > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > ipv6@tools.ietf.org; > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-inta= rea- > > gre- > > > > ipv6 > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > It appears that we disagree and have taken to repeating > > ourselves. > > > > > > > > > > > > > > > > This is not a disagreement; this is a case in which the tex= t is > > > > actually > > > > > > > > broken > > > > > > > > which you have more or less acknowledged. You can fix the t= ext in > > > > question > > > > > > > > as follows: > > > > > > > > > > > > > > > > OLD: > > > > > > > > **** > > > > > > > > In its default configuration, the GRE ingress router MUS= T: > > > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE he= ader > > and IP > > > > > > > > delivery header > > > > > > > > > > > > > > > > o fragment the delivery header, so that it can be reass= embled > > by > > > > the > > > > > > > > GRE egress > > > > > > > > > > > > > > > > However, in an alternative configuration, the GRE ingres= s MAY: > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message= to the > > > > IPv6 > > > > > > > > packet source. The MTU field in the ICMPv6 PTB messa= ge is > > set > > > > to > > > > > > > > the GMTU. > > > > > > > > > > > > > > > > NEW: > > > > > > > > **** > > > > > > > > The GRE ingress router MUST: > > > > > > > > > > > > > > > > o if the IPv6 payload packet includes a fragment header= , > > fragment > > > > the > > > > > > > > payload packet into fragments no larger than the GMT= U and > > > > > > encapsulate > > > > > > > > each fragment in a single GRE header and IP delivery = header. > > > > > > Otherwise: > > > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE = header > > and > > > > IP > > > > > > > > delivery header > > > > > > > > > > > > > > > > o fragment the delivery packet, so that it can be > > reassembled by > > > > the > > > > > > > > GRE egress > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] messa= ge to > > the > > > > IPv6 > > > > > > > > packet source, subject to rate limiting. The MTU = field > > in > > > > the > > > > > > ICMPv6 > > > > > > > > PTB > > > > > > > > message is set to the GMTU. > > > > > > > > > > > > > > > > > So, why don't we solicit opinions from the rest of the WG= and > > defer > > > > to > > > > > > their > > > > > > > > will. > > > > > > > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text t= hrough > > the > > > > > > > > process based on popular opinion does not make it good. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > R= on > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com= ] > > > > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > ipv6@tools.ietf.org; > > > > > > > > intarea- > > > > > > > > > > chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf-in= tarea- > > gre- > > > > ipv6 > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 1280= bytes > > and > > > > so > > > > > > the > > > > > > > > > > design must account for tunnel paths that include links= with > > such > > > > a > > > > > > small > > > > > > > > > > MTU. The design must also account for nested tunnels-wi= thin- > > > > tunnels, > > > > > > > > > > where the MTU seen by the first tunnel ingress may be r= educed > > by > > > > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > > > > > > > But again, the point is that the tunnel ingress cannot > > > > legitimately > > > > > > send > > > > > > > > PTBs > > > > > > > > > > that report a size smaller than 1280 *and* perpetually = drop > > > > packets > > > > > > > > smaller > > > > > > > > > > than 1280 which is exactly the behavior your text is > > permitting. > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > ipv6@tools.ietf.org; > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf- > > intarea- > > > > gre- > > > > > > ipv6 > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > In the last network that I operated, all interior lin= ks had > > MTU > > > > > > > > > > > greater than 9k. If I configured a GRE tunnel between= two > > points > > > > in > > > > > > that > > > > > > > > > > network and detected a GMTU less than 1280, it would ha= ve > > > > indicated > > > > > > one of > > > > > > > > > > the following: > > > > > > > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in how= their > > > > networks > > > > > > > > > > > would behave. Why deny them this flexibility by takin= g away > > the > > > > > > > > > > configuration option? > > > > > > > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any pac= ket > > that > > > > might > > > > > > > > degrade > > > > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing= .com] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > > > ipv6@tools.ietf.org; > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf= .org > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks in= which > > all > > > > > > links > > > > > > > > > > > > > have MTU greater than or equal to 1500. In those > > networks, > > > > the > > > > > > > > > > > > > very detection of a GMTU smaller than 1280 indica= tes > > > > brokenness. > > > > > > > > > > > > > Those > > > > > > > > > > > > operators, the alternative behavior may be preferab= le to > > the > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how muc= h the > > link > > > > must > > > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 do= es not > > > > indicate > > > > > > > > > > > > brokennesss; it can naturally happen if 1) there is= a link > > > > with a > > > > > > > > > > > > small MTU in the path, or > > > > > > > > > > > > 2) there are multiple tunnel nesting levels, or bot= h. > > > > > > > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than 12= 80 is a > > no- > > > > no, > > > > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Templin, Fred L > > [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf= .org > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.n= et] > > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configuratio= n, the > > GRE > > > > > > ingress > > > > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) > > [RFC4443] > > > > > > message > > > > > > > > > > > > > > > > to the > > > > > > > > > > > > IPv6 > > > > > > > > > > > > > > > > packet source. The MTU field in the = ICMPv6 > > PTB > > > > > > message > > > > > > > > is set > > > > > > > > > > to > > > > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstances = when > > the > > > > GRE > > > > > > > > > > > > > > > > ingress sends a PTB reporting a size less t= han > > 1280. > > > > > > > > > > > > > > > > According to RFC2460, Section 5, the standa= rd > > behavior > > > > for > > > > > > a > > > > > > > > > > > > > > > > host that receives > > > > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > > > > is not required to reduce the size of sub= sequent > > > > packets > > > > > > to > > > > > > > > less > > > > > > > > > > than > > > > > > > > > > > > > > > > 1280, but must include a Fragment header= in > > those > > > > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 will = see a > > > > perpetual > > > > > > > > > > > > > > > > black hole if the GMTU is smaller than 1280= which > > is > > > > > > > > > > > > > > > > probably not what we > > > > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > All true. This is why the WG decided to make = this > > the > > > > > > > > > > > > > > > alternative behavior > > > > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regardl= ess of > > > > whether > > > > > > it > > > > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts to = provide > > > > > > guidance > > > > > > > > > > > > > > > > to hosts on how to react to PTB messages th= at > > report a > > > > > > small > > > > > > > > size. > > > > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavior= . > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures described = in > > Section > > > > 5 or > > > > > > > > > > > > > > > RFC > > > > > > > > > > > > > > > 246 are > > > > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decision > > regarding > > > > the > > > > > > > > > > > > > > > current > > > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whethe= r > > > > alternative > > > > > > or > > > > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Int-area mailing list > > > > > > > > Int-area@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 1 16:27:19 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23DA1A90A1; Wed, 1 Apr 2015 16:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH4Q-WXeVloR; Wed, 1 Apr 2015 16:27:12 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 6E0F21AC3C6; Wed, 1 Apr 2015 16:27:10 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31NR5Fw004993 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2015 19:27:06 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t31NR5Fw004993 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1427930826; bh=dk48oiin5lFW+YDk6xH2Mn+fkAI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ccsbXK84Ehu+bI/fbOZ4+WgBEfaJE7liDvcxdYPFb0CBLH71GcpyCybZkU1eCgD4c y4dBxsacHcpxConhb+TXTbJL/Zt1ybkBPJ2PcirdDfybig0CwH5FWtq5tP8sjG9GlI 5mS24pEJeU67iSZEM4Y1/We0qgfQpRYGxqHOsRPs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t31NR5Fw004993 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 1 Apr 2015 19:27:00 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t31NQh2S003646 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 19:26:43 -0400 Received: from MXHUB201.corp.emc.com (10.253.68.27) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 1 Apr 2015 19:26:42 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB201.corp.emc.com ([10.253.68.27]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 19:26:43 -0400 From: "Black, David" To: "Templin, Fred L" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCAAAhGi8AAB9x+QAACAahA= Date: Wed, 1 Apr 2015 23:26:42 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:27:17 -0000 One more inline ... > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, April 01, 2015 7:17 PM > To: Black, David; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configurat= ion >=20 > Hi David, >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Wednesday, April 01, 2015 4:08 PM > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configur= ation > > > > > > I think it would be better to directly explain the GRE situation he= re, > and > > > > add an informative citation of RFC 2473 as providing additional > explanation, > > > > particularly for situations in which different operational practice= s are > > > > used. > > > > > > How is the GRE situation any different than for any generic encapsula= tion > > > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific = use > > > cases"? > > > > Yes, specifically networks where a GMTU < 1280 always indicates a probl= em. >=20 > OK, for specific use cases then, i.e., the same as for any generic > IPv6 encapsulation in specific use cases and not only for GRE. >=20 > > > Section 7 of RFC2473 already provides guidance that applies also > > > to GRE in any use case. > > > > Ok, as previously noted - the text here is specific to GRE and certain > > networks. >=20 > Specific to certain networks, perhaps, but not specific to GRE. >=20 > > > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped d= raft > > > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does = not > > > > cite RFC 2473); I think a separate draft would be more appropriate. > > > > > > OK, then have this draft simply cite RFC2473, Section 7 normatively > > > and break the exception cases out into a separate document like > > > intarea-tunnels. The exception cases are not limited to GRE in > > > particular, and apply also to any generic tunneling in IPv6. > > > > Right now, the exception case is proposed as GRE-only, and hence is > > appropriate for this draft. I hesitate to generalize it to all IPv6 > > tunnels or have the GRE provisions await that being done. >=20 > This is where we differ - there is nothing in this recommendation > that is specific to GRE - the recommendation applies to any generic > IPv6 encapsulation and is appropriate to only those use cases where > shutting down the tunnel altogether is preferable to allowing the > tunnel to fragment. This is a generic IPv6 encapsulation consideration; > not a GRE consideration. The "running code" involved here is GRE. I am concerned that we lack the foundation to update 2473 for all encapsulated protocols. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Wednesday, April 01, 2015 5:34 PM > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.o= rg > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > Hi David, > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:david.black@emc.com] > > > > Sent: Wednesday, April 01, 2015 1:26 PM > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf= .org; > > > Black, David > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > configuration > > > > > > > > Fred, > > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an > indication > > > > > > > that something is wrong, as explained in Section 7 of RFC2473= . The > > > > > > > same considerations apply here. > > > > > > > > > > > > I agree with the text quoted above, > > > > > > > > Adding the rest of the sentence ... > > > > > > > > > > but what I'm observing is that there > > > > > > are networks for which GMTU is an indication that something is = wrong > > > > > > (this is a consequence of operator decisions that are specific = to > such > > > > > > a network). > > > > > > > > > OK, then this document should cite Section 7 of RFC2473 normative= ly. > > > > > > > > I think it would be better to directly explain the GRE situation he= re, > and > > > > add an informative citation of RFC 2473 as providing additional > explanation, > > > > particularly for situations in which different operational practice= s are > > > used. > > > > > > How is the GRE situation any different than for any generic encapsula= tion > > > in IPv6 situation (RFC2473)? Are you meaning to say "GRE in specific = use > > > cases"? Section 7 of RFC2473 already provides guidance that applies a= lso > > > to GRE in any use case. > > > > > > > > If there is operational assurance that all links in the tunnel pa= th > > > configure > > > > > a sufficiently large MTU, and there will never be a nesting of tu= nnels > > > that > > > > > would result in a too-small MTU, then tunnel fragmentation would = not > > > > > need to be invoked and there is no need to talk about sending PTB= s > with > > > > > GMTU less than 1280. > > > > > > > > Never say "never" ... quoting RFC 5706, "Anything that can be confi= gured > can > > > > be misconfigured." ;-). > > > > > > Right, that's what I said (having used that phrase many times in > > > the past myself). > > > > > > > I'll leave the rationale for sending PTBs to Ron, but keep in mind = that > > > > "running code" (i.e., existing implementations) is(are) an importan= t > > > > consideration - see the second sentence in the Introduction. > > > > > > Sending PTB with MTU<1280 is supposed to have an effect as described > > > in Section 5 of RFC. Namely, the original source is supposed to start > > > including IPv6 fragment headers in subsequent packets and the network > > > is supposed to find some way to get them through. What Ron's text > > > is suggesting is that the original source lives up to its part of the > bargain > > > but then the network dumps the packets into a black hole. > > > > > > > > Or, if you did want to include text that would tell > > > > > what to do in the case of misconfigurations, then this document w= ould > > > > > need to update RFC2473 since the same considerations apply to gen= eric > > > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > > > > > It's more than misconfigurations - attacks on PMTU monitoring can h= ave > > > > similar effects. > > > > > > If you want to start talking about PTB forgery, then we should also t= alk > > > about PTB filtering and how the mechanisms work when PTBs are lost. > > > RFC2473 itself is imperfect in that regard, and this draft is not > proposing > > > anything different than RFC2473. > > > > > > > Beyond that, if an update to RFC 2473 is desired, this GRE-scoped d= raft > > > > seems like a poor vehicle for that purpose (e.g., as RFC 2784 does = not > > > > cite RFC 2473); I think a separate draft would be more appropriate. > > > > > > OK, then have this draft simply cite RFC2473, Section 7 normatively > > > and break the exception cases out into a separate document like > > > intarea-tunnels. The exception cases are not limited to GRE in > > > particular, and apply also to any generic tunneling in IPv6. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Wednesday, April 01, 2015 12:12 PM > > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > chairs@ietf.org > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > configuration > > > > > > > > > > Hi David, > > > > > > > > > > > -----Original Message----- > > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > > Sent: Wednesday, April 01, 2015 8:43 AM > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > chairs@ietf.org; > > > > > Black, David > > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > configuration > > > > > > > > > > > > Fred, > > > > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an > indication > > > > > > > that something is wrong, as explained in Section 7 of RFC2473= . The > > > > > > > same considerations apply here. > > > > > > > > > > > > I agree with the text quoted above, > > > > > > > > > > OK, then this document should cite Section 7 of RFC2473 normative= ly. > > > > > > > > > > > but what I'm observing is that there > > > > > > are networks for which GMTU is an indication that something is = wrong > > > > > > (this is a consequence of operator decisions that are specific = to > such > > > > > > a network). The alternative configuration is intended for such > > > networks, > > > > > > but is not intended for all networks, and would need to be qual= ified > > > > > > with words making it applicable primarily or only (or suggest s= ome > > > > > > other words) to such networks. > > > > > > > > > > If there is operational assurance that all links in the tunnel pa= th > > > configure > > > > > a sufficiently large MTU, and there will never be a nesting of tu= nnels > > > that > > > > > would result in a too-small MTU, then tunnel fragmentation would = not > > > > > need to be invoked and there is no need to talk about sending PTB= s > with > > > > > GMTU less than 1280. Or, if you did want to include text that wou= ld > tell > > > > > what to do in the case of misconfigurations, then this document w= ould > > > > > need to update RFC2473 since the same considerations apply to gen= eric > > > > > encapsulation over IPv6 and not just GRE encapsulation over IPv6. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > Upshot: the use of "necessarily" in the text quoted above is > correct, > > > but > > > > > > misses the point. > > > > > > > > > > > > Thanks, > > > > > > --David > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > > Sent: Wednesday, April 01, 2015 10:13 AM > > > > > > > To: Black, David; int-area@ietf.org; ipv6@ietf.org > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > > chairs@ietf.org > > > > > > > Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternativ= e > > > > > configuration > > > > > > > > > > > > > > Hi David, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > > > > Sent: Tuesday, March 31, 2015 7:06 PM > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > > chairs@ietf.org; > > > > > > > Black, David > > > > > > > > Subject: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative > > > configuration > > > > > > > > > > > > > > > > So, I talked to Ron off-list and it looks like something is > missing > > > from > > > > > > > > this discussion. > > > > > > > > > > > > > > > > The "alternative configuration" is not motivated by a desir= e to > > > allow > > > > > > > > implementation flexibility or bless broken implementations. > It's > > > > > motivated > > > > > > > > by consideration of networks with operational practices whe= rein > a > > > GMTU > > > > > of > > > > > > > > less than 1280 octets is evidence that something is serious= ly > wrong. > > > > > That > > > > > > > > something might be misconfiguration (quoting RFC 5706, "Any= thing > > > that > > > > > > > > can be configured can be misconfigured."), or an attack on = the > GRE > > > > > > > > ingress's PMTU estimation. > > > > > > > > > > > > > > > > So, in the situation of interest (GMTU < 1280) something is > wrong, > > > and > > > > > > > > the operator may be faced with a Hobson's choice: either > blackhole > > > the > > > > > > > > traffic that can no longer be sent without fragmentation, o= r > > > fragment a > > > > > > > > lot of traffic, causing problems at the GRE egress by > overwhelming > > > its > > > > > > > > reassembly code - there may be good operational and/or secu= rity > > > reasons > > > > > > > > to not want to do the latter. All of this ought to be expl= ained > in > > > the > > > > > > > > draft. > > > > > > > > > > > > > > No, that's is not right. GMTU < 1280 is not necessarily an > indication > > > > > > > that something is wrong, as explained in Section 7 of RFC2473= . The > > > > > > > same considerations apply here. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > Thanks, > > > > > > > > --David > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Beha= lf Of > > > > > Templin, > > > > > > > Fred L > > > > > > > > > Sent: Tuesday, March 31, 2015 6:39 PM > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea- > > > > > chairs@ietf.org > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for draft-ietf-inta= rea- > gre- > > > ipv6 > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:12 PM > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > ipv6@tools.ietf.org; > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf- > intarea- > > > gre- > > > > > ipv6 > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > It appears that we disagree and have taken to repeating > > > ourselves. > > > > > > > > > > > > > > > > > > This is not a disagreement; this is a case in which the t= ext > is > > > > > actually > > > > > > > > > broken > > > > > > > > > which you have more or less acknowledged. You can fix the= text > in > > > > > question > > > > > > > > > as follows: > > > > > > > > > > > > > > > > > > OLD: > > > > > > > > > **** > > > > > > > > > In its default configuration, the GRE ingress router M= UST: > > > > > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GRE > header > > > and IP > > > > > > > > > delivery header > > > > > > > > > > > > > > > > > > o fragment the delivery header, so that it can be > reassembled > > > by > > > > > the > > > > > > > > > GRE egress > > > > > > > > > > > > > > > > > > However, in an alternative configuration, the GRE ingr= ess > MAY: > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] messa= ge to > the > > > > > IPv6 > > > > > > > > > packet source. The MTU field in the ICMPv6 PTB mes= sage > is > > > set > > > > > to > > > > > > > > > the GMTU. > > > > > > > > > > > > > > > > > > NEW: > > > > > > > > > **** > > > > > > > > > The GRE ingress router MUST: > > > > > > > > > > > > > > > > > > o if the IPv6 payload packet includes a fragment head= er, > > > fragment > > > > > the > > > > > > > > > payload packet into fragments no larger than the G= MTU > and > > > > > > > encapsulate > > > > > > > > > each fragment in a single GRE header and IP deliver= y > header. > > > > > > > Otherwise: > > > > > > > > > > > > > > > > > > o encapsulate the entire IPv6 packet in a single GR= E > header > > > and > > > > > IP > > > > > > > > > delivery header > > > > > > > > > > > > > > > > > > o fragment the delivery packet, so that it can be > > > reassembled by > > > > > the > > > > > > > > > GRE egress > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) [RFC4443] mes= sage > to > > > the > > > > > IPv6 > > > > > > > > > packet source, subject to rate limiting. The MT= U > field > > > in > > > > > the > > > > > > > ICMPv6 > > > > > > > > > PTB > > > > > > > > > message is set to the GMTU. > > > > > > > > > > > > > > > > > > > So, why don't we solicit opinions from the rest of the = WG > and > > > defer > > > > > to > > > > > > > their > > > > > > > > > will. > > > > > > > > > > > > > > > > > > We can't do that for broken text. Ram-rodding broken text > through > > > the > > > > > > > > > process based on popular opinion does not make it good. > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > = Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.c= om] > > > > > > > > > > > Sent: Tuesday, March 31, 2015 4:38 PM > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > > ipv6@tools.ietf.org; > > > > > > > > > intarea- > > > > > > > > > > > chairs@ietf.org > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-ietf- > intarea- > > > gre- > > > > > ipv6 > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > I will say again that the minimum IPv6 link MTU is 12= 80 > bytes > > > and > > > > > so > > > > > > > the > > > > > > > > > > > design must account for tunnel paths that include lin= ks > with > > > such > > > > > a > > > > > > > small > > > > > > > > > > > MTU. The design must also account for nested tunnels- > within- > > > > > tunnels, > > > > > > > > > > > where the MTU seen by the first tunnel ingress may be > reduced > > > by > > > > > > > > > > > potentially many layers of additional encapsulation. > > > > > > > > > > > > > > > > > > > > > > But again, the point is that the tunnel ingress canno= t > > > > > legitimately > > > > > > > send > > > > > > > > > PTBs > > > > > > > > > > > that report a size smaller than 1280 *and* perpetuall= y > drop > > > > > packets > > > > > > > > > smaller > > > > > > > > > > > than 1280 which is exactly the behavior your text is > > > permitting. > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:21 PM > > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; ipv6@ietf.o= rg > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > > ipv6@tools.ietf.org; > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for draft-iet= f- > > > intarea- > > > > > gre- > > > > > > > ipv6 > > > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > > > In the last network that I operated, all interior l= inks > had > > > MTU > > > > > > > > > > > > greater than 9k. If I configured a GRE tunnel betwe= en > two > > > points > > > > > in > > > > > > > that > > > > > > > > > > > network and detected a GMTU less than 1280, it would = have > > > > > indicated > > > > > > > one of > > > > > > > > > > > the following: > > > > > > > > > > > > > > > > > > > > > > > > - Phenomenal brokenness > > > > > > > > > > > > - An ICMP PTB-based attack in progress > > > > > > > > > > > > > > > > > > > > > > > > In such cases, operators need some flexibility in h= ow > their > > > > > networks > > > > > > > > > > > > would behave. Why deny them this flexibility by tak= ing > away > > > the > > > > > > > > > > > configuration option? > > > > > > > > > > > > > > > > > > > > > > > > Isn't it an operator's prerogative to discard any p= acket > > > that > > > > > might > > > > > > > > > degrade > > > > > > > > > > > network performance? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Templin, Fred L > [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 3:01 PM > > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.o= rg > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; draft-ietf-intarea-gre- > > > > > > > ipv6@tools.ietf.org; > > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper.net= ] > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 11:38 AM > > > > > > > > > > > > > > To: Templin, Fred L; int-area@ietf.org; > ipv6@ietf.org > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some (if not most) operators maintain networks = in > which > > > all > > > > > > > links > > > > > > > > > > > > > > have MTU greater than or equal to 1500. In thos= e > > > networks, > > > > > the > > > > > > > > > > > > > > very detection of a GMTU smaller than 1280 indi= cates > > > > > brokenness. > > > > > > > > > > > > > > Those > > > > > > > > > > > > > operators, the alternative behavior may be prefer= able > to > > > the > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > > > The minimum IPv6 MTU is 1280 bytes; that is how m= uch > the > > > link > > > > > must > > > > > > > > > > > > > deliver no matter what. A GMTU smaller than 1280 = does > not > > > > > indicate > > > > > > > > > > > > > brokennesss; it can naturally happen if 1) there = is a > link > > > > > with a > > > > > > > > > > > > > small MTU in the path, or > > > > > > > > > > > > > 2) there are multiple tunnel nesting levels, or b= oth. > > > > > > > > > > > > > > > > > > > > > > > > > > As such, sustained dropping of packets less than = 1280 > is a > > > no- > > > > > no, > > > > > > > > > > > > > and cannot be specified in a document like this. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Templin, Fred L > > > [mailto:Fred.L.Templin@boeing.com] > > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 1:30 PM > > > > > > > > > > > > > > > To: Ronald Bonica; int-area@ietf.org; > ipv6@ietf.org > > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > > intarea- chairs@ietf.org > > > > > > > > > > > > > > > Subject: RE: [Int-area] Start of WGLC for > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Ronald Bonica [mailto:rbonica@juniper= .net] > > > > > > > > > > > > > > > > Sent: Tuesday, March 31, 2015 10:18 AM > > > > > > > > > > > > > > > > To: int-area@ietf.org; ipv6@ietf.org > > > > > > > > > > > > > > > > Cc: Zuniga, Juan Carlos; Templin, Fred L; > > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6@tools.ietf.org; > > > > > > > > > > > > > > > > intarea-chairs@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Int-area] Start of WGLC for > > > > > > > > > > > > > > > > draft-ietf-intarea-gre-ipv6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Inline..... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Juan Carlos, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Final passage of Section 3.1 says: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?However, in an alternative configurat= ion, > the > > > GRE > > > > > > > ingress > > > > > > > > > MAY: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o discard the IPv6 packet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > o send an ICMPv6 Packet Too Big (PTB) > > > [RFC4443] > > > > > > > message > > > > > > > > > > > > > > > > > to the > > > > > > > > > > > > > IPv6 > > > > > > > > > > > > > > > > > packet source. The MTU field in th= e > ICMPv6 > > > PTB > > > > > > > message > > > > > > > > > is set > > > > > > > > > > > to > > > > > > > > > > > > > > > > > the GMTU.? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This means that there may be circumstance= s > when > > > the > > > > > GRE > > > > > > > > > > > > > > > > > ingress sends a PTB reporting a size less= than > > > 1280. > > > > > > > > > > > > > > > > > According to RFC2460, Section 5, the stan= dard > > > behavior > > > > > for > > > > > > > a > > > > > > > > > > > > > > > > > host that receives > > > > > > > > > > > > > such a PTB is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?In that case, the IPv6 node > > > > > > > > > > > > > > > > > is not required to reduce the size of > subsequent > > > > > packets > > > > > > > to > > > > > > > > > less > > > > > > > > > > > than > > > > > > > > > > > > > > > > > 1280, but must include a Fragment head= er in > > > those > > > > > > > packets? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So, hosts that obey RFC2460 Section 5 wil= l see > a > > > > > perpetual > > > > > > > > > > > > > > > > > black hole if the GMTU is smaller than 12= 80 > which > > > is > > > > > > > > > > > > > > > > > probably not what we > > > > > > > > > > > > > > > want. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > All true. This is why the WG decided to mak= e > this > > > the > > > > > > > > > > > > > > > > alternative behavior > > > > > > > > > > > > > > > and not the default behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Behavior that is broken is still broken regar= dless > of > > > > > whether > > > > > > > it > > > > > > > > > > > > > > > is alternative or default. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ?draft-templin-6man-linkadapt? attempts t= o > provide > > > > > > > guidance > > > > > > > > > > > > > > > > > to hosts on how to react to PTB messages = that > > > report a > > > > > > > small > > > > > > > > > size. > > > > > > > > > > > > > > > > > But, as of right now, > > > > > > > > > > > > > > > > > RFC2460 Section 5 is the normative behavi= or. > > > > > > > > > > > > > > > > [RPB] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Absolutely correct. The procedures describe= d in > > > Section > > > > > 5 or > > > > > > > > > > > > > > > > RFC > > > > > > > > > > > > > > > > 246 are > > > > > > > > > > > > > > > normative. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't how this impacts the WG's LC decisi= on > > > regarding > > > > > the > > > > > > > > > > > > > > > > current > > > > > > > > > > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Broken behavior should not be specified, whet= her > > > > > alternative > > > > > > > or > > > > > > > > > > > default. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks ? Fred > > > > > > > > > > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Int-area mailing list > > > > > > > > > Int-area@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 2 07:49:14 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077261A9147; Thu, 2 Apr 2015 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbf_TcziCFLf; Thu, 2 Apr 2015 07:49:11 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5761A9138; Thu, 2 Apr 2015 07:49:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t32EnAiC007613; Thu, 2 Apr 2015 09:49:11 -0500 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t32Emp3v006874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 2 Apr 2015 09:49:06 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-212.sw.nos.boeing.com ([169.254.12.72]) with mapi id 14.03.0210.002; Thu, 2 Apr 2015 07:49:03 -0700 From: "Templin, Fred L" To: "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCAAAhGi8AAB9x+QAACAahAAIAzugA== Date: Thu, 2 Apr 2015 14:49:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E30D40@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:49:13 -0000 Hi David, > > This is where we differ - there is nothing in this recommendation > > that is specific to GRE - the recommendation applies to any generic > > IPv6 encapsulation and is appropriate to only those use cases where > > shutting down the tunnel altogether is preferable to allowing the > > tunnel to fragment. This is a generic IPv6 encapsulation consideration; > > not a GRE consideration. >=20 > The "running code" involved here is GRE. I am concerned that we lack > the foundation to update 2473 for all encapsulated protocols. I don't get that. Just write a 3-pager that says it is OK for any kind of tunnel to collapse if it gets into a state where fragmentation is needed; a halt-and-catch-fire clause. But, why would you even need an RFC for that? Thanks - Fred fred.l.templin@boeing.com From nobody Thu Apr 2 08:08:05 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2381B2CC8; Thu, 2 Apr 2015 08:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X41pV03jUYo; Thu, 2 Apr 2015 08:08:02 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622CF1B2CC1; Thu, 2 Apr 2015 08:08:02 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t32F6H09011985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 08:06:28 -0700 (PDT) Message-ID: <551D5AE7.6050806@isi.edu> Date: Thu, 02 Apr 2015 08:06:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30D40@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E30D40@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:08:04 -0000 On 4/2/2015 7:49 AM, Templin, Fred L wrote: > Hi David, > >>> This is where we differ - there is nothing in this recommendation >>> that is specific to GRE - the recommendation applies to any generic >>> IPv6 encapsulation and is appropriate to only those use cases where >>> shutting down the tunnel altogether is preferable to allowing the >>> tunnel to fragment. This is a generic IPv6 encapsulation consideration; >>> not a GRE consideration. >> >> The "running code" involved here is GRE. I am concerned that we lack >> the foundation to update 2473 for all encapsulated protocols. > > I don't get that. Just write a 3-pager that says it is OK for any kind of > tunnel to collapse if it gets into a state where fragmentation is needed; > a halt-and-catch-fire clause. But, why would you even need an RFC for that? For the benefit of others, here's my view on this (as I posted to Fred yesterday, which is where collapsing the tunnel comes from): defs: ingress packet - what arrives at the tunnel ingress egress packet - what leaves at the tunnel egress tunnel packet - packet that traverses from the ingress to egress, that contains the ingress packet plus encapsulation tunnel MTU - MTU of the path between ingress and egress of tunneled packets reassembly MTU - largest tunnel packet that can be reassembled at the egress General rules (which apply to more than GRE; they should apply to ANY tunnel that carries ANY packet): ingress packet <= (tunnel MTU - encapsulation) send through the tunnel as one tunnel packet ingress packet > (reassembly MTU - encapsulation) drop and send ICMP PTB back (tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps) do one of the following: a) fragment at ingress and reassemble at egress b) drop and declare the link down to all further traffic until a probe of size "reassy MTU" succeeds to the egress (this is what Fred just called "halt and catch fire", but it has an important property: - stay down while the required tunnel MTU cannot traverse without fragmentation - come up when the required tunnel MTU is supported) (a) is more robust but more expensive to implement The tunnel MTU is defined by the protocols over which the tunnel is defined as transiting. The egress MTU is defined by the encapsulation protocol. Note: the (b) case is allowed because a link can always declare itself down. What it should never do is fail to transit packets that should fit while allowing other smaller packets to get through - i.e., a link should never be allowed to redefine the specs of the type of protocol link it intends to support. The rules are augmented a bit when the ingress packet can be re-fragmented: ingress packet <= (tunnel MTU - encapsulation) send through the tunnel as one tunnel packet ingress packet > (reassembly MTU - encapsulation) refragment the ingress packet to fit the tunnel MTU (tunnel MTU - encaps) < ingress packet <= (reassy MTU - encaps) do one of the following: a) fragment at ingress and reassemble at egress b) refragment the ingress packet to fit the tunnel MTU in this case, (b) is preferred --- From nobody Thu Apr 2 08:35:06 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59671B2D33; Thu, 2 Apr 2015 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1AB6XHaYpuX; Thu, 2 Apr 2015 08:35:02 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8081B2D2D; Thu, 2 Apr 2015 08:35:02 -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 t32FZ17J032610; Thu, 2 Apr 2015 08:35:01 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t32FYw4A032481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 2 Apr 2015 08:34:59 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.107]) with mapi id 14.03.0210.002; Thu, 2 Apr 2015 08:34:58 -0700 From: "Templin, Fred L" To: Joe Touch , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Thread-Index: AdBsIGaY/gSp6LdDRyOAYy9uht3UAwAZR72AAAMZN0AAANCb0AAIDWYgAALjyCAAAhGi8AAB9x+QAACAahAAIAzugAAPfLGAAA3hYcA= Date: Thu, 2 Apr 2015 15:34:57 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E30EAC@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E2F84E@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E2FA16@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E300C8@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30214@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E30D40@XCH-BLV-504.nw.nos.boeing.com> <551D5AE7.6050806@isi.edu> In-Reply-To: <551D5AE7.6050806@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:35:04 -0000 Hi Joe, It looks from your description that you have at least read Section 3.13 of draft-templin-aerolink, because there are many similarities. However, AERO is more comprehensive in the way it minimizes fragmentation and turns off fragmentation when it is no longer needed. AERO also allows larger packets through even if they are larger than the maximum size the egress is capable of reassembling. There is no reason the egress' maximum reassembly unit needs to be as large as the largest packet that can travers= e the tunnel in one piece. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, April 02, 2015 8:06 AM > To: Templin, Fred L; Black, David; int-area@ietf.org; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative= configuration >=20 >=20 >=20 > On 4/2/2015 7:49 AM, Templin, Fred L wrote: > > Hi David, > > > >>> This is where we differ - there is nothing in this recommendation > >>> that is specific to GRE - the recommendation applies to any generic > >>> IPv6 encapsulation and is appropriate to only those use cases where > >>> shutting down the tunnel altogether is preferable to allowing the > >>> tunnel to fragment. This is a generic IPv6 encapsulation consideratio= n; > >>> not a GRE consideration. > >> > >> The "running code" involved here is GRE. I am concerned that we lack > >> the foundation to update 2473 for all encapsulated protocols. > > > > I don't get that. Just write a 3-pager that says it is OK for any kind = of > > tunnel to collapse if it gets into a state where fragmentation is neede= d; > > a halt-and-catch-fire clause. But, why would you even need an RFC for t= hat? >=20 > For the benefit of others, here's my view on this (as I posted to Fred > yesterday, which is where collapsing the tunnel comes from): >=20 > defs: > ingress packet - what arrives at the tunnel ingress >=20 > egress packet - what leaves at the tunnel egress >=20 > tunnel packet - packet that traverses from the > ingress to egress, that contains > the ingress packet plus encapsulation >=20 > tunnel MTU - MTU of the path between ingress and egress > of tunneled packets >=20 > reassembly MTU - largest tunnel packet that can be > reassembled at the egress >=20 > General rules (which apply to more than GRE; they should apply to ANY > tunnel that carries ANY packet): >=20 > ingress packet <=3D (tunnel MTU - encapsulation) > send through the tunnel as one tunnel packet >=20 > ingress packet > (reassembly MTU - encapsulation) > drop and send ICMP PTB back >=20 > (tunnel MTU - encaps) < ingress packet <=3D (reassy MTU - encaps) > do one of the following: >=20 > a) fragment at ingress and reassemble at egress >=20 > b) drop and declare the link down to all further > traffic until a probe of size "reassy MTU" > succeeds to the egress >=20 > (this is what Fred just called "halt and catch fire", > but it has an important property: > - stay down while the required tunnel MTU > cannot traverse without fragmentation > - come up when the required tunnel MTU > is supported) >=20 > (a) is more robust but more expensive to implement >=20 > The tunnel MTU is defined by the protocols over which the tunnel is > defined as transiting. >=20 > The egress MTU is defined by the encapsulation protocol. >=20 > Note: the (b) case is allowed because a link can always declare itself > down. What it should never do is fail to transit packets that should fit > while allowing other smaller packets to get through - i.e., a link > should never be allowed to redefine the specs of the type of protocol > link it intends to support. >=20 > The rules are augmented a bit when the ingress packet can be re-fragmente= d: >=20 > ingress packet <=3D (tunnel MTU - encapsulation) > send through the tunnel as one tunnel packet >=20 > ingress packet > (reassembly MTU - encapsulation) > refragment the ingress packet to fit the tunnel MTU >=20 > (tunnel MTU - encaps) < ingress packet <=3D (reassy MTU - encaps) > do one of the following: > a) fragment at ingress and reassemble at egress >=20 > b) refragment the ingress packet to fit the tunnel MTU >=20 > in this case, (b) is preferred > --- >=20 From nobody Thu Apr 2 12:21:14 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297E81ACF60; Tue, 31 Mar 2015 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK_VNYZri6PP; Tue, 31 Mar 2015 12:02:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408781AD069; Tue, 31 Mar 2015 12:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49831; q=dns/txt; s=iport; t=1427828490; x=1429038090; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9m7GWleF0RUTuv5U53MJieKDbqi4knXBR80RT9Fs5Bw=; b=SOni5Cp6t/oORAqCuWWTBhiQlKy2427TTZ4Txx5ekLfyPTUU3VHlorTU d61UIVroRwV6yJ9udeq/qNCP8MHR9hZNhAX1Q7QTQV/9dK5YJ/0V0WImP B1q3OZ8G8sjaEcOijEOXr458ZWhj79LbjJxuvpgTldhcrpuMlh/wYxs3v 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CSCAC47RpV/40NJK1cgkNDUlwFgw/AMzwqBoFGAQmFcwKBRDgUAQEBAQEBAXyEFAEBAQMBAQEBIEsLBQsCAQgRBAEBASABBgMCAicLFAkIAgQBDQUOiBkIDbRtmRABAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymEFhEBTAQGAYJoL4EWBY5Tgg+BbIEyVIYDgR06gniMJINIIoICHIFQb4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,502,1422921600"; d="asc'?scan'208,217";a="137040806" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 31 Mar 2015 19:01:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2VJ1SrE023738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 19:01:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.130]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 14:01:28 -0500 From: "Carlos Pignataro (cpignata)" To: "Black, David" , Lucy yong Thread-Topic: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgAC9ARgAAFkw8AAAT40EAAAitxwAAB0qeAAArfCMAAy+K+A Date: Tue, 31 Mar 2015 19:01:13 +0000 Message-ID: <78DCD4FF-4030-4386-A0CA-7AA5FF1C2E4A@cisco.com> References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.15] Content-Type: multipart/signed; boundary="Apple-Mail=_7BF7AAB0-31FF-4750-A54E-8F0508E50AB0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 12:21:13 -0700 Cc: "Ronald P. Bonica" , "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "int-area@ietf.org" , "intarea-chairs@ietf.org" , "ipv6@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:02:15 -0000 --Apple-Mail=_7BF7AAB0-31FF-4750-A54E-8F0508E50AB0 Content-Type: multipart/alternative; boundary="Apple-Mail=_9DCCC290-D99B-463B-A0CD-3CA1223105B0" --Apple-Mail=_9DCCC290-D99B-463B-A0CD-3CA1223105B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Lucy, One approach is to add a 3.c) to the list that Ron shared. I think there = is another potential approach to your initial comment: we could note = that for a tunneling protocol (GRE), this is equivalent to the = relaxation of the UDP checksum in RFC 6935, and keep the existing text. Fred, RFC 2473 does not mention checksums. Thanks, Carlos. > On Mar 30, 2015, at 7:47 PM, Black, David wrote: >=20 > > Also, why would you object to 3b? The packet ends up at the right = node, just via an unexpected route. >=20 > That assertion is based on the assumption that the payload destination = address is worldwide unique. >=20 > There are lots of counterexamples that void the assumption, e.g., = 10.0.0.0/8. >=20 > Thanks, > --David >=20 > From: Lucy yong [mailto:lucy.yong@huawei.com = ] > Sent: Monday, March 30, 2015 6:31 PM > To: Ronald Bonica; Zuniga, Juan Carlos; int-area@ietf.org = ; ipv6@ietf.org ; Black, = David > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Hi Ron, >=20 > 3b) is the concern. GRE payload may be non-IP type. If a gre-in-ipv6 = tunnel is used for mux of different payload types, the outcome may be = unknown and can be unacceptable upon IP address and/or GRE header are = corrupted. >=20 > Lucy >=20 >=20 >=20 > From: Ronald Bonica [mailto:rbonica@juniper.net = ] > Sent: Monday, March 30, 2015 5:14 PM > To: Lucy yong; Zuniga, Juan Carlos; int-area@ietf.org = ; ipv6@ietf.org ; Black, = David > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Lucy, >=20 > Why would you object to 3a? Dropping the packet is the preferred = behavior? >=20 > Also, why would you object to 3b? The packet ends up at the right = node, just via an unexpected route. Recall that the destination address = in the payload header is protected by the UDP/TCP checksum. >=20 > Are you thinking that there might be a 3c)? >=20 > Ron >=20 >=20 > From: Lucy yong [mailto:lucy.yong@huawei.com = ] > Sent: Monday, March 30, 2015 6:05 PM > To: Ronald Bonica; Zuniga, Juan Carlos; int-area@ietf.org = ; ipv6@ietf.org ; Black, = David > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Hi Ron, >=20 > 1) and 2 ) are fine. IMO: 3) works under certain conditions but = not all. >=20 > I add David Black (TSVWG chair) to the thread. He can provide the = thorough check. >=20 > Regards, > Lucy >=20 > From: Ronald Bonica [mailto:rbonica@juniper.net = ] > Sent: Monday, March 30, 2015 4:49 PM > To: Lucy yong; Zuniga, Juan Carlos; int-area@ietf.org = ; ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Lucy, >=20 > Would the following text work? >=20 > OLD> > Because the IPv6 delivery header does not include a checksum of its > own, it is subject to corruption. However, even if the delivery > header is corrupted, to likelihood of that corruption resulting in > misdelivery of the payload is extremely low. > =20 > NEW> > Because the IPv6 delivery header does not include a checksum of its > own, the destination address in the delivery header is subject to > corruption. If the destination address in the deliver header is = corrupted, > the following outcomes are possible: >=20 > 1) The delivery packet is dropped because the new destination = address is unreachable > 2) The delivery packet is dropped because the new destination = address is reachable, but that node is not configured to process GRE = delivery packets from the ingress > 3) The delivery packet is processed by a GRE egress other than = that which was originally specified by the GRE ingress. Processing = options are: > a. The payload packet is dropped because the payload destination = is unreachable from the node that processed the delivery packet > b. The payload packet is delivered to its intended destination = because the payload destination is reachable from the node that = processed the delivery packet >=20 > All of these outcomes are acceptable. >=20 > =20 > Ron >=20 > From: Lucy yong [mailto:lucy.yong@huawei.com = ] > Sent: Monday, March 30, 2015 4:50 PM > To: Zuniga, Juan Carlos; int-area@ietf.org ; = ipv6@ietf.org > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Thanks authors to add section 4.1. >=20 > I am not sure if the statement of =E2=80=9CHowever, even if the = delivery header is corrupted, to likelihood of that corruption resulting = in misdelivery of the payload is extremely low.=E2=80=9D is proper. IPv6 = requires the end point/upper layer to deal with the header corruption. = Could we state that this is the difference from gre-in-ipv4 instead? >=20 > Lucy >=20 >=20 > From: Int-area [mailto:int-area-bounces@ietf.org = ] On Behalf Of Zuniga, Juan Carlos > Sent: Monday, March 30, 2015 3:27 PM > To: int-area@ietf.org ; ipv6@ietf.org = > Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org = ; = intarea-chairs@ietf.org > Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 >=20 > Dear Int-Area and 6man WGs, >=20 > At the Int-Area WG meeting in Dallas there were some comments on = draft-ietf-intarea-gre-ipv6. It was decided to submit the document for = WG Last Call to the Int-Area & 6man WGs as soon as the agreed changes = were made. >=20 > The document has now been updated accordingly, so this email starts an = Int-Area/6man WGs Last Call on: >=20 > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04 = >=20 > Please respond to this email to support the document and/or send = comments by 2015-04-06. >=20 > In addition, to satisfy RFC 6702 "Promoting Compliance with = Intellectual Property Rights (IPR)": > Are you personally aware of any IPR that applies to = draft-ietf-intarea-gre-ipv6? > If so, has this IPR been disclosed in compliance with IETF IPR rules? > (See RFCs 3979, 4879, 3669, and 5378 for more details.) >=20 > Best, >=20 > Juan Carlos Zuniga > (as Int-Area WG co-chair) >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_9DCCC290-D99B-463B-A0CD-3CA1223105B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Lucy,

One approach is to add a 3.c) to the list that Ron shared. I = think there is another potential approach to your initial comment: we = could note that for a tunneling protocol (GRE), this is equivalent to = the relaxation of the UDP checksum in RFC 6935, and keep the = existing text.

Fred, RFC 2473 does not mention checksums.

Thanks,

Carlos.

On Mar 30, 2015, at 7:47 PM, Black, David <david.black@emc.com>= wrote:

> Also, why would you object to 3b? The = packet ends up at the right node, just via an unexpected route.
 
That = assertion is based on the assumption that the payload destination = address is worldwide unique.
 
There are lots of = counterexamples that void the assumption, e.g., 10.0.0.0/8.
 
Thanks,
--David
 
From: Lucy yong [mailto:lucy.yong@huawei.com] 
Sent: Monday, March 30, 2015 6:31 = PM
To: Ronald Bonica; Zuniga, Juan = Carlos; int-area@ietf.org; ipv6@ietf.org; Black, = David
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for = draft-ietf-intarea-gre-ipv6
 
Hi = Ron,
 
3b) is the concern. GRE = payload may be non-IP type. If a gre-in-ipv6 tunnel is used for mux of = different payload types, the outcome may be unknown and can be = unacceptable upon IP address and/or GRE header are corrupted.
 
Lucy
 
 
 
From: Ronald Bonica [mailto:rbonica@juniper.net] 
Sent: Monday, March 30, 2015 5:14 = PM
To: Lucy yong; Zuniga, Juan = Carlos; int-area@ietf.org; ipv6@ietf.org; Black, = David
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for = draft-ietf-intarea-gre-ipv6
 
Lucy,
 
Why would you object to 3a? Dropping the packet is the = preferred behavior?
 
Also, why = would you object to 3b? The packet ends up at the right node, just via = an unexpected route. Recall that the destination address in the payload = header is protected by the UDP/TCP checksum.
 
Are you thinking that there might be a 3c)?
 
          &nb= sp;           Ron
 
 
From: Lucy yong [mailto:lucy.yong@huawei.com] 
Sent: Monday, March 30, 2015 6:05 = PM
To: Ronald Bonica; Zuniga, Juan = Carlos; int-area@ietf.org; ipv6@ietf.org; Black, = David
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for = draft-ietf-intarea-gre-ipv6
 
Hi Ron,
 
1)      and 2 ) are fine. IMO: 3) works under = certain conditions but not all.
 
I add = David Black (TSVWG chair) to the thread. He can provide the thorough = check.
 
Regards,
Lucy
 
From: Ronald Bonica [mailto:rbonica@juniper.net] 
Sent: Monday, March 30, 2015 4:49 = PM
To: Lucy yong; Zuniga, Juan = Carlos; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for = draft-ietf-intarea-gre-ipv6
 
Lucy,
 
Would the following text work?
 
OLD>
   Because the IPv6 delivery header does not = include a checksum of its
   own, it is subject to corruption.  = However, even if the delivery
   header is corrupted, to likelihood of = that corruption resulting in
   misdelivery of the payload is extremely = low.
<OLD
 
NEW>
   Because the IPv6 delivery header does not = include a checksum of its
   own,  the destination address in the = delivery header is subject to
   corruption. If the destination = address in the deliver header is corrupted,
   the following = outcomes are possible:
 
1)      The delivery packet is dropped because the = new destination address is unreachable
2)      The delivery packet is dropped because the = new destination address is reachable, but that node is not configured to = process GRE delivery packets from the ingress
3)      The delivery packet is processed by a GRE = egress other than that which was originally specified by the GRE = ingress. Processing options are:
a.       The payload packet is dropped because the = payload destination is unreachable from the node that processed the = delivery packet
b.      The payload packet is delivered to its = intended destination because the payload destination is reachable from = the node that processed the delivery packet
 
All of these outcomes are acceptable.
 
<NEW
 
          &nb= sp;            = ;   Ron
 
From: Lucy yong [mailto:lucy.yong@huawei.com] 
Sent: Monday, March 30, 2015 4:50 = PM
To: Zuniga, Juan Carlos; int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: RE: Start of WGLC for = draft-ietf-intarea-gre-ipv6
 
Thanks authors to add section 4.1.
 
I am not sure if the statement of =E2=80=9CHowever, even = if the delivery header is corrupted, to likelihood of that corruption = resulting in misdelivery of the payload is extremely low.=E2=80=9D is = proper. IPv6 requires the end point/upper layer to deal with the header = corruption. Could we state that this is the difference from gre-in-ipv4 = instead?
 
Lucy
 
 
From: Int-area = [mailto:int-area-bounces@ietf.org] On Behalf = Of Zuniga, Juan = Carlos
Sent: Monday, March 30, 2015 3:27 = PM
To: int-area@ietf.org; ipv6@ietf.org
Cc: draft-ietf-intarea-gre-ipv6@tools.ietf.org; intarea-chairs@ietf.org
Subject: [Int-area] Start of WGLC = for draft-ietf-intarea-gre-ipv6
 
Dear Int-Area and 6man WGs,
 
At the Int-Area WG meeting in Dallas = there were some comments on draft-ietf-intarea-gre-ipv6. It was decided = to submit the document for WG Last Call to the Int-Area & 6man WGs = as soon as the agreed changes were made.
 
The document has now been updated = accordingly, so this email starts an Int-Area/6man WGs Last Call on:
 
 
Please = respond to this email to support the document and/or send comments by = 2015-04-06.
 
In addition, to satisfy RFC 6702 "Promoting Compliance with = Intellectual Property Rights (IPR)":
Are you personally aware of any IPR = that applies to draft-ietf-intarea-gre-ipv6? 
If so, = has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs = 3979, 4879, 3669, and 5378 for more details.)
 
Best,
 
Juan = Carlos Zuniga 
(as = Int-Area WG co-chair)
 
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
=

= --Apple-Mail=_9DCCC290-D99B-463B-A0CD-3CA1223105B0-- --Apple-Mail=_7BF7AAB0-31FF-4750-A54E-8F0508E50AB0 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 iEYEARECAAYFAlUa7wkACgkQtfDPGTp3USyIIACffiYIDZDHjyD+mTl1dKCtWjng mkcAn2fKHqmPVnI/YqAakH3kWsipCAr9 =7tn3 -----END PGP SIGNATURE----- --Apple-Mail=_7BF7AAB0-31FF-4750-A54E-8F0508E50AB0-- From nobody Thu Apr 2 12:21:15 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529241A906E; Tue, 31 Mar 2015 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC6XMoJ4aUYN; Tue, 31 Mar 2015 12:07:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5E31A01F6; Tue, 31 Mar 2015 12:07:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQX48045; Tue, 31 Mar 2015 19:07:32 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Mar 2015 20:07:31 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 31 Mar 2015 12:07:18 -0700 From: Lucy yong To: "Carlos Pignataro (cpignata)" , "Black, David" Thread-Topic: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgAC9ARgAAFkw8AAAT40EAAAitxwAAB0qeAAArfCMAAy+K+AAApXc7A= Date: Tue, 31 Mar 2015 19:07:18 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57155576@dfweml701-chm> References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> <78DCD4FF-4030-4386-A0CA-7AA5FF1C2E4A@cisco.com> In-Reply-To: <78DCD4FF-4030-4386-A0CA-7AA5FF1C2E4A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.181] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57155576dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 12:21:12 -0700 Cc: "Ronald P. Bonica" , "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "int-area@ietf.org" , "intarea-chairs@ietf.org" , "ipv6@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:07:39 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57155576dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpJIGFtIG5vdCBjbGVhciB3aGF0IHlvdSBwcm9wb3NlLiBVRFAgY2hlY2tz dW0gaW5jbHVkZXMgSVAgaGVhZGVyLiBHUkUgZG9lcyBub3QuDQoNCkx1Y3kNCg0KRnJvbTogQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KU2Vu dDogVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgMjowMSBQTQ0KVG86IEJsYWNrLCBEYXZpZDsgTHVj eSB5b25nDQpDYzogUm9uYWxkIFAuIEJvbmljYTsgaW50LWFyZWFAaWV0Zi5vcmc7IGlwdjZAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzsgaW50YXJl YS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIFN0YXJ0IG9mIFdHTEMg Zm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ng0KDQpIaSwgTHVjeSwNCg0KT25lIGFwcHJv YWNoIGlzIHRvIGFkZCBhIDMuYykgdG8gdGhlIGxpc3QgdGhhdCBSb24gc2hhcmVkLiBJIHRoaW5r IHRoZXJlIGlzIGFub3RoZXIgcG90ZW50aWFsIGFwcHJvYWNoIHRvIHlvdXIgaW5pdGlhbCBjb21t ZW50OiB3ZSBjb3VsZCBub3RlIHRoYXQgZm9yIGEgdHVubmVsaW5nIHByb3RvY29sIChHUkUpLCB0 aGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlIHJlbGF4YXRpb24gb2YgdGhlIFVEUCBjaGVja3N1bSBp biBSRkMgNjkzNSwgYW5kIGtlZXAgdGhlIGV4aXN0aW5nIHRleHQuDQoNCkZyZWQsIFJGQyAyNDcz IGRvZXMgbm90IG1lbnRpb24gY2hlY2tzdW1zLg0KDQpUaGFua3MsDQoNCkNhcmxvcy4NCg0KT24g TWFyIDMwLCAyMDE1LCBhdCA3OjQ3IFBNLCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5j b208bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+PiB3cm90ZToNCg0KPiBBbHNvLCB3aHkgd291 bGQgeW91IG9iamVjdCB0byAzYj8gVGhlIHBhY2tldCBlbmRzIHVwIGF0IHRoZSByaWdodCBub2Rl LCBqdXN0IHZpYSBhbiB1bmV4cGVjdGVkIHJvdXRlLg0KDQpUaGF0IGFzc2VydGlvbiBpcyBiYXNl ZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBwYXlsb2FkIGRlc3RpbmF0aW9uIGFkZHJlc3Mg aXMgd29ybGR3aWRlIHVuaXF1ZS4NCg0KVGhlcmUgYXJlIGxvdHMgb2YgY291bnRlcmV4YW1wbGVz IHRoYXQgdm9pZCB0aGUgYXNzdW1wdGlvbiwgZS5nLiwgMTAuMC4wLjAvOC4NCg0KVGhhbmtzLA0K LS1EYXZpZA0KDQpGcm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbV0N ClNlbnQ6IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNjozMSBQTQ0KVG86IFJvbmFsZCBCb25pY2E7 IFp1bmlnYSwgSnVhbiBDYXJsb3M7IGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJlYUBp ZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+OyBCbGFjaywgRGF2 aWQNCkNjOiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZz47IGludGFyZWEtY2hh aXJzQGlldGYub3JnPG1haWx0bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYNCg0KSGkgUm9u LA0KDQozYikgaXMgdGhlIGNvbmNlcm4uIEdSRSBwYXlsb2FkIG1heSBiZSBub24tSVAgdHlwZS4g SWYgYSBncmUtaW4taXB2NiB0dW5uZWwgaXMgdXNlZCBmb3IgbXV4IG9mIGRpZmZlcmVudCBwYXls b2FkIHR5cGVzLCB0aGUgb3V0Y29tZSBtYXkgYmUgdW5rbm93biBhbmQgY2FuIGJlIHVuYWNjZXB0 YWJsZSB1cG9uIElQIGFkZHJlc3MgYW5kL29yIEdSRSBoZWFkZXIgYXJlIGNvcnJ1cHRlZC4NCg0K THVjeQ0KDQoNCg0KRnJvbTogUm9uYWxkIEJvbmljYSBbbWFpbHRvOnJib25pY2FAanVuaXBlci5u ZXRdDQpTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDU6MTQgUE0NClRvOiBMdWN5IHlvbmc7 IFp1bmlnYSwgSnVhbiBDYXJsb3M7IGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJlYUBp ZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+OyBCbGFjaywgRGF2 aWQNCkNjOiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZz47IGludGFyZWEtY2hh aXJzQGlldGYub3JnPG1haWx0bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYNCg0KTHVjeSwN Cg0KV2h5IHdvdWxkIHlvdSBvYmplY3QgdG8gM2E/IERyb3BwaW5nIHRoZSBwYWNrZXQgaXMgdGhl IHByZWZlcnJlZCBiZWhhdmlvcj8NCg0KQWxzbywgd2h5IHdvdWxkIHlvdSBvYmplY3QgdG8gM2I/ IFRoZSBwYWNrZXQgZW5kcyB1cCBhdCB0aGUgcmlnaHQgbm9kZSwganVzdCB2aWEgYW4gdW5leHBl Y3RlZCByb3V0ZS4gUmVjYWxsIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gdGhlIHBh eWxvYWQgaGVhZGVyIGlzIHByb3RlY3RlZCBieSB0aGUgVURQL1RDUCBjaGVja3N1bS4NCg0KQXJl IHlvdSB0aGlua2luZyB0aGF0IHRoZXJlIG1pZ2h0IGJlIGEgM2MpPw0KDQogICAgICAgICAgICAg ICAgICAgICAgUm9uDQoNCg0KRnJvbTogTHVjeSB5b25nIFttYWlsdG86bHVjeS55b25nQGh1YXdl aS5jb21dDQpTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1IDY6MDUgUE0NClRvOiBSb25hbGQg Qm9uaWNhOyBadW5pZ2EsIEp1YW4gQ2FybG9zOyBpbnQtYXJlYUBpZXRmLm9yZzxtYWlsdG86aW50 LWFyZWFAaWV0Zi5vcmc+OyBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPjsgQmxh Y2ssIERhdmlkDQpDYzogZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc+OyBpbnRh cmVhLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2DQoN CkhpIFJvbiwNCg0KMSkgICAgICBhbmQgMiApIGFyZSBmaW5lLiBJTU86IDMpIHdvcmtzIHVuZGVy IGNlcnRhaW4gY29uZGl0aW9ucyBidXQgbm90IGFsbC4NCg0KSSBhZGQgRGF2aWQgQmxhY2sgKFRT VldHIGNoYWlyKSB0byB0aGUgdGhyZWFkLiBIZSBjYW4gcHJvdmlkZSB0aGUgdGhvcm91Z2ggY2hl Y2suDQoNClJlZ2FyZHMsDQpMdWN5DQoNCkZyb206IFJvbmFsZCBCb25pY2EgW21haWx0bzpyYm9u aWNhQGp1bmlwZXIubmV0XQ0KU2VudDogTW9uZGF5LCBNYXJjaCAzMCwgMjAxNSA0OjQ5IFBNDQpU bzogTHVjeSB5b25nOyBadW5pZ2EsIEp1YW4gQ2FybG9zOyBpbnQtYXJlYUBpZXRmLm9yZzxtYWls dG86aW50LWFyZWFAaWV0Zi5vcmc+OyBpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3Jn Pg0KQ2M6IGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnPjsgaW50YXJlYS1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOmludGFyZWEtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFN0YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ng0KDQpMdWN5LA0K DQpXb3VsZCB0aGUgZm9sbG93aW5nIHRleHQgd29yaz8NCg0KT0xEPg0KICAgQmVjYXVzZSB0aGUg SVB2NiBkZWxpdmVyeSBoZWFkZXIgZG9lcyBub3QgaW5jbHVkZSBhIGNoZWNrc3VtIG9mIGl0cw0K ICAgb3duLCBpdCBpcyBzdWJqZWN0IHRvIGNvcnJ1cHRpb24uICBIb3dldmVyLCBldmVuIGlmIHRo ZSBkZWxpdmVyeQ0KICAgaGVhZGVyIGlzIGNvcnJ1cHRlZCwgdG8gbGlrZWxpaG9vZCBvZiB0aGF0 IGNvcnJ1cHRpb24gcmVzdWx0aW5nIGluDQogICBtaXNkZWxpdmVyeSBvZiB0aGUgcGF5bG9hZCBp cyBleHRyZW1lbHkgbG93Lg0KPE9MRA0KDQpORVc+DQogICBCZWNhdXNlIHRoZSBJUHY2IGRlbGl2 ZXJ5IGhlYWRlciBkb2VzIG5vdCBpbmNsdWRlIGEgY2hlY2tzdW0gb2YgaXRzDQogICBvd24sICB0 aGUgZGVzdGluYXRpb24gYWRkcmVzcyBpbiB0aGUgZGVsaXZlcnkgaGVhZGVyIGlzIHN1YmplY3Qg dG8NCiAgIGNvcnJ1cHRpb24uIElmIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBkZWxp dmVyIGhlYWRlciBpcyBjb3JydXB0ZWQsDQogICB0aGUgZm9sbG93aW5nIG91dGNvbWVzIGFyZSBw b3NzaWJsZToNCg0KMSkgICAgICBUaGUgZGVsaXZlcnkgcGFja2V0IGlzIGRyb3BwZWQgYmVjYXVz ZSB0aGUgbmV3IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgdW5yZWFjaGFibGUNCjIpICAgICAgVGhl IGRlbGl2ZXJ5IHBhY2tldCBpcyBkcm9wcGVkIGJlY2F1c2UgdGhlIG5ldyBkZXN0aW5hdGlvbiBh ZGRyZXNzIGlzIHJlYWNoYWJsZSwgYnV0IHRoYXQgbm9kZSBpcyBub3QgY29uZmlndXJlZCB0byBw cm9jZXNzIEdSRSBkZWxpdmVyeSBwYWNrZXRzIGZyb20gdGhlIGluZ3Jlc3MNCjMpICAgICAgVGhl IGRlbGl2ZXJ5IHBhY2tldCBpcyBwcm9jZXNzZWQgYnkgYSBHUkUgZWdyZXNzIG90aGVyIHRoYW4g dGhhdCB3aGljaCB3YXMgb3JpZ2luYWxseSBzcGVjaWZpZWQgYnkgdGhlIEdSRSBpbmdyZXNzLiBQ cm9jZXNzaW5nIG9wdGlvbnMgYXJlOg0KYS4gICAgICAgVGhlIHBheWxvYWQgcGFja2V0IGlzIGRy b3BwZWQgYmVjYXVzZSB0aGUgcGF5bG9hZCBkZXN0aW5hdGlvbiBpcyB1bnJlYWNoYWJsZSBmcm9t IHRoZSBub2RlIHRoYXQgcHJvY2Vzc2VkIHRoZSBkZWxpdmVyeSBwYWNrZXQNCmIuICAgICAgVGhl IHBheWxvYWQgcGFja2V0IGlzIGRlbGl2ZXJlZCB0byBpdHMgaW50ZW5kZWQgZGVzdGluYXRpb24g YmVjYXVzZSB0aGUgcGF5bG9hZCBkZXN0aW5hdGlvbiBpcyByZWFjaGFibGUgZnJvbSB0aGUgbm9k ZSB0aGF0IHByb2Nlc3NlZCB0aGUgZGVsaXZlcnkgcGFja2V0DQoNCkFsbCBvZiB0aGVzZSBvdXRj b21lcyBhcmUgYWNjZXB0YWJsZS4NCg0KPE5FVw0KDQogICAgICAgICAgICAgICAgICAgICAgICAg IFJvbg0KDQpGcm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbV0NClNl bnQ6IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDo1MCBQTQ0KVG86IFp1bmlnYSwgSnVhbiBDYXJs b3M7IGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJlYUBpZXRmLm9yZz47IGlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1p cHY2QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9v bHMuaWV0Zi5vcmc+OyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aW50YXJlYS1jaGFp cnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1p bnRhcmVhLWdyZS1pcHY2DQoNClRoYW5rcyBhdXRob3JzIHRvIGFkZCBzZWN0aW9uIDQuMS4NCg0K SSBhbSBub3Qgc3VyZSBpZiB0aGUgc3RhdGVtZW50IG9mIOKAnEhvd2V2ZXIsIGV2ZW4gaWYgdGhl IGRlbGl2ZXJ5IGhlYWRlciBpcyBjb3JydXB0ZWQsIHRvIGxpa2VsaWhvb2Qgb2YgdGhhdCBjb3Jy dXB0aW9uIHJlc3VsdGluZyBpbiBtaXNkZWxpdmVyeSBvZiB0aGUgcGF5bG9hZCBpcyBleHRyZW1l bHkgbG93LuKAnSBpcyBwcm9wZXIuIElQdjYgcmVxdWlyZXMgdGhlIGVuZCBwb2ludC91cHBlciBs YXllciB0byBkZWFsIHdpdGggdGhlIGhlYWRlciBjb3JydXB0aW9uLiBDb3VsZCB3ZSBzdGF0ZSB0 aGF0IHRoaXMgaXMgdGhlIGRpZmZlcmVuY2UgZnJvbSBncmUtaW4taXB2NCBpbnN0ZWFkPw0KDQpM dWN5DQoNCg0KRnJvbTogSW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgWnVuaWdhLCBKdWFuIENhcmxvcw0KU2VudDogTW9uZGF5LCBNYXJjaCAz MCwgMjAxNSAzOjI3IFBNDQpUbzogaW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGll dGYub3JnPjsgaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkNjOiBkcmFmdC1p ZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaW50 YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZz47IGludGFyZWEtY2hhaXJzQGlldGYub3JnPG1h aWx0bzppbnRhcmVhLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtJbnQtYXJlYV0gU3RhcnQg b2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2DQoNCkRlYXIgSW50LUFyZWEg YW5kIDZtYW4gV0dzLA0KDQpBdCB0aGUgSW50LUFyZWEgV0cgbWVldGluZyBpbiBEYWxsYXMgdGhl cmUgd2VyZSBzb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni4gSXQg d2FzIGRlY2lkZWQgdG8gc3VibWl0IHRoZSBkb2N1bWVudCBmb3IgV0cgTGFzdCBDYWxsIHRvIHRo ZSBJbnQtQXJlYSAmIDZtYW4gV0dzIGFzIHNvb24gYXMgdGhlIGFncmVlZCBjaGFuZ2VzIHdlcmUg bWFkZS4NCg0KVGhlIGRvY3VtZW50IGhhcyBub3cgYmVlbiB1cGRhdGVkIGFjY29yZGluZ2x5LCBz byB0aGlzIGVtYWlsIHN0YXJ0cyBhbiBJbnQtQXJlYS82bWFuIFdHcyBMYXN0IENhbGwgb246DQoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni0w NA0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHRvIHN1cHBvcnQgdGhlIGRvY3VtZW50 IGFuZC9vciBzZW5kIGNvbW1lbnRzIGJ5IDIwMTUtMDQtMDYuDQoNCkluIGFkZGl0aW9uLCB0byBz YXRpc2Z5IFJGQyA2NzAyICJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVhbCBQ cm9wZXJ0eSBSaWdodHMgKElQUikiOg0KQXJlIHlvdSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJ UFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Nj8NCklmIHNvLCBo YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzPw0KKFNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjksIGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp bHMuKQ0KDQpCZXN0LA0KDQpKdWFuIENhcmxvcyBadW5pZ2ENCihhcyBJbnQtQXJlYSBXRyBjby1j aGFpcikNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkludC1hcmVhIG1haWxpbmcgbGlzdA0KSW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOkludC1hcmVh QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJl YQ0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D57155576dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgQ2FybG9zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3QgY2xlYXIgd2hhdCB5b3UgcHJvcG9zZS4g VURQIGNoZWNrc3VtIGluY2x1ZGVzIElQIGhlYWRlci4gR1JFIGRvZXMgbm90Lg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5MdWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFtt YWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1h cmNoIDMxLCAyMDE1IDI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZDsgTHVjeSB5 b25nPGJyPg0KPGI+Q2M6PC9iPiBSb25hbGQgUC4gQm9uaWNhOyBpbnQtYXJlYUBpZXRmLm9yZzsg aXB2NkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3Jn OyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ludC1h cmVhXSBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgTHVjeSw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBhcHByb2FjaCBpcyB0 byBhZGQgYSAzLmMpIHRvIHRoZSBsaXN0IHRoYXQgUm9uIHNoYXJlZC4gSSB0aGluayB0aGVyZSBp cyBhbm90aGVyIHBvdGVudGlhbCBhcHByb2FjaCB0byB5b3VyIGluaXRpYWwgY29tbWVudDogd2Ug Y291bGQgbm90ZSB0aGF0IGZvciBhIHR1bm5lbGluZyBwcm90b2NvbCAoR1JFKSwgdGhpcyBpcyBl cXVpdmFsZW50IHRvIHRoZSByZWxheGF0aW9uIG9mIHRoZSBVRFAgY2hlY2tzdW0NCiBpbiBSRkMm bmJzcDs2OTM1LCBhbmQga2VlcCB0aGUgZXhpc3RpbmcgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJlZCwgUkZDIDI0NzMgZG9lcyBu b3QgbWVudGlvbiBjaGVja3N1bXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FybG9zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDMwLCAyMDE1LCBhdCA3OjQ3IFBN LCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIj5k YXZpZC5ibGFja0BlbWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIHdoeSB3b3VsZCB5b3Ugb2JqZWN0IHRvIDNiPyBU aGUgcGFja2V0IGVuZHMNCiB1cCBhdCB0aGUgcmlnaHQgbm9kZSwganVzdCB2aWEgYW4gdW5leHBl Y3RlZCByb3V0ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlRoYXQgYXNzZXJ0aW9uIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHBheWxv YWQgZGVzdGluYXRpb24gYWRkcmVzcyBpcyB3b3JsZHdpZGUgdW5pcXVlLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlcmUgYXJlIGxvdHMgb2YgY291bnRl cmV4YW1wbGVzIHRoYXQgdm9pZCB0aGUgYXNzdW1wdGlvbiwgZS5nLiwgMTAuMC4wLjAvOC48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ VGhhbmtzLDxicj4NCi0tRGF2aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+THVjeQ0KIHlvbmcgWzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPm1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbTwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+TW9uZGF5LCBNYXJjaCAzMCwgMjAxNSA2OjMxIFBNPGJyPg0KPGI+VG86PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Sb25hbGQg Qm9uaWNhOyBadW5pZ2EsIEp1YW4gQ2FybG9zOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pbnQtYXJlYUBpZXRmLm9yZzwvc3Bhbj48L2E+Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86aXB2NkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmlwdjZAaWV0 Zi5vcmc8L3NwYW4+PC9hPjsNCiBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjojOTU0RjcyIj5kcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8 L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmludGFyZWEtY2hhaXJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SRTogU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvbiw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjNiKSBpcyB0aGUgY29uY2Vybi4gR1JFIHBheWxvYWQg bWF5IGJlIG5vbi1JUCB0eXBlLiBJZiBhIGdyZS1pbi1pcHY2IHR1bm5lbCBpcyB1c2VkIGZvciBt dXggb2YgZGlmZmVyZW50IHBheWxvYWQgdHlwZXMsIHRoZSBvdXRjb21lIG1heSBiZSB1bmtub3du IGFuZCBjYW4gYmUNCiB1bmFjY2VwdGFibGUgdXBvbiBJUCBhZGRyZXNzIGFuZC9vciBHUkUgaGVh ZGVyIGFyZSBjb3JydXB0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5MdWN5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlJvbmFsZA0KIEJvbmljYSBbPGEgaHJlZj0ibWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQi PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5tYWlsdG86cmJvbmljYUBqdW5pcGVyLm5ldDwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+TW9uZGF5LCBNYXJjaCAzMCwgMjAxNSA1OjE0IFBNPGJyPg0KPGI+VG86PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5MdWN5IHlv bmc7IFp1bmlnYSwgSnVhbiBDYXJsb3M7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnQtYXJlYUBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPmludC1hcmVhQGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzppcHY2QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aXB2NkBpZXRmLm9y Zzwvc3Bhbj48L2E+Ow0KIEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5NTRGNzIiPmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzwvc3Bh bj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjojOTU0RjcyIj5pbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJFOiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjY8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+THVjeSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldoeSB3b3VsZCB5b3Ugb2JqZWN0IHRvIDNhPyBEcm9wcGluZyB0 aGUgcGFja2V0IGlzIHRoZSBwcmVmZXJyZWQgYmVoYXZpb3I/PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvLCB3aHkgd291bGQgeW91IG9i amVjdCB0byAzYj8gVGhlIHBhY2tldCBlbmRzIHVwIGF0IHRoZSByaWdodCBub2RlLCBqdXN0IHZp YSBhbiB1bmV4cGVjdGVkIHJvdXRlLiBSZWNhbGwgdGhhdCB0aGUgZGVzdGluYXRpb24gYWRkcmVz cyBpbiB0aGUgcGF5bG9hZCBoZWFkZXINCiBpcyBwcm90ZWN0ZWQgYnkgdGhlIFVEUC9UQ1AgY2hl Y2tzdW0uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BcmUgeW91IHRoaW5raW5nIHRoYXQgdGhlcmUgbWlnaHQgYmUgYSAzYyk/PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUm9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkx1Y3kNCiB5b25nIFs8 YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjoj OTU0RjcyIj5tYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwg TWFyY2ggMzAsIDIwMTUgNjowNSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Um9uYWxkIEJvbmljYTsgWnVuaWdhLCBKdWFu IENhcmxvczs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmludC1hcmVhQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1 NEY3MiI+aW50LWFyZWFAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pcHY2QGlldGYub3JnPC9zcGFuPjwvYT47DQog QmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pbnRhcmVhLWdy ZS1pcHY2QHRvb2xzLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ZHJhZnQt aWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpp bnRhcmVhLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmludGFy ZWEtY2hhaXJzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFN0YXJ0IG9mIFdH TEMgZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb24sPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hbmQNCiAyICkgYXJlIGZpbmUuIElNTzog Mykgd29ya3MgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zIGJ1dCBub3QgYWxsLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZGQgRGF2aWQgQmxhY2sg KFRTVldHIGNoYWlyKSB0byB0aGUgdGhyZWFkLiBIZSBjYW4gcHJvdmlkZSB0aGUgdGhvcm91Z2gg Y2hlY2suPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Sb25hbGQNCiBCb25pY2EgWzxhIGhyZWY9Im1haWx0bzpyYm9u aWNhQGp1bmlwZXIubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bWFpbHRvOnJib25p Y2FAanVuaXBlci5uZXQ8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDo0OSBQ TTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+THVjeSB5b25nOyBadW5pZ2EsIEp1YW4gQ2FybG9zOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW50LWFyZWFA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pbnQtYXJlYUBpZXRmLm9yZzwv c3Bhbj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRG NzIiPmlwdjZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5NTRGNzIiPmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzwvc3Bh bj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjojOTU0RjcyIj5pbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJFOiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjY8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+THVjeSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldvdWxkIHRoZSBmb2xsb3dpbmcgdGV4dCB3b3JrPzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEJmd0Ozwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgQmVjYXVzZSB0aGUgSVB2NiBkZWxp dmVyeSBoZWFkZXIgZG9lcyBub3QgaW5jbHVkZSBhIGNoZWNrc3VtIG9mIGl0czwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb3duLCBpdCBpcyBzdWJqZWN0IHRvIGNvcnJ1cHRp b24uJm5ic3A7IEhvd2V2ZXIsIGV2ZW4gaWYgdGhlIGRlbGl2ZXJ5PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBoZWFkZXIgaXMgY29ycnVwdGVkLCB0byBsaWtlbGlob29kIG9m IHRoYXQgY29ycnVwdGlvbiByZXN1bHRpbmcgaW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IG1pc2RlbGl2ZXJ5IG9mIHRoZSBwYXlsb2FkIGlzIGV4dHJlbWVseSBsb3cuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtPTEQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5FVyZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7IEJlY2F1c2UgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyIGRvZXMgbm90 IGluY2x1ZGUgYSBjaGVja3N1bSBvZiBpdHM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IG93biwgJm5ic3A7dGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gdGhlIGRlbGl2ZXJ5 IGhlYWRlciBpcyBzdWJqZWN0IHRvPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwO2NvcnJ1cHRpb24uIElmIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBkZWxp dmVyIGhlYWRlciBpcyBjb3JydXB0ZWQsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyB0aGUgZm9sbG93aW5nIG91dGNvbWVzIGFyZSBwb3NzaWJsZTo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUNCiBkZWxp dmVyeSBwYWNrZXQgaXMgZHJvcHBlZCBiZWNhdXNlIHRoZSBuZXcgZGVzdGluYXRpb24gYWRkcmVz cyBpcyB1bnJlYWNoYWJsZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIpPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlDQogZGVs aXZlcnkgcGFja2V0IGlzIGRyb3BwZWQgYmVjYXVzZSB0aGUgbmV3IGRlc3RpbmF0aW9uIGFkZHJl c3MgaXMgcmVhY2hhYmxlLCBidXQgdGhhdCBub2RlIGlzIG5vdCBjb25maWd1cmVkIHRvIHByb2Nl c3MgR1JFIGRlbGl2ZXJ5IHBhY2tldHMgZnJvbSB0aGUgaW5ncmVzczwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlDQogZGVsaXZlcnkgcGFja2V0IGlzIHByb2Nlc3NlZCBieSBhIEdS RSBlZ3Jlc3Mgb3RoZXIgdGhhbiB0aGF0IHdoaWNoIHdhcyBvcmlnaW5hbGx5IHNwZWNpZmllZCBi eSB0aGUgR1JFIGluZ3Jlc3MuIFByb2Nlc3Npbmcgb3B0aW9ucyBhcmU6PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjI1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlDQogcGF5bG9hZCBwYWNrZXQgaXMgZHJvcHBlZCBi ZWNhdXNlIHRoZSBwYXlsb2FkIGRlc3RpbmF0aW9uIGlzIHVucmVhY2hhYmxlIGZyb20gdGhlIG5v ZGUgdGhhdCBwcm9jZXNzZWQgdGhlIGRlbGl2ZXJ5IHBhY2tldDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4yNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZQ0KIHBheWxvYWQgcGFja2V0IGlzIGRlbGl2ZXJlZCB0byBpdHMgaW50 ZW5kZWQgZGVzdGluYXRpb24gYmVjYXVzZSB0aGUgcGF5bG9hZCBkZXN0aW5hdGlvbiBpcyByZWFj aGFibGUgZnJvbSB0aGUgbm9kZSB0aGF0IHByb2Nlc3NlZCB0aGUgZGVsaXZlcnkgcGFja2V0PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbGwg b2YgdGhlc2Ugb3V0Y29tZXMgYXJlIGFjY2VwdGFibGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7TkVXPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUm9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+THVjeQ0KIHlvbmcgWzxhIGhyZWY9Im1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPm1haWx0bzps dWN5LnlvbmdAaHVhd2VpLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBNYXJjaCAzMCwgMjAxNSA0 OjUwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5adW5pZ2EsIEp1YW4gQ2FybG9zOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pbnQtYXJlYUBpZXRmLm9yZzwvc3Bhbj48 L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmlw djZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt aW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRG NzIiPmRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+ OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0 RjcyIj5pbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBT dGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGF1dGhvcnMgdG8gYWRkIHNlY3Rp b24gNC4xLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhbSBub3Qgc3VyZSBpZiB0aGUgc3RhdGVtZW50IG9mIOKAnDwvc3Bhbj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGV2 ZW4gaWYgdGhlIGRlbGl2ZXJ5DQogaGVhZGVyIGlzIGNvcnJ1cHRlZCwgdG8gbGlrZWxpaG9vZCBv ZiB0aGF0IGNvcnJ1cHRpb24gcmVzdWx0aW5nIGluIG1pc2RlbGl2ZXJ5IG9mIHRoZSBwYXlsb2Fk IGlzIGV4dHJlbWVseSBsb3cu4oCdIGlzIHByb3Blci4gSVB2NiByZXF1aXJlcyB0aGUgZW5kIHBv aW50L3VwcGVyIGxheWVyIHRvIGRlYWwgd2l0aCB0aGUgaGVhZGVyIGNvcnJ1cHRpb24uIENvdWxk IHdlIHN0YXRlIHRoYXQgdGhpcyBpcyB0aGUgZGlmZmVyZW5jZSBmcm9tIGdyZS1pbi1pcHY0DQog aW5zdGVhZD88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+THVjeTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkludC1hcmVhDQogWzxhIGhy ZWY9Im1haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+bWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxm IE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5a dW5pZ2EsIEp1YW4gQ2FybG9zPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgTWFyY2ggMzAsIDIwMTUgMzoyNyBQ TTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludC1hcmVhQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aW50LWFyZWFAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlwdjZA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pcHY2QGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZA dG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5kcmFmdC1pZXRmLWlu dGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludGFyZWEt Y2hhaXJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aW50YXJlYS1jaGFp cnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bSW50LWFyZWFdIFN0YXJ0IG9mIFdH TEMgZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Njwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGVhciBJbnQtQXJlYSBh bmQgNm1hbiBXR3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0IHRoZSBJbnQtQXJlYSBXRyBtZWV0aW5nIGluIERh bGxhcyB0aGVyZSB3ZXJlIHNvbWUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1p cHY2LiBJdCB3YXMgZGVjaWRlZCB0byBzdWJtaXQgdGhlIGRvY3VtZW50IGZvciBXRyBMYXN0IENh bGwgdG8gdGhlIEludC1BcmVhICZhbXA7IDZtYW4NCiBXR3MgYXMgc29vbiBhcyB0aGUgYWdyZWVk IGNoYW5nZXMgd2VyZSBtYWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgZG9jdW1lbnQgaGFzIG5vdyBiZWVu IHVwZGF0ZWQgYWNjb3JkaW5nbHksIHNvIHRoaXMgZW1haWwgc3RhcnRzIGFuIEludC1BcmVhLzZt YW4gV0dzIExhc3QgQ2FsbCBvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2LTA0Ij48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRh cmVhLWdyZS1pcHY2LTA0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxlYXNlIHJlc3BvbmQgdG8g dGhpcyBlbWFpbCB0byBzdXBwb3J0IHRoZSBkb2N1bWVudCBhbmQvb3Igc2VuZCBjb21tZW50cyBi eSAyMDE1LTA0LTA2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBhZGRpdGlvbiwgdG8gc2F0aXNmeSBSRkMgNjcw MiAmcXVvdDtQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBS aWdodHMgKElQUikmcXVvdDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcmUgeW91 IHBlcnNvbmFsbHkgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1p bnRhcmVhLWdyZS1pcHY2PyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYg c28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4oU2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSwgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscy4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3Qs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkp1YW4gQ2FybG9zIFp1bmlnYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihh cyBJbnQtQXJlYSBXRyBjby1jaGFpcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJbnQtYXJl YSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SW50LWFyZWFAaWV0Zi5vcmciPklu dC1hcmVhQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaW50LWFyZWEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaW50LWFyZWE8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D57155576dfweml701chm_-- From nobody Thu Apr 2 12:21:16 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705B41A872E for ; Tue, 31 Mar 2015 16:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0ku0g-lIJVr for ; Tue, 31 Mar 2015 16:50:05 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id A79651A6F02 for ; Tue, 31 Mar 2015 16:50:05 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 31 Mar 2015 18:50:04 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f170.google.com [209.85.213.170] #+LO+TS+TR X-Umn-Classification: local Received: by igbqf9 with SMTP id qf9so32120013igb.1 for ; Tue, 31 Mar 2015 16:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h2G9KDqT/YmZPTwZATTs6Y6zQ3PhWhvi3U8Et2Wdt+A=; b=Y/bF70qjHmtxHbybv866NDPuAR0Hw7ePhPl5FAv49nTDJeea8Chdq7HgKQLOOhtu22 sIUf8cppgESq1lBC33riiZ+hp01c+rBDJ0dsCIiNc8nTC86VnFlE4ltEaPm4CuCxO/fT sgBvctegUih1GKFM8D8vcTTlSbtqoWDd67FVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=h2G9KDqT/YmZPTwZATTs6Y6zQ3PhWhvi3U8Et2Wdt+A=; b=VRmEKC7BEipIv/dM3dVgyisp67D+++OqM40YOHkkC7yAmMTxlFct9EaHEBCt+M7xLX WOE5vf4nd5dm8WCZelW0TyjUP7MTh2GizuoFieGx/aZLQ1RLcyNJRBEurqgqZlDvauhX rXNhROEPM8yG7g73fEOaL2/BpIoV6EymSuKMGQIl8QD4JgTJoRZWGF6Xx5cUFq8v95lb e1JNEXQ7YnKgtrVQlVvBra0izRHHhTZOkgeWD12Ap6B+MoR6unMg+WcCroiWmqC3cred oG458gzCUP8Y5mOhu+cyK45NtBM4O3/YeyOY0q9xjRbIjEyrovQIr2r3tMvUxAgbk/An QKhQ== X-Gm-Message-State: ALoCoQldyKWEUocU7DCdHuZh2eW48Xe4jkgpzkjk5G1MCUU2LdsQa9ibwSRFbujMVSB3ibotyiv88x16tFzhrFDWZA0QuuhFcp0RaQ6pvti01zemy6hCVllhlBsF803x15KEhu03vfRt X-Received: by 10.50.142.38 with SMTP id rt6mr8135036igb.17.1427845802721; Tue, 31 Mar 2015 16:50:02 -0700 (PDT) X-Received: by 10.50.142.38 with SMTP id rt6mr8134864igb.17.1427845800384; Tue, 31 Mar 2015 16:50:00 -0700 (PDT) Received: from x-134-84-88-79.nts.umn.edu ([2607:ea00:101:2001:f543:18ee:5d24:7b81]) by mx.google.com with ESMTPSA id b17sm108858iob.31.2015.03.31.16.49.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 16:49:58 -0700 (PDT) Message-ID: <551B32A4.6030604@umn.edu> Date: Tue, 31 Mar 2015 18:49:56 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" , "int-area@ietf.org" , "ipv6@ietf.org" References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> In-Reply-To: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 12:21:12 -0700 Cc: David Farmer , "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 23:50:07 -0000 The Security Considerations for this Draft are not sufficient by today's standards in my opinion. The Security Considerations of RFC2784 does not even discuss data protection (encryption) or tunnel end point authentication issues, and this draft basically just references RFC2784. Any proper discussion of Security Considerations for this topic should at least include references on these issues. I point you to RFC4023 section 8, for an much more in depth handling of Security Considerations of similar issues. I'm not sure its necessary to go to that depth, but some pointers to IPSec and/or SSL would seem a minimum, especially since IPSec was suppose to be a key feature for IPv6. Also, RFC6196 has a good discussion of security issues with tunnels in general. Thanks On 3/30/15 15:27 , Zuniga, Juan Carlos wrote: > Dear Int-Area and 6man WGs, > > At the Int-Area WG meeting in Dallas there were some comments on > draft-ietf-intarea-gre-ipv6. It was decided to submit the document for > WG Last Call to the Int-Area & 6man WGs as soon as the agreed changes > were made. > > The document has now been updated accordingly, so this email starts an > Int-Area/6man WGs Last Call on: > > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04 > > Please respond to this email to support the document and/or send > comments by 2015-04-06. > > In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual > Property Rights (IPR)": > > Are you personally aware of any IPR that applies to > draft-ietf-intarea-gre-ipv6? > > If so, has this IPR been disclosed in compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > Best, > > Juan Carlos Zuniga > > (as Int-Area WG co-chair) > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Apr 2 12:39:20 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C51A0103; Thu, 2 Apr 2015 12:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3RIPn4zWY33; Thu, 2 Apr 2015 12:39:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934A61A00FD; Thu, 2 Apr 2015 12:39:14 -0700 (PDT) Received: from BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 2 Apr 2015 19:38:52 +0000 Received: from BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) by BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) with mapi id 15.01.0125.002; Thu, 2 Apr 2015 19:38:52 +0000 From: Ronald Bonica To: Lucy yong , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" , "Stewart Bryant (stbryant)" Thread-Topic: Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgAC9ARgAAFkw8AAAT40EAAAitxwAAB0qeAAArfCMAAmU5wwAAGCFgAAAO0wYAAC3xTgAFhv1xA= Date: Thu, 2 Apr 2015 19:38:52 +0000 Message-ID: References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57155632@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57155632@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(99286002)(19625215002)(33656002)(230783001)(16236675004)(2201001)(93886004)(87936001)(46102003)(2656002)(76576001)(74316001)(19300405004)(2501003)(2950100001)(66066001)(62966003)(122556002)(77156002)(2900100001)(15975445007)(92566002)(102836002)(50986999)(86362001)(76176999)(54356999)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:BLUPR05MB433.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB435; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_BLUPR05MB433CD2BDA87CC868451C6B7AEF20BLUPR05MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 19:38:52.3860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:39:17 -0000 --_000_BLUPR05MB433CD2BDA87CC868451C6B7AEF20BLUPR05MB433namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 THVjeSwgVG9tLCBTdGV3YXJkLA0KDQpJIGFncmVlIHdpdGggd2hhdCB5b3UgYXJlIHNheWluZyBh bmQgaGF2ZSB0cmllZCB0byBjcmFmdCBzb21lIHRleHQgdGhhdCBhZGRyZXNzZXMgYWxsIG9mIHlv dXIgY29tbWVudHMuIFBsZWFzZSB0ZWxsIG1lIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBkb2VzIHRo ZSB0cmljay4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0K T0xEPg0KICAgQXMgc3RhdGVkIGluIFtSRkMyNzg0XSwgdGhlIENoZWNrc3VtIGZpZWxkIGNvbnRh aW5zIHRoZSBJUCAob25lJ3MNCiAgIGNvbXBsZW1lbnQpIGNoZWNrc3VtIHN1bSBvZiB0aGUgYWxs IHRoZSAxNiBiaXQgd29yZHMgaW4gdGhlIEdSRQ0KICAgaGVhZGVyIGFuZCB0aGUgcGF5bG9hZCBw YWNrZXQuICBUaGVyZWZvcmUsIHRoZSBjaGVja3N1bSBkb2VzIG5vdA0KICAgZW5zdXJlIHRoZSBp bnRlZ3JpdHkgb2YgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyLg0KDQogIEJlY2F1c2UgdGhlIElQ djYgZGVsaXZlcnkgaGVhZGVyIGRvZXMgbm90IGluY2x1ZGUgYSBjaGVja3N1bSBvZiBpdHMNCiAg IG93biwgaXQgaXMgc3ViamVjdCB0byBjb3JydXB0aW9uLiAgSG93ZXZlciwgZXZlbiBpZiB0aGUg ZGVsaXZlcnkNCiAgIGhlYWRlciBpcyBjb3JydXB0ZWQsIHRvIGxpa2VsaWhvb2Qgb2YgdGhhdCBj b3JydXB0aW9uIHJlc3VsdGluZyBpbg0KICAgbWlzZGVsaXZlcnkgb2YgdGhlIHBheWxvYWQgaXMg ZXh0cmVtZWx5IGxvdy4NCjxPTEQNCg0KTkVXPg0KICAgQXMgc3RhdGVkIGluIFtSRkMyNzg0XSwg dGhlIEdSRSBoZWFkZXIgY2FuIGNvbnRhaW4gYSBjaGVja3N1bS4NCiAgIElmIHByZXNlbnQsIHRo ZSBHUkUgaGVhZGVyIGNoZWNrc3VtIGNhbiBiZSB1c2VkIHRvIGRldGVjdA0KICAgY29ycnVwdGlv biBvZiB0aGUgR1JFIGhlYWRlciBhbmQgR1JFIHBheWxvYWQuDQoNCiAgIFRoZSBHUkUgaGVhZGVy IGNoZWNrc3VtIGNhbm5vdCBiZSB1c2VkIHRvIGRldGVjdCBjb3JydXB0aW9uDQogICAgb2YgdGhl IElQdjYgZGVsaXZlcnkgaGVhZGVyLiBGdXJ0aGVybW9yZSwgdGhlIElQdjYgZGVsaXZlcnkgaGVh ZGVyDQogICBkb2VzIG5vdCBjb250YWluICBhIGNoZWNrc3VtIG9yIGl0cyBvd24uIFRoZXJlZm9y ZSwgbm8gY2hlY2tzdW0NCiAgIGNhbiBiZSB1c2VkIHRvIGRldGVjdCBjb3JydXB0aW9uIG9mIHRo ZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4NCg0KICAgSW4gb25lIGZhaWx1cmUgc2NlbmFyaW8sIHRo ZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBJUHY2IGRlbGl2ZXJ5DQogICBoZWFkZXIgaXMg Y29ycnVwdGVkLiBBcyBhIHJlc3VsdCwgdGhlIElQdjYgZGVsaXZlcnkgcGFja2V0IGlzIGRlbGl2 ZXJlZA0KICAgdG8gIGEgbm9kZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBHUkUgZWdyZXNzIG5v ZGUuIERlcGVuZGluZyB1cG9uDQogICB0aGUgc3RhdGUgYW5kIGNvbmZpZ3VyYXRpb24gb2YgdGhh dCBub2RlLCBpdCB3aWxsIGVpdGhlcjoNCg0KDQphKSAgICAgIERyb3AgdGhlIHBhY2tldA0KDQpi KSAgICAgIERlLWVuY2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3YXJkIGl0IHRvIGl0cyBp bnRlbmRlZCBkZXN0aW5hdGlvbg0KDQpjKSAgICAgICBEZS1lbmNhcHN1bGF0ZSB0aGUgcGF5bG9h ZCBhbmQgZm9yd2FyZCBpdCB0byBhIG5vZGUgb3RoZXIgdGhhbiBpdHMgaW50ZW5kZWQgZGVzdGlu YXRpb24uIEZvciBleGFtcGxlLCB0aGUgcGF5bG9hZCBtaWdodCBiZSBpbnRlbmRlZCBmb3IgYSBu b2RlIG9uIG9uZSBWUE4sIGJ1dCBkZWxpdmVyZWQgdG8gYW4gaWRlbnRpY2FsbHkgbnVtYmVyZWQg bm9kZSBpbiBhbm90aGVyIFZQTi4NCg0KDQpCZWhhdmlvcnMgYSkgYW5kIGIpIGFyZSBhY2NlcHRh YmxlLiBCZWhhdmlvciBjKSBpcyBub3QgYWNjZXB0YWJsZS4NCg0KQmVmb3JlIGRlcGxveWluZyBH UkUgb3ZlciBJUHY2LCBuZXR3b3JrIG9wZXJhdG9ycyBzaG91bGQgY29uc2lkZXIgdGhlDQpsaWtl bGlob29kIG9mIGJlaGF2aW9yIGMpIGluIHRoZWlyIG5ldHdvcmsuIE5ldHdvcmsgb3BlcmF0b3Jz IHNob3VsZCBkZXBsb3kNCkdSRSBvdmVyIElQdjYgaWYgdGhleSBjYW4gdG9sZXJhdGUgdGhlIHJp c2sgYXNzb2NpYXRlZCB3aXRoIGJlaGF2aW9yIGMpLg0KDQo8TkVXDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoNCg== --_000_BLUPR05MB433CD2BDA87CC868451C6B7AEF20BLUPR05MB433namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRp di5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBs aS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJp b3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4t Ym90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMt c2VyaWY7fQ0KcC5pbXByaW50dW5pcXVlaWQsIGxpLmltcHJpbnR1bmlxdWVpZCwgZGl2LmltcHJp bnR1bmlxdWVpZA0KCXttc28tc3R5bGUtbmFtZTppbXByaW50dW5pcXVlaWQ7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUzNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6Mjc0NTU2MjA5Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTIzOTE0MDM1OCAtMTE3NzYz MTQyNCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDox LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEuNzVpbjsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi43NWlu Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozLjI1aW47DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My43 NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuMjVpbjsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6NC43NWluOw0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDozMzYwMDgwMzc7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk5OTMyODAwNiAtNTMwNzA4 MDQ2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7 bXNvLWxpc3QtaWQ6NTgwNzk0MDY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjEzMDc3MzU5NCAxMDU3OTg2MTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MdWN5LCBUb20sIFN0 ZXdhcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGgg d2hhdCB5b3UgYXJlIHNheWluZyBhbmQgaGF2ZSB0cmllZCB0byBjcmFmdCBzb21lIHRleHQgdGhh dCBhZGRyZXNzZXMgYWxsIG9mIHlvdXIgY29tbWVudHMuIFBsZWFzZSB0ZWxsIG1lIGlmIHRoZSBm b2xsb3dpbmcgdGV4dCBkb2VzIHRoZSB0cmljay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9MRCZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEFzIHN0YXRlZCBpbiBbUkZDMjc4NF0sIHRoZSBDaGVj a3N1bSBmaWVsZCBjb250YWlucyB0aGUgSVAgKG9uZSdzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBjb21wbGVtZW50KSBjaGVja3N1bSBzdW0gb2YgdGhlIGFsbCB0aGUgMTYgYml0IHdvcmRz IGluIHRoZSBHUkU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGhlYWRlciBhbmQgdGhlIHBh eWxvYWQgcGFja2V0LiZuYnNwOyBUaGVyZWZvcmUsIHRoZSBjaGVja3N1bSBkb2VzIG5vdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZW5zdXJlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIElQdjYg ZGVsaXZlcnkgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7QmVjYXVzZSB0aGUgSVB2NiBkZWxpdmVyeSBoZWFkZXIgZG9lcyBub3QgaW5jbHVk ZSBhIGNoZWNrc3VtIG9mIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb3duLCBpdCBp cyBzdWJqZWN0IHRvIGNvcnJ1cHRpb24uJm5ic3A7IEhvd2V2ZXIsIGV2ZW4gaWYgdGhlIGRlbGl2 ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBoZWFkZXIgaXMgY29ycnVwdGVkLCB0byBs aWtlbGlob29kIG9mIHRoYXQgY29ycnVwdGlvbiByZXN1bHRpbmcgaW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IG1pc2RlbGl2ZXJ5IG9mIHRoZSBwYXlsb2FkIGlzIGV4dHJlbWVseSBsb3cu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZsdDtPTEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPk5FVyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEFzIHN0YXRlZCBpbiBbUkZD Mjc4NF0sIHRoZSBHUkUgaGVhZGVyIGNhbiBjb250YWluIGEgY2hlY2tzdW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBJZiBwcmVzZW50LCB0aGUgR1JFIGhlYWRlciBjaGVja3N1bSBjYW4g YmUgdXNlZCB0byBkZXRlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNvcnJ1cHRpb24g b2YgdGhlIEdSRSBoZWFkZXIgYW5kIEdSRSBwYXlsb2FkLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgVGhlIEdSRSBoZWFkZXIgY2hlY2tzdW0gY2Fu bm90IGJlIHVzZWQgdG8gZGV0ZWN0IGNvcnJ1cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4gRnVydGhlcm1vcmUsIHRoZSBJ UHY2IGRlbGl2ZXJ5IGhlYWRlcg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwO2Rv ZXMgbm90IGNvbnRhaW4gJm5ic3A7YSBjaGVja3N1bSBvciBpdHMgb3duLiBUaGVyZWZvcmUsIG5v IGNoZWNrc3VtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBjYW4gYmUgdXNlZCB0byBkZXRl Y3QgY29ycnVwdGlvbiBvZiB0aGUgSVB2NiBkZWxpdmVyeSBoZWFkZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgSW4gb25lIGZhaWx1cmUgc2NlbmFy aW8sIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBJUHY2IGRlbGl2ZXJ5DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aGVhZGVyIGlzIGNvcnJ1cHRlZC4gQXMgYSByZXN1 bHQsIHRoZSBJUHY2IGRlbGl2ZXJ5IHBhY2tldCBpcyBkZWxpdmVyZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IHRvICZuYnNwO2Egbm9kZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBHUkUg ZWdyZXNzIG5vZGUuIERlcGVuZGluZyB1cG9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIHN0YXRlIGFuZCBjb25maWd1cmF0aW9uIG9mIHRoYXQgbm9kZSwgaXQgd2lsbCBl aXRoZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRyb3AgdGhlIHBhY2tldDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRl LWVuY2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3YXJkIGl0IHRvIGl0cyBpbnRlbmRlZCBk ZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5jKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRlLWVuY2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3 YXJkIGl0IHRvIGEgbm9kZSBvdGhlciB0aGFuIGl0cyBpbnRlbmRlZCBkZXN0aW5hdGlvbi4gRm9y IGV4YW1wbGUsIHRoZSBwYXlsb2FkIG1pZ2h0IGJlIGludGVuZGVkIGZvciBhIG5vZGUgb24gb25l IFZQTiwgYnV0IGRlbGl2ZXJlZCB0byBhbiBpZGVudGljYWxseSBudW1iZXJlZCBub2RlDQogaW4g YW5vdGhlciBWUE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CZWhhdmlvcnMgYSkgYW5kIGIpIGFyZSBhY2NlcHRh YmxlLiBCZWhhdmlvciBjKSBpcyBub3QgYWNjZXB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkJlZm9yZSBkZXBsb3lpbmcgR1JFIG92ZXIgSVB2NiwgbmV0d29yayBv cGVyYXRvcnMgc2hvdWxkIGNvbnNpZGVyIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5saWtlbGlob29kIG9m IGJlaGF2aW9yIGMpIGluIHRoZWlyIG5ldHdvcmsuIE5ldHdvcmsgb3BlcmF0b3JzIHNob3VsZCBk ZXBsb3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+R1JFIG92ZXIgSVB2NiBpZiB0aGV5IGNhbiB0b2xlcmF0ZSB0 aGUgcmlzayBhc3NvY2lhdGVkIHdpdGggYmVoYXZpb3IgYykuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbHQ7TkVXPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR05MB433CD2BDA87CC868451C6B7AEF20BLUPR05MB433namprd_-- From nobody Thu Apr 2 13:02:19 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6D11A035F; Thu, 2 Apr 2015 13:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyqSG-Kyeew9; Thu, 2 Apr 2015 13:02:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF18C1A033B; Thu, 2 Apr 2015 13:02:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQZ58339; Thu, 02 Apr 2015 20:02:12 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Apr 2015 20:58:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 2 Apr 2015 12:58:07 -0700 From: Lucy yong To: Ronald Bonica , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" , "Stewart Bryant (stbryant)" Thread-Topic: Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgAC9ARgAAFkw8AAAT40EAAAitxwAAB0qeAAArfCMAAmU5wwAAGCFgAAAO0wYAAC3xTgAFhv1xAACo9RgA== Date: Thu, 2 Apr 2015 19:58:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57156796@dfweml701-chm> References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57155632@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.126] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57156796dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:02:17 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57156796dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQpHb29kIFRyeS4gU2VlIGlubGluZSBiZWxvdy4NCg0KRnJvbTogUm9uYWxkIEJv bmljYSBbbWFpbHRvOnJib25pY2FAanVuaXBlci5uZXRdDQpTZW50OiBUaHVyc2RheSwgQXByaWwg MDIsIDIwMTUgMjozOSBQTQ0KVG86IEx1Y3kgeW9uZzsgQmxhY2ssIERhdmlkOyBpbnQtYXJlYUBp ZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KQ2M6IGRy YWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NkB0b29scy5pZXRmLm9yZzsgaW50YXJlYS1jaGFpcnNA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFy ZWEtZ3JlLWlwdjYNCg0KTHVjeSwgVG9tLCBTdGV3YXJkLA0KDQpJIGFncmVlIHdpdGggd2hhdCB5 b3UgYXJlIHNheWluZyBhbmQgaGF2ZSB0cmllZCB0byBjcmFmdCBzb21lIHRleHQgdGhhdCBhZGRy ZXNzZXMgYWxsIG9mIHlvdXIgY29tbWVudHMuIFBsZWFzZSB0ZWxsIG1lIGlmIHRoZSBmb2xsb3dp bmcgdGV4dCBkb2VzIHRoZSB0cmljay4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBSb24NCg0KT0xEPg0KICAgQXMgc3RhdGVkIGluIFtSRkMyNzg0XSwgdGhlIENoZWNr c3VtIGZpZWxkIGNvbnRhaW5zIHRoZSBJUCAob25lJ3MNCiAgIGNvbXBsZW1lbnQpIGNoZWNrc3Vt IHN1bSBvZiB0aGUgYWxsIHRoZSAxNiBiaXQgd29yZHMgaW4gdGhlIEdSRQ0KICAgaGVhZGVyIGFu ZCB0aGUgcGF5bG9hZCBwYWNrZXQuICBUaGVyZWZvcmUsIHRoZSBjaGVja3N1bSBkb2VzIG5vdA0K ICAgZW5zdXJlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyLg0KDQog IEJlY2F1c2UgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyIGRvZXMgbm90IGluY2x1ZGUgYSBjaGVj a3N1bSBvZiBpdHMNCiAgIG93biwgaXQgaXMgc3ViamVjdCB0byBjb3JydXB0aW9uLiAgSG93ZXZl ciwgZXZlbiBpZiB0aGUgZGVsaXZlcnkNCiAgIGhlYWRlciBpcyBjb3JydXB0ZWQsIHRvIGxpa2Vs aWhvb2Qgb2YgdGhhdCBjb3JydXB0aW9uIHJlc3VsdGluZyBpbg0KICAgbWlzZGVsaXZlcnkgb2Yg dGhlIHBheWxvYWQgaXMgZXh0cmVtZWx5IGxvdy4NCjxPTEQNCg0KTkVXPg0KICAgQXMgc3RhdGVk IGluIFtSRkMyNzg0XSwgdGhlIEdSRSBoZWFkZXIgY2FuIGNvbnRhaW4gYSBjaGVja3N1bS4NCiAg IElmIHByZXNlbnQsIHRoZSBHUkUgaGVhZGVyIGNoZWNrc3VtIGNhbiBiZSB1c2VkIHRvIGRldGVj dA0KICAgY29ycnVwdGlvbiBvZiB0aGUgR1JFIGhlYWRlciBhbmQgR1JFIHBheWxvYWQuDQoNCiAg IFRoZSBHUkUgaGVhZGVyIGNoZWNrc3VtIGNhbm5vdCBiZSB1c2VkIHRvIGRldGVjdCBjb3JydXB0 aW9uDQogICAgb2YgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyLiBGdXJ0aGVybW9yZSwgdGhlIElQ djYgZGVsaXZlcnkgaGVhZGVyDQogICBkb2VzIG5vdCBjb250YWluICBhIGNoZWNrc3VtIG9yIGl0 cyBvd24uIFRoZXJlZm9yZSwgbm8gY2hlY2tzdW0NCiAgIGNhbiBiZSB1c2VkIHRvIGRldGVjdCBj b3JydXB0aW9uIG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4NCltMdWN5XSBuaXQ6IOKAnG9u IGl0cyBvd27igJ0NCiAgIEluIG9uZSBmYWlsdXJlIHNjZW5hcmlvLCB0aGUgZGVzdGluYXRpb24g YWRkcmVzcyBpbiB0aGUgSVB2NiBkZWxpdmVyeQ0KICAgaGVhZGVyIGlzIGNvcnJ1cHRlZC4gQXMg YSByZXN1bHQsIHRoZSBJUHY2IGRlbGl2ZXJ5IHBhY2tldCBpcyBkZWxpdmVyZWQNCiAgIHRvICBh IG5vZGUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgR1JFIGVncmVzcyBub2RlLiBEZXBlbmRpbmcg dXBvbg0KICAgdGhlIHN0YXRlIGFuZCBjb25maWd1cmF0aW9uIG9mIHRoYXQgbm9kZSwgaXQgd2ls bCBlaXRoZXI6DQoNCg0KYSkgICAgICBEcm9wIHRoZSBwYWNrZXQNCg0KYikgICAgICBEZS1lbmNh cHN1bGF0ZSB0aGUgcGF5bG9hZCBhbmQgZm9yd2FyZCBpdCB0byBpdHMgaW50ZW5kZWQgZGVzdGlu YXRpb24NCg0KYykgICAgICAgRGUtZW5jYXBzdWxhdGUgdGhlIHBheWxvYWQgYW5kIGZvcndhcmQg aXQgdG8gYSBub2RlIG90aGVyIHRoYW4gaXRzIGludGVuZGVkIGRlc3RpbmF0aW9uLiBGb3IgZXhh bXBsZSwgdGhlIHBheWxvYWQgbWlnaHQgYmUgaW50ZW5kZWQgZm9yIGEgbm9kZSBvbiBvbmUgVlBO LCBidXQgZGVsaXZlcmVkIHRvIGFuIGlkZW50aWNhbGx5IG51bWJlcmVkIG5vZGUgaW4gYW5vdGhl ciBWUE4uDQoNCg0KQmVoYXZpb3JzIGEpIGFuZCBiKSBhcmUgYWNjZXB0YWJsZS4gQmVoYXZpb3Ig YykgaXMgbm90IGFjY2VwdGFibGUuDQoNCkJlZm9yZSBkZXBsb3lpbmcgR1JFIG92ZXIgSVB2Niwg bmV0d29yayBvcGVyYXRvcnMgc2hvdWxkIGNvbnNpZGVyIHRoZQ0KbGlrZWxpaG9vZCBvZiBiZWhh dmlvciBjKSBpbiB0aGVpciBuZXR3b3JrLiBOZXR3b3JrIG9wZXJhdG9ycyBzaG91bGQgZGVwbG95 DQpHUkUgb3ZlciBJUHY2IGlmIHRoZXkgY2FuIHRvbGVyYXRlIHRoZSByaXNrIGFzc29jaWF0ZWQg d2l0aCBiZWhhdmlvciBjKS4NCltMdWN5XSDigJxjYW4gZGVwbG954oCdIGlzIGJldHRlciB0aGFu IOKAnHNob3VsZCBkZXBsb3nigJ0NCg0KSSBhbSBmaW5lIHdpdGggdGhlIHRleHQgZm9yIHRoZSBj b3JydXB0aW9uIGNhc2UuIERvIHdlIG5lZWQgdG8gYWRkcmVzcyBtaXNkZWxpdmVyeSBhcyB3ZWxs Lg0KDQpUaGFua3MsDQpMdWN5DQoNCjxORVcNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSb24NCg0KDQoNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D57156796dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1z b1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLmltcHJpbnR1bmlxdWVpZCwgbGku aW1wcmludHVuaXF1ZWlkLCBkaXYuaW1wcmludHVuaXF1ZWlkDQoJe21zby1zdHlsZS1uYW1lOmlt cHJpbnR1bmlxdWVpZDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlv bjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUzNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzYN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkg Um9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29vZCBUcnkuIFNlZSBp bmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gUm9uYWxkIEJvbmljYSBbbWFpbHRvOnJib25pY2FAanVuaXBlci5u ZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDAyLCAyMDE1IDI6MzkgUE08 YnI+DQo8Yj5Ubzo8L2I+IEx1Y3kgeW9uZzsgQmxhY2ssIERhdmlkOyBpbnQtYXJlYUBpZXRmLm9y ZzsgaXB2NkBpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KTxicj4NCjxiPkNjOjwv Yj4gZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnOyBpbnRhcmVhLWNo YWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU3RhcnQgb2YgV0dMQyBmb3Ig ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkx1Y3ksIFRvbSwg U3Rld2FyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0 aCB3aGF0IHlvdSBhcmUgc2F5aW5nIGFuZCBoYXZlIHRyaWVkIHRvIGNyYWZ0IHNvbWUgdGV4dCB0 aGF0IGFkZHJlc3NlcyBhbGwgb2YgeW91ciBjb21tZW50cy4gUGxlYXNlIHRlbGwgbWUgaWYgdGhl IGZvbGxvd2luZyB0ZXh0IGRvZXMgdGhlIHRyaWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T0xEJmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgQXMgc3RhdGVkIGluIFtSRkMyNzg0XSwgdGhlIENo ZWNrc3VtIGZpZWxkIGNvbnRhaW5zIHRoZSBJUCAob25lJ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IGNvbXBsZW1lbnQpIGNoZWNrc3VtIHN1bSBvZiB0aGUgYWxsIHRoZSAxNiBiaXQgd29y ZHMgaW4gdGhlIEdSRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgaGVhZGVyIGFuZCB0aGUg cGF5bG9hZCBwYWNrZXQuJm5ic3A7IFRoZXJlZm9yZSwgdGhlIGNoZWNrc3VtIGRvZXMgbm90PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBlbnN1cmUgdGhlIGludGVncml0eSBvZiB0aGUgSVB2 NiBkZWxpdmVyeSBoZWFkZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDtCZWNhdXNlIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlciBkb2VzIG5vdCBpbmNs dWRlIGEgY2hlY2tzdW0gb2YgaXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvd24sIGl0 IGlzIHN1YmplY3QgdG8gY29ycnVwdGlvbi4mbmJzcDsgSG93ZXZlciwgZXZlbiBpZiB0aGUgZGVs aXZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGhlYWRlciBpcyBjb3JydXB0ZWQsIHRv IGxpa2VsaWhvb2Qgb2YgdGhhdCBjb3JydXB0aW9uIHJlc3VsdGluZyBpbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgbWlzZGVsaXZlcnkgb2YgdGhlIHBheWxvYWQgaXMgZXh0cmVtZWx5IGxv dy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jmx0O09MRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+TkVXJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgQXMgc3RhdGVkIGluIFtS RkMyNzg0XSwgdGhlIEdSRSBoZWFkZXIgY2FuIGNvbnRhaW4gYSBjaGVja3N1bS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IElmIHByZXNlbnQsIHRoZSBHUkUgaGVhZGVyIGNoZWNrc3VtIGNh biBiZSB1c2VkIHRvIGRldGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgY29ycnVwdGlv biBvZiB0aGUgR1JFIGhlYWRlciBhbmQgR1JFIHBheWxvYWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBUaGUgR1JFIGhlYWRlciBjaGVja3N1bSBj YW5ub3QgYmUgdXNlZCB0byBkZXRlY3QgY29ycnVwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsgb2YgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyLiBGdXJ0aGVybW9yZSwgdGhl IElQdjYgZGVsaXZlcnkgaGVhZGVyDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZG9lcyBub3QgY29udGFpbiAmbmJzcDthIGNoZWNrc3VtIG9yIGl0cyBvd24uIFRoZXJlZm9yZSwg bm8gY2hlY2tzdW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNhbiBiZSB1c2VkIHRvIGRl dGVjdCBjb3JydXB0aW9uIG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+W0x1Y3ldIDwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5uaXQ6IOKAnG9uIGl0cyBvd27igJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgSW4gb25lIGZhaWx1cmUgc2NlbmFyaW8sIHRo ZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBJUHY2IGRlbGl2ZXJ5DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aGVhZGVyIGlzIGNvcnJ1cHRlZC4gQXMgYSByZXN1bHQsIHRo ZSBJUHY2IGRlbGl2ZXJ5IHBhY2tldCBpcyBkZWxpdmVyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IHRvICZuYnNwO2Egbm9kZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCBHUkUgZWdyZXNz IG5vZGUuIERlcGVuZGluZyB1cG9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 dGhlIHN0YXRlIGFuZCBjb25maWd1cmF0aW9uIG9mIHRoYXQgbm9kZSwgaXQgd2lsbCBlaXRoZXI6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4y NWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+YSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRyb3AgdGhlIHBhY2tldDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Yik8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkRlLWVuY2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3YXJkIGl0 IHRvIGl0cyBpbnRlbmRlZCBkZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRl bnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Yyk8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRlLWVu Y2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3YXJkIGl0IHRvIGEgbm9kZSBvdGhlciB0aGFu IGl0cyBpbnRlbmRlZCBkZXN0aW5hdGlvbi4gRm9yIGV4YW1wbGUsIHRoZSBwYXlsb2FkIG1pZ2h0 IGJlIGludGVuZGVkIGZvciBhIG5vZGUgb24gb25lIFZQTiwgYnV0IGRlbGl2ZXJlZCB0byBhbiBp ZGVudGljYWxseSBudW1iZXJlZCBub2RlIGluIGFub3RoZXIgVlBOLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1 aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVo YXZpb3JzIGEpIGFuZCBiKSBhcmUgYWNjZXB0YWJsZS4gQmVoYXZpb3IgYykgaXMgbm90IGFjY2Vw dGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CZWZvcmUgZGVwbG95 aW5nIEdSRSBvdmVyIElQdjYsIG5ldHdvcmsgb3BlcmF0b3JzIHNob3VsZCBjb25zaWRlciB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+bGlrZWxpaG9vZCBvZiBiZWhhdmlvciBjKSBpbiB0aGVpciBuZXR3b3Jr LiBOZXR3b3JrIG9wZXJhdG9ycyBzaG91bGQgZGVwbG95PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkdSRSBvdmVy IElQdjYgaWYgdGhleSBjYW4gdG9sZXJhdGUgdGhlIHJpc2sgYXNzb2NpYXRlZCB3aXRoIGJlaGF2 aW9yIGMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTHVjeV0g4oCcY2FuIGRlcGxveeKAnSBpcyBi ZXR0ZXIgdGhhbiDigJxzaG91bGQgZGVwbG954oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbSBmaW5lIHdpdGggdGhl IHRleHQgZm9yIHRoZSBjb3JydXB0aW9uIGNhc2UuIERvIHdlIG5lZWQgdG8gYWRkcmVzcyBtaXNk ZWxpdmVyeSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5MdWN5PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O05FVzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D57156796dfweml701chm_-- From nobody Thu Apr 2 15:01:07 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF411A854B; Thu, 2 Apr 2015 15:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2J3oYA1wiZX; Thu, 2 Apr 2015 15:01:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB511A8547; Thu, 2 Apr 2015 15:01:03 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 2 Apr 2015 22:01:01 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 22:01:01 +0000 From: Ronald Bonica To: Lucy yong , "Black, David" , "int-area@ietf.org" , "ipv6@ietf.org" , "Stewart Bryant (stbryant)" Thread-Topic: Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgAC9ARgAAFkw8AAAT40EAAAitxwAAB0qeAAArfCMAAmU5wwAAGCFgAAAO0wYAAC3xTgAFhv1xAACo9RgAAEsy7g Date: Thu, 2 Apr 2015 22:01:01 +0000 Message-ID: References: <785DB11636645E438E2E096E1ADA47C40DAC8053@KAMACITE.InterDigital.com> <2691CE0099834E4A9C5044EEC662BB9D57154F13@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F68@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57154F85@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57155632@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D57156796@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57156796@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(377454003)(57704003)(164054003)(86362001)(46102003)(54356999)(50986999)(2201001)(74316001)(93886004)(19300405004)(122556002)(40100003)(2900100001)(2950100001)(76176999)(19580395003)(2656002)(87936001)(19580405001)(19625215002)(76576001)(77156002)(33656002)(62966003)(230783001)(92566002)(66066001)(2501003)(99286002)(102836002)(15975445007)(16236675004)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 0534947130 Content-Type: multipart/alternative; boundary="_000_CO1PR05MB442208874C186B2A18B08F5AEF20CO1PR05MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 22:01:01.3254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Cc: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 22:01:06 -0000 --_000_CO1PR05MB442208874C186B2A18B08F5AEF20CO1PR05MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 THVjeSwNCg0KQm90aCBnb29kIGNhdGNoZXMuIFN0YW5kIGJ5IGZvciB0ZXh0IG9uIG1pc2RlbGl2 ZXJ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0K DQoNCkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tXQ0KU2VudDog VGh1cnNkYXksIEFwcmlsIDAyLCAyMDE1IDM6NTggUE0NClRvOiBSb25hbGQgQm9uaWNhOyBCbGFj aywgRGF2aWQ7IGludC1hcmVhQGlldGYub3JnOyBpcHY2QGlldGYub3JnOyBTdGV3YXJ0IEJyeWFu dCAoc3RicnlhbnQpDQpDYzogZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYu b3JnOyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFN0YXJ0IG9mIFdHTEMg Zm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ng0KDQpIaSBSb24sDQoNCkdvb2QgVHJ5LiBT ZWUgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb25hbGQgQm9uaWNhIFttYWlsdG86cmJvbmljYUBq dW5pcGVyLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMiwgMjAxNSAyOjM5IFBNDQpUbzog THVjeSB5b25nOyBCbGFjaywgRGF2aWQ7IGludC1hcmVhQGlldGYub3JnPG1haWx0bzppbnQtYXJl YUBpZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+OyBTdGV3YXJ0 IEJyeWFudCAoc3RicnlhbnQpDQpDYzogZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5v cmc+OyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aW50YXJlYS1jaGFpcnNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogU3RhcnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdy ZS1pcHY2DQoNCkx1Y3ksIFRvbSwgU3Rld2FyZCwNCg0KSSBhZ3JlZSB3aXRoIHdoYXQgeW91IGFy ZSBzYXlpbmcgYW5kIGhhdmUgdHJpZWQgdG8gY3JhZnQgc29tZSB0ZXh0IHRoYXQgYWRkcmVzc2Vz IGFsbCBvZiB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgdGVsbCBtZSBpZiB0aGUgZm9sbG93aW5nIHRl eHQgZG9lcyB0aGUgdHJpY2suDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9uDQoNCk9MRD4NCiAgIEFzIHN0YXRlZCBpbiBbUkZDMjc4NF0sIHRoZSBDaGVja3N1bSBm aWVsZCBjb250YWlucyB0aGUgSVAgKG9uZSdzDQogICBjb21wbGVtZW50KSBjaGVja3N1bSBzdW0g b2YgdGhlIGFsbCB0aGUgMTYgYml0IHdvcmRzIGluIHRoZSBHUkUNCiAgIGhlYWRlciBhbmQgdGhl IHBheWxvYWQgcGFja2V0LiAgVGhlcmVmb3JlLCB0aGUgY2hlY2tzdW0gZG9lcyBub3QNCiAgIGVu c3VyZSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4NCg0KICBCZWNh dXNlIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlciBkb2VzIG5vdCBpbmNsdWRlIGEgY2hlY2tzdW0g b2YgaXRzDQogICBvd24sIGl0IGlzIHN1YmplY3QgdG8gY29ycnVwdGlvbi4gIEhvd2V2ZXIsIGV2 ZW4gaWYgdGhlIGRlbGl2ZXJ5DQogICBoZWFkZXIgaXMgY29ycnVwdGVkLCB0byBsaWtlbGlob29k IG9mIHRoYXQgY29ycnVwdGlvbiByZXN1bHRpbmcgaW4NCiAgIG1pc2RlbGl2ZXJ5IG9mIHRoZSBw YXlsb2FkIGlzIGV4dHJlbWVseSBsb3cuDQo8T0xEDQoNCk5FVz4NCiAgIEFzIHN0YXRlZCBpbiBb UkZDMjc4NF0sIHRoZSBHUkUgaGVhZGVyIGNhbiBjb250YWluIGEgY2hlY2tzdW0uDQogICBJZiBw cmVzZW50LCB0aGUgR1JFIGhlYWRlciBjaGVja3N1bSBjYW4gYmUgdXNlZCB0byBkZXRlY3QNCiAg IGNvcnJ1cHRpb24gb2YgdGhlIEdSRSBoZWFkZXIgYW5kIEdSRSBwYXlsb2FkLg0KDQogICBUaGUg R1JFIGhlYWRlciBjaGVja3N1bSBjYW5ub3QgYmUgdXNlZCB0byBkZXRlY3QgY29ycnVwdGlvbg0K ICAgIG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4gRnVydGhlcm1vcmUsIHRoZSBJUHY2IGRl bGl2ZXJ5IGhlYWRlcg0KICAgZG9lcyBub3QgY29udGFpbiAgYSBjaGVja3N1bSBvciBpdHMgb3du LiBUaGVyZWZvcmUsIG5vIGNoZWNrc3VtDQogICBjYW4gYmUgdXNlZCB0byBkZXRlY3QgY29ycnVw dGlvbiBvZiB0aGUgSVB2NiBkZWxpdmVyeSBoZWFkZXIuDQpbTHVjeV0gbml0OiDigJxvbiBpdHMg b3du4oCdDQogICBJbiBvbmUgZmFpbHVyZSBzY2VuYXJpbywgdGhlIGRlc3RpbmF0aW9uIGFkZHJl c3MgaW4gdGhlIElQdjYgZGVsaXZlcnkNCiAgIGhlYWRlciBpcyBjb3JydXB0ZWQuIEFzIGEgcmVz dWx0LCB0aGUgSVB2NiBkZWxpdmVyeSBwYWNrZXQgaXMgZGVsaXZlcmVkDQogICB0byAgYSBub2Rl IG90aGVyIHRoYW4gdGhlIGludGVuZGVkIEdSRSBlZ3Jlc3Mgbm9kZS4gRGVwZW5kaW5nIHVwb24N CiAgIHRoZSBzdGF0ZSBhbmQgY29uZmlndXJhdGlvbiBvZiB0aGF0IG5vZGUsIGl0IHdpbGwgZWl0 aGVyOg0KDQoNCmEpICAgICAgRHJvcCB0aGUgcGFja2V0DQoNCmIpICAgICAgRGUtZW5jYXBzdWxh dGUgdGhlIHBheWxvYWQgYW5kIGZvcndhcmQgaXQgdG8gaXRzIGludGVuZGVkIGRlc3RpbmF0aW9u DQoNCmMpICAgICAgIERlLWVuY2Fwc3VsYXRlIHRoZSBwYXlsb2FkIGFuZCBmb3J3YXJkIGl0IHRv IGEgbm9kZSBvdGhlciB0aGFuIGl0cyBpbnRlbmRlZCBkZXN0aW5hdGlvbi4gRm9yIGV4YW1wbGUs IHRoZSBwYXlsb2FkIG1pZ2h0IGJlIGludGVuZGVkIGZvciBhIG5vZGUgb24gb25lIFZQTiwgYnV0 IGRlbGl2ZXJlZCB0byBhbiBpZGVudGljYWxseSBudW1iZXJlZCBub2RlIGluIGFub3RoZXIgVlBO Lg0KDQoNCkJlaGF2aW9ycyBhKSBhbmQgYikgYXJlIGFjY2VwdGFibGUuIEJlaGF2aW9yIGMpIGlz IG5vdCBhY2NlcHRhYmxlLg0KDQpCZWZvcmUgZGVwbG95aW5nIEdSRSBvdmVyIElQdjYsIG5ldHdv cmsgb3BlcmF0b3JzIHNob3VsZCBjb25zaWRlciB0aGUNCmxpa2VsaWhvb2Qgb2YgYmVoYXZpb3Ig YykgaW4gdGhlaXIgbmV0d29yay4gTmV0d29yayBvcGVyYXRvcnMgc2hvdWxkIGRlcGxveQ0KR1JF IG92ZXIgSVB2NiBpZiB0aGV5IGNhbiB0b2xlcmF0ZSB0aGUgcmlzayBhc3NvY2lhdGVkIHdpdGgg YmVoYXZpb3IgYykuDQpbTHVjeV0g4oCcY2FuIGRlcGxveeKAnSBpcyBiZXR0ZXIgdGhhbiDigJxz aG91bGQgZGVwbG954oCdDQoNCkkgYW0gZmluZSB3aXRoIHRoZSB0ZXh0IGZvciB0aGUgY29ycnVw dGlvbiBjYXNlLiBEbyB3ZSBuZWVkIHRvIGFkZHJlc3MgbWlzZGVsaXZlcnkgYXMgd2VsbC4NCg0K VGhhbmtzLA0KTHVjeQ0KDQo8TkVXDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQoNCg0KDQoNCg== --_000_CO1PR05MB442208874C186B2A18B08F5AEF20CO1PR05MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0 DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAuaW1w cmludHVuaXF1ZWlkLCBsaS5pbXByaW50dW5pcXVlaWQsIGRpdi5pbXByaW50dW5pcXVlaWQNCgl7 bXNvLXN0eWxlLW5hbWU6aW1wcmludHVuaXF1ZWlkOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3Jh dGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUzNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTM1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzYNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMzkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MdWN5LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Qm90aCBnb29kIGNhdGNoZXMuIFN0YW5kIGJ5IGZvciB0ZXh0IG9u IG1pc2RlbGl2ZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gTHVjeSB5b25nIFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb21d IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDIsIDIwMTUgMzo1OCBQTTxicj4N CjxiPlRvOjwvYj4gUm9uYWxkIEJvbmljYTsgQmxhY2ssIERhdmlkOyBpbnQtYXJlYUBpZXRmLm9y ZzsgaXB2NkBpZXRmLm9yZzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KTxicj4NCjxiPkNjOjwv Yj4gZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnOyBpbnRhcmVhLWNo YWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU3RhcnQgb2YgV0dMQyBmb3Ig ZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgUm9uLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29vZCBUcnkuIFNlZSBpbmxpbmUgYmVsb3cuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gUm9uYWxkIEJvbmljYSBbPGEgaHJl Zj0ibWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQiPm1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0 PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMDIsIDIwMTUgMjozOSBQ TTxicj4NCjxiPlRvOjwvYj4gTHVjeSB5b25nOyBCbGFjaywgRGF2aWQ7IDxhIGhyZWY9Im1haWx0 bzppbnQtYXJlYUBpZXRmLm9yZyI+aW50LWFyZWFAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFp bHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8L2E+OyBTdGV3YXJ0IEJyeWFudCAoc3Ri cnlhbnQpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pbnRhcmVh LWdyZS1pcHY2QHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9v bHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmludGFyZWEtY2hhaXJzQGlldGYub3Jn Ij5pbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFN0 YXJ0IG9mIFdHTEMgZm9yIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2NjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5MdWN5LCBUb20sIFN0ZXdhcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JIGFncmVlIHdpdGggd2hhdCB5b3UgYXJlIHNheWluZyBhbmQgaGF2ZSB0cmllZCB0byBj cmFmdCBzb21lIHRleHQgdGhhdCBhZGRyZXNzZXMgYWxsIG9mIHlvdXIgY29tbWVudHMuIFBsZWFz ZSB0ZWxsIG1lIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBkb2VzIHRoZSB0cmljay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPk9MRCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEFzIHN0YXRlZCBpbiBb UkZDMjc4NF0sIHRoZSBDaGVja3N1bSBmaWVsZCBjb250YWlucyB0aGUgSVAgKG9uZSdzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBjb21wbGVtZW50KSBjaGVja3N1bSBzdW0gb2YgdGhlIGFs bCB0aGUgMTYgYml0IHdvcmRzIGluIHRoZSBHUkU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IGhlYWRlciBhbmQgdGhlIHBheWxvYWQgcGFja2V0LiZuYnNwOyBUaGVyZWZvcmUsIHRoZSBjaGVj a3N1bSBkb2VzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZW5zdXJlIHRoZSBpbnRl Z3JpdHkgb2YgdGhlIElQdjYgZGVsaXZlcnkgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7QmVjYXVzZSB0aGUgSVB2NiBkZWxpdmVyeSBoZWFk ZXIgZG9lcyBub3QgaW5jbHVkZSBhIGNoZWNrc3VtIG9mIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsgb3duLCBpdCBpcyBzdWJqZWN0IHRvIGNvcnJ1cHRpb24uJm5ic3A7IEhvd2V2ZXIs IGV2ZW4gaWYgdGhlIGRlbGl2ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBoZWFkZXIg aXMgY29ycnVwdGVkLCB0byBsaWtlbGlob29kIG9mIHRoYXQgY29ycnVwdGlvbiByZXN1bHRpbmcg aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1pc2RlbGl2ZXJ5IG9mIHRoZSBwYXlsb2Fk IGlzIGV4dHJlbWVseSBsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtPTEQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5FVyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IEFzIHN0YXRlZCBpbiBbUkZDMjc4NF0sIHRoZSBHUkUgaGVhZGVyIGNhbiBjb250YWluIGEgY2hl Y2tzdW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJZiBwcmVzZW50LCB0aGUgR1JFIGhl YWRlciBjaGVja3N1bSBjYW4gYmUgdXNlZCB0byBkZXRlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IGNvcnJ1cHRpb24gb2YgdGhlIEdSRSBoZWFkZXIgYW5kIEdSRSBwYXlsb2FkLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgVGhlIEdSRSBo ZWFkZXIgY2hlY2tzdW0gY2Fubm90IGJlIHVzZWQgdG8gZGV0ZWN0IGNvcnJ1cHRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlci4g RnVydGhlcm1vcmUsIHRoZSBJUHY2IGRlbGl2ZXJ5IGhlYWRlcg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwO2RvZXMgbm90IGNvbnRhaW4gJm5ic3A7YSBjaGVja3N1bSBvciBpdHMg b3duLiBUaGVyZWZvcmUsIG5vIGNoZWNrc3VtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBj YW4gYmUgdXNlZCB0byBkZXRlY3QgY29ycnVwdGlvbiBvZiB0aGUgSVB2NiBkZWxpdmVyeSBoZWFk ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMdWN5XSA8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+bml0OiDigJxvbiBpdHMgb3du4oCdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBJbiBvbmUgZmFpbHVyZSBzY2VuYXJpbywgdGhlIGRlc3RpbmF0aW9uIGFkZHJl c3MgaW4gdGhlIElQdjYgZGVsaXZlcnkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDtoZWFkZXIgaXMgY29ycnVwdGVkLiBBcyBhIHJlc3VsdCwgdGhlIElQdjYgZGVsaXZlcnkgcGFj a2V0IGlzIGRlbGl2ZXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdG8gJm5ic3A7YSBu b2RlIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIEdSRSBlZ3Jlc3Mgbm9kZS4gRGVwZW5kaW5nIHVw b24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgc3RhdGUgYW5kIGNvbmZp Z3VyYXRpb24gb2YgdGhhdCBub2RlLCBpdCB3aWxsIGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5hKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+RHJvcCB0aGUgcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDot LjI1aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5iKTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGUtZW5jYXBzdWxhdGUgdGhlIHBheWxvYWQg YW5kIGZvcndhcmQgaXQgdG8gaXRzIGludGVuZGVkIGRlc3RpbmF0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDou NzVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5jKTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGUt ZW5jYXBzdWxhdGUgdGhlIHBheWxvYWQgYW5kIGZvcndhcmQgaXQgdG8gYSBub2RlIG90aGVyIHRo YW4gaXRzIGludGVuZGVkIGRlc3RpbmF0aW9uLiBGb3IgZXhhbXBsZSwgdGhlIHBheWxvYWQgbWln aHQgYmUgaW50ZW5kZWQgZm9yIGEgbm9kZSBvbiBvbmUgVlBOLCBidXQgZGVsaXZlcmVkIHRvIGFu IGlkZW50aWNhbGx5IG51bWJlcmVkIG5vZGUgaW4gYW5vdGhlciBWUE4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDou NzVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5C ZWhhdmlvcnMgYSkgYW5kIGIpIGFyZSBhY2NlcHRhYmxlLiBCZWhhdmlvciBjKSBpcyBub3QgYWNj ZXB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJlZm9yZSBkZXBs b3lpbmcgR1JFIG92ZXIgSVB2NiwgbmV0d29yayBvcGVyYXRvcnMgc2hvdWxkIGNvbnNpZGVyIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5saWtlbGlob29kIG9mIGJlaGF2aW9yIGMpIGluIHRoZWlyIG5ldHdv cmsuIE5ldHdvcmsgb3BlcmF0b3JzIHNob3VsZCBkZXBsb3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R1JFIG92 ZXIgSVB2NiBpZiB0aGV5IGNhbiB0b2xlcmF0ZSB0aGUgcmlzayBhc3NvY2lhdGVkIHdpdGggYmVo YXZpb3IgYykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMdWN5XSDigJxjYW4gZGVwbG954oCdIGlz IGJldHRlciB0aGFuIOKAnHNob3VsZCBkZXBsb3nigJ08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFtIGZpbmUgd2l0aCB0 aGUgdGV4dCBmb3IgdGhlIGNvcnJ1cHRpb24gY2FzZS4gRG8gd2UgbmVlZCB0byBhZGRyZXNzIG1p c2RlbGl2ZXJ5IGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkx1Y3k8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7TkVXPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CO1PR05MB442208874C186B2A18B08F5AEF20CO1PR05MB442namprd_-- From nobody Tue Apr 7 13:01:55 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A131B3BBA for ; Tue, 7 Apr 2015 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmXOnEKc0GSV for ; Tue, 7 Apr 2015 13:01:52 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (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 7152D1B3BBB for ; Tue, 7 Apr 2015 13:01:52 -0700 (PDT) X-ASG-Debug-ID: 1428436910-06daaa66b916a70001-lk1YkQ Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id HFmxkDUsTAR8w9iM (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 07 Apr 2015 16:01:50 -0400 (EDT) X-Barracuda-Envelope-From: JuanCarlos.Zuniga@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Tue, 7 Apr 2015 16:01:50 -0400 From: "Zuniga, Juan Carlos" To: "draft-ietf-intarea-gre-ipv6@tools.ietf.org" Thread-Topic: Start of WGLC for draft-ietf-intarea-gre-ipv6 X-ASG-Orig-Subj: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgGTuWtA Date: Tue, 7 Apr 2015 20:01:50 +0000 Message-ID: <785DB11636645E438E2E096E1ADA47C410718A4A@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.202] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: multipart/alternative; boundary="_000_785DB11636645E438E2E096E1ADA47C410718A4ANABESITEInterDi_" MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1428436910 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.17646 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: "ipv6@ietf.org" , "int-area@ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:01:54 -0000 --_000_785DB11636645E438E2E096E1ADA47C410718A4ANABESITEInterDi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXV0aG9ycywNCg0KVGhlIFdHTEMgaGFzIGVuZGVkLiBQbGVhc2UgcHJvZHVjZSBhIG5ldyB2ZXJz aW9uIG9mIHRoZSBkb2N1bWVudCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBjb21tZW50cyByZWNl aXZlZCBvbiB0aGUgbGlzdHMgYW5kIHN1Ym1pdCBhIHN1bW1hcnkgb2YgdGhlIGRpZmZlcmVudCBp c3N1ZXMgYWRkcmVzc2VkIGluIHRoaXMgbmV3IHZlcnNpb24uDQoNCkJlc3QsDQoNCkp1YW4gQ2Fy bG9zDQooYXMgSW50LUFyZWEgV0cgY28tY2hhaXIpDQoNCkZyb206IFp1bmlnYSwgSnVhbiBDYXJs b3MNClNlbnQ6IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDoyNyBQTQ0KVG86ICdpbnQtYXJlYUBp ZXRmLm9yZyc7ICdpcHY2QGlldGYub3JnJw0KQ2M6ICdkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlw djZAdG9vbHMuaWV0Zi5vcmcnOyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogU3Rh cnQgb2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2DQoNCg0KRGVhciBJbnQt QXJlYSBhbmQgNm1hbiBXR3MsDQoNCg0KDQpBdCB0aGUgSW50LUFyZWEgV0cgbWVldGluZyBpbiBE YWxsYXMgdGhlcmUgd2VyZSBzb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUt aXB2Ni4gSXQgd2FzIGRlY2lkZWQgdG8gc3VibWl0IHRoZSBkb2N1bWVudCBmb3IgV0cgTGFzdCBD YWxsIHRvIHRoZSBJbnQtQXJlYSAmIDZtYW4gV0dzIGFzIHNvb24gYXMgdGhlIGFncmVlZCBjaGFu Z2VzIHdlcmUgbWFkZS4NCg0KDQoNClRoZSBkb2N1bWVudCBoYXMgbm93IGJlZW4gdXBkYXRlZCBh Y2NvcmRpbmdseSwgc28gdGhpcyBlbWFpbCBzdGFydHMgYW4gSW50LUFyZWEvNm1hbiBXR3MgTGFz dCBDYWxsIG9uOg0KDQoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p bnRhcmVhLWdyZS1pcHY2LTA0DQoNCg0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHRv IHN1cHBvcnQgdGhlIGRvY3VtZW50IGFuZC9vciBzZW5kIGNvbW1lbnRzIGJ5IDIwMTUtMDQtMDYu DQoNCg0KDQpJbiBhZGRpdGlvbiwgdG8gc2F0aXNmeSBSRkMgNjcwMiAiUHJvbW90aW5nIENvbXBs aWFuY2Ugd2l0aCBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIChJUFIpIjoNCg0KQXJlIHlv dSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYt aW50YXJlYS1ncmUtaXB2Nj8NCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM/DQoNCihTZWUgUkZDcyAzOTc5LCA0ODc5 LCAzNjY5LCBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzLikNCg0KDQoNCkJlc3QsDQoNCg0KDQpK dWFuIENhcmxvcyBadW5pZ2ENCihhcyBJbnQtQXJlYSBXRyBjby1jaGFpcikNCg0K --_000_785DB11636645E438E2E096E1ADA47C410718A4ANABESITEInterDi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBTaWduYXR1cmUgTWFuYWdlciBFeGNoYW5nZSBFZGl0aW9uIG9uIDA0OjAxOjUwIFR1ZXNk YXksIDcgQXByaWwgMjAxNSAtLT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ UC5JbXByaW50VW5pcXVlSUQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLkltcHJpbnRV bmlxdWVJRCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLkltcHJpbnRVbmlxdWVJRCB7 DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KVEFCTEUuSW1wcmludFVuaXF1ZUlEVGFibGUgew0K CU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NCjwvc3R5bGU+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRp b25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxwPjwvcD4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXV0aG9ycyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBXR0xDIGhhcyBlbmRlZC4g UGxlYXNlIHByb2R1Y2UgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgdGFraW5nIGludG8g YWNjb3VudCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgb24gdGhlIGxpc3RzIGFuZCBzdWJtaXQgYSBz dW1tYXJ5IG9mIHRoZSBkaWZmZXJlbnQgaXNzdWVzIGFkZHJlc3NlZCBpbiB0aGlzIG5ldyB2ZXJz aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVzdCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkp1YW4gQ2FybG9zIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4o YXMgSW50LUFyZWEgV0cgY28tY2hhaXIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFp1bmlnYSwg SnVhbiBDYXJsb3MgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDoy NyBQTTxicj4NCjxiPlRvOjwvYj4gJ2ludC1hcmVhQGlldGYub3JnJzsgJ2lwdjZAaWV0Zi5vcmcn PGJyPg0KPGI+Q2M6PC9iPiAnZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYu b3JnJzsgaW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU3RhcnQg b2YgV0dMQyBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EZWFyIEludC1BcmVhIGFuZCA2bWFuIFdHcyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXQgdGhlIEludC1BcmVhIFdHIG1lZXRpbmcgaW4g RGFsbGFzIHRoZXJlIHdlcmUgc29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWludGFyZWEtZ3Jl LWlwdjYuIEl0IHdhcyBkZWNpZGVkIHRvIHN1Ym1pdCB0aGUgZG9jdW1lbnQgZm9yIFdHIExhc3Qg Q2FsbCB0byB0aGUgSW50LUFyZWEgJmFtcDsgNm1hbiBXR3MgYXMgc29vbiBhcyB0aGUgYWdyZWVk IGNoYW5nZXMgd2VyZSBtYWRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgZG9j dW1lbnQgaGFzIG5vdyBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nbHksIHNvIHRoaXMgZW1haWwgc3Rh cnRzIGFuIEludC1BcmVhLzZtYW4gV0dzIExhc3QgQ2FsbCBvbjo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1pbnRhcmVhLWdyZS1pcHY2LTA0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWludGFyZWEtZ3JlLWlwdjYtMDQ8L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB0byBzdXBwb3J0IHRoZSBkb2N1bWVudCBh bmQvb3Igc2VuZCBjb21tZW50cyBieSAyMDE1LTA0LTA2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JbiBhZGRpdGlvbiwgdG8gc2F0aXNmeSBSRkMgNjcwMiAmcXVvdDtQcm9tb3Rpbmcg Q29tcGxpYW5jZSB3aXRoIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUikmcXVvdDs6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcmUgeW91IHBlcnNvbmFs bHkgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1pbnRhcmVhLWdy ZS1pcHY2PyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J ZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPihTZWUg UkZDcyAzOTc5LCA0ODc5LCAzNjY5LCBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzLik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SnVhbiBDYXJsb3MgWnVuaWdhIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KGFzIEludC1BcmVhIFdHIGNvLWNoYWlyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PC9wPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_785DB11636645E438E2E096E1ADA47C410718A4ANABESITEInterDi_-- From nobody Tue Apr 7 13:26:13 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EBF1B3C12; Tue, 7 Apr 2015 13:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoxrXzMW-WwU; Tue, 7 Apr 2015 13:26:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951FF1B3C11; Tue, 7 Apr 2015 13:26:09 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 20:26:07 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Tue, 7 Apr 2015 20:26:07 +0000 From: Ronald Bonica To: "Zuniga, Juan Carlos" , "draft-ietf-intarea-gre-ipv6@tools.ietf.org" Thread-Topic: Start of WGLC for draft-ietf-intarea-gre-ipv6 Thread-Index: AdBrHeUvMOmHRKvzSsuuWoWBg4qFNgGTuWtAAAEOeuA= Date: Tue, 7 Apr 2015 20:26:07 +0000 Message-ID: References: <785DB11636645E438E2E096E1ADA47C410718A4A@NABESITE.InterDigital.com> In-Reply-To: <785DB11636645E438E2E096E1ADA47C410718A4A@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: InterDigital.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(19617315012)(2501003)(122556002)(40100003)(77156002)(86362001)(99286002)(54356999)(62966003)(76576001)(76176999)(15975445007)(102836002)(50986999)(16236675004)(19625215002)(2900100001)(92566002)(230783001)(2950100001)(19300405004)(46102003)(19580395003)(2656002)(19580405001)(87936001)(74316001)(33656002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0539EEBD11 Content-Type: multipart/alternative; boundary="_000_CO1PR05MB442581A7F90D01000C9FD37AEFD0CO1PR05MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2015 20:26:07.3430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Cc: "ipv6@ietf.org" , "int-area@ietf.org" , "intarea-chairs@ietf.org" Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 20:26:12 -0000 --_000_CO1PR05MB442581A7F90D01000C9FD37AEFD0CO1PR05MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCkkgd2lsbCB0cnkgdG8gcHJvZHVjZSBhIG5ldyB2ZXJzaW9uIGJ5IENPQiB0b21v cnJvdy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS b24NCg0KDQpGcm9tOiBadW5pZ2EsIEp1YW4gQ2FybG9zIFttYWlsdG86SnVhbkNhcmxvcy5adW5p Z2FASW50ZXJEaWdpdGFsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDA3LCAyMDE1IDQ6MDIg UE0NClRvOiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmcNCkNjOiBp bnQtYXJlYUBpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzsgaW50YXJlYS1jaGFpcnNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBTdGFydCBvZiBXR0xDIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlw djYNCg0KQXV0aG9ycywNCg0KVGhlIFdHTEMgaGFzIGVuZGVkLiBQbGVhc2UgcHJvZHVjZSBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBjb21tZW50 cyByZWNlaXZlZCBvbiB0aGUgbGlzdHMgYW5kIHN1Ym1pdCBhIHN1bW1hcnkgb2YgdGhlIGRpZmZl cmVudCBpc3N1ZXMgYWRkcmVzc2VkIGluIHRoaXMgbmV3IHZlcnNpb24uDQoNCkJlc3QsDQoNCkp1 YW4gQ2FybG9zDQooYXMgSW50LUFyZWEgV0cgY28tY2hhaXIpDQoNCkZyb206IFp1bmlnYSwgSnVh biBDYXJsb3MNClNlbnQ6IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDoyNyBQTQ0KVG86ICdpbnQt YXJlYUBpZXRmLm9yZyc7ICdpcHY2QGlldGYub3JnJw0KQ2M6ICdkcmFmdC1pZXRmLWludGFyZWEt Z3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmcnOyBpbnRhcmVhLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 aW50YXJlYS1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTdGFydCBvZiBXR0xDIGZvciBkcmFm dC1pZXRmLWludGFyZWEtZ3JlLWlwdjYNCg0KDQpEZWFyIEludC1BcmVhIGFuZCA2bWFuIFdHcywN Cg0KDQoNCkF0IHRoZSBJbnQtQXJlYSBXRyBtZWV0aW5nIGluIERhbGxhcyB0aGVyZSB3ZXJlIHNv bWUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2LiBJdCB3YXMgZGVjaWRl ZCB0byBzdWJtaXQgdGhlIGRvY3VtZW50IGZvciBXRyBMYXN0IENhbGwgdG8gdGhlIEludC1BcmVh ICYgNm1hbiBXR3MgYXMgc29vbiBhcyB0aGUgYWdyZWVkIGNoYW5nZXMgd2VyZSBtYWRlLg0KDQoN Cg0KVGhlIGRvY3VtZW50IGhhcyBub3cgYmVlbiB1cGRhdGVkIGFjY29yZGluZ2x5LCBzbyB0aGlz IGVtYWlsIHN0YXJ0cyBhbiBJbnQtQXJlYS82bWFuIFdHcyBMYXN0IENhbGwgb246DQoNCg0KDQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYtMDQN Cg0KDQoNClBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgdG8gc3VwcG9ydCB0aGUgZG9jdW1l bnQgYW5kL29yIHNlbmQgY29tbWVudHMgYnkgMjAxNS0wNC0wNi4NCg0KDQoNCkluIGFkZGl0aW9u LCB0byBzYXRpc2Z5IFJGQyA2NzAyICJQcm9tb3RpbmcgQ29tcGxpYW5jZSB3aXRoIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQUikiOg0KDQpBcmUgeW91IHBlcnNvbmFsbHkgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2Pw0K DQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcz8NCg0KKFNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjksIGFuZCA1Mzc4IGZv ciBtb3JlIGRldGFpbHMuKQ0KDQoNCg0KQmVzdCwNCg0KDQoNCkp1YW4gQ2FybG9zIFp1bmlnYQ0K KGFzIEludC1BcmVhIFdHIGNvLWNoYWlyKQ0KDQo= --_000_CO1PR05MB442581A7F90D01000C9FD37AEFD0CO1PR05MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuaW1wcmludHVuaXF1ZWlkLCBsaS5p bXByaW50dW5pcXVlaWQsIGRpdi5pbXByaW50dW5pcXVlaWQNCgl7bXNvLXN0eWxlLW5hbWU6aW1w cmludHVuaXF1ZWlkOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Rm9sa3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHdpbGwgdHJ5IHRvIHByb2R1Y2Ug YSBuZXcgdmVyc2lvbiBieSBDT0IgdG9tb3Jyb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBadW5p Z2EsIEp1YW4gQ2FybG9zIFttYWlsdG86SnVhbkNhcmxvcy5adW5pZ2FASW50ZXJEaWdpdGFsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAwNywgMjAxNSA0OjAyIFBNPGJy Pg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjZAdG9vbHMuaWV0Zi5vcmc8 YnI+DQo8Yj5DYzo8L2I+IGludC1hcmVhQGlldGYub3JnOyBpcHY2QGlldGYub3JnOyBpbnRhcmVh LWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU3RhcnQgb2YgV0dMQyBm b3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXV0aG9ycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBXR0xDIGhhcyBlbmRlZC4gUGxlYXNl IHByb2R1Y2UgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgdGFraW5nIGludG8gYWNjb3Vu dCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgb24gdGhlIGxpc3RzIGFuZCBzdWJtaXQgYSBzdW1tYXJ5 IG9mIHRoZSBkaWZmZXJlbnQgaXNzdWVzIGFkZHJlc3NlZCBpbiB0aGlzIG5ldyB2ZXJzaW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkp1YW4gQ2FybG9zIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4oYXMgSW50 LUFyZWEgV0cgY28tY2hhaXIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFp1bmlnYSwgSnVhbiBD YXJsb3MgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMzAsIDIwMTUgNDoyNyBQTTxi cj4NCjxiPlRvOjwvYj4gJ2ludC1hcmVhQGlldGYub3JnJzsgJ2lwdjZAaWV0Zi5vcmcnPGJyPg0K PGI+Q2M6PC9iPiAnZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2QHRvb2xzLmlldGYub3JnJzsg PGEgaHJlZj0ibWFpbHRvOmludGFyZWEtY2hhaXJzQGlldGYub3JnIj4NCmludGFyZWEtY2hhaXJz QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBTdGFydCBvZiBXR0xDIGZvciBkcmFm dC1pZXRmLWludGFyZWEtZ3JlLWlwdjY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkRlYXIgSW50LUFyZWEgYW5kIDZtYW4gV0dzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5BdCB0aGUgSW50LUFyZWEgV0cgbWVldGluZyBpbiBEYWxsYXMgdGhlcmUgd2Vy ZSBzb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni4gSXQgd2FzIGRl Y2lkZWQgdG8gc3VibWl0IHRoZSBkb2N1bWVudCBmb3IgV0cgTGFzdCBDYWxsIHRvIHRoZSBJbnQt QXJlYSAmYW1wOyA2bWFuIFdHcyBhcyBzb29uIGFzIHRoZSBhZ3JlZWQgY2hhbmdlcyB3ZXJlIG1h ZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBkb2N1bWVudCBoYXMgbm93IGJl ZW4gdXBkYXRlZCBhY2NvcmRpbmdseSwgc28gdGhpcyBlbWFpbCBzdGFydHMgYW4gSW50LUFyZWEv Nm1hbiBXR3MgTGFzdCBDYWxsIG9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlw djYtMDQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaW50YXJlYS1ncmUt aXB2Ni0wNDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2UgcmVzcG9u ZCB0byB0aGlzIGVtYWlsIHRvIHN1cHBvcnQgdGhlIGRvY3VtZW50IGFuZC9vciBzZW5kIGNvbW1l bnRzIGJ5IDIwMTUtMDQtMDYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIGFkZGl0 aW9uLCB0byBzYXRpc2Z5IFJGQyA2NzAyICZxdW90O1Byb21vdGluZyBDb21wbGlhbmNlIHdpdGgg SW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyAoSVBSKSZxdW90Ozo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFyZSB5b3UgcGVyc29uYWxseSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjY/Jm5ic3A7DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHNvLCBoYXMgdGhpcyBJ UFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KFNlZSBSRkNzIDM5NzksIDQ4Nzks IDM2NjksIGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5KdWFuIENhcmxvcyBa dW5pZ2EgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYXMgSW50LUFyZWEg V0cgY28tY2hhaXIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CO1PR05MB442581A7F90D01000C9FD37AEFD0CO1PR05MB442namprd_-- From nobody Wed Apr 8 09:55:11 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0631B345D; Wed, 8 Apr 2015 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-THzOZEoAZx; Wed, 8 Apr 2015 09:55:05 -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 476101B3455; Wed, 8 Apr 2015 09:55:02 -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 2601788119; Wed, 8 Apr 2015 09:55:02 -0700 (PDT) Received: from Brians-MacBook-Pro.local (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 C9DBC13682CA; Wed, 8 Apr 2015 09:55:01 -0700 (PDT) Message-ID: <55255D5B.7090007@innovationslab.net> Date: Wed, 08 Apr 2015 12:54:51 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: draft-ietf-intarea-gre-mtu@ietf.org, int-area@ietf.org Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rUVFVjGk8Ag1rBNXg4DrCO8rhpqtFh21B" Archived-At: Subject: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 16:55:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rUVFVjGk8Ag1rBNXg4DrCO8rhpqtFh21B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, I have completed my AD Evaluation of draft-ietf-intarea-gre-mtu as a part of the publication process. I only have a few minor comments for the authors to address. Once that is done, I will start the IETF Last Ca= ll. * Section 1 - The 4th paragraph specifies that the techniques described in this document are limited on what protocols can be in the GRE payload, but doesn't say anything about the delivery protocol. The Terminology section indicates only v4 and v6 are applicable as the delivery protocol discussed in this document. I think it would be useful to expand the 4th paragraph of the intro to mention the limit on the delivery protocol. * Section 1.1 - s/specific MTU discovery/specific to MTU discovery/ - The definition of "fragmentable packet" should include mention of IPv6 - The definition of PTB should be consistent and indicate that IPv6 uses ICMPv6 Type=3D2 for PTB messages. * Section 2.2 - I would suggest clarifying the first bullet by saying that the fragmentation logic is derived from the payload protocol. Regards, Brian --rUVFVjGk8Ag1rBNXg4DrCO8rhpqtFh21B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJV1bAAoJEBOZRqCi7goqrqQH/3+IgvESVI68L7VyZfRSWo2U AFqH5OVzsJMXiZoeFL9X7olSbtlD8L8oV5E+6PGd3sbyNphjQcNH11TDVZyzLBeg PDUP454SLZjzZhad0SbFSU3ZjtZJ60t8NYO2+3MFqFHYElM6HbFZyRqr2Jhnkckl xnYf5Ln84uSaTp33LP/3096ax3YgYD7ENgEYZaq4Cbn/mZcAZRaJ+68Uyj+rL9Mp VGj2HJVxqecVA6JS72fYu2Vi6g4kFNFTLFZaej5DsyQmSfT7zlI97BKuSV7rq2BU YG/6i2u5Z9s63hEh1Agt2q7xgifp1QOlr/w8Z5fa7wOdsX/vrTxkPS8MUa8jLZs= =w2Kz -----END PGP SIGNATURE----- --rUVFVjGk8Ag1rBNXg4DrCO8rhpqtFh21B-- From nobody Wed Apr 8 11:00:14 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5381A88F0; Wed, 8 Apr 2015 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtuCaX1cPEwP; Wed, 8 Apr 2015 11:00:09 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7547B1A88F7; Wed, 8 Apr 2015 11:00:09 -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 t38I08Ll029282; Wed, 8 Apr 2015 11:00:08 -0700 Received: from XCH-BLV-506.nw.nos.boeing.com (xch-blv-506.nw.nos.boeing.com [130.247.25.196]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t38HxwlI028338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 8 Apr 2015 10:59:58 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-506.nw.nos.boeing.com ([169.254.6.205]) with mapi id 14.03.0210.002; Wed, 8 Apr 2015 10:59:58 -0700 From: "Templin, Fred L" To: Brian Haberman , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQchzRsT9xesxs4k2M4sj2j8uMmZ1DZcpA Date: Wed, 8 Apr 2015 17:59:57 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> References: <55255D5B.7090007@innovationslab.net> In-Reply-To: <55255D5B.7090007@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:00:12 -0000 SGksDQoNCkp1c3QgbG9va2luZyBub3csIHRoaXMgZG9jdW1lbnQgaXMgc2VyaW91c2x5IG1lc3Nl ZCB1cC4gSXQgbGVhdmVzIG9wZW4NCnRoZSBwb3NzaWJpbGl0eSBmb3IgZGVuaWFsIG9mIHNlcnZp Y2UgdG8gSVB2NiBwYWNrZXRzIG9mIDEyODAgYnl0ZXMgb3INCnNtYWxsZXIgd2hpY2ggaXMgYSB2 aW9sYXRpb24gb2YgdGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlLiBJIGhhZCB0aGUgc2FtZQ0KY29t bWVudCByZWdhcmRpbmcgdGhlIG90aGVyIEdSRSBkb2N1bWVudC4NCg0KSWYgcGVvcGxlIHdhbnQg dG8gc2VlIGhvdyB0byBoYW5kbGUgdHVubmVsIE1UVSwgcGxlYXNlIHJldmlldw0KU2VjdGlvbiAz LjEzIG9mIGRyYWZ0LXRlbXBsaW4tYWVyb2xpbmsuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50 ZW1wbGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBJbnQtYXJlYSBbbWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBCcmlhbiBIYWJlcm1hbg0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA4LCAyMDE1IDk6NTUg QU0NCj4gVG86IGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtbXR1QGlldGYub3JnOyBpbnQtYXJlYUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbSW50LWFyZWFdIEFEIEV2YWx1YXRpb246IGRyYWZ0LWlldGYt aW50YXJlYS1ncmUtbXR1DQo+IA0KPiBBbGwsDQo+ICAgICAgSSBoYXZlIGNvbXBsZXRlZCBteSBB RCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtbXR1IGFzDQo+IGEgcGFydCBv ZiB0aGUgcHVibGljYXRpb24gcHJvY2Vzcy4gIEkgb25seSBoYXZlIGEgZmV3IG1pbm9yIGNvbW1l bnRzIGZvcg0KPiB0aGUgYXV0aG9ycyB0byBhZGRyZXNzLiAgT25jZSB0aGF0IGlzIGRvbmUsIEkg d2lsbCBzdGFydCB0aGUgSUVURiBMYXN0IENhbGwuDQo+IA0KPiAqIFNlY3Rpb24gMSAtIFRoZSA0 dGggcGFyYWdyYXBoIHNwZWNpZmllcyB0aGF0IHRoZSB0ZWNobmlxdWVzIGRlc2NyaWJlZA0KPiBp biB0aGlzIGRvY3VtZW50IGFyZSBsaW1pdGVkIG9uIHdoYXQgcHJvdG9jb2xzIGNhbiBiZSBpbiB0 aGUgR1JFDQo+IHBheWxvYWQsIGJ1dCBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCB0aGUgZGVs aXZlcnkgcHJvdG9jb2wuIFRoZQ0KPiBUZXJtaW5vbG9neSBzZWN0aW9uIGluZGljYXRlcyBvbmx5 IHY0IGFuZCB2NiBhcmUgYXBwbGljYWJsZSBhcyB0aGUNCj4gZGVsaXZlcnkgcHJvdG9jb2wgZGlz Y3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuICBJIHRoaW5rIGl0IHdvdWxkIGJlDQo+IHVzZWZ1bCB0 byBleHBhbmQgdGhlIDR0aCBwYXJhZ3JhcGggb2YgdGhlIGludHJvIHRvIG1lbnRpb24gdGhlIGxp bWl0IG9uDQo+IHRoZSBkZWxpdmVyeSBwcm90b2NvbC4NCj4gDQo+ICogU2VjdGlvbiAxLjENCj4g DQo+IC0gcy9zcGVjaWZpYyBNVFUgZGlzY292ZXJ5L3NwZWNpZmljIHRvIE1UVSBkaXNjb3Zlcnkv DQo+IA0KPiAtIFRoZSBkZWZpbml0aW9uIG9mICJmcmFnbWVudGFibGUgcGFja2V0IiBzaG91bGQg aW5jbHVkZSBtZW50aW9uIG9mIElQdjYNCj4gDQo+IC0gVGhlIGRlZmluaXRpb24gb2YgUFRCIHNo b3VsZCBiZSBjb25zaXN0ZW50IGFuZCBpbmRpY2F0ZSB0aGF0IElQdjYgdXNlcw0KPiBJQ01QdjYg VHlwZT0yIGZvciBQVEIgbWVzc2FnZXMuDQo+IA0KPiAqIFNlY3Rpb24gMi4yIC0gSSB3b3VsZCBz dWdnZXN0IGNsYXJpZnlpbmcgdGhlIGZpcnN0IGJ1bGxldCBieSBzYXlpbmcNCj4gdGhhdCB0aGUg ZnJhZ21lbnRhdGlvbiBsb2dpYyBpcyBkZXJpdmVkIGZyb20gdGhlIHBheWxvYWQgcHJvdG9jb2wu DQo+IA0KPiBSZWdhcmRzLA0KPiBCcmlhbg0KDQo= From nobody Wed Apr 8 12:20:22 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B509E1B351D; Wed, 8 Apr 2015 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WZW8w3Oy_P4; Wed, 8 Apr 2015 12:20:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CD41B3532; Wed, 8 Apr 2015 12:20:14 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 8 Apr 2015 19:20:13 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 19:20:13 +0000 From: Ronald Bonica To: Brian Haberman , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" Thread-Topic: AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQchzHfy17x81HiUuuiI633K/kkZ1DfZQA Date: Wed, 8 Apr 2015 19:20:12 +0000 Message-ID: References: <55255D5B.7090007@innovationslab.net> In-Reply-To: <55255D5B.7090007@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: innovationslab.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(51914003)(13464003)(46102003)(19580395003)(74316001)(2656002)(33656002)(230783001)(92566002)(2950100001)(2201001)(66066001)(19580405001)(87936001)(86362001)(2501003)(106116001)(122556002)(77156002)(40100003)(76176999)(2900100001)(102836002)(50986999)(76576001)(99286002)(54356999)(107886001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0540846A1D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 19:20:12.9784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:20:20 -0000 QnJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gSSB3aWxsIHNwaW4gYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQgYWRkcmVzc2luZyBhbGwgb2YgdGhlc2UgY29tbWVudHMuDQoNCkkgd2ls bCBzcGluIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFkZHJlc3NpbmcgYWxsIG9mIHRoZXNl IGNvbW1lbnRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBIYWJlcm1hbiBbbWFp bHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAw OCwgMjAxNSAxMjo1NSBQTQ0KPiBUbzogZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1tdHVAaWV0Zi5v cmc7IGludC1hcmVhQGlldGYub3JnDQo+IFN1YmplY3Q6IEFEIEV2YWx1YXRpb246IGRyYWZ0LWll dGYtaW50YXJlYS1ncmUtbXR1DQo+IA0KPiBBbGwsDQo+ICAgICAgSSBoYXZlIGNvbXBsZXRlZCBt eSBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtbXR1IGFzIGEgcGFydA0K PiBvZiB0aGUgcHVibGljYXRpb24gcHJvY2Vzcy4gIEkgb25seSBoYXZlIGEgZmV3IG1pbm9yIGNv bW1lbnRzIGZvciB0aGUNCj4gYXV0aG9ycyB0byBhZGRyZXNzLiAgT25jZSB0aGF0IGlzIGRvbmUs IEkgd2lsbCBzdGFydCB0aGUgSUVURiBMYXN0IENhbGwuDQo+IA0KPiAqIFNlY3Rpb24gMSAtIFRo ZSA0dGggcGFyYWdyYXBoIHNwZWNpZmllcyB0aGF0IHRoZSB0ZWNobmlxdWVzIGRlc2NyaWJlZCBp biB0aGlzDQo+IGRvY3VtZW50IGFyZSBsaW1pdGVkIG9uIHdoYXQgcHJvdG9jb2xzIGNhbiBiZSBp biB0aGUgR1JFIHBheWxvYWQsIGJ1dA0KPiBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCB0aGUg ZGVsaXZlcnkgcHJvdG9jb2wuIFRoZSBUZXJtaW5vbG9neSBzZWN0aW9uDQo+IGluZGljYXRlcyBv bmx5IHY0IGFuZCB2NiBhcmUgYXBwbGljYWJsZSBhcyB0aGUgZGVsaXZlcnkgcHJvdG9jb2wgZGlz Y3Vzc2VkIGluDQo+IHRoaXMgZG9jdW1lbnQuICBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byBleHBhbmQgdGhlIDR0aCBwYXJhZ3JhcGggb2YgdGhlDQo+IGludHJvIHRvIG1lbnRpb24gdGhl IGxpbWl0IG9uIHRoZSBkZWxpdmVyeSBwcm90b2NvbC4NCj4gDQo+ICogU2VjdGlvbiAxLjENCj4g DQo+IC0gcy9zcGVjaWZpYyBNVFUgZGlzY292ZXJ5L3NwZWNpZmljIHRvIE1UVSBkaXNjb3Zlcnkv DQo+IA0KPiAtIFRoZSBkZWZpbml0aW9uIG9mICJmcmFnbWVudGFibGUgcGFja2V0IiBzaG91bGQg aW5jbHVkZSBtZW50aW9uIG9mIElQdjYNCj4gDQo+IC0gVGhlIGRlZmluaXRpb24gb2YgUFRCIHNo b3VsZCBiZSBjb25zaXN0ZW50IGFuZCBpbmRpY2F0ZSB0aGF0IElQdjYgdXNlcw0KPiBJQ01QdjYg VHlwZT0yIGZvciBQVEIgbWVzc2FnZXMuDQo+IA0KPiAqIFNlY3Rpb24gMi4yIC0gSSB3b3VsZCBz dWdnZXN0IGNsYXJpZnlpbmcgdGhlIGZpcnN0IGJ1bGxldCBieSBzYXlpbmcgdGhhdCB0aGUNCj4g ZnJhZ21lbnRhdGlvbiBsb2dpYyBpcyBkZXJpdmVkIGZyb20gdGhlIHBheWxvYWQgcHJvdG9jb2wu DQo+IA0KPiBSZWdhcmRzLA0KPiBCcmlhbg0KDQo= From nobody Wed Apr 8 12:31:13 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79AD1B3552; Wed, 8 Apr 2015 12:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaR2-0-WnVJR; Wed, 8 Apr 2015 12:31:09 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFED1B3551; Wed, 8 Apr 2015 12:31:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t38JV8Dd008031; Wed, 8 Apr 2015 14:31:08 -0500 Received: from XCH-BLV-408.nw.nos.boeing.com (xch-blv-408.nw.nos.boeing.com [130.247.25.166]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t38JUvDq007851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 8 Apr 2015 14:30:58 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.188]) with mapi id 14.03.0210.002; Wed, 8 Apr 2015 12:30:56 -0700 From: "Templin, Fred L" To: Brian Haberman , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQchzRsT9xesxs4k2M4sj2j8uMmZ1DZcpAgAAYYAA= Date: Wed, 8 Apr 2015 19:30:55 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:31:12 -0000 To be constructive, one way forward would be to define a new field in the G= RE header called the "fragment" field. It would be used to fragment the payloa= d packet prior to encapsulating each fragment in a separate delivery header. This would be an example of tunnel fragmentation as suggested in Section 3.1.7 of RFC2764. End result is that the tunnel egress still has to reassemble, but the syste= m would not run afoul of IPv4 nor IPv6 fragmentation pitfalls since everythin= g would look like a whole (unfragmented) packet to the underlying links insid= e the tunnel. 'draft-templin-aerolinlk' is one example of this; 'draft-herbert-gue-fragme= ntation' is a second. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Wednesday, April 08, 2015 11:00 AM > To: Brian Haberman; draft-ietf-intarea-gre-mtu@ietf.org; int-area@ietf.or= g > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 > Hi, >=20 > Just looking now, this document is seriously messed up. It leaves open > the possibility for denial of service to IPv6 packets of 1280 bytes or > smaller which is a violation of the robustness principle. I had the same > comment regarding the other GRE document. >=20 > If people want to see how to handle tunnel MTU, please review > Section 3.13 of draft-templin-aerolink. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Brian Ha= berman > > Sent: Wednesday, April 08, 2015 9:55 AM > > To: draft-ietf-intarea-gre-mtu@ietf.org; int-area@ietf.org > > Subject: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > All, > > I have completed my AD Evaluation of draft-ietf-intarea-gre-mtu as > > a part of the publication process. I only have a few minor comments fo= r > > the authors to address. Once that is done, I will start the IETF Last = Call. > > > > * Section 1 - The 4th paragraph specifies that the techniques described > > in this document are limited on what protocols can be in the GRE > > payload, but doesn't say anything about the delivery protocol. The > > Terminology section indicates only v4 and v6 are applicable as the > > delivery protocol discussed in this document. I think it would be > > useful to expand the 4th paragraph of the intro to mention the limit on > > the delivery protocol. > > > > * Section 1.1 > > > > - s/specific MTU discovery/specific to MTU discovery/ > > > > - The definition of "fragmentable packet" should include mention of IPv= 6 > > > > - The definition of PTB should be consistent and indicate that IPv6 use= s > > ICMPv6 Type=3D2 for PTB messages. > > > > * Section 2.2 - I would suggest clarifying the first bullet by saying > > that the fragmentation logic is derived from the payload protocol. > > > > Regards, > > Brian >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 8 15:18:09 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2731A9054; Wed, 8 Apr 2015 15:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J31bTJCNGyPk; Wed, 8 Apr 2015 15:18:06 -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 D004C1A904F; Wed, 8 Apr 2015 15:18:06 -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 AAE5B880E2; Wed, 8 Apr 2015 15:18:06 -0700 (PDT) Received: from Littlejohn.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0B94A13682CB; Wed, 8 Apr 2015 15:18:05 -0700 (PDT) Message-ID: <5525A918.2000808@innovationslab.net> Date: Wed, 08 Apr 2015 18:18:00 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0dPAKViiurfq9dDt27oTuoFw3DAxap3xA" Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:18:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0dPAKViiurfq9dDt27oTuoFw3DAxap3xA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fred, On 4/8/15 3:30 PM, Templin, Fred L wrote: > To be constructive, one way forward would be to define a new field in t= he GRE > header called the "fragment" field. It would be used to fragment the pa= yload > packet prior to encapsulating each fragment in a separate delivery head= er. > This would be an example of tunnel fragmentation as suggested in Sectio= n > 3.1.7 of RFC2764. That would be a fine proposal to write-up, but it does not belong in this document. *This* document describes what vendors have implemented. It is an Informational document. If anything were to go in this document, I could see an additional description in the Security Considerations section that describes the vulnerability you are concerned about. WG? Regards, Brian --0dPAKViiurfq9dDt27oTuoFw3DAxap3xA 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 - https://gpgtools.org iQEcBAEBCgAGBQJVJakfAAoJEBOZRqCi7goqkF0IAIuQYx9WXFl2swVTk/nd713O nXF7FoicRaQZPaY/k8W4Nc93wIzIc+BZbJpAgstmilqNXPi+29ghXCs8L5wW3DvC d3JAmd2V461GaV7eBtmqzNXRMmPcZiVr6uOozkaPkSxEfZFP6FQg6w2evLHeKiUU lvM0ibKm4R886JBuvm2tEbDEFrOa89oPDH9D5mF5KB403MFF2F57ik3pfI0FMj7n TePTN4jMxPCk9bRtvES8zevKNWeNwRlS29nKI8YWbDl8LG7UWilxq7BYaQKgEdOa 6HFmdr+WOczOMrkG92vAdOoc1YkTJgzbTyOvKZpTPABTWqUMd2vjO78ZypI/hUY= =F/+0 -----END PGP SIGNATURE----- --0dPAKViiurfq9dDt27oTuoFw3DAxap3xA-- From nobody Wed Apr 8 22:13:30 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1E1B2B15; Wed, 8 Apr 2015 22:13:28 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waP5pBSAcHDG; Wed, 8 Apr 2015 22:13:27 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053551B2B11; Wed, 8 Apr 2015 22:13:26 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-75-5525b3eda6d7 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.1C.12456.DE3B5255; Thu, 9 Apr 2015 01:04:13 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 01:13:25 -0400 From: Suresh Krishnan To: Brian Haberman , "Templin, Fred L" , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQchzJd7ACryB46E+udp5LInzA1A== Date: Thu, 9 Apr 2015 05:13:24 +0000 Message-ID: References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXSPn+7bzaqhBnt3y1nM7PnHaNFweROz xflTU1gsbsy6yeLA4vH74BtmjyVLfjJ5zDz+hSWAOYrLJiU1J7MstUjfLoErY/vbG0wFu7gr tm5oYm5gXMDZxcjJISFgIvF5zxQmCFtM4sK99WwgtpDAUUaJpXvMuxi5gOxljBIt89aygCTY gBo27PzMBJIQEbjBKNE+6SYrSEJYwFFi5rwHQAkOoISTxJNzFSBhEQE9ickTIHpZBFQkDp+d D1bOK+Ar8WvzRHaIBe8ZJd6cuA62mRHoiu+n1oBdxCwgLnHryXyo6wQkluw5zwxhi0q8fPyP FcJWkvj4ez47RL2OxILdn9ggbG2JZQtfM0MsE5Q4OfMJywRGkVlIxs5C0jILScssJC0LGFlW MXKUFqeW5aYbGWxiBEbFMQk23R2Me15aHmIU4GBU4uF9sEQ1VIg1say4MvcQozQHi5I476IH B0OEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MFrcuvP7VXZCYKtZ7Xn3c66SEbOcE6vLbD59 ZZqqsEbQRjm06+SUIL1bl/wK18/cynozS7Tt553yP52yt3Q1zVW0lvZ+NLc3kblWt7ijsHDa Pt3U1XJvzF86PIjrLTt7PPBiq4lAvtek9IJorSetqXsUo8VvOX7bxXzH13/vweyuXzGTDmk3 KLEUZyQaajEXFScCANVGtCNrAgAA Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:13:28 -0000 Hi Brian,=0A= =0A= On 04/08/2015 06:18 PM, Brian Haberman wrote:=0A= > Fred,=0A= >=0A= > On 4/8/15 3:30 PM, Templin, Fred L wrote:=0A= >> To be constructive, one way forward would be to define a new field in th= e GRE=0A= >> header called the "fragment" field. It would be used to fragment the pay= load=0A= >> packet prior to encapsulating each fragment in a separate delivery heade= r.=0A= >> This would be an example of tunnel fragmentation as suggested in Section= =0A= >> 3.1.7 of RFC2764.=0A= >=0A= > That would be a fine proposal to write-up, but it does not belong in=0A= > this document. *This* document describes what vendors have implemented.= =0A= > It is an Informational document.=0A= =0A= Exactly.=0A= =0A= >=0A= > If anything were to go in this document, I could see an additional=0A= > description in the Security Considerations section that describes the=0A= > vulnerability you are concerned about.=0A= >=0A= > WG?=0A= =0A= This was discussed even before the document was adopted. The document =0A= was originally shooting for BCP and due to these concerns, all =0A= prescriptive text was removed and it became solely a description of =0A= existing (and widely deployed) implementations. I had summarized this in = =0A= the WG summary of the Shepherd writeup. I am not sure what to add to the = =0A= Security considerations of this draft, but it is worth exploring.=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Thu Apr 9 03:36:16 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8214F1B2E1E; Thu, 9 Apr 2015 03:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzuEvhZVkxPZ; Thu, 9 Apr 2015 03:36:09 -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 42A8A1B2E1F; Thu, 9 Apr 2015 03:36:06 -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 22BE9880CE; Thu, 9 Apr 2015 03:36:06 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9D36113682D4; Thu, 9 Apr 2015 03:36:05 -0700 (PDT) Message-ID: <55265614.2040609@innovationslab.net> Date: Thu, 09 Apr 2015 06:36:04 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Suresh Krishnan , "Templin, Fred L" , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AeMRsM7MnH0WSlPSwWACS6JinIWTEeQ9F" Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 10:36:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AeMRsM7MnH0WSlPSwWACS6JinIWTEeQ9F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Suresh, On 4/9/15 1:13 AM, Suresh Krishnan wrote: > Hi Brian, >=20 > On 04/08/2015 06:18 PM, Brian Haberman wrote: >> >> If anything were to go in this document, I could see an additional >> description in the Security Considerations section that describes the >> vulnerability you are concerned about. >> >> WG? >=20 > This was discussed even before the document was adopted. The document=20 > was originally shooting for BCP and due to these concerns, all=20 > prescriptive text was removed and it became solely a description of=20 > existing (and widely deployed) implementations. I had summarized this i= n=20 > the WG summary of the Shepherd writeup. I am not sure what to add to th= e=20 > Security considerations of this draft, but it is worth exploring. Given that Fred raised the issue, I would ask that he propose text for the Security Considerations section that the WG to consider. Regards, Brian --AeMRsM7MnH0WSlPSwWACS6JinIWTEeQ9F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJlYUAAoJEBOZRqCi7goqavwH/0ex5U/hy0MmDr0EiOUei3qJ 3xHSCqDp/MuNpC3zkQj2oXitQ7BVQfLUD0/icKW5ZN68Y0uvRZNoxgO9Jpb4ZQBU 6kMNhdinjxSaQ45r3Hzx5diSm38uBvExS/rfk8g4LRHN6oM1LRAvAcy9A69sByC1 SiQ8sG3WEBDBRylYmu3k0L0U84OyOfJjHxTAuDiLejFu1O/vMEulXo189sVwMgaT SmRrN4B5Nz4jUjrwcv1MxHn2LYEpilQ2/J4zhd+RPNKEHvEWpIoYjrc8Yx8EvEfc vcw4/UYidFCwv7WOWy8XRUlyrMwPbkBOamxZuSwyqg0laEiogISx6f620JrM1n0= =yDfd -----END PGP SIGNATURE----- --AeMRsM7MnH0WSlPSwWACS6JinIWTEeQ9F-- From nobody Thu Apr 9 10:01:31 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC86B1B2F39 for ; Thu, 9 Apr 2015 10:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccbdWDw2UHnF for ; Thu, 9 Apr 2015 10:01:27 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1660A1B2F38 for ; Thu, 9 Apr 2015 10:01:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t39H1PqJ022599; Thu, 9 Apr 2015 12:01:25 -0500 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t39H1GZJ022503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 9 Apr 2015 12:01:17 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.32]) with mapi id 14.03.0235.001; Thu, 9 Apr 2015 10:01:14 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AdBy5q5IGeB55GW+S/yodTwV/A/ZHQ== Date: Thu, 9 Apr 2015 17:01:13 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E42632@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:01:30 -0000 Hi Brian, > On 4/8/15 3:30 PM, Templin, Fred L wrote: > > To be constructive, one way forward would be to define a new field in t= he GRE > > header called the "fragment" field. It would be used to fragment the pa= yload > > packet prior to encapsulating each fragment in a separate delivery head= er. > > This would be an example of tunnel fragmentation as suggested in Sectio= n > > 3.1.7 of RFC2764. >=20 > That would be a fine proposal to write-up, but it does not belong in > this document. I wrote up a quick draft (see below). 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: Thursday, April 09, 2015 9:34 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-intarea-grefrag-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : GRE Tunnel Fragmentation Author : Fred L. Templin Filename : draft-templin-intarea-grefrag-00.txt Pages : 5 Date : 2015-04-09 Abstract: GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet when the delivery packet exceeds the tunnel MTU, or when otherwise necessary. This can cause problems when unmitigated IPv4 fragemntation ensues, or when middleboxes drop IPv6 fragments unconditionally. This document proposes GRE tunnel fragmentation which avoids these pitfalls.. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-intarea-grefrag/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-intarea-grefrag-00 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 nobody Thu Apr 9 10:37:22 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDE1B2FC6 for ; Thu, 9 Apr 2015 10:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E7oUQqsFEoG for ; Thu, 9 Apr 2015 10:37:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1698F1B2FC8 for ; Thu, 9 Apr 2015 10:37:12 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 17:36:52 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Thu, 9 Apr 2015 17:36:52 +0000 From: Ronald Bonica To: "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AdBy68Cf/m5vCwYuTRm3zy/U/pQ8rg== Date: Thu, 9 Apr 2015 17:36:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(51704005)(77156002)(40100003)(450100001)(50986999)(2351001)(86362001)(110136001)(122556002)(2501003)(62966003)(54356999)(107886001)(76576001)(102836002)(99286002)(2900100001)(33656002)(92566002)(230783001)(46102003)(19580395003)(74316001)(2656002)(87936001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0541031FF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2015 17:36:52.1336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:37:19 -0000 Fred, How would you achieve backwards compatibility with legacy implementations? = If backwards compatibility cannot be achieved, maybe you are talking about = a new protocol, that will ultimately replace GRE? Ron > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : GRE Tunnel Fragmentation > Author : Fred L. Templin > Filename : draft-templin-intarea-grefrag-00.txt > Pages : 5 > Date : 2015-04-09 >=20 > Abstract: > GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet > when the delivery packet exceeds the tunnel MTU, or when otherwise > necessary. This can cause problems when unmitigated IPv4 > fragemntation ensues, or when middleboxes drop IPv6 fragments > unconditionally. This document proposes GRE tunnel fragmentation > which avoids these pitfalls.. >=20 >=20 From nobody Thu Apr 9 10:44:04 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238BD1B2FF2 for ; Thu, 9 Apr 2015 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlK54-qE4OQm for ; Thu, 9 Apr 2015 10:44:01 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC82F1B2FEF for ; Thu, 9 Apr 2015 10:44:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t39Hi05R007714; Thu, 9 Apr 2015 12:44:00 -0500 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t39Hhtkq007177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Apr 2015 12:43:55 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.222]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 10:43:53 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AdBy68CfGeB55GW+S/yodTwV/A/ZHQAAF9BA Date: Thu, 9 Apr 2015 17:43:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E43824@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:44:03 -0000 Hi Ron, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bon= ica > Sent: Thursday, April 09, 2015 10:37 AM > To: int-area@ietf.org > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 > Fred, >=20 > How would you achieve backwards compatibility with legacy implementations= ? If backwards compatibility cannot be achieved, maybe > you are talking about a new protocol, that will ultimately replace GRE? Haven't thought about it too much, but I assume backwards compat would be handled in the same way that it was handled when RFC2784 was updated by RFC2890. That is why this document says "updates RFC2784 and RFC2890". Plus, two new bits have been carved out of the Reserved0 field in the GRE header and, if the bits are non-zero, it is a pretty good indication that the fragment header is included. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : GRE Tunnel Fragmentation > > Author : Fred L. Templin > > Filename : draft-templin-intarea-grefrag-00.txt > > Pages : 5 > > Date : 2015-04-09 > > > > Abstract: > > GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet > > when the delivery packet exceeds the tunnel MTU, or when otherwise > > necessary. This can cause problems when unmitigated IPv4 > > fragemntation ensues, or when middleboxes drop IPv6 fragments > > unconditionally. This document proposes GRE tunnel fragmentation > > which avoids these pitfalls.. > > > > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 9 11:03:22 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03511B305B; Thu, 9 Apr 2015 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5_SUjjbxKE8; Thu, 9 Apr 2015 11:03:09 -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 0226D1B3062; Thu, 9 Apr 2015 11:03:09 -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 D435C880D1; Thu, 9 Apr 2015 11:03:08 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8FBCD13682CB; Thu, 9 Apr 2015 11:03:03 -0700 (PDT) Message-ID: <5526BED6.1080608@innovationslab.net> Date: Thu, 09 Apr 2015 14:03:02 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Suresh Krishnan , "Templin, Fred L" , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> <55265614.2040609@innovationslab.net> In-Reply-To: <55265614.2040609@innovationslab.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BIMLHLESP9eGSKLr2CwQ8SG9421qhhIwE" Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:03:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BIMLHLESP9eGSKLr2CwQ8SG9421qhhIwE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/9/15 6:36 AM, Brian Haberman wrote: >=20 > Given that Fred raised the issue, I would ask that he propose text for > the Security Considerations section that the WG to consider. Will there be a text proposal for this or can the authors spin a new document based on the existing commentary? Regards, Brian --BIMLHLESP9eGSKLr2CwQ8SG9421qhhIwE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJr7WAAoJEBOZRqCi7goqGFMH/jREPIxMzrkWng1j6R1HwYV4 i6uUltJWGozF60WfVA9ZxZMglNgeDMADA7ggU+CXYleP9eAUUmraUN93gargZk1W OyZ3Eu208EIHB8D4rSz2IGJxYyNrM1YlIjBef/In44+4SHkCs1efHgW6jGcBEfZ1 DtN49UeRydYoQ1OEtP0qhcda8cTj65kIPO6vU54N15w06DkF4huLXQRevgz+eSvy oL0sdy29yhH4AGeAB0HdnS2CH9hSqx3SIHoiQ6Lo2KegaVyO6/lAetDzYxLzujSv zNDhqxXyE4e3zetcrTONKs46ZT/RvWwC6F4GIbJ7naaFps+3UK/nTpivjAIj1Ew= =aXwC -----END PGP SIGNATURE----- --BIMLHLESP9eGSKLr2CwQ8SG9421qhhIwE-- From nobody Thu Apr 9 11:13:05 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998071A0378; Thu, 9 Apr 2015 11:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGkUEo6EIRxF; Thu, 9 Apr 2015 11:13:03 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2165C1A0377; Thu, 9 Apr 2015 11:13:02 -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 t39ID1GE013205; Thu, 9 Apr 2015 11:13:01 -0700 Received: from XCH-BLV-205.nw.nos.boeing.com (xch-blv-205.nw.nos.boeing.com [10.57.37.61]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t39ICoFU012596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Apr 2015 11:12:51 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.19]) with mapi id 14.03.0235.001; Thu, 9 Apr 2015 11:12:50 -0700 From: "Templin, Fred L" To: Brian Haberman , Suresh Krishnan , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQchzRsT9xesxs4k2M4sj2j8uMmZ1DZcpAgAAYYACAAXy/E4AAAOhA Date: Thu, 9 Apr 2015 18:12:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E438D6@XCH-BLV-504.nw.nos.boeing.com> References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> <55265614.2040609@innovationslab.net> <5526BED6.1080608@innovationslab.net> In-Reply-To: <5526BED6.1080608@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:13:04 -0000 Hi Brian, I don't have plans of submitting a text proposal, but I have to say that th= is document concerns me on many levels. It essentially says that there are deployed implementations that do not honor the robustness principle and then seeks to bless them by noting the behavior in the RFC series. The presence of fragmentation should be an indication to network operators that something is out of tune and needs to be tuned. It should not be an excuse to take the tunnel down unconditionally. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Thursday, April 09, 2015 11:03 AM > To: Suresh Krishnan; Templin, Fred L; draft-ietf-intarea-gre-mtu@ietf.org= ; int-area@ietf.org > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 >=20 >=20 > On 4/9/15 6:36 AM, Brian Haberman wrote: > > > > Given that Fred raised the issue, I would ask that he propose text for > > the Security Considerations section that the WG to consider. >=20 > Will there be a text proposal for this or can the authors spin a new > document based on the existing commentary? >=20 > Regards, > Brian >=20 From nobody Thu Apr 9 11:13:18 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789E91A1A1B for ; Thu, 9 Apr 2015 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo51FwYgDODQ for ; Thu, 9 Apr 2015 11:13:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D80F1A1AA9 for ; Thu, 9 Apr 2015 11:13:09 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 18:12:53 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Thu, 9 Apr 2015 18:12:53 +0000 From: Ronald Bonica To: "Templin, Fred L" , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AdBy68Cf/m5vCwYuTRm3zy/U/pQ8rgAAP4GAAADuBQA= Date: Thu, 9 Apr 2015 18:12:52 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E43824@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E43824@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: boeing.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(13464003)(51704005)(377454003)(15975445007)(77156002)(40100003)(50986999)(76176999)(86362001)(122556002)(2501003)(62966003)(54356999)(107886001)(76576001)(102836002)(99286002)(2900100001)(33656002)(2950100001)(92566002)(230783001)(46102003)(19580395003)(74316001)(2656002)(87936001)(66066001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0541031FF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2015 18:12:52.9846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:13:15 -0000 Fred, What happens when a legacy device that supports 2784 and 2890 receives a pa= cket that is fragmented as per draft-ietf-intarea-gre-mtu? Is that behavior acceptable? = Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Thursday, April 09, 2015 1:44 PM > To: Ronald Bonica; int-area@ietf.org > Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 > Hi Ron, >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald > > Bonica > > Sent: Thursday, April 09, 2015 10:37 AM > > To: int-area@ietf.org > > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > Fred, > > > > How would you achieve backwards compatibility with legacy > > implementations? If backwards compatibility cannot be achieved, maybe > you are talking about a new protocol, that will ultimately replace GRE? >=20 > Haven't thought about it too much, but I assume backwards compat would > be handled in the same way that it was handled when RFC2784 was updated > by RFC2890. That is why this document says "updates RFC2784 and RFC2890". >=20 > Plus, two new bits have been carved out of the Reserved0 field in the GRE > header and, if the bits are non-zero, it is a pretty good indication that= the > fragment header is included. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Ron > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > > > > Title : GRE Tunnel Fragmentation > > > Author : Fred L. Templin > > > Filename : draft-templin-intarea-grefrag-00.txt > > > Pages : 5 > > > Date : 2015-04-09 > > > > > > Abstract: > > > GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet > > > when the delivery packet exceeds the tunnel MTU, or when otherwise > > > necessary. This can cause problems when unmitigated IPv4 > > > fragemntation ensues, or when middleboxes drop IPv6 fragments > > > unconditionally. This document proposes GRE tunnel fragmentation > > > which avoids these pitfalls.. > > > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 9 11:19:30 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C361B308D; Thu, 9 Apr 2015 11:19: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMl4uZyAVsH3; Thu, 9 Apr 2015 11:19:27 -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 81D1D1B30C1; Thu, 9 Apr 2015 11:18:55 -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 5C41B880D1; Thu, 9 Apr 2015 11:18:55 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5111813682CB; Thu, 9 Apr 2015 11:18:45 -0700 (PDT) Message-ID: <5526C289.30406@innovationslab.net> Date: Thu, 09 Apr 2015 14:18:49 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Suresh Krishnan , "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> <55265614.2040609@innovationslab.net> <5526BED6.1080608@innovationslab.net> <2134F8430051B64F815C691A62D9831832E438D6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E438D6@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CKoQ33wH2vtHNnxHRhGneebo2Ma9ua3W3" Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:19:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CKoQ33wH2vtHNnxHRhGneebo2Ma9ua3W3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fred, On 4/9/15 2:12 PM, Templin, Fred L wrote: > Hi Brian, >=20 > I don't have plans of submitting a text proposal, but I have to say tha= t this > document concerns me on many levels. It essentially says that there are= > deployed implementations that do not honor the robustness principle > and then seeks to bless them by noting the behavior in the RFC series. This is not blessing these behaviors. It is documenting what has been deployed. The goal is to provide sufficient information so that people understand what is going on since this approach is not standardized. If the WG felt it important to describe limitations/issues with the approach, it would be well within its right to do so in the document. There are plenty of examples of Informational RFCs describing deployed protocols not developed in the IETF. More than a few times, these efforts have helped operators understand observed behaviors or led to a standardization effort to fix issues identified in these Informational documents. Regards, Brian --CKoQ33wH2vtHNnxHRhGneebo2Ma9ua3W3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJsKJAAoJEBOZRqCi7goqq3gH/jBzbpt4VInCe1K6vyuNe1cY /GbDofordVlMFDK4IPvDU8cOZq/ZsZEhM6l3CHzpB+jEtl3KwxF7s/WYuzmCmgGM wOBPdXyMhh9NFEXHt1BZjB7tmUCSuaRu9VrwhFV5Nq2rG7zIu8MKROXwYMPSwITg AoZJQKw6ChdBIvTcnwz2slbJo5xU6X017W1w7SbeNCnbrnEAoo1Eh9ZL2nAlosYU DhXGaRstgl9aoLGR0tbllztUb4EZJQXc+T1HSnZAjaEP1XNZC8M6XvHfbWEUvRLp +UqdcVarXSo1TlO0M/aE2TULSoukpc/1OZMpI9AETCXeT0NT+DaTpg16s/xILJ4= =5Mbr -----END PGP SIGNATURE----- --CKoQ33wH2vtHNnxHRhGneebo2Ma9ua3W3-- From nobody Thu Apr 9 11:20:12 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E81A872A; Thu, 9 Apr 2015 11:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igscFNPABJuq; Thu, 9 Apr 2015 11:20:10 -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 EA91E1A86F3; Thu, 9 Apr 2015 11:20:09 -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 D4E06880D1; Thu, 9 Apr 2015 11:20:09 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 302DC13682CB; Thu, 9 Apr 2015 11:20:00 -0700 (PDT) Message-ID: <5526C2D8.3030106@innovationslab.net> Date: Thu, 09 Apr 2015 14:20:08 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "draft-ietf-intarea-gre-mtu@ietf.org" , "int-area@ietf.org" References: <55255D5B.7090007@innovationslab.net> <2134F8430051B64F815C691A62D9831832E381AB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E3845A@XCH-BLV-504.nw.nos.boeing.com> <5525A918.2000808@innovationslab.net> <55265614.2040609@innovationslab.net> <5526BED6.1080608@innovationslab.net> <2134F8430051B64F815C691A62D9831832E438D6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E438D6@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iKHOlXqWooGMpPUXjQfHkXNtCtfmjVsNo" Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:20:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iKHOlXqWooGMpPUXjQfHkXNtCtfmjVsNo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Given the below response, a new version should be generated based on my feedback and we can continue with the publication process. Regards, Brian On 4/9/15 2:12 PM, Templin, Fred L wrote: > Hi Brian, >=20 > I don't have plans of submitting a text proposal, but I have to say tha= t this > document concerns me on many levels. It essentially says that there are= > deployed implementations that do not honor the robustness principle > and then seeks to bless them by noting the behavior in the RFC series. >=20 > The presence of fragmentation should be an indication to network > operators that something is out of tune and needs to be tuned. It > should not be an excuse to take the tunnel down unconditionally. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: Brian Haberman [mailto:brian@innovationslab.net] >> Sent: Thursday, April 09, 2015 11:03 AM >> To: Suresh Krishnan; Templin, Fred L; draft-ietf-intarea-gre-mtu@ietf.= org; int-area@ietf.org >> Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >> >> >> >> On 4/9/15 6:36 AM, Brian Haberman wrote: >>> >>> Given that Fred raised the issue, I would ask that he propose text fo= r >>> the Security Considerations section that the WG to consider. >> >> Will there be a text proposal for this or can the authors spin a new >> document based on the existing commentary? >> >> Regards, >> Brian >> --iKHOlXqWooGMpPUXjQfHkXNtCtfmjVsNo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVJsLYAAoJEBOZRqCi7goqsPcIAI8uFxb2jOXXXezK8A3Jz9lb +rU+xDKu6LkO8tvIGoCHIO7+oNTsJGRE5yTMXxDFjXojb0tXmOQJpvse3Nokm/ts lU8o4FLWnzm2vf9sixcK/yfoSC7RYX1i6taa7lWt6LLHHeBNCuKzhp+Wbj9N5bsI Q5p/Okbu4Od3nG5ibWBQCSk91+9xdAS4kDeFIWFd8xjRN/nivtswqVZ4ENA4u0BE z9KTi4jYRC/m2MINGAs6DynnHEPgLKDazjcOuVDeeaUV5vNd82qwbtke97KGDvW5 jq6bWeGIA2uwDUMnp1EDkwOm1Q3JtAzHLMSR4i9FjO+WqTfblEO8fyJ00kDh2aU= =QUqP -----END PGP SIGNATURE----- --iKHOlXqWooGMpPUXjQfHkXNtCtfmjVsNo-- From nobody Thu Apr 9 11:30:13 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB55E1A8839 for ; Thu, 9 Apr 2015 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9t0G4L3vo_K for ; Thu, 9 Apr 2015 11:30:10 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E3E1A8830 for ; Thu, 9 Apr 2015 11:30:09 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t39ISS3B000329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Apr 2015 11:28:40 -0700 (PDT) Message-ID: <5526C4CB.2090903@isi.edu> Date: Thu, 09 Apr 2015 11:28:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ronald Bonica , "int-area@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:30:11 -0000 IMO, this doc should: - document existing default behavior - if needed, recommend SHOULD-level changes to that default behavior via currently-available configuration or deployment changes I.e., describe where it can be used in a way consistent with existing requirements, or indicate where that isn't the case and how it can be detected and what to do when that happens. I had already proposed a solution to this case, e.g., if the tunnel cannot support the required IPv6 (or IPv4, for that matter) minimums, it should shut itself down. I'd like to see the updated text before jumping to conclusions, but I don't think we need yet another new, undeployed solution. Joe On 4/9/2015 10:36 AM, Ronald Bonica wrote: > Fred, > > How would you achieve backwards compatibility with legacy implementations? If backwards compatibility cannot be achieved, maybe you are talking about a new protocol, that will ultimately replace GRE? > > Ron > > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : GRE Tunnel Fragmentation >> Author : Fred L. Templin >> Filename : draft-templin-intarea-grefrag-00.txt >> Pages : 5 >> Date : 2015-04-09 >> >> Abstract: >> GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet >> when the delivery packet exceeds the tunnel MTU, or when otherwise >> necessary. This can cause problems when unmitigated IPv4 >> fragemntation ensues, or when middleboxes drop IPv6 fragments >> unconditionally. This document proposes GRE tunnel fragmentation >> which avoids these pitfalls.. >> >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Thu Apr 9 11:48:19 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722101A87AB for ; Thu, 9 Apr 2015 11:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKPPetk_9DFC for ; Thu, 9 Apr 2015 11:48:07 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367081A875B for ; Thu, 9 Apr 2015 11:48:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t39Im5To031042; Thu, 9 Apr 2015 11:48:05 -0700 Received: from XCH-BLV-307.nw.nos.boeing.com (xch-blv-307.nw.nos.boeing.com [130.247.25.219]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t39Ilxw2030994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Apr 2015 11:47:59 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-307.nw.nos.boeing.com ([169.254.7.119]) with mapi id 14.03.0235.001; Thu, 9 Apr 2015 11:47:59 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AdBy68CfGeB55GW+S/yodTwV/A/ZHQAAF9BAAA/V6gAADa9K8A== Date: Thu, 9 Apr 2015 18:47:58 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E43A24@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E43824@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:48:12 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Thursday, April 09, 2015 11:13 AM > To: Templin, Fred L; int-area@ietf.org > Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 > Fred, >=20 > What happens when a legacy device that supports 2784 and 2890 receives a = packet that is fragmented That would only happen when an augmented ingress send a fragmented packet to a legacy egress that it knows nothing about - an unmanaged situation. Two solutions are 1) allow the ingress to use the augmented behavior when it knows that the egress also supports the behavior, or 2) send the egress a little test packet for which the egress can only respond if is supports the augmentation. > as per draft-ietf-intarea-gre-mtu? I think you meant per draft-templin-intarea-grefrag? > Is that behavior acceptable? The ingress should only use the augmented behavior when it knows that the egress also supports the behavior - e.g., via administrative configuration, test packet probing. etc. Thanks - Fred fred.l.templin@boeing.com > = Ron >=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Thursday, April 09, 2015 1:44 PM > > To: Ronald Bonica; int-area@ietf.org > > Subject: RE: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald > > > Bonica > > > Sent: Thursday, April 09, 2015 10:37 AM > > > To: int-area@ietf.org > > > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu > > > > > > Fred, > > > > > > How would you achieve backwards compatibility with legacy > > > implementations? If backwards compatibility cannot be achieved, maybe > > you are talking about a new protocol, that will ultimately replace GRE? > > > > Haven't thought about it too much, but I assume backwards compat would > > be handled in the same way that it was handled when RFC2784 was updated > > by RFC2890. That is why this document says "updates RFC2784 and RFC2890= ". > > > > Plus, two new bits have been carved out of the Reserved0 field in the G= RE > > header and, if the bits are non-zero, it is a pretty good indication th= at the > > fragment header is included. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > Ron > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > > > > Title : GRE Tunnel Fragmentation > > > > Author : Fred L. Templin > > > > Filename : draft-templin-intarea-grefrag-00.txt > > > > Pages : 5 > > > > Date : 2015-04-09 > > > > > > > > Abstract: > > > > GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packe= t > > > > when the delivery packet exceeds the tunnel MTU, or when otherwi= se > > > > necessary. This can cause problems when unmitigated IPv4 > > > > fragemntation ensues, or when middleboxes drop IPv6 fragments > > > > unconditionally. This document proposes GRE tunnel fragmentatio= n > > > > which avoids these pitfalls.. > > > > > > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > Int-area@ietf.org > > > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 9 12:14:17 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C641A8A9C for ; Thu, 9 Apr 2015 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46m8LiQdxqDa for ; Thu, 9 Apr 2015 12:13:57 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B860D1A8AB6 for ; Thu, 9 Apr 2015 12:13:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t39JDrPY009408; Thu, 9 Apr 2015 12:13:53 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t39JDkmu009348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 9 Apr 2015 12:13:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.90]) with mapi id 14.03.0235.001; Thu, 9 Apr 2015 12:13:46 -0700 From: "Templin, Fred L" To: Joe Touch , Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu Thread-Index: AQHQcvL4sT9xesxs4k2M4sj2j8uMmZ1FCWhw Date: Thu, 9 Apr 2015 19:13:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E43AB7@XCH-BLV-504.nw.nos.boeing.com> References: <5526C4CB.2090903@isi.edu> In-Reply-To: <5526C4CB.2090903@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 19:14:06 -0000 Hi Joe, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, April 09, 2015 11:28 AM > To: Ronald Bonica; int-area@ietf.org > Subject: Re: [Int-area] AD Evaluation: draft-ietf-intarea-gre-mtu >=20 > IMO, this doc should: >=20 > - document existing default behavior >=20 > - if needed, recommend SHOULD-level changes to > that default behavior via currently-available > configuration or deployment changes >=20 > I.e., describe where it can be used in a way consistent with existing > requirements, or indicate where that isn't the case and how it can be > detected and what to do when that happens. >=20 > I had already proposed a solution to this case, e.g., if the tunnel > cannot support the required IPv6 (or IPv4, for that matter) minimums, it > should shut itself down. There is lots of deployed kit out there that does not do this. Pretty much anything that is based on RFC4213 (and there is a lot of that) just lets it fragment. That is bad in a lot of ways (e.g., RFC4963, RFC6864, etc.) but that is what is out there. Shutting down tunnels over IPv6 makes no sense to me, because IPv6 frag/reass work (modulo paths that drop IPv6 fragments, I guess). Shutting down tunnels over IPv4 sounds tempting, but can be avoided if the ingress institutes rate limiting. But, institution of tunnel fragmentation per draft-templin-intarea-grefrag, draft-templin-aerolink and the others avoids these pitfalls and can keep the tunnel up at least long enough for operators to diagnose the cause of fragmentation if necessary. Fragmentation is there to support the robustness principle. Shutting down tunnels for fear of a little fragmentation is not robust. Thanks - Fred fred.l.templin@boeing.com > I'd like to see the updated text before jumping to conclusions, but I > don't think we need yet another new, undeployed solution. >=20 > Joe >=20 > On 4/9/2015 10:36 AM, Ronald Bonica wrote: > > Fred, > > > > How would you achieve backwards compatibility with legacy implementatio= ns? If backwards compatibility cannot be achieved, > maybe you are talking about a new protocol, that will ultimately replace = GRE? > > > > Ron > > > > > >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. > >> > >> > >> Title : GRE Tunnel Fragmentation > >> Author : Fred L. Templin > >> Filename : draft-templin-intarea-grefrag-00.txt > >> Pages : 5 > >> Date : 2015-04-09 > >> > >> Abstract: > >> GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet > >> when the delivery packet exceeds the tunnel MTU, or when otherwise > >> necessary. This can cause problems when unmitigated IPv4 > >> fragemntation ensues, or when middleboxes drop IPv6 fragments > >> unconditionally. This document proposes GRE tunnel fragmentation > >> which avoids these pitfalls.. > >> > >> > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 9 13:55:15 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CA11B32A1; Thu, 9 Apr 2015 13:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZg2etp8NrRf; Thu, 9 Apr 2015 13:55:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E921B329A; Thu, 9 Apr 2015 13:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409205509.7515.76470.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 13:55:09 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-mtu-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:55:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem Authors : Ron Bonica Carlos Pignataro Joe Touch Filename : draft-ietf-intarea-gre-mtu-02.txt Pages : 10 Date : 2015-04-09 Abstract: This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-gre-mtu-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-mtu-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 9 13:57:40 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4673B1B32C3; Thu, 9 Apr 2015 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DSe8OW8-UyE; Thu, 9 Apr 2015 13:57:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CEE1B32BE; Thu, 9 Apr 2015 13:57:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409205737.10780.45084.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 13:57:37 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:57:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : IPv6 Support for Generic Routing Encapsulation (GRE) Authors : Carlos Pignataro Ron Bonica Suresh Krishnan Filename : draft-ietf-intarea-gre-ipv6-05.txt Pages : 8 Date : 2015-04-09 Abstract: Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. It updates the GRE specification, RFC 2784. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 9 14:03:21 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C29E1B3308; Thu, 9 Apr 2015 14:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSkK4TW0yPZL; Thu, 9 Apr 2015 14:03:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139CB1B3300; Thu, 9 Apr 2015 14:03:07 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 21:02:49 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Thu, 9 Apr 2015 21:02:49 +0000 From: Ronald Bonica To: "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQcwfSHRL6IJKFxUecEJirrd5rvJ1FKqxw Date: Thu, 9 Apr 2015 21:02:49 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> In-Reply-To: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(377424004)(2900100001)(19580395003)(450100001)(2950100001)(19580405001)(92566002)(62966003)(50986999)(87936001)(86362001)(46102003)(2501003)(76576001)(107886001)(33656002)(122556002)(1720100001)(15975445007)(54356999)(74316001)(106116001)(77156002)(102836002)(76176999)(66066001)(2656002)(99286002)(2420400003)(230783001)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 0541031FF6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2015 21:02:49.1193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:03:19 -0000 Rm9sa3MsDQoNCkkgaGF2ZSB1cGRhdGVkIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni4gUGxl YXNlIHRlbGwgbWUgaWYgSSBoYXZlIGFkZHJlc3NlZCBhbGwgb2YgeW91ciBjb21tZW50cy4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNk YXksIEFwcmlsIDA5LCAyMDE1IDQ6NTggUE0NCj4gVG86IFJvbmFsZCBCb25pY2E7IFN1cmVzaCBL cmlzaG5hbjsgU3VyZXNoIEtyaXNobmFuOyBDYXJsb3MgUGlnbmF0YXJvOw0KPiBSb25hbGQgQm9u aWNhOyBDYXJsb3MgUGlnbmF0YXJvDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2LTA1LnR4dA0KPiANCj4gDQo+IEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYtMDUudHh0DQo+IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmljYSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaWV0Zi1pbnRhcmVh LWdyZS1pcHY2DQo+IFJldmlzaW9uOgkwNQ0KPiBUaXRsZToJCUlQdjYgU3VwcG9ydCBmb3IgR2Vu ZXJpYyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24gKEdSRSkNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNS0w NC0xMA0KPiBHcm91cDoJCWludGFyZWENCj4gUGFnZXM6CQk4DQo+IFVSTDogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWludGFyZWEtZ3Jl LWlwdjYtDQo+IDA1LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2Lw0KPiBIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLWdyZS1pcHY2 LTA1DQo+IERpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYtMDUNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBHZW5l cmljIFJvdXRpbmcgRW5jYXBzdWxhdGlvbiAoR1JFKSBjYW4gYmUgdXNlZCB0byBjYXJyeSBhbnkg bmV0d29yay0NCj4gICAgbGF5ZXIgcGF5bG9hZCBwcm90b2NvbCBvdmVyIGFueSBuZXR3b3JrLWxh eWVyIGRlbGl2ZXJ5IHByb3RvY29sLiAgR1JFDQo+ICAgIHByb2NlZHVyZXMgYXJlIHNwZWNpZmll ZCBmb3IgSVB2NCwgdXNlZCBhcyBlaXRoZXIgdGhlIHBheWxvYWQgb3INCj4gICAgZGVsaXZlcnkg cHJvdG9jb2wuICBIb3dldmVyLCBHUkUgcHJvY2VkdXJlcyBhcmUgbm90IHNwZWNpZmllZCBmb3IN Cj4gICAgSVB2Ni4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIEdSRSBwcm9jZWR1 cmVzIGZvciBJUHY2LCB1c2VkIGFzIGVpdGhlciB0aGUNCj4gICAgcGF5bG9hZCBvciBkZWxpdmVy eSBwcm90b2NvbC4gIEl0IHVwZGF0ZXMgdGhlIEdSRSBzcGVjaWZpY2F0aW9uLCBSRkMNCj4gICAg Mjc4NC4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Apr 9 14:14:58 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6E91B3297; Thu, 9 Apr 2015 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir5mgLFUliBl; Thu, 9 Apr 2015 14:14:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDBD1B327A; Thu, 9 Apr 2015 14:14:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUR23682; Thu, 09 Apr 2015 21:14:51 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 22:14:51 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 14:14:38 -0700 From: Lucy yong To: Ronald Bonica , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQcwfSHRL6IJKFxUecEJirrd5rvJ1FKqxwgAACbyA= Date: Thu, 9 Apr 2015 21:14:38 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:14:56 -0000 Hi Ron, Security considerations should state that IPsec [RFC4301] can be used to pr= ovide payload security and privacy over an IP network where the security is= a concern. Thanks, Lucy=20 -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bonic= a Sent: Thursday, April 09, 2015 4:03 PM To: int-area@ietf.org; ipv6@ietf.org Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre= -ipv6-05.txt Folks, I have updated draft-ietf-intarea-gre-ipv6. Please tell me if I have addres= sed all of your comments. Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, April 09, 2015 4:58 PM > To: Ronald Bonica; Suresh Krishnan; Suresh Krishnan; Carlos Pignataro;=20 > Ronald Bonica; Carlos Pignataro > Subject: New Version Notification for=20 > draft-ietf-intarea-gre-ipv6-05.txt >=20 >=20 > A new version of I-D, draft-ietf-intarea-gre-ipv6-05.txt > has been successfully submitted by Ron Bonica and posted to the IETF=20 > repository. >=20 > Name: draft-ietf-intarea-gre-ipv6 > Revision: 05 > Title: IPv6 Support for Generic Routing Encapsulation (GRE) > Document date: 2015-04-10 > Group: intarea > Pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-ietf-intarea-gr= e-ipv6- > 05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-i= pv6/ > Htmlized: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-05 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-gre= -ipv6-05 >=20 > Abstract: > Generic Routing Encapsulation (GRE) can be used to carry any network- > layer payload protocol over any network-layer delivery protocol. GRE > procedures are specified for IPv4, used as either the payload or > delivery protocol. However, GRE procedures are not specified for > IPv6. >=20 > This document specifies GRE procedures for IPv6, used as either the > payload or delivery protocol. It updates the GRE specification, RFC > 2784. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 9 15:10:18 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812521B340D; Thu, 9 Apr 2015 15:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VymTGRF3LOIN; Thu, 9 Apr 2015 15:10:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95E1B3402; Thu, 9 Apr 2015 15:10:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 15:10:14 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:10:15 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 10 01:00:29 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613561B2A85; Fri, 10 Apr 2015 01:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ0uDHoEeJBP; Fri, 10 Apr 2015 01:00:19 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670131B2A84; Fri, 10 Apr 2015 01:00:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3A80GZA014447; Fri, 10 Apr 2015 09:00:16 +0100 Received: from 950129200 (089144218118.atnat0027.highway.a1.net [89.144.218.118]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3A80D44014424 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 09:00:15 +0100 From: "Adrian Farrel" To: References: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> In-Reply-To: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:00:16 +0100 Message-ID: <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLmTmiwoLCkyyB7V8Qb3jH7T8Wn8psaKsUQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21464.004 X-TM-AS-Result: No--9.393-10.0-31-10 X-imss-scan-details: No--9.393-10.0-31-10 X-TMASE-MatchedRID: csPTYAMX1+FfsB4HYR80ZggKAWhuC2ojCckvlPjoBZEKu26FJul59Gn7 AlTb8W2xuRdJYGhEyFIx+V4PxjuhskI69L22RjXL8eSmTJSmEv07UrmIzxDooMi9AjK6C8p1Pzq yGxd2DMbjYPnqQG+98VXaVsiwbCGFDCWUT3P4Uqe8coKUcaOOvUvE+2pLwGbnmyS5fP0Zp2Tlnb BfOj9S72ZpEMu9ZmOnkZOl7WKIImq0P2qkGU0XytAtbEEX0MxBxEHRux+uk8jHUU+U0ACZwDa1O xUd7PfooCBicOTsxY11n9K8lQ+bl2y+pxSCv13Jnqg/VrSZEiM= Archived-At: Cc: int-area@ietf.org Subject: Re: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:00:26 -0000 I have read this document and consider it a useful addition to the material on GRE that will help new implementations arrive at an interoperable solution. Trivially I wondered whether there was a need for 3.3.2.3. Tunneling GRE Over MPLS Thanks, Adrian > The IESG has received a request from the Internet Area Working Group WG > (intarea) to consider the following document: > - 'A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) > Fragmentation Problem' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-23. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. From nobody Fri Apr 10 06:21:49 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5EB1B354E; Fri, 10 Apr 2015 06:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR32VSit0G0T; Fri, 10 Apr 2015 06:21:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3051B3544; Fri, 10 Apr 2015 06:21:45 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 13:21:25 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 13:21:25 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 13:21:24 +0000 From: Ronald Bonica To: Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQcwrDp9dxYEBnxUmM6NRkqzG+ep1GOwxA Date: Fri, 10 Apr 2015 13:21:23 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB521; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(377454003)(377424004)(13464003)(74316001)(107886001)(19580395003)(19580405001)(46102003)(2656002)(54356999)(50986999)(76176999)(106116001)(2900100001)(86362001)(2950100001)(92566002)(33656002)(230783001)(15975445007)(87936001)(2201001)(99286002)(40100003)(62966003)(66066001)(76576001)(2501003)(1720100001)(122556002)(102836002)(2420400003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB444; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444; x-forefront-prvs: 054231DC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 13:21:23.8050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 13:21:48 -0000 Hi Lucy, MPLS over GRE [RFC 4023] has exactly the same security issues as IPv6 over = GRE. Fortunately, RFC 4023 has an extensive Security Considerations section= that references IPSec. So, the current document references RFC 4023 and ge= ts IPSec through one layer of indirection. = Ron > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Thursday, April 09, 2015 5:15 PM > To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > Subject: RE: [Int-area] FW: New Version Notification for draft-ietf-intar= ea- > gre-ipv6-05.txt >=20 > Hi Ron, >=20 > Security considerations should state that IPsec [RFC4301] can be used to > provide payload security and privacy over an IP network where the securit= y is > a concern. >=20 > Thanks, > Lucy >=20 > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald > Bonica > Sent: Thursday, April 09, 2015 4:03 PM > To: int-area@ietf.org; ipv6@ietf.org > Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-g= re- > ipv6-05.txt >=20 > Folks, >=20 > I have updated draft-ietf-intarea-gre-ipv6. Please tell me if I have addr= essed > all of your comments. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, April 09, 2015 4:58 PM > > To: Ronald Bonica; Suresh Krishnan; Suresh Krishnan; Carlos Pignataro; > > Ronald Bonica; Carlos Pignataro > > Subject: New Version Notification for > > draft-ietf-intarea-gre-ipv6-05.txt > > > > > > A new version of I-D, draft-ietf-intarea-gre-ipv6-05.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-ietf-intarea-gre-ipv6 > > Revision: 05 > > Title: IPv6 Support for Generic Routing Encapsulation (GRE) > > Document date: 2015-04-10 > > Group: intarea > > Pages: 8 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-intarea-= gre-ipv6- > > 05.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre= -ipv6/ > > Htmlized: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-= 05 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-g= re-ipv6-05 > > > > Abstract: > > Generic Routing Encapsulation (GRE) can be used to carry any network= - > > layer payload protocol over any network-layer delivery protocol. GR= E > > procedures are specified for IPv4, used as either the payload or > > delivery protocol. However, GRE procedures are not specified for > > IPv6. > > > > This document specifies GRE procedures for IPv6, used as either the > > payload or delivery protocol. It updates the GRE specification, RFC > > 2784. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > The IETF Secretariat >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Apr 10 06:50:52 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D881B2F9C for ; Fri, 10 Apr 2015 05:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyCpzGfQMTs4 for ; Fri, 10 Apr 2015 05:26:17 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 2A47E1B2F94 for ; Fri, 10 Apr 2015 05:26:16 -0700 (PDT) Received: (qmail 36025 invoked from network); 10 Apr 2015 12:11:34 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 10 Apr 2015 12:11:34 -0000 Message-ID: <5527C160.1090505@necom830.hpcl.titech.ac.jp> Date: Fri, 10 Apr 2015 21:26:08 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> In-Reply-To: <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 06:50:51 -0700 Cc: int-area@ietf.org Subject: Re: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 12:26:18 -0000 As the draft says; o When the GRE ingress node receives a non-fragmentable packet with length greater than the GMTU, it discards the packet and send an ICMP PTB message to the packet's source. the draft should clearly state that, if GMTU<1280B, it is a violation of the following requirement of RFC2460: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. and that 1280B IPv6 packets can not be carried over IPv6 with the default GRE configuration. It is especially so, because, according to the draft: Typically, GRE ingress nodes further refine their GMTU estimate by executing PMTUD procedures. However, if an implementation supports PMTUD for GRE tunnels, it also includes a configuration option that disables PMTUD. This configuration option is required to mitigate certain denial of service attacks (see Section 5). PMTUD is often turned off and, then, RFC2460 requires GMTU<1280B. Also, I think the paragraph above is not very honest on the reason why PMTUD is often turned off. Masataka Ohta From nobody Fri Apr 10 07:41:20 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEB41A024E; Fri, 10 Apr 2015 07:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2xtNz4TrkOx; Fri, 10 Apr 2015 07:41:18 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEAC1A0074; Fri, 10 Apr 2015 07:41:17 -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 t3AEfHFS003048; Fri, 10 Apr 2015 07:41:17 -0700 Received: from XCH-BLV-204.nw.nos.boeing.com (xch-blv-204.nw.nos.boeing.com [10.57.37.58]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3AEfD9d003033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 10 Apr 2015 07:41:14 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-204.nw.nos.boeing.com ([169.254.4.225]) with mapi id 14.03.0235.001; Fri, 10 Apr 2015 07:41:13 -0700 From: "Templin, Fred L" To: Masataka Ohta , "ietf@ietf.org" Thread-Topic: Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC Thread-Index: AQLmTmiwoLCkyyB7V8Qb3jH7T8Wn8psaKsUQgADAzQD//690wA== Date: Fri, 10 Apr 2015 14:41:13 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4465C@XCH-BLV-504.nw.nos.boeing.com> References: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> <5527C160.1090505@necom830.hpcl.titech.ac.jp> In-Reply-To: <5527C160.1090505@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: "int-area@ietf.org" Subject: Re: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 14:41:19 -0000 Hi, > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Masataka Ohta > Sent: Friday, April 10, 2015 5:26 AM > To: ietf@ietf.org > Cc: int-area@ietf.org > Subject: Re: Last Call: (A Widely-Dep= loyed Solution To The Generic Routing Encapsulation (GRE) > Fragmentation Problem) to Informational RFC >=20 > As the draft says; >=20 > o When the GRE ingress node receives a non-fragmentable packet with > length greater than the GMTU, it discards the packet and send an > ICMP PTB message to the packet's source. >=20 > the draft should clearly state that, if GMTU<1280B, it is a violation > of the following requirement of RFC2460: >=20 > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and reassembly must > be provided at a layer below IPv6. >=20 > and that 1280B IPv6 packets can not be carried over IPv6 with the > default GRE configuration. We have been through this already. They want to say that widely deployed implementations already ignore this requirement and so they want to document the behavior to make it all OK. The non-robustness principle in action. Thanks - Fred fred.l.templin@boeing.com > It is especially so, because, according to the draft: >=20 > Typically, GRE ingress nodes further refine their GMTU estimate by > executing PMTUD procedures. However, if an implementation supports > PMTUD for GRE tunnels, it also includes a configuration option that > disables PMTUD. This configuration option is required to mitigate > certain denial of service attacks (see Section 5). >=20 > PMTUD is often turned off and, then, RFC2460 requires GMTU<1280B. >=20 > Also, I think the paragraph above is not very honest on the reason > why PMTUD is often turned off. >=20 > Masataka Ohta From nobody Fri Apr 10 10:31:16 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF11A88C1; Fri, 10 Apr 2015 10:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fwxK6KANN1i; Fri, 10 Apr 2015 10:31:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C851A885B; Fri, 10 Apr 2015 10:31:10 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 17:31:08 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 17:31:08 +0000 From: Ronald Bonica To: Masataka Ohta , "ietf@ietf.org" Thread-Topic: Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC Thread-Index: AQLmTmiwoLCkyyB7V8Qb3jH7T8Wn8psaKsUQgABLdACAACr3sA== Date: Fri, 10 Apr 2015 17:31:08 +0000 Message-ID: References: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> <5527C160.1090505@necom830.hpcl.titech.ac.jp> In-Reply-To: <5527C160.1090505@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: necom830.hpcl.titech.ac.jp; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(92566002)(230783001)(87936001)(46102003)(33656002)(54356999)(50986999)(76176999)(2950100001)(2900100001)(86362001)(2656002)(19580405001)(19580395003)(74316001)(102836002)(2501003)(76576001)(66066001)(122556002)(77156002)(62966003)(99286002)(106116001)(41533002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 054231DC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 17:31:08.4780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 17:31:12 -0000 Masataka, Thanks for your thoughtful review. Would your concern be addressed if we ad= ded the text below? Ron TEXT =3D=3D=3D=3D 2.2.1. RFC 2460 Compliance OLD> The solution described above is widely-deployed on the Internet in its defa= ult configuration. The solution described above is widely-deployed on the Internet in its defa= ult configuration. However, the default configuration is not always appropr= iate for GRE tunnels that carry IPv6. IPv6 requires that every link in the Internet have an MTU of 1280 octets or= greater. On any link that cannot convey a 1280-octet packet in one piece,= link-specific fragmentation and reassembly must be provided at a layer bel= ow IPv6. =20 Therefore, the default configuration is appropriate for tunnels that carry = IPv6 only if the network is engineered so that the GMTU is guaranteed to be= 1280-bytes or greater. In all other scenarios, a non-default configuration= is required.=20 In the non-default configuration, when the GRE ingress router receives a pa= cket lager than the GMTU, the GRE ingress router encapsulates the entire pa= cket in a single GRE and delivery header. It then fragments the delivery he= ader and sends the resulting fragments to the GRE egress, where they are re= assembled. -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Masataka Ohta > Sent: Friday, April 10, 2015 8:26 AM > To: ietf@ietf.org > Cc: int-area@ietf.org > Subject: Re: Last Call: (A Widely- > Deployed Solution To The Generic Routing Encapsulation (GRE) > Fragmentation Problem) to Informational RFC >=20 > As the draft says; >=20 > o When the GRE ingress node receives a non-fragmentable packet with > length greater than the GMTU, it discards the packet and send an > ICMP PTB message to the packet's source. >=20 > the draft should clearly state that, if GMTU<1280B, it is a violation of = the > following requirement of RFC2460: >=20 > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and reassembly must > be provided at a layer below IPv6. >=20 > and that 1280B IPv6 packets can not be carried over IPv6 with the default= GRE > configuration. >=20 > It is especially so, because, according to the draft: >=20 > Typically, GRE ingress nodes further refine their GMTU estimate by > executing PMTUD procedures. However, if an implementation supports > PMTUD for GRE tunnels, it also includes a configuration option that > disables PMTUD. This configuration option is required to mitigate > certain denial of service attacks (see Section 5). >=20 > PMTUD is often turned off and, then, RFC2460 requires GMTU<1280B. >=20 > Also, I think the paragraph above is not very honest on the reason why > PMTUD is often turned off. >=20 > Masataka Ohta From nobody Fri Apr 10 12:00:39 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CE01B2E23 for ; Fri, 10 Apr 2015 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjM6HvIagTlZ for ; Fri, 10 Apr 2015 12:00:36 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 137B11B2E20 for ; Fri, 10 Apr 2015 12:00:26 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 10 Apr 2015 14:00:24 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f172.google.com [209.85.223.172] #+LO+TS+TR X-Umn-Classification: local Received: by iebrs15 with SMTP id rs15so24795996ieb.3 for ; Fri, 10 Apr 2015 12:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bgSHpm+ELmZx6veZn2pPcB5MBEwzxYSGWcl3G/lSo4A=; b=NzHtxArdAP2iP5HIbC/PKjPG2dkuHJwdWDQna9ttosa+mnK7KtjT74WFcq1ovQnu5N qHwa1MEujTXhfunsh7C5MC3bPph2EnDzQ5RUeoHznlDvCvmhQAOG6KX78BFz7tMQ6WBs 5YHahW3He+X104fAFa5lAJ3/2Twh8BGreuz4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bgSHpm+ELmZx6veZn2pPcB5MBEwzxYSGWcl3G/lSo4A=; b=H+UDZMKqS2w7YUw87B6jlrHfgD0XdNmGr+dfGoXyh1MsxpsvzpbFoUKj38vnlXqDJm rwH6zMOb+E99B515J6urv/ymB9WDmEaZn9XnRfO0PfuWIH9uhVA2UBRVUtTcWw6zsRHt JLnNQ7uYVKZb17Z3UCdbG5J1S4chWOUerBkkVg1Rwn/mLxiTvo9LcejdE/OhWwlCgboe pOcuPqa1oSC52AeLfHqYsnhhCHlU8kRSkWaBJs7gpi9C7fdhfqP1cSkH79WEJqNEmDCi 0+Ru19mMhi4DRNoT0pkJ0plyVqp31IODEMLYXkkRn4AmqXpxGjIHtlosfGp2dHos58Zk 0M6w== X-Received: by 10.51.17.40 with SMTP id gb8mr375004igd.44.1428691936088; Fri, 10 Apr 2015 11:52:16 -0700 (PDT) X-Gm-Message-State: ALoCoQnWFLTyhTWcZVUF2R/DhFGQhxjS8Ewo3Ei7mMs0LAgC9/vP4aA9KIbRYfFFl5e1cxBS7qGdVyRBS7GzFNgwoukZHIYo5ug4vfcGmJ06//ur2opC3OYGsKTj2IMioeOI7IIiXorA X-Received: by 10.51.17.40 with SMTP id gb8mr374971igd.44.1428691935761; Fri, 10 Apr 2015 11:52:15 -0700 (PDT) Received: from x-160-94-246-22.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:8460:f194:7c3a:cdb1]) by mx.google.com with ESMTPSA id i80sm1623925iod.6.2015.04.10.11.52.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 11:52:14 -0700 (PDT) Message-ID: <55281BDB.1040804@umn.edu> Date: Fri, 10 Apr 2015 13:52:11 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Farmer Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 19:00:38 -0000 I agree with Lucy, I'd like to see a direct reference to IPsec. How about something like what Lucy had and then reference RFC 4023 for a more extensive discussion. IPsec [RFC4301] can be used to provide payload security and privacy over an IP network where security is a concern, the Security Considerations section of MPLS in GRE [RFC4023] discusses this more extensively and applies equally to the current specification. Beyond that, the current specification introduces no security considerations beyond those mentioned in RFC 2784. I'd like to see general security references for IPv6 and tunnels included as well, maybe something like the following as a second paragraph. More generically, security considerations for IPv6 are discussed in [RFC4942], operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and security concerns for tunnels in general are discussed in [RFC6169]. Thanks On 4/10/15 08:21 , Ronald Bonica wrote: > Hi Lucy, > > MPLS over GRE [RFC 4023] has exactly the same security issues as IPv6 over GRE. Fortunately, RFC 4023 has an extensive Security Considerations section that references IPSec. So, the current document references RFC 4023 and gets IPSec through one layer of indirection. > > Ron > > >> -----Original Message----- >> From: Lucy yong [mailto:lucy.yong@huawei.com] >> Sent: Thursday, April 09, 2015 5:15 PM >> To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org >> Subject: RE: [Int-area] FW: New Version Notification for draft-ietf-intarea- >> gre-ipv6-05.txt >> >> Hi Ron, >> >> Security considerations should state that IPsec [RFC4301] can be used to >> provide payload security and privacy over an IP network where the security is >> a concern. >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald >> Bonica >> Sent: Thursday, April 09, 2015 4:03 PM >> To: int-area@ietf.org; ipv6@ietf.org >> Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre- >> ipv6-05.txt >> >> Folks, >> >> I have updated draft-ietf-intarea-gre-ipv6. Please tell me if I have addressed >> all of your comments. >> >> Ron >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, April 09, 2015 4:58 PM >>> To: Ronald Bonica; Suresh Krishnan; Suresh Krishnan; Carlos Pignataro; >>> Ronald Bonica; Carlos Pignataro >>> Subject: New Version Notification for >>> draft-ietf-intarea-gre-ipv6-05.txt >>> >>> >>> A new version of I-D, draft-ietf-intarea-gre-ipv6-05.txt >>> has been successfully submitted by Ron Bonica and posted to the IETF >>> repository. >>> >>> Name: draft-ietf-intarea-gre-ipv6 >>> Revision: 05 >>> Title: IPv6 Support for Generic Routing Encapsulation (GRE) >>> Document date: 2015-04-10 >>> Group: intarea >>> Pages: 8 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-intarea-gre-ipv6- >>> 05.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ >>> Htmlized: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-05 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-05 >>> >>> Abstract: >>> Generic Routing Encapsulation (GRE) can be used to carry any network- >>> layer payload protocol over any network-layer delivery protocol. GRE >>> procedures are specified for IPv4, used as either the payload or >>> delivery protocol. However, GRE procedures are not specified for >>> IPv6. >>> >>> This document specifies GRE procedures for IPv6, used as either the >>> payload or delivery protocol. It updates the GRE specification, RFC >>> 2784. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Fri Apr 10 14:56:37 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577291B2D72; Fri, 10 Apr 2015 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaPqu9o0MjG6; Fri, 10 Apr 2015 14:56:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A551B2D6C; Fri, 10 Apr 2015 14:56:31 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 21:56:12 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 21:56:11 +0000 From: Ronald Bonica To: David Farmer , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQc795MeXvxGLYck68SuOpfDNlq51Gyn2A Date: Fri, 10 Apr 2015 21:56:11 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> In-Reply-To: <55281BDB.1040804@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: umn.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(24454002)(479174004)(377424004)(164054003)(252514010)(40100003)(2420400003)(99286002)(1720100001)(50986999)(230783001)(92566002)(2201001)(54356999)(15975445007)(102836002)(122556002)(2900100001)(74316001)(77156002)(62966003)(46102003)(2501003)(33656002)(86362001)(93886004)(76176999)(19580405001)(19580395003)(66066001)(2656002)(2171001)(2950100001)(106116001)(87936001)(107886001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; x-forefront-prvs: 054231DC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 21:56:11.4205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:56:34 -0000 David, Works for me. I will spin a new version that includes this text. Ron > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Friday, April 10, 2015 2:52 PM > To: Ronald Bonica; Lucy yong; int-area@ietf.org; ipv6@ietf.org > Cc: David Farmer > Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intar= ea- > gre-ipv6-05.txt >=20 > I agree with Lucy, I'd like to see a direct reference to IPsec. How about > something like what Lucy had and then reference RFC 4023 for a more > extensive discussion. >=20 > IPsec [RFC4301] can be used to provide payload security and privacy > over an IP network where security is a concern, the Security > Considerations section of MPLS in GRE [RFC4023] discusses this more > extensively and applies equally to the current specification. Beyond > that, the current specification introduces no security > considerations beyond those mentioned in RFC 2784. >=20 > I'd like to see general security references for IPv6 and tunnels included= as > well, maybe something like the following as a second paragraph. >=20 > More generically, security considerations for IPv6 are discussed in > [RFC4942], operational security for IPv6 is discussed in > [I-D.ietf-opsec-v6], and security concerns for tunnels in general are > discussed in [RFC6169]. >=20 > Thanks >=20 > On 4/10/15 08:21 , Ronald Bonica wrote: > > Hi Lucy, > > > > MPLS over GRE [RFC 4023] has exactly the same security issues as IPv6 o= ver > GRE. Fortunately, RFC 4023 has an extensive Security Considerations secti= on > that references IPSec. So, the current document references RFC 4023 and > gets IPSec through one layer of indirection. > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Lucy yong [mailto:lucy.yong@huawei.com] > >> Sent: Thursday, April 09, 2015 5:15 PM > >> To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > >> Subject: RE: [Int-area] FW: New Version Notification for > >> draft-ietf-intarea- gre-ipv6-05.txt > >> > >> Hi Ron, > >> > >> Security considerations should state that IPsec [RFC4301] can be used > >> to provide payload security and privacy over an IP network where the > >> security is a concern. > >> > >> Thanks, > >> Lucy > >> > >> -----Original Message----- > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald > >> Bonica > >> Sent: Thursday, April 09, 2015 4:03 PM > >> To: int-area@ietf.org; ipv6@ietf.org > >> Subject: [Int-area] FW: New Version Notification for > >> draft-ietf-intarea-gre- ipv6-05.txt > >> > >> Folks, > >> > >> I have updated draft-ietf-intarea-gre-ipv6. Please tell me if I have > >> addressed all of your comments. > >> > >> Ron > >> > >> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Thursday, April 09, 2015 4:58 PM > >>> To: Ronald Bonica; Suresh Krishnan; Suresh Krishnan; Carlos > >>> Pignataro; Ronald Bonica; Carlos Pignataro > >>> Subject: New Version Notification for > >>> draft-ietf-intarea-gre-ipv6-05.txt > >>> > >>> > >>> A new version of I-D, draft-ietf-intarea-gre-ipv6-05.txt > >>> has been successfully submitted by Ron Bonica and posted to the IETF > >>> repository. > >>> > >>> Name: draft-ietf-intarea-gre-ipv6 > >>> Revision: 05 > >>> Title: IPv6 Support for Generic Routing Encapsulation (GRE) > >>> Document date: 2015-04-10 > >>> Group: intarea > >>> Pages: 8 > >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-intare= a-gre- > ipv6- > >>> 05.txt > >>> Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-g= re-ipv6/ > >>> Htmlized: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv= 6-05 > >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea= -gre-ipv6-05 > >>> > >>> Abstract: > >>> Generic Routing Encapsulation (GRE) can be used to carry any > network- > >>> layer payload protocol over any network-layer delivery protocol. = GRE > >>> procedures are specified for IPv4, used as either the payload or > >>> delivery protocol. However, GRE procedures are not specified for > >>> IPv6. > >>> > >>> This document specifies GRE procedures for IPv6, used as either t= he > >>> payload or delivery protocol. It updates the GRE specification, = RFC > >>> 2784. > >>> > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Apr 10 15:24:45 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92E1B2DCB; Fri, 10 Apr 2015 15:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-Nn-bgSdFKv; Fri, 10 Apr 2015 15:24:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C2E1B2DC9; Fri, 10 Apr 2015 15:24:39 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 10 Apr 2015 22:24:37 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Fri, 10 Apr 2015 22:24:37 +0000 From: Ronald Bonica To: David Farmer , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQc795MeXvxGLYck68SuOpfDNlq51G0K1w Date: Fri, 10 Apr 2015 22:24:36 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> In-Reply-To: <55281BDB.1040804@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: umn.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377424004)(479174004)(164054003)(377454003)(252514010)(13464003)(51704005)(77156002)(106116001)(74316001)(2656002)(230783001)(66066001)(102836002)(15975445007)(33656002)(1720100001)(54356999)(122556002)(2201001)(76176999)(2420400003)(99286002)(40100003)(19580395003)(92566002)(19580405001)(2950100001)(93886004)(2900100001)(46102003)(86362001)(2171001)(76576001)(107886001)(62966003)(50986999)(87936001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 054231DC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2015 22:24:36.9070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:24:42 -0000 David, Lucy, Having thought about it a little more, would you mind if I crafted the text= as follows: The security section of [RFC 4023] identifies threats encountered when MPLS= is deliver over GRE. These threats apply equally to any GRE payload that i= s delivered over GRE. As stated in RFC 4023, these threats can be mitigated= by authenticating and/or encrypting the delivery packet using IPSec [RFC 4= 301] procedures. When the payload is IPv6, they can also be mitigated by au= thenticating and/or encrypting the payload using IPSec. Beyond that, the cu= rrent specification introduces no security considerations beyond those ment= ioned in RFC 2784. More generically, security considerations for IPv6 are discussed in [RFC49= 42], operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and= security concerns for tunnels in general are discussed in [RFC6169]. R= on > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Friday, April 10, 2015 2:52 PM > To: Ronald Bonica; Lucy yong; int-area@ietf.org; ipv6@ietf.org > Cc: David Farmer > Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intar= ea- > gre-ipv6-05.txt >=20 > I agree with Lucy, I'd like to see a direct reference to IPsec. How about > something like what Lucy had and then reference RFC 4023 for a more > extensive discussion. >=20 > IPsec [RFC4301] can be used to provide payload security and privacy > over an IP network where security is a concern, the Security > Considerations section of MPLS in GRE [RFC4023] discusses this more > extensively and applies equally to the current specification. Beyond > that, the current specification introduces no security > considerations beyond those mentioned in RFC 2784. >=20 > I'd like to see general security references for IPv6 and tunnels included= as > well, maybe something like the following as a second paragraph. >=20 > More generically, security considerations for IPv6 are discussed in > [RFC4942], operational security for IPv6 is discussed in > [I-D.ietf-opsec-v6], and security concerns for tunnels in general are > discussed in [RFC6169]. >=20 > Thanks >=20 > On 4/10/15 08:21 , Ronald Bonica wrote: > > Hi Lucy, > > > > MPLS over GRE [RFC 4023] has exactly the same security issues as IPv6 o= ver > GRE. Fortunately, RFC 4023 has an extensive Security Considerations secti= on > that references IPSec. So, the current document references RFC 4023 and > gets IPSec through one layer of indirection. > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Lucy yong [mailto:lucy.yong@huawei.com] > >> Sent: Thursday, April 09, 2015 5:15 PM > >> To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org > >> Subject: RE: [Int-area] FW: New Version Notification for > >> draft-ietf-intarea- gre-ipv6-05.txt > >> > >> Hi Ron, > >> > >> Security considerations should state that IPsec [RFC4301] can be used > >> to provide payload security and privacy over an IP network where the > >> security is a concern. > >> > >> Thanks, > >> Lucy > >> > >> -----Original Message----- > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald > >> Bonica > >> Sent: Thursday, April 09, 2015 4:03 PM > >> To: int-area@ietf.org; ipv6@ietf.org > >> Subject: [Int-area] FW: New Version Notification for > >> draft-ietf-intarea-gre- ipv6-05.txt > >> > >> Folks, > >> > >> I have updated draft-ietf-intarea-gre-ipv6. Please tell me if I have > >> addressed all of your comments. > >> > >> Ron > >> > >> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Thursday, April 09, 2015 4:58 PM > >>> To: Ronald Bonica; Suresh Krishnan; Suresh Krishnan; Carlos > >>> Pignataro; Ronald Bonica; Carlos Pignataro > >>> Subject: New Version Notification for > >>> draft-ietf-intarea-gre-ipv6-05.txt > >>> > >>> > >>> A new version of I-D, draft-ietf-intarea-gre-ipv6-05.txt > >>> has been successfully submitted by Ron Bonica and posted to the IETF > >>> repository. > >>> > >>> Name: draft-ietf-intarea-gre-ipv6 > >>> Revision: 05 > >>> Title: IPv6 Support for Generic Routing Encapsulation (GRE) > >>> Document date: 2015-04-10 > >>> Group: intarea > >>> Pages: 8 > >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-intare= a-gre- > ipv6- > >>> 05.txt > >>> Status: https://datatracker.ietf.org/doc/draft-ietf-intarea-g= re-ipv6/ > >>> Htmlized: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv= 6-05 > >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea= -gre-ipv6-05 > >>> > >>> Abstract: > >>> Generic Routing Encapsulation (GRE) can be used to carry any > network- > >>> layer payload protocol over any network-layer delivery protocol. = GRE > >>> procedures are specified for IPv4, used as either the payload or > >>> delivery protocol. However, GRE procedures are not specified for > >>> IPv6. > >>> > >>> This document specifies GRE procedures for IPv6, used as either t= he > >>> payload or delivery protocol. It updates the GRE specification, = RFC > >>> 2784. > >>> > >>> > >>> > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > >>> submission until the htmlized version and diff are available at > tools.ietf.org. > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Apr 10 16:26:08 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8881B2E67 for ; Fri, 10 Apr 2015 16:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH7BIN1dYLbN for ; Fri, 10 Apr 2015 16:26:04 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id DCD121B2E68 for ; Fri, 10 Apr 2015 16:26:03 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 10 Apr 2015 18:25:58 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by igblo3 with SMTP id lo3so10033106igb.1 for ; Fri, 10 Apr 2015 16:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zR5V31NRz43XEZd1gcZQy6ICucXka2HAyY7d73/Mw9E=; b=UMz6JMVhnS55pHGwiYXqpA5oEvWBLIeMx2MGkpw34ufkNzJLaroqmEe1q92LKbhcnj jwXUVSTCuvlzUp35UlCeUq77LF5+2DqOQ+zibSp6NnNIaol694SnmTZ6MRAkk7OlVtGa Rh5eBsnq5n60qa7P+vDisqifB+zfKenPcbqYc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zR5V31NRz43XEZd1gcZQy6ICucXka2HAyY7d73/Mw9E=; b=ArG8FolaWxHQZXqlEYENzNrDZZ1YE83zU+LGdXPbiaAZQ6jDSr+V4szuf802bmp0R9 jNyZ4nDLS6y5Jfe+J5yOD8l8mINDPmNF9dU/ANSAYGqf3AmS2s54wyjnP+uD+9Z3NAaS q05fBi7rqNiZpNZVS1z0J3VJ2DxmlvTN0CbTkHltGonYRxVzwMvhtwUuin/BEjbkvT13 a8MpvtVgeMOFhOuZGfwNC36JeZZT9Qbi6MSGD96PZDeJt73YtJVXqlvBMlRJEPvngTev m9KmqwdGDaReKASyCvVz8RdJ4DHJTgyeIyO1Lcix5Bd0oS1rHHQMpDr5Gs3wWpxvuWWP zQYg== X-Gm-Message-State: ALoCoQlY37g49M5Ok3ZP4Zizi3fB0SxUtRa6VXNZaNqPwuy4/oDb+5kWBa2PwzbnYusxJKRoIigrPSdUbSeAJkr63DKDZ5X0QQCOeSYOVztSkbOd729jQ7mb+spH3FyzR475IM/XJX6a X-Received: by 10.42.113.134 with SMTP id c6mr6682850icq.17.1428708358225; Fri, 10 Apr 2015 16:25:58 -0700 (PDT) X-Received: by 10.42.113.134 with SMTP id c6mr6682838icq.17.1428708358056; Fri, 10 Apr 2015 16:25:58 -0700 (PDT) Received: from x-128-101-233-117.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:8475:ae36:2dc5:425d]) by mx.google.com with ESMTPSA id j126sm183723ioe.22.2015.04.10.16.25.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 16:25:56 -0700 (PDT) Message-ID: <55285BFF.2040903@umn.edu> Date: Fri, 10 Apr 2015 18:25:51 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Farmer Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 23:26:05 -0000 Sure, that works, but few nits; - The first "GRE" in in the second sentence seems redundant, I'd suggest just removing it. - Except for applying to IPv6, the fourth sentence says almost the same thing as the third sentence. I'd suggest adding ", including IPv6" to the second sentence, and remove the fourth sentence all together. - The double use of the word "beyond" in the last sentence seems redundant as well. Maybe substitute, "Otherwise," for "Beyond that," at the beginning of the sentence. Putting those together you get; The security section of [RFC 4023] identifies threats encountered when MPLS is deliver over GRE. These threats apply equally to any payload that is delivered over GRE, including IPv6. As stated in RFC 4023, these threats can be mitigated by authenticating and/or encrypting the delivery packet using IPSec [RFC 4301] procedures. Otherwise, the current specification introduces no security considerations beyond those mentioned in RFC 2784. More generically, security considerations for IPv6 are discussed in [RFC4942], operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and security concerns for tunnels in general are discussed in [RFC6169]. On 4/10/15 17:24 , Ronald Bonica wrote: > David, Lucy, > > Having thought about it a little more, would you mind if I crafted the text as follows: > > The security section of [RFC 4023] identifies threats encountered when MPLS is deliver over GRE. These threats apply equally to any GRE payload that is delivered over GRE. As stated in RFC 4023, these threats can be mitigated by authenticating and/or encrypting the delivery packet using IPSec [RFC 4301] procedures. When the payload is IPv6, they can also be mitigated by authenticating and/or encrypting the payload using IPSec. Beyond that, the current specification introduces no security considerations beyond those mentioned in RFC 2784. > > More generically, security considerations for IPv6 are discussed in [RFC4942], operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and security concerns for tunnels in general are discussed in [RFC6169]. > > > Ron -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Fri Apr 10 17:30:45 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7BA1A8996; Fri, 10 Apr 2015 17:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k08UTfP-KybJ; Fri, 10 Apr 2015 17:30:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2411A8742; Fri, 10 Apr 2015 17:30:42 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Sat, 11 Apr 2015 00:30:41 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Sat, 11 Apr 2015 00:30:41 +0000 From: Ronald Bonica To: David Farmer , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQc795MeXvxGLYck68SuOpfDNlq51G0K1wgAATMYCAAA1p4A== Date: Sat, 11 Apr 2015 00:30:41 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> <55285BFF.2040903@umn.edu> In-Reply-To: <55285BFF.2040903@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: umn.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(377454003)(252514010)(13464003)(51704005)(77156002)(106116001)(230783001)(66066001)(2656002)(102836002)(33656002)(74316001)(54356999)(2201001)(122556002)(76176999)(99286002)(40100003)(19580395003)(92566002)(19580405001)(2950100001)(93886004)(2900100001)(46102003)(86362001)(2171001)(76576001)(107886001)(62966003)(50986999)(87936001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 05437568AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2015 00:30:41.2936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 00:30:45 -0000 > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Friday, April 10, 2015 7:26 PM > To: Ronald Bonica; Lucy yong; int-area@ietf.org; ipv6@ietf.org > Cc: David Farmer > Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intar= ea- > gre-ipv6-05.txt >=20 > Sure, that works, but few nits; >=20 > - The first "GRE" in in the second sentence seems redundant, I'd suggest = just > removing it. [RPB]=20 Yikes! That was certainly redundant! I will remove it. >=20 > - Except for applying to IPv6, the fourth sentence says almost the same t= hing > as the third sentence. I'd suggest adding ", including IPv6" to the seco= nd > sentence, and remove the fourth sentence all together. [RPB]=20 I don't agree. In the third sentence, the GRE ingress and GRE egress nodes = execute IPSec procedures. They encrypt and/or authenticate the GRE delivery= header. (That's all you can do when the payload is MPLS). In the fourth s= entence, the payload originator and payload destination execute IPSec proce= dures. They encrypt and/or authenticate the payload packet. This is an opti= on when the payload is IPv6.=20 In the first case, the=20 >=20 > - The double use of the word "beyond" in the last sentence seems > redundant as well. Maybe substitute, "Otherwise," for "Beyond that," at = the > beginning of the sentence. [RPB]=20 Agree. Ron >=20 > Putting those together you get; >=20 > The security section of [RFC 4023] identifies threats encountered when MP= LS > is deliver over GRE. These threats apply equally to any payload that is > delivered over GRE, including IPv6. As stated in RFC 4023, these threats = can > be mitigated by authenticating and/or encrypting the delivery packet usin= g > IPSec [RFC 4301] procedures. Otherwise, the current specification introdu= ces > no security considerations beyond those mentioned in RFC 2784. >=20 > More generically, security considerations for IPv6 are discussed in [RFC4= 942], > operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and se= curity > concerns for tunnels in general are discussed in [RFC6169]. >=20 > On 4/10/15 17:24 , Ronald Bonica wrote: > > David, Lucy, > > > > Having thought about it a little more, would you mind if I crafted the = text as > follows: > > > > The security section of [RFC 4023] identifies threats encountered when > MPLS is deliver over GRE. These threats apply equally to any GRE payload > that is delivered over GRE. As stated in RFC 4023, these threats can be > mitigated by authenticating and/or encrypting the delivery packet using > IPSec [RFC 4301] procedures. When the payload is IPv6, they can also be > mitigated by authenticating and/or encrypting the payload using IPSec. > Beyond that, the current specification introduces no security considerati= ons > beyond those mentioned in RFC 2784. > > > > More generically, security considerations for IPv6 are discussed in > [RFC4942], operational security for IPv6 is discussed in [I-D.ietf-opsec-= v6], > and security concerns for tunnels in general are discussed in [RFC6169]. > > > > > > > > Ron >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Apr 10 17:31:26 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A0E1A8A39 for ; Fri, 10 Apr 2015 17:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.599 X-Spam-Level: * X-Spam-Status: No, score=1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_45=1, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzc5AeE_Cysz for ; Fri, 10 Apr 2015 17:31:20 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 246441A8A41 for ; Fri, 10 Apr 2015 17:31:15 -0700 (PDT) Received: (qmail 85813 invoked from network); 11 Apr 2015 00:16:33 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Apr 2015 00:16:33 -0000 Message-ID: <55286B4B.50106@necom830.hpcl.titech.ac.jp> Date: Sat, 11 Apr 2015 09:31:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , "ietf@ietf.org" References: <20150409221014.23004.70247.idtracker@ietfa.amsl.com> <029801d07364$6454fe80$2cfefb80$@olddog.co.uk> <5527C160.1090505@necom830.hpcl.titech.ac.jp> <2134F8430051B64F815C691A62D9831832E4465C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4465C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] Last Call: (A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 00:31:22 -0000 Templin, Fred L wrote: > Hi, Hi, >> As the draft says; >> >> o When the GRE ingress node receives a non-fragmentable packet with >> length greater than the GMTU, it discards the packet and send an >> ICMP PTB message to the packet's source. >> >> the draft should clearly state that, if GMTU<1280B, it is a violation >> of the following requirement of RFC2460: >> >> IPv6 requires that every link in the internet have an MTU of 1280 >> octets or greater. On any link that cannot convey a 1280-octet >> packet in one piece, link-specific fragmentation and reassembly must >> be provided at a layer below IPv6. >> >> and that 1280B IPv6 packets can not be carried over IPv6 with the >> default GRE configuration. > > We have been through this already. They want to say that widely deployed > implementations already ignore this requirement How the requirement is ignored? Is GMTU<1280B or are GRE gateways sending >1280B packets without PMTUD? > and so they want to document the behavior to make it all OK. Then, the document should be on standard track updating RFC2460. That's how the "running code" principle works, or, why implementations and operational experiences are required for draft and full standards. Let feedback from the real world work to fix poor specifications. > The non-robustness principle in action. For the robustness, IPv6 capable hosts should not send, e.g., >1200B packets without PMTUD, while links are still required to have MTU of >=1280B. Or, IPv6 capable hosts should not send, >1280B packets without PMTUD, while links are required to have MTU of, e.g., >=1400B. Masataka Ohta From nobody Fri Apr 10 18:37:51 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0851AC425 for ; Fri, 10 Apr 2015 18:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hX3owkBC-Tn for ; Fri, 10 Apr 2015 18:37:46 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D01A870F for ; Fri, 10 Apr 2015 18:37:46 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 10 Apr 2015 20:37:45 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f175.google.com [209.85.213.175] #+LO+TS+TR X-Umn-Classification: local Received: by ignm3 with SMTP id m3so24182635ign.0 for ; Fri, 10 Apr 2015 18:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/UtbCKxIPfS3S90+Gi0jtmC36AHO4s7RUz2XN9RwdxQ=; b=j09uOBWfvcqkOcCmipZ5pM2CgBexUncmCY/GToEScH4fZi6zNBoKlMUGoFxYqPUzax dOa3uvXdHAbnGcy2A1n6ptD0ZYo5Iw9ZHFECym8yu2Tk9f9hAYZPMh2hAm7qPRzE6W+i NhO6mrtP82/MvghBKlKV3T8Fypz+Aq+wxe1Sk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/UtbCKxIPfS3S90+Gi0jtmC36AHO4s7RUz2XN9RwdxQ=; b=jwiD5oas2tjZgxnnW00DQfLezwIt8SBwVWbx4ik4oHS9ROhw6BqyZT0dRhk7UiR4T7 VNkcNG5qA0RL4QLppy9ykDgJ9uYDC3WzyTZlIqdK2aVmuBZt53/sfuiX/seytHGEFRrB unfbQ1R2Bh5OFD4URQF97GjVvHUVOqKMts2X9GTCI02JLvXwT2cUReWKJk+OW0b2q4iQ TpIaZc3Bh/SniqECxxHUED7g5hJq7+dFeySfR2UkdhUy6/DaxqgZmIV/6Q6hJENyqR97 k5+U4Beakvkjm1IzD5u83H46/jK/04bDriXtRszH7/U7Wj8oohKjbXDYFAnIH8A85aHL R1FA== X-Gm-Message-State: ALoCoQm4XQIAs6P+N4CVzRptS4C40XfKa6HFJapGSXjedwDWl3EmuCrh8w/UwAkrRjbin104nY/6KbDyTAug5YtK8FTnURj4z/NiFR3EuYBunOPqCvQd9Vg9KVDrJbEA3iDg2/wN5hyX X-Received: by 10.50.79.229 with SMTP id m5mr2184753igx.23.1428716264754; Fri, 10 Apr 2015 18:37:44 -0700 (PDT) X-Received: by 10.50.79.229 with SMTP id m5mr2184726igx.23.1428716264314; Fri, 10 Apr 2015 18:37:44 -0700 (PDT) Received: from oit201651646.local ([2601:2:5b00:a9f:b024:8bbc:9164:c351]) by mx.google.com with ESMTPSA id lp7sm925536igb.20.2015.04.10.18.37.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 18:37:42 -0700 (PDT) Message-ID: <55287AE2.8050304@umn.edu> Date: Fri, 10 Apr 2015 20:37:38 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ronald Bonica , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> <55285BFF.2040903@umn.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Farmer Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:37:48 -0000 On 4/10/15 19:30 , Ronald Bonica wrote: >> - Except for applying to IPv6, the fourth sentence says almost the same thing >> as the third sentence. I'd suggest adding ", including IPv6" to the second >> sentence, and remove the fourth sentence all together. > [RPB] > > I don't agree. In the third sentence, the GRE ingress and GRE egress nodes execute IPSec procedures. They encrypt and/or authenticate the GRE delivery header. (That's all you can do when the payload is MPLS). In the fourth sentence, the payload originator and payload destination execute IPSec procedures. They encrypt and/or authenticate the payload packet. This is an option when the payload is IPv6. Ok, I missed that distinction the first time, I might not be the only one that misses it. How can that distinction be highlighted a little more? Maybe something like the following: Alternatively when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPSec, instead of the delivery packet. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Fri Apr 10 18:41:26 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10421B2EA6; Fri, 10 Apr 2015 18:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7y4Kl2m2tWd; Fri, 10 Apr 2015 18:41:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD171B2CE1; Fri, 10 Apr 2015 18:41:22 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.130.23; Sat, 11 Apr 2015 01:41:03 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Sat, 11 Apr 2015 01:41:03 +0000 From: Ronald Bonica To: David Farmer , Lucy yong , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt Thread-Index: AQHQc795MeXvxGLYck68SuOpfDNlq51G0K1wgAATMYCAAA1p4IAAF2kAgAAA2+A= Date: Sat, 11 Apr 2015 01:41:02 +0000 Message-ID: References: <20150409205737.10780.29197.idtracker@ietfa.amsl.com> <2691CE0099834E4A9C5044EEC662BB9D5715802F@dfweml701-chm> <55281BDB.1040804@umn.edu> <55285BFF.2040903@umn.edu> <55287AE2.8050304@umn.edu> In-Reply-To: <55287AE2.8050304@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: umn.edu; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(252514010)(377454003)(24454002)(51704005)(13464003)(76176999)(19580405001)(19580395003)(66066001)(46102003)(33656002)(86362001)(93886004)(2501003)(87936001)(106116001)(2950100001)(107886001)(76576001)(2656002)(2171001)(99286002)(50986999)(40100003)(74316001)(2900100001)(102836002)(122556002)(62966003)(77156002)(2201001)(92566002)(230783001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; x-forefront-prvs: 05437568AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2015 01:41:02.8560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:41:24 -0000 Works for me. I will spin a new version and post it in a few minutes. Ron > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Friday, April 10, 2015 9:38 PM > To: Ronald Bonica; Lucy yong; int-area@ietf.org; ipv6@ietf.org > Cc: David Farmer > Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intar= ea- > gre-ipv6-05.txt >=20 > On 4/10/15 19:30 , Ronald Bonica wrote: >=20 > >> - Except for applying to IPv6, the fourth sentence says almost the > >> same thing as the third sentence. I'd suggest adding ", including > >> IPv6" to the second sentence, and remove the fourth sentence all > together. > > [RPB] > > > > I don't agree. In the third sentence, the GRE ingress and GRE egress no= des > execute IPSec procedures. They encrypt and/or authenticate the GRE > delivery header. (That's all you can do when the payload is MPLS). In th= e > fourth sentence, the payload originator and payload destination execute > IPSec procedures. They encrypt and/or authenticate the payload packet. Th= is > is an option when the payload is IPv6. >=20 > Ok, I missed that distinction the first time, I might not be the only one= that > misses it. How can that distinction be highlighted a little more? Maybe > something like the following: >=20 > Alternatively when the payload is IPv6, these threats can also be mitigat= ed by > authenticating and/or encrypting the payload using IPSec, instead of the > delivery packet. >=20 >=20 >=20 >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Apr 10 18:44:07 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440441B2F11; Fri, 10 Apr 2015 18:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6qCUIkxYOJU; Fri, 10 Apr 2015 18:44:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FD01A0037; Fri, 10 Apr 2015 18:44:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150411014404.22246.77581.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 18:44:04 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:44:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : IPv6 Support for Generic Routing Encapsulation (GRE) Authors : Carlos Pignataro Ron Bonica Suresh Krishnan Filename : draft-ietf-intarea-gre-ipv6-06.txt Pages : 8 Date : 2015-04-10 Abstract: Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. It updates the GRE specification, RFC 2784. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 18:45:41 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2171B2F1C; Fri, 10 Apr 2015 18:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tMG87iilOGc; Fri, 10 Apr 2015 18:45:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3E41B2F0F; Fri, 10 Apr 2015 18:45:38 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.130.23; Sat, 11 Apr 2015 01:45:17 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Sat, 11 Apr 2015 01:45:17 +0000 From: Ronald Bonica To: "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt Thread-Index: AQHQc/kAF00w+FoQ/UGi9PVoOkID1J1HCkwQ Date: Sat, 11 Apr 2015 01:45:16 +0000 Message-ID: References: <20150411014404.22246.15898.idtracker@ietfa.amsl.com> In-Reply-To: <20150411014404.22246.15898.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(13464003)(69234005)(377454003)(51704005)(74316001)(76576001)(2501003)(107886001)(15975445007)(102836002)(19580405001)(19580395003)(99286002)(62966003)(77156002)(106116001)(2420400003)(40100003)(66066001)(1720100001)(122556002)(450100001)(46102003)(230783001)(92566002)(87936001)(2950100001)(54356999)(86362001)(2656002)(50986999)(33656002)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 05437568AA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2015 01:45:16.0623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:45:40 -0000 DQpGWUkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6 IEZyaWRheSwgQXByaWwgMTAsIDIwMTUgOTo0NCBQTQ0KPiBUbzogUm9uYWxkIEJvbmljYTsgU3Vy ZXNoIEtyaXNobmFuOyBTdXJlc2ggS3Jpc2huYW47IENhcmxvcyBQaWduYXRhcm87DQo+IFJvbmFs ZCBCb25pY2E7IENhcmxvcyBQaWduYXRhcm8NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYtMDYudHh0DQo+IA0KPiANCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni0wNi50eHQN Cj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb24gQm9uaWNhIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1pZXRmLWlu dGFyZWEtZ3JlLWlwdjYNCj4gUmV2aXNpb246CTA2DQo+IFRpdGxlOgkJSVB2NiBTdXBwb3J0IGZv ciBHZW5lcmljIFJvdXRpbmcgRW5jYXBzdWxhdGlvbiAoR1JFKQ0KPiBEb2N1bWVudCBkYXRlOgky MDE1LTA0LTExDQo+IEdyb3VwOgkJaW50YXJlYQ0KPiBQYWdlczoJCTgNCj4gVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtaW50YXJl YS1ncmUtaXB2Ni0NCj4gMDYudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWludGFyZWEtZ3JlLWlwdjYvDQo+IEh0bWxpemVk OiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtZ3Jl LWlwdjYtMDYNCj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtaW50YXJlYS1ncmUtaXB2Ni0wNg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg IEdlbmVyaWMgUm91dGluZyBFbmNhcHN1bGF0aW9uIChHUkUpIGNhbiBiZSB1c2VkIHRvIGNhcnJ5 IGFueSBuZXR3b3JrLQ0KPiAgICBsYXllciBwYXlsb2FkIHByb3RvY29sIG92ZXIgYW55IG5ldHdv cmstbGF5ZXIgZGVsaXZlcnkgcHJvdG9jb2wuICBHUkUNCj4gICAgcHJvY2VkdXJlcyBhcmUgc3Bl Y2lmaWVkIGZvciBJUHY0LCB1c2VkIGFzIGVpdGhlciB0aGUgcGF5bG9hZCBvcg0KPiAgICBkZWxp dmVyeSBwcm90b2NvbC4gIEhvd2V2ZXIsIEdSRSBwcm9jZWR1cmVzIGFyZSBub3Qgc3BlY2lmaWVk IGZvcg0KPiAgICBJUHY2Lg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgR1JFIHBy b2NlZHVyZXMgZm9yIElQdjYsIHVzZWQgYXMgZWl0aGVyIHRoZQ0KPiAgICBwYXlsb2FkIG9yIGRl bGl2ZXJ5IHByb3RvY29sLiAgSXQgdXBkYXRlcyB0aGUgR1JFIHNwZWNpZmljYXRpb24sIFJGQw0K PiAgICAyNzg0Lg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Apr 13 03:01:36 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE01B30C5; Mon, 13 Apr 2015 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.11 X-Spam-Level: X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 602Dx9Xg9uNG; Mon, 13 Apr 2015 03:01:33 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CC31B30C7; Mon, 13 Apr 2015 03:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1663; q=dns/txt; s=iport; t=1428919292; x=1430128892; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=v/+EypcDFLsmHsL4EYmjLa/xdv3kqBTNdnyyBS+Uypg=; b=do+Ji4NqB+1tuhnf+G542JCtldICzoq4vWjz8yiu+wD/uJq14s0urJ2B 9FrYvTzgpTzaxZxuExBBCnru1nw2otIdkJgzk9gYcHmFfzTAKBc0QYJZZ s0D3V0mGg2g7SuGXInqgdtCPrSvieFODIYjZrFzEHn9dX6jr8os8mSZyi Q=; X-IronPort-AV: E=Sophos;i="5.11,569,1422921600"; d="scan'208,217";a="425157990" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 13 Apr 2015 10:01:30 +0000 Received: from [10.55.98.187] (ams-stbryant-88110.cisco.com [10.55.98.187]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3DA1UVp015768; Mon, 13 Apr 2015 10:01:30 GMT Message-ID: <552B93FA.4040606@cisco.com> Date: Mon, 13 Apr 2015 11:01:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ronald Bonica , "int-area@ietf.org" , "ipv6@ietf.org" References: <20150411014404.22246.15898.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080705030903020701030509" Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 10:01:34 -0000 This is a multi-part message in MIME format. --------------080705030903020701030509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Ron The text GRE over IPv6 is deployable only in environments where the network operator deems the risk associated with behavior c) to be acceptable. really cries out for some form of RFC2119 language such as: GRE over IPv6 is MUST NOT be deployed other than where the network operator deems the risk associated with behavior c) to be acceptable. or something similar. - Stewart --------------080705030903020701030509 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Ron

The text

GRE over IPv6 is deployable only in environments where the network operator
deems the risk associated with behavior c) to be acceptable.

really cries out for some form of RFC2119 language such as:

GRE over IPv6 is MUST NOT be deployed other than where the
network operator deems the risk associated with behavior c) to be
acceptable.

or something similar.

- Stewart
--------------080705030903020701030509-- From nobody Mon Apr 13 04:14:15 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752F1A90A6; Mon, 13 Apr 2015 04:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGLxEMlHYST3; Mon, 13 Apr 2015 04:14:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 430331A90A1; Mon, 13 Apr 2015 04:14:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413111411.7525.84736.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 04:14:11 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 11:14:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : IPv6 Support for Generic Routing Encapsulation (GRE) Authors : Carlos Pignataro Ron Bonica Suresh Krishnan Filename : draft-ietf-intarea-gre-ipv6-07.txt Pages : 8 Date : 2015-04-13 Abstract: Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. It updates the GRE specification, RFC 2784. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 13 04:16:35 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB5D1A9071; Mon, 13 Apr 2015 04:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqFIFie2DDBW; Mon, 13 Apr 2015 04:16:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BC81A9068; Mon, 13 Apr 2015 04:16:30 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB523.namprd05.prod.outlook.com (10.141.72.18) with Microsoft SMTP Server (TLS) id 15.1.136.25; Mon, 13 Apr 2015 11:16:29 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 13 Apr 2015 11:16:28 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Mon, 13 Apr 2015 11:16:28 +0000 From: Ronald Bonica To: "stbryant@cisco.com" , "int-area@ietf.org" , "ipv6@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt Thread-Index: AQHQc/kAF00w+FoQ/UGi9PVoOkID1J1HCkwQgAOvYgCAABTNkA== Date: Mon, 13 Apr 2015 11:16:28 +0000 Message-ID: References: <20150411014404.22246.15898.idtracker@ietfa.amsl.com> <552B93FA.4040606@cisco.com> In-Reply-To: <552B93FA.4040606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB523; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(81156005)(46102003)(74316001)(19300405004)(230783001)(97736003)(16236675004)(99286002)(2501003)(40100003)(122556002)(19625215002)(33656002)(101416001)(2950100001)(92566002)(2900100001)(19580395003)(19580405001)(77156002)(62966003)(68736005)(2420400003)(102836002)(15975445007)(86362001)(87936001)(2656002)(2201001)(54356999)(76176999)(50986999)(107886001)(106116001)(106356001)(105586002)(76576001)(64706001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB444; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444; x-forefront-prvs: 0545EFAC9A received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CO1PR05MB4428A66797CCD7C2A1E5A3CAEE70CO1PR05MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 11:16:28.1175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea-gre-ipv6-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 11:16:32 -0000 --_000_CO1PR05MB4428A66797CCD7C2A1E5A3CAEE70CO1PR05MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stuart, Works for me. I just made the change and posted a new version of the draft. Ron From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Monday, April 13, 2015 6:02 AM To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-intarea= -gre-ipv6-06.txt Ron The text GRE over IPv6 is deployable only in environments where the network operato= r deems the risk associated with behavior c) to be acceptable. really cries out for some form of RFC2119 language such as: GRE over IPv6 is MUST NOT be deployed other than where the network operator deems the risk associated with behavior c) to be acceptable. or something similar. - Stewart --_000_CO1PR05MB4428A66797CCD7C2A1E5A3CAEE70CO1PR05MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stuart,

 

Works for me. I just made the change = and posted a new version of the draft.

 

      &= nbsp;           &nbs= p;             = Ron

 

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Monday, April 13, 2015 6:02 AM
To: Ronald Bonica; int-area@ietf.org; ipv6@ietf.org
Subject: Re: [Int-area] FW: New Version Notification for draft-ietf-= intarea-gre-ipv6-06.txt

 


Ron

The text

GRE over IPv6 is  deployable only in environments where the network op= erator
deems the  risk associated with behavior c) to be acceptable.

really cries out for some form of RFC2119 language such as:

GRE over IPv6 is MUST NOT be deployed other than where the
network operator deems the  risk associated with behavior c) to be acceptable.

or something similar.

- Stewart

--_000_CO1PR05MB4428A66797CCD7C2A1E5A3CAEE70CO1PR05MB442namprd_-- From nobody Tue Apr 14 09:24:14 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2D1B2E3F for ; Tue, 14 Apr 2015 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOHMF-n3Cn2O for ; Tue, 14 Apr 2015 09:24:09 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5B21ACDCD for ; Tue, 14 Apr 2015 09:24:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3EGO8Bw001687; Tue, 14 Apr 2015 09:24:08 -0700 Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3EGO2uV001609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 14 Apr 2015 09:24:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.188]) with mapi id 14.03.0235.001; Tue, 14 Apr 2015 09:24:00 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" Thread-Topic: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AQHQddsBLOH9xb+cYk6sfhtfd9pkSJ1MqlrQ Date: Tue, 14 Apr 2015 16:24:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV-504.nw.nos.boeing.com> References: <20150413111411.7525.84736.idtracker@ietfa.amsl.com> In-Reply-To: <20150413111411.7525.84736.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 16:24:12 -0000 Hi, in Section 3.2 there is now specification for sending a 1280 byte probe= packet to test the path between the ingress and egress. The stated goal is to ensu= re that a 1280 byte packet can traverse the tunnel without fragmentation. However, if there are other tunnels on the path from the first tunnel ingre= ss toward the corresponding egress, it is possible that another tunnel could b= e fragmenting and reassembling the probe packet before it arrives at the fina= l egress. And, fragmentation and reassembly closer to the middle of the network is much worse than fragmentation and reassembly nearer the edges of the network. This is why I have proposed a new "Don't Fragment" bit in the GRE header. It can be set by the first tunnel ingress to tell other tunnels not to frag= ment the packet that is being used as a probe. Fragmentation and reassembly of probe packets must be avoided if we are to avoid fragmentation and reassembly of data packets. Also, it might be worth noting that this is not the first time a tunnel loo= pback test packet has been specified. A similar facility is specified in Section = 8 of RFC5969. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Monday, April 13, 2015 4:14 AM > To: i-d-announce@ietf.org > Cc: int-area@ietf.org > Subject: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Internet Area Working Group Working Gro= up of the IETF. >=20 > Title : IPv6 Support for Generic Routing Encapsulation = (GRE) > Authors : Carlos Pignataro > Ron Bonica > Suresh Krishnan > Filename : draft-ietf-intarea-gre-ipv6-07.txt > Pages : 8 > Date : 2015-04-13 >=20 > Abstract: > Generic Routing Encapsulation (GRE) can be used to carry any network- > layer payload protocol over any network-layer delivery protocol. GRE > procedures are specified for IPv4, used as either the payload or > delivery protocol. However, GRE procedures are not specified for > IPv6. >=20 > This document specifies GRE procedures for IPv6, used as either the > payload or delivery protocol. It updates the GRE specification, RFC > 2784. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-gre-ipv6-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Apr 14 10:13:51 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B9F1A0194 for ; Tue, 14 Apr 2015 10:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paxQUBrxYCau for ; Tue, 14 Apr 2015 10:13:48 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697B41A037D for ; Tue, 14 Apr 2015 10:13:03 -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 t3EHD2Bn003962; Tue, 14 Apr 2015 10:13:02 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3EHCsPN003886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 14 Apr 2015 10:12:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.186]) with mapi id 14.03.0235.001; Tue, 14 Apr 2015 10:12:54 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" Thread-Topic: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AQHQddsBLOH9xb+cYk6sfhtfd9pkSJ1MqlrQgAAV7EA= Date: Tue, 14 Apr 2015 17:12:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E495AD@XCH-BLV-504.nw.nos.boeing.com> References: <20150413111411.7525.84736.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 17:13:50 -0000 I will say also that the act of probing in general is a bit troublesome. In= particular, when there is Equal Cost MultiPath (ECMP) how can you tell that the probe packets will follow the same path as the data packets? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Tuesday, April 14, 2015 9:24 AM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Hi, in Section 3.2 there is now specification for sending a 1280 byte pro= be packet > to test the path between the ingress and egress. The stated goal is to en= sure > that a 1280 byte packet can traverse the tunnel without fragmentation. >=20 > However, if there are other tunnels on the path from the first tunnel ing= ress > toward the corresponding egress, it is possible that another tunnel could= be > fragmenting and reassembling the probe packet before it arrives at the fi= nal > egress. And, fragmentation and reassembly closer to the middle of the > network is much worse than fragmentation and reassembly nearer the > edges of the network. >=20 > This is why I have proposed a new "Don't Fragment" bit in the GRE header. > It can be set by the first tunnel ingress to tell other tunnels not to fr= agment > the packet that is being used as a probe. Fragmentation and reassembly > of probe packets must be avoided if we are to avoid fragmentation and > reassembly of data packets. >=20 > Also, it might be worth noting that this is not the first time a tunnel l= oopback > test packet has been specified. A similar facility is specified in Sectio= n 8 of > RFC5969. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > > Sent: Monday, April 13, 2015 4:14 AM > > To: i-d-announce@ietf.org > > Cc: int-area@ietf.org > > Subject: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Internet Area Working Group Working G= roup of the IETF. > > > > Title : IPv6 Support for Generic Routing Encapsulatio= n (GRE) > > Authors : Carlos Pignataro > > Ron Bonica > > Suresh Krishnan > > Filename : draft-ietf-intarea-gre-ipv6-07.txt > > Pages : 8 > > Date : 2015-04-13 > > > > Abstract: > > Generic Routing Encapsulation (GRE) can be used to carry any network= - > > layer payload protocol over any network-layer delivery protocol. GR= E > > procedures are specified for IPv4, used as either the payload or > > delivery protocol. However, GRE procedures are not specified for > > IPv6. > > > > This document specifies GRE procedures for IPv6, used as either the > > payload or delivery protocol. It updates the GRE specification, RFC > > 2784. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-gre-ipv6-07 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > 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 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Apr 15 21:29:49 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7A1B2EB8 for ; Wed, 15 Apr 2015 21:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u2CswdXdZfe for ; Wed, 15 Apr 2015 21:29:46 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A3C1B2EB5 for ; Wed, 15 Apr 2015 21:29:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3G4TjID025782; Wed, 15 Apr 2015 23:29:45 -0500 Received: from XCH-BLV-506.nw.nos.boeing.com (xch-blv-506.nw.nos.boeing.com [130.247.25.196]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3G4TZld025625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 15 Apr 2015 23:29:35 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-506.nw.nos.boeing.com ([169.254.6.93]) with mapi id 14.03.0235.001; Wed, 15 Apr 2015 21:29:34 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" Thread-Topic: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AQHQddsBLOH9xb+cYk6sfhtfd9pkSJ1MqlrQgAAV7ECAAk1jQA== Date: Thu, 16 Apr 2015 04:29:33 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4A882@XCH-BLV-504.nw.nos.boeing.com> References: <20150413111411.7525.84736.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E495AD@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E495AD@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 04:29:48 -0000 I will say one more thing. When the original source is not within the same administrative domain as the GRE ingress there is no guarantee that PTBs sent by the ingress will make it back to the source. Hence, the ingress sho= uld fragment packets up to 1500 bytes (if necessary) and send PTBs for packets larger than 1500 bytes (if necessary). Then, whether or not the true GRE MTU can be determined depends on where the ingress and egress are located. If both are within the same administrative domain then the ingress can reasonably expect to receive accurate PTBs from either a router on the path or from the egress itself. Otherwise, there is no guarantee that the ingress will receive PTBs. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Tuesday, April 14, 2015 10:13 AM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > I will say also that the act of probing in general is a bit troublesome. = In particular, > when there is Equal Cost MultiPath (ECMP) how can you tell that the probe > packets will follow the same path as the data packets? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin,= Fred L > > Sent: Tuesday, April 14, 2015 9:24 AM > > To: int-area@ietf.org > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi, in Section 3.2 there is now specification for sending a 1280 byte p= robe packet > > to test the path between the ingress and egress. The stated goal is to = ensure > > that a 1280 byte packet can traverse the tunnel without fragmentation. > > > > However, if there are other tunnels on the path from the first tunnel i= ngress > > toward the corresponding egress, it is possible that another tunnel cou= ld be > > fragmenting and reassembling the probe packet before it arrives at the = final > > egress. And, fragmentation and reassembly closer to the middle of the > > network is much worse than fragmentation and reassembly nearer the > > edges of the network. > > > > This is why I have proposed a new "Don't Fragment" bit in the GRE heade= r. > > It can be set by the first tunnel ingress to tell other tunnels not to = fragment > > the packet that is being used as a probe. Fragmentation and reassembly > > of probe packets must be avoided if we are to avoid fragmentation and > > reassembly of data packets. > > > > Also, it might be worth noting that this is not the first time a tunnel= loopback > > test packet has been specified. A similar facility is specified in Sect= ion 8 of > > RFC5969. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf O= f internet-drafts@ietf.org > > > Sent: Monday, April 13, 2015 4:14 AM > > > To: i-d-announce@ietf.org > > > Cc: int-area@ietf.org > > > Subject: I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > > > This draft is a work item of the Internet Area Working Group Working= Group of the IETF. > > > > > > Title : IPv6 Support for Generic Routing Encapsulat= ion (GRE) > > > Authors : Carlos Pignataro > > > Ron Bonica > > > Suresh Krishnan > > > Filename : draft-ietf-intarea-gre-ipv6-07.txt > > > Pages : 8 > > > Date : 2015-04-13 > > > > > > Abstract: > > > Generic Routing Encapsulation (GRE) can be used to carry any netwo= rk- > > > layer payload protocol over any network-layer delivery protocol. = GRE > > > procedures are specified for IPv4, used as either the payload or > > > delivery protocol. However, GRE procedures are not specified for > > > IPv6. > > > > > > This document specifies GRE procedures for IPv6, used as either th= e > > > payload or delivery protocol. It updates the GRE specification, R= FC > > > 2784. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-gre-ipv6-07 > > > > > > > > > Please note that it may take a couple of minutes from the time of sub= mission > > > 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 > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 16 06:02:13 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3A51B3162 for ; Thu, 16 Apr 2015 06:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-ZykatMrpYJ for ; Thu, 16 Apr 2015 06:02:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433CD1B3161 for ; Thu, 16 Apr 2015 06:02:10 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 16 Apr 2015 13:01:52 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) with mapi id 15.01.0136.014; Thu, 16 Apr 2015 13:01:52 +0000 From: Ronald Bonica To: "int-area@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6-07 Thread-Index: AdB4RX9jTIT97vUGSf6b1f7L8GYJ3A== Date: Thu, 16 Apr 2015 13:01:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(86362001)(54356999)(77156002)(62966003)(50986999)(102836002)(230783001)(19580395003)(19580405001)(87936001)(2656002)(66066001)(99286002)(40100003)(122556002)(2351001)(512954002)(33656002)(450100001)(110136001)(107886001)(74316001)(2501003)(76576001)(46102003)(92566002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB444; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444; x-forefront-prvs: 0548586081 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 13:01:51.8191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Archived-At: Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6-07 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 13:02:12 -0000 Fred, Inline.... Ron >=20 > Message: 1 > Date: Tue, 14 Apr 2015 16:24:00 +0000 > From: "Templin, Fred L" > To: "int-area@ietf.org" > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > Message-ID: > <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV- > 504.nw.nos.boeing.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, in Section 3.2 there is now specification for sending a 1280 byte pro= be > packet to test the path between the ingress and egress. The stated goal i= s to > ensure that a 1280 byte packet can traverse the tunnel without > fragmentation. >=20 > However, if there are other tunnels on the path from the first tunnel ing= ress > toward the corresponding egress, it is possible that another tunnel could= be > fragmenting and reassembling the probe packet before it arrives at the fi= nal > egress. And, fragmentation and reassembly closer to the middle of the > network is much worse than fragmentation and reassembly nearer the > edges of the network. >=20 [RPB]=20 In that case, configure the inner tunnel so that it can't fragment the deli= very packet and configure the outer tunnel so that it can. > This is why I have proposed a new "Don't Fragment" bit in the GRE header. > It can be set by the first tunnel ingress to tell other tunnels not to fr= agment > the packet that is being used as a probe. Fragmentation and reassembly of > probe packets must be avoided if we are to avoid fragmentation and > reassembly of data packets. [RPB]=20 That's a fine idea, but because it isn't backwards compatible, it isn't GRE= . >=20 > Also, it might be worth noting that this is not the first time a tunnel l= oopback > test packet has been specified. A similar facility is specified in Sectio= n 8 of > RFC5969. [RPB]=20 GRE Liveness testing isn't specified in any RFC, but it has been widely dep= loyed by many vendors for over a decade. R= on >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >=20 ***** From nobody Thu Apr 16 07:15:22 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61501A87CD for ; Thu, 16 Apr 2015 07:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNeAuOzu0GkO for ; Thu, 16 Apr 2015 07:15:19 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DEF1A87CB for ; Thu, 16 Apr 2015 07:15:18 -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 t3GEFIBJ016396; Thu, 16 Apr 2015 07:15:18 -0700 Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3GEFDrI016312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 16 Apr 2015 07:15:13 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.46]) with mapi id 14.03.0235.001; Thu, 16 Apr 2015 07:15:12 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: draft-ietf-intarea-gre-ipv6-07 Thread-Index: AdB4RX9jTIT97vUGSf6b1f7L8GYJ3AACbFVA Date: Thu, 16 Apr 2015 14:15:11 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4ABCC@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] draft-ietf-intarea-gre-ipv6-07 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 14:15:21 -0000 Hi Ron, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bon= ica > Sent: Thursday, April 16, 2015 6:02 AM > To: int-area@ietf.org > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6-07 >=20 > Fred, >=20 > Inline.... >=20 > Ron >=20 > > > > Message: 1 > > Date: Tue, 14 Apr 2015 16:24:00 +0000 > > From: "Templin, Fred L" > > To: "int-area@ietf.org" > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > Message-ID: > > <2134F8430051B64F815C691A62D9831832E483BE@XCH-BLV- > > 504.nw.nos.boeing.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Hi, in Section 3.2 there is now specification for sending a 1280 byte p= robe > > packet to test the path between the ingress and egress. The stated goal= is to > > ensure that a 1280 byte packet can traverse the tunnel without > > fragmentation. > > > > However, if there are other tunnels on the path from the first tunnel i= ngress > > toward the corresponding egress, it is possible that another tunnel cou= ld be > > fragmenting and reassembling the probe packet before it arrives at the = final > > egress. And, fragmentation and reassembly closer to the middle of the > > network is much worse than fragmentation and reassembly nearer the > > edges of the network. > > > [RPB] > In that case, configure the inner tunnel so that it can't fragment the de= livery packet and configure the outer tunnel so that it can. There may be more than one levels of nesting. And, when there are multiple layers of nesting it is better to fragment in the innermost nesting rather = than at outer nestings since the innermost nesting is nearest the edge of the network and not nearest the core. > > This is why I have proposed a new "Don't Fragment" bit in the GRE heade= r. > > It can be set by the first tunnel ingress to tell other tunnels not to = fragment > > the packet that is being used as a probe. Fragmentation and reassembly = of > > probe packets must be avoided if we are to avoid fragmentation and > > reassembly of data packets. > [RPB] > That's a fine idea, but because it isn't backwards compatible, it isn't G= RE. It is GRE. I already told you how the tunnel ingress can run a quick check = to see if the feature is available. > > Also, it might be worth noting that this is not the first time a tunnel= loopback > > test packet has been specified. A similar facility is specified in Sect= ion 8 of > > RFC5969. > [RPB] >=20 > GRE Liveness testing isn't specified in any RFC, but it has been widely d= eployed by many vendors for over a decade. That is fine. But, liveness testing is not quite the same thing as fragment= ation testing. Thanks - Fred fred.l.templin@boeing.com > = Ron >=20 >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > ***** >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 16 15:44:19 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFB41B3823 for ; Thu, 16 Apr 2015 15:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2O-J0-Z-ipD for ; Thu, 16 Apr 2015 15:44:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914A71B3817 for ; Thu, 16 Apr 2015 15:43:24 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 16 Apr 2015 22:43:23 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) with mapi id 15.01.0136.014; Thu, 16 Apr 2015 22:43:23 +0000 From: Ronald Bonica To: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPw== Date: Thu, 16 Apr 2015 22:43:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(2900100001)(450100001)(110136001)(86362001)(62966003)(54356999)(102836002)(77156002)(107886001)(2351001)(512954002)(92566002)(87936001)(40100003)(2656002)(33656002)(99286002)(19580405001)(66066001)(46102003)(19580395003)(50986999)(2501003)(76576001)(230783001)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 0548586081 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 22:43:22.5474 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 22:44:18 -0000 Fred, In Section 3.2, we put implementation details of the probing mechanism out = of scope. Regardless of MTU and fragmentation issues, a robust GRE implementation req= uires a probing mechanism. Without such a probing mechanism, a GRE ingress = node might activate a GRE tunnel when the egress was not reachable at all. = This would result in black-holing. Since RFC 2784 doesn't specify a probing mechanism (or even require one) mo= st vendors have developed proprietary probing mechanisms. These proprietary= mechanism must deal with the problems of LAG and ECMP. However, because th= e probing mechanisms aren't IPv6 specific, and because they are proprietary= , we put them out of scope. = Ron > ------------------------------ >=20 > Message: 2 > Date: Tue, 14 Apr 2015 17:12:53 +0000 > From: "Templin, Fred L" > To: "int-area@ietf.org" > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > Message-ID: > <2134F8430051B64F815C691A62D9831832E495AD@XCH-BLV- > 504.nw.nos.boeing.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > I will say also that the act of probing in general is a bit troublesome. = In > particular, when there is Equal Cost MultiPath (ECMP) how can you tell th= at > the probe packets will follow the same path as the data packets? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 [RPB]=20 *** From nobody Thu Apr 16 19:14:55 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85A41A8F4F for ; Thu, 16 Apr 2015 19:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu4eDI6-XdGq for ; Thu, 16 Apr 2015 19:14:53 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4BF1A8F4E for ; Thu, 16 Apr 2015 19:14:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3H2EqLo013810; Thu, 16 Apr 2015 19:14:52 -0700 Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3H2EnA5013800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 16 Apr 2015 19:14:50 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.46]) with mapi id 14.03.0235.001; Thu, 16 Apr 2015 19:14:49 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjg Date: Fri, 17 Apr 2015 02:14:48 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 02:14:54 -0000 Hi Ron, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bon= ica > Sent: Thursday, April 16, 2015 3:43 PM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Fred, >=20 > In Section 3.2, we put implementation details of the probing mechanism ou= t of scope. But, Section 3.2 is all about probing for a specific size - 1280 bytes. > Regardless of MTU and fragmentation issues, a robust GRE implementation r= equires a probing mechanism. Without such a probing > mechanism, a GRE ingress node might activate a GRE tunnel when the egress= was not reachable at all. This would result in black- > holing. Probing for liveness, I can understand. Like maybe send a little 100 byte p= acket and see if it boomerangs back to you. But, probing with 1280 might not tell the= whole story if there are ECMP or LAG branches on the path. Also, while probing, why not also check to see if it supports GRE fragmenta= tion? > Since RFC 2784 doesn't specify a probing mechanism (or even require one) = most vendors have developed proprietary probing > mechanisms. These proprietary mechanism must deal with the problems of LA= G and ECMP. However, because the probing > mechanisms aren't IPv6 specific, and because they are proprietary, we put= them out of scope. Your document Section 3.2 is asking for probing the IPv6 minMTU of 1280 plu= s the encapsulation overhead. That might work on one path of a multipath but actual data packets might take a different path. This does not make me happ= y because I also want to do some probing of my own. But, it seems like something we may need to worry about. Thanks - Fred fred.l.templin@boeing.com > = Ron >=20 > > ------------------------------ > > > > Message: 2 > > Date: Tue, 14 Apr 2015 17:12:53 +0000 > > From: "Templin, Fred L" > > To: "int-area@ietf.org" > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > Message-ID: > > <2134F8430051B64F815C691A62D9831832E495AD@XCH-BLV- > > 504.nw.nos.boeing.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I will say also that the act of probing in general is a bit troublesome= . In > > particular, when there is Equal Cost MultiPath (ECMP) how can you tell = that > > the probe packets will follow the same path as the data packets? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > >=20 > [RPB] > *** >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Apr 17 00:31:41 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23391B2A2B; Fri, 17 Apr 2015 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXy4Z-KIq3N9; Fri, 17 Apr 2015 00:31:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4DF1B2A11; Fri, 17 Apr 2015 00:28:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUZ02738; Fri, 17 Apr 2015 07:28:33 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Apr 2015 08:28:32 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 17 Apr 2015 15:28:29 +0800 From: Xuxiaohu To: Internet Area Thread-Topic: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt Thread-Index: AQHQeN7X+zCAKWkizkar4vH7PZ5u9J1QzJdw Date: Fri, 17 Apr 2015 07:28:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326453@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Softwires WG Subject: [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 07:31:38 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGlzIGEgcmVwbGFjZW1lbnQgb2YgZHJhZnQteHUtc29mdHdp cmUtaXAtaW4tdWRwIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc29mdHdp cmUtaXAtaW4tdWRwLTAzKS4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ IFNlbnQ6IEZyaWRheSwgQXByaWwgMTcsIDIwMTUgMzoxOSBQTQ0KPiBUbzogTHVjeSB5b25nOyBZ aXUgTGVlOyBYdXhpYW9odTsgUmFqaXYgQXNhdGk7IFh1eGlhb2h1OyBMdWN5IHlvbmc7IElsaml0 c2NoIHZhbg0KPiBCZWlqbnVtOyBZaXUgTGVlOyBZb25nYmluZyBGYW47IFJhaml2IEFzYXRpOyBJ bGppdHNjaCB2YW4gQmVpam51bTsgRmFuIFlvbmdiaW5nDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDAudHh0DQo+IA0K PiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1LWludGFyZWEtaXAtaW4tdWRwLTAw LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkNCj4gc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQteHUtaW50 YXJlYS1pcC1pbi11ZHANCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJRW5jYXBzdWxhdGluZyBJ UCBpbiBVRFANCj4gRG9jdW1lbnQgZGF0ZToJMjAxNS0wNC0xNw0KPiBHcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTEwDQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDAudHh0DQo+IFN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1p bnRhcmVhLWlwLWluLXVkcC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LWludGFyZWEtaXAtaW4tdWRwLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6 DQo+ICAgIEV4aXN0aW5nIFNvZnR3aXJlIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVzIGFyZSBu b3QgYWRlcXVhdGUgZm9yDQo+ICAgIGVmZmljaWVudCBsb2FkIGJhbGFuY2luZyBvZiBTb2Z0d2ly ZSBzZXJ2aWNlIHRyYWZmaWMgYWNyb3NzIElQDQo+ICAgIG5ldHdvcmtzLiAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYWRkaXRpb25hbCBTb2Z0d2lyZSBlbmNhcHN1bGF0aW9uDQo+ICAgIHRlY2hu b2xvZ3ksIHJlZmVycmVkIHRvIGFzIElQLWluLVVzZXIgRGF0YWdyYW0gUHJvdG9jb2wgKFVEUCks IHdoaWNoDQo+ICAgIGNhbiBmYWNpbGl0YXRlIHRoZSBsb2FkIGJhbGFuY2luZyBvZiBTb2Z0d2ly ZSBzZXJ2aWNlIHRyYWZmaWMgYWNyb3NzDQo+ICAgIElQIG5ldHdvcmtzLg0KPiANCj4gDQo+IA0K PiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From nobody Fri Apr 17 08:58:26 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C61A87B1 for ; Fri, 17 Apr 2015 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90YK4p8izWr8 for ; Fri, 17 Apr 2015 08:58:23 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 619E51B2E38 for ; Fri, 17 Apr 2015 08:55:39 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so15682654igb.1 for ; Fri, 17 Apr 2015 08:55:38 -0700 (PDT) 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:content-type; bh=WB7aw0HbHmvahf3eZrAoVBZxJuywmvD7hb7W9uM1r3A=; b=FdzaD1nAcanqI0I1szYQnJj4J6J2JeeUVnc8jDBWv01X3sTzT0wpC2XoPbODlGzuG1 8viHmKqS73WxdOwCOAtpKFo8YN5QbEqsjmuigADayVlB9ndGbHPCM4nTqoxjG0WSq0iP 0VMGxLv2shXIUgb5SfcD/P2i1yXL0rXNN0YN/Mk86pz8Pkj+kMxHyDAV+s9RJ3SEK3O3 dLGx0ZgHJJiX2cM8IpyENJJm4c/iclz5PgED1m6T1K7YkjYdVFWf1NBWPeYrT4aJF0NW a53BFjjtpkhW6QR8g/iyacp3CrRPT2UquV7JJIoQ+t0YiPZ4kGuIbRdalEE/YRQejgTj V70A== X-Gm-Message-State: ALoCoQlcmptyZUz++BBv5IkqqD+ngKn8GqEZJOuFTKvt3sfmwBYiZ0w2i+DJZrvIjV7LOBAc3upT MIME-Version: 1.0 X-Received: by 10.107.130.165 with SMTP id m37mr4503590ioi.62.1429286138816; Fri, 17 Apr 2015 08:55:38 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Fri, 17 Apr 2015 08:55:38 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326453@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326453@NKGEML512-MBS.china.huawei.com> Date: Fri, 17 Apr 2015 08:55:38 -0700 Message-ID: From: Tom Herbert To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Softwires WG , Internet Area Subject: Re: [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 15:58:25 -0000 Hi Xuxiaohu, A few comments... - It seems like the proposal is just to encapsulate IP in UDP analogous to IPIP, so I'm not sure that the references to softwire are particularly necessary. - IP-in-UDP is already implement in Linux using foo-over-udp (as is GRE-in-UDP, and IPv6-in-UDP), https://lwn.net/Articles/614348/. You might also want to look at http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf for implementation details of UDP encapsulation. - GUE can also be used to solve this same problem at the cost of four additional bytes, but with the advantages of an extensible and generic protocol (draft-ietf-nvo3-gue). - I don't believe that it is a good to recommend not using IPv4 checksum in a protocol specification. This should be a MAY to set zero for IPv4 checksum and the operator should decide what to do. This is because: 1) The UDP destination port is not covered by the IPv4 header checksum. The IPv4 checksum protects against mis-delivery to wrong address, but not to the wrong port. The UDP checksum does cover the ports so would protect against mis-delivery to wrong port. Arguably, mis-delivery to a port may be worse than mis-delivery to an address. If a UDP packet is sent to wrong address but right port the receiver will likely correctly interpret the packet as IP-in-UDP and will either drop the packet because if it has no tunnel with the source established, or will just decapsulate and forward the packet to the inner destination. If the destination port is corrupted, the packet is crossing applications so the results are nondeterministic. 2) Presumably, the rationale for not using the UDP checksum is to avoid the performance hit in checksum calculation. However we have found that for hosts using the most common deployed NICs, using the UDP checksum with encapsulation is actually a performance benefit. See the paper I linked above. - Conversely, requiring the UDP checksum to be used with IPv6 is probably not necessary. RFC6935 and RFC6936 provide conditions when a tunneling protocol such as this can use a zero checksum for IPv6. GRE-in-UDP defines specific requirements for zero checksum mode, some of that could be replicated here (most likely as a subset since GRE allows non-IP protocols which needed to be considered wrt checksum). Tom On Fri, Apr 17, 2015 at 12:28 AM, Xuxiaohu wrote: > Hi all, > > This draft is a replacement of draft-xu-softwire-ip-in-udp (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp-03). Any comments are welcome. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, April 17, 2015 3:19 PM >> To: Lucy yong; Yiu Lee; Xuxiaohu; Rajiv Asati; Xuxiaohu; Lucy yong; Iljitsch van >> Beijnum; Yiu Lee; Yongbing Fan; Rajiv Asati; Iljitsch van Beijnum; Fan Yongbing >> Subject: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt >> >> >> A new version of I-D, draft-xu-intarea-ip-in-udp-00.txt has been successfully >> submitted by Xiaohu Xu and posted to the IETF repository. >> >> Name: draft-xu-intarea-ip-in-udp >> Revision: 00 >> Title: Encapsulating IP in UDP >> Document date: 2015-04-17 >> Group: Individual Submission >> Pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-xu-intarea-ip-in-udp-00.txt >> Status: https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/ >> Htmlized: http://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-00 >> >> >> Abstract: >> Existing Softwire encapsulation technologies are not adequate for >> efficient load balancing of Softwire service traffic across IP >> networks. This document specifies additional Softwire encapsulation >> technology, referred to as IP-in-User Datagram Protocol (UDP), which >> can facilitate the load balancing of Softwire service traffic across >> IP networks. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Sun Apr 19 19:40:49 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3F1AC3AE; Sun, 19 Apr 2015 19:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CviRQVhMLKO0; Sun, 19 Apr 2015 19:40:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5561C1AC3AC; Sun, 19 Apr 2015 19:40:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRO99533; Mon, 20 Apr 2015 02:40:44 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Apr 2015 03:40:42 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 20 Apr 2015 10:40:39 +0800 From: Xuxiaohu To: Tom Herbert Thread-Topic: [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt Thread-Index: AQHQeN7X+zCAKWkizkar4vH7PZ5u9J1QzJdwgAAJdACABFRd4A== Date: Mon, 20 Apr 2015 02:40:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832697E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326453@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Softwires WG , Internet Area Subject: Re: [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 02:40:48 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMuIFBsZWFzZSBzZWUg bXkgcmVzcG9uc2UgaW5saW5lLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+IFNlbnQ6IEZy aWRheSwgQXByaWwgMTcsIDIwMTUgMTE6NTYgUE0NCj4gVG86IFh1eGlhb2h1DQo+IENjOiBJbnRl cm5ldCBBcmVhOyBTb2Z0d2lyZXMgV0cNCj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAt MDAudHh0DQo+IA0KPiBIaSBYdXhpYW9odSwNCj4gDQo+IEEgZmV3IGNvbW1lbnRzLi4uDQo+IA0K PiAtIEl0IHNlZW1zIGxpa2UgdGhlIHByb3Bvc2FsIGlzIGp1c3QgdG8gZW5jYXBzdWxhdGUgSVAg aW4gVURQIGFuYWxvZ291cyB0byBJUElQLCBzbw0KPiBJJ20gbm90IHN1cmUgdGhhdCB0aGUgcmVm ZXJlbmNlcyB0byBzb2Z0d2lyZSBhcmUgcGFydGljdWxhcmx5IG5lY2Vzc2FyeS4NCg0KWW91ciBv YnNlcnZhdGlvbiBpcyBjb3JyZWN0IHRoYXQgdGhpcyBwcm9wb3NhbCBpcyBqdXN0IHRvIGVuY2Fw c3VsYXRlIElQIGluIFVEUC4gIFNpbmNlIGFsbCBjb21iaW5hdGlvbnMgb2YgSVAgdmVyc2lvbnMg b3ZlciBvbmUgb3RoZXIgKElQdjQgb3ZlciBJUHY2LCBJUHY2IG92ZXIgSVB2NCwgSVB2NCBvdmVy IElQdjQsIElQdjYgb3ZlciBJUHY2KSBoYWQgZXZlciBiZWVuIHJlZmVycmVkIHRvIGFzIHNvZnR3 aXJlIGVuY2Fwc3VsYXRpb24gbWVjaGFuaXNtcyBpbiB0aGUgSUVURiBjb21tdW5pdHkgKHNlZSBo dHRwczovL3Rvb2xzLmlldGYub3JnL3dnL3NvZnR3aXJlL2NoYXJ0ZXJzKSwgInNvZnR3aXJlIiBp cyBhZGRlZCB0byB0aGlzIHByb3Bvc2FsIGFzIGEgdXNlIGNhc2UgZm9yIElQLWluLVVEUC4NCg0K QlRXLCBzaW5jZSBJIHdhcyB0b2xkIGJ5IHRoZSBzb2Z0d2lyZSBjby1jaGFpcnMgdGhhdCB0aGUg c29mdHdpcmUgV0cgaXMgZ29pbmcgdG8gYmUgc2h1dGRvd24gYW5kIHRoZXJlZm9yZSB3b3VsZCBu b3QgYmUgc3VpdGFibGUgZm9yIHB1cnN1aW5nIHRoaXMgcHJvcG9zYWwsIEkgdGhlcmVmb3JlIHJl bmFtZWQgZHJhZnQteHUtc29mdHdpcmUtaXAtaW4tdWRwIChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQteHUtc29mdHdpcmUtaXAtaW4tdWRwLTAzKSBhbmQgdGhlbiBzdWJtaXR0ZWQg aXQgdG8gaW50YXJlYSBXRy4NCg0KPiAtIElQLWluLVVEUCBpcyBhbHJlYWR5IGltcGxlbWVudCBp biBMaW51eCB1c2luZyBmb28tb3Zlci11ZHAgKGFzIGlzIEdSRS1pbi1VRFAsDQo+IGFuZCBJUHY2 LWluLVVEUCksIGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy82MTQzNDgvLiBZb3UgbWlnaHQgYWxz byB3YW50IHRvIGxvb2sNCj4gYXQNCj4gaHR0cDovL3Blb3BsZS5uZXRmaWx0ZXIub3JnL3BhYmxv L25ldGRldjAuMS9wYXBlcnMvVURQLUVuY2Fwc3VsYXRpb24taW4tTGludXgNCj4gLnBkZg0KPiBm b3IgaW1wbGVtZW50YXRpb24gZGV0YWlscyBvZiBVRFAgZW5jYXBzdWxhdGlvbi4NCg0KSSdtIGds YWQgdG8gc2VlIHRoYXQgSVAtaW4tVURQIGhhcyBiZWVuIGltcGxlbWVudGVkIGluIExpbnV4LiBU aGFua3MgZm9yIHNoYXJpbmcgdGhpcyBpbmZvcm1hdGlvbi4NCg0KPiAtIEdVRSBjYW4gYWxzbyBi ZSB1c2VkIHRvIHNvbHZlIHRoaXMgc2FtZSBwcm9ibGVtIGF0IHRoZSBjb3N0IG9mIGZvdXIgYWRk aXRpb25hbA0KPiBieXRlcywgYnV0IHdpdGggdGhlIGFkdmFudGFnZXMgb2YgYW4gZXh0ZW5zaWJs ZSBhbmQgZ2VuZXJpYyBwcm90b2NvbA0KPiAoZHJhZnQtaWV0Zi1udm8zLWd1ZSkuDQo+IA0KPiAt IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGl0IGlzIGEgZ29vZCB0byByZWNvbW1lbmQgbm90IHVzaW5n IElQdjQgY2hlY2tzdW0gaW4gYQ0KPiBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLiBUaGlzIHNob3Vs ZCBiZSBhIE1BWSB0byBzZXQgemVybyBmb3IgSVB2NCBjaGVja3N1bSBhbmQNCj4gdGhlIG9wZXJh dG9yIHNob3VsZCBkZWNpZGUgd2hhdCB0byBkby4gIFRoaXMgaXMNCj4gYmVjYXVzZToNCj4gDQo+ IDEpIFRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBpcyBub3QgY292ZXJlZCBieSB0aGUgSVB2NCBo ZWFkZXIgY2hlY2tzdW0uIFRoZQ0KPiBJUHY0IGNoZWNrc3VtIHByb3RlY3RzIGFnYWluc3QgbWlz LWRlbGl2ZXJ5IHRvIHdyb25nIGFkZHJlc3MsIGJ1dCBub3QgdG8gdGhlDQo+IHdyb25nIHBvcnQu IFRoZSBVRFAgY2hlY2tzdW0gZG9lcyBjb3ZlciB0aGUgcG9ydHMgc28gd291bGQgcHJvdGVjdCBh Z2FpbnN0DQo+IG1pcy1kZWxpdmVyeSB0byB3cm9uZyBwb3J0LiBBcmd1YWJseSwgbWlzLWRlbGl2 ZXJ5IHRvIGEgcG9ydCBtYXkgYmUgd29yc2UgdGhhbg0KPiBtaXMtZGVsaXZlcnkgdG8gYW4gYWRk cmVzcy4NCj4gSWYgYSBVRFAgcGFja2V0IGlzIHNlbnQgdG8gd3JvbmcgYWRkcmVzcyBidXQgcmln aHQgcG9ydCB0aGUgcmVjZWl2ZXIgd2lsbCBsaWtlbHkNCj4gY29ycmVjdGx5IGludGVycHJldCB0 aGUgcGFja2V0IGFzIElQLWluLVVEUCBhbmQgd2lsbCBlaXRoZXIgZHJvcCB0aGUgcGFja2V0DQo+ IGJlY2F1c2UgaWYgaXQgaGFzIG5vIHR1bm5lbCB3aXRoIHRoZSBzb3VyY2UgZXN0YWJsaXNoZWQs IG9yIHdpbGwganVzdCBkZWNhcHN1bGF0ZQ0KPiBhbmQgZm9yd2FyZCB0aGUgcGFja2V0IHRvIHRo ZSBpbm5lciBkZXN0aW5hdGlvbi4gSWYgdGhlIGRlc3RpbmF0aW9uIHBvcnQgaXMNCj4gY29ycnVw dGVkLCB0aGUgcGFja2V0IGlzIGNyb3NzaW5nIGFwcGxpY2F0aW9ucyBzbyB0aGUgcmVzdWx0cyBh cmUgbm9uZGV0ZXJtaW5pc3RpYy4NCj4gDQo+IDIpIFByZXN1bWFibHksIHRoZSByYXRpb25hbGUg Zm9yIG5vdCB1c2luZyB0aGUgVURQIGNoZWNrc3VtIGlzIHRvIGF2b2lkIHRoZQ0KPiBwZXJmb3Jt YW5jZSBoaXQgaW4gY2hlY2tzdW0gY2FsY3VsYXRpb24uIEhvd2V2ZXIgd2UgaGF2ZSBmb3VuZCB0 aGF0IGZvciBob3N0cw0KPiB1c2luZyB0aGUgbW9zdCBjb21tb24gZGVwbG95ZWQgTklDcywgdXNp bmcgdGhlIFVEUCBjaGVja3N1bSB3aXRoDQo+IGVuY2Fwc3VsYXRpb24gaXMgYWN0dWFsbHkgYSBw ZXJmb3JtYW5jZSBiZW5lZml0LiBTZWUgdGhlIHBhcGVyIEkgbGlua2VkIGFib3ZlLg0KPiANCj4g LSBDb252ZXJzZWx5LCByZXF1aXJpbmcgdGhlIFVEUCBjaGVja3N1bSB0byBiZSB1c2VkIHdpdGgg SVB2NiBpcyBwcm9iYWJseSBub3QNCj4gbmVjZXNzYXJ5LiBSRkM2OTM1IGFuZCBSRkM2OTM2IHBy b3ZpZGUgY29uZGl0aW9ucyB3aGVuIGEgdHVubmVsaW5nIHByb3RvY29sDQo+IHN1Y2ggYXMgdGhp cyBjYW4gdXNlIGEgemVybyBjaGVja3N1bSBmb3IgSVB2Ni4NCj4gR1JFLWluLVVEUCBkZWZpbmVz IHNwZWNpZmljIHJlcXVpcmVtZW50cyBmb3IgemVybyBjaGVja3N1bSBtb2RlLCBzb21lIG9mDQo+ IHRoYXQgY291bGQgYmUgcmVwbGljYXRlZCBoZXJlIChtb3N0IGxpa2VseSBhcyBhIHN1YnNldCBz aW5jZSBHUkUgYWxsb3dzIG5vbi1JUA0KPiBwcm90b2NvbHMgd2hpY2ggbmVlZGVkIHRvIGJlIGNv bnNpZGVyZWQgd3J0IGNoZWNrc3VtKS4NCg0KVGhhbmtzIGZvciB5b3VyIGFib3ZlIGNvbW1lbnRz IHJlZ2FyZGluZyBVRFAgY2hlY2tzdW0uIFRob3NlIFVEUCBjaGVja3N1bSBjb25zaWRlcmF0aW9u cyB3aGljaCBoYXZlIGJlZW4gY29uY2x1ZGVkIGluIGJvdGggUkZDNzUxMCAoaS5lLiwgTVBMUy1p bi1VRFApIGFuZCBHUkUtaW4tVURQIGRyYWZ0IGFuZCBhcmUgYXBwbGljYWJsZSB0byBJUC1pbi1V RFAgY2FzZSB3b3VsZCBiZSByZXBsaWNhdGVkIHRvIHRoaXMgZHJhZnQgbGF0ZXIuIE9mIGNvdXJz ZSwgaWYgeW91IGhhdmUgYW55IGFkZGl0aW9uYWwgc3VnZ2VzdGlvbnMgYmFzZWQgb24geW91ciBp bXBsZW1lbnRhdGlvbiBvZiBJUC1pbi1VRFAgaW4gTGludXgsIHRoYXQgd291bGQgYmUgbXVjaCBh cHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gVG9tDQo+IA0KPiANCj4g DQo+IA0KPiBPbiBGcmksIEFwciAxNywgMjAxNSBhdCAxMjoyOCBBTSwgWHV4aWFvaHUgPHh1eGlh b2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFRoaXMgZHJhZnQg aXMgYSByZXBsYWNlbWVudCBvZiBkcmFmdC14dS1zb2Z0d2lyZS1pcC1pbi11ZHANCj4gKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zb2Z0d2lyZS1pcC1pbi11ZHAtMDMpLiBB bnkgY29tbWVudHMgYXJlDQo+IHdlbGNvbWUuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4g WGlhb2h1DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XQ0KPiA+PiBTZW50OiBGcmlkYXksIEFwcmlsIDE3LCAyMDE1IDM6MTkgUE0NCj4gPj4gVG86IEx1 Y3kgeW9uZzsgWWl1IExlZTsgWHV4aWFvaHU7IFJhaml2IEFzYXRpOyBYdXhpYW9odTsgTHVjeSB5 b25nOw0KPiA+PiBJbGppdHNjaCB2YW4gQmVpam51bTsgWWl1IExlZTsgWW9uZ2JpbmcgRmFuOyBS YWppdiBBc2F0aTsgSWxqaXRzY2gNCj4gPj4gdmFuIEJlaWpudW07IEZhbiBZb25nYmluZw0KPiA+ PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+IGRyYWZ0LXh1LWlu dGFyZWEtaXAtaW4tdWRwLTAwLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDAudHh0IGhhcyBiZWVuDQo+ID4+IHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCj4gPj4NCj4gPj4gTmFtZTogICAgICAgICBkcmFmdC14dS1pbnRhcmVhLWlw LWluLXVkcA0KPiA+PiBSZXZpc2lvbjogICAgIDAwDQo+ID4+IFRpdGxlOiAgICAgICAgICAgICAg ICBFbmNhcHN1bGF0aW5nIElQIGluIFVEUA0KPiA+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgMjAx NS0wNC0xNw0KPiA+PiBHcm91cDogICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4+IFBhZ2VzOiAgICAgICAgICAgICAgICAxMA0KPiA+PiBVUkw6DQo+ID4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LWludGFyZWEtaXAtaW4tdWRwLTAw LnR4dA0KPiA+PiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAvDQo+ID4+IEh0bWxpemVkOiAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pbnRhcmVhLWlwLWluLXVkcC0wMA0KPiA+ Pg0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgRXhpc3RpbmcgU29mdHdpcmUgZW5jYXBz dWxhdGlvbiB0ZWNobm9sb2dpZXMgYXJlIG5vdCBhZGVxdWF0ZSBmb3INCj4gPj4gICAgZWZmaWNp ZW50IGxvYWQgYmFsYW5jaW5nIG9mIFNvZnR3aXJlIHNlcnZpY2UgdHJhZmZpYyBhY3Jvc3MgSVAN Cj4gPj4gICAgbmV0d29ya3MuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhZGRpdGlvbmFsIFNv ZnR3aXJlIGVuY2Fwc3VsYXRpb24NCj4gPj4gICAgdGVjaG5vbG9neSwgcmVmZXJyZWQgdG8gYXMg SVAtaW4tVXNlciBEYXRhZ3JhbSBQcm90b2NvbCAoVURQKSwgd2hpY2gNCj4gPj4gICAgY2FuIGZh Y2lsaXRhdGUgdGhlIGxvYWQgYmFsYW5jaW5nIG9mIFNvZnR3aXJlIHNlcnZpY2UgdHJhZmZpYyBh Y3Jvc3MNCj4gPj4gICAgSVAgbmV0d29ya3MuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQo+ID4gSW50LWFyZWFA aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1h cmVhDQo= From nobody Mon Apr 20 21:05:13 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED91A905E for ; Mon, 20 Apr 2015 21:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrFwfoaRsZr5 for ; Mon, 20 Apr 2015 21:05:10 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6D01A905D for ; Mon, 20 Apr 2015 21:05:10 -0700 (PDT) Received: by pdea3 with SMTP id a3so229006514pde.3 for ; Mon, 20 Apr 2015 21:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QZeJqvYbE7sbP099UsapOW1bv5wH9YLbHDb1y+kATkg=; b=ZkEB3jcCJzSh1OjPD0mJiDh7VznHs+VfKHhHmBvBdY1tsr45pacwByx4Jbmqaf1Uf4 vy+L78nvidYwSTwcnlz+VFt6szsyWJz+QviZSv73Sbk6dZpH3DmSo4tguGrDbyd6ePM9 +UAXs/Ye+///UMbb/y3sHF4ymlYKl2PU86IjCE7Z5vNhWTifkoldNunIuGDi/ey0FKj0 r9SUZlCt9Mg6qnMQ69Dxk4ln5On3q62+qTqPCzJg+R8tN/+YP6xzBBEGUBpYnSiHBJIn QXq9jwTRZKim/wy6RRUGVVX68CqwchJ5Vyv9Pev4pGYsPYbIX0x4w2fQVj1w2P/nI4Y6 Q2HQ== X-Received: by 10.68.68.134 with SMTP id w6mr33702810pbt.25.1429589110149; Mon, 20 Apr 2015 21:05:10 -0700 (PDT) Received: from ?IPv6:2406:e007:679c:1:28cc:dc4c:9703:6781? ([2406:e007:679c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id pv2sm469369pbb.12.2015.04.20.21.05.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 21:05:08 -0700 (PDT) Message-ID: <5535CC76.4060204@gmail.com> Date: Tue, 21 Apr 2015 16:05:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: int-area@ietf.org References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> In-Reply-To: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 04:05:12 -0000 Hi, > IPv6 flow label has been proposed as an entropy field for load > balancing in IPv6 network environment [RFC6438]. However, as stated > in [RFC6936], the end-to-end use of flow labels for load balancing is > a long-term solution and therefore the use of load balancing using > the transport header fields would continue until any widespread > deployment is finally achieved. That is a false argument. RFC6438 describes a model where the tunnel end point sets the flow label; that is a much smaller fix to a tunnel end point that converting it to use a new encapsulation such as IP-in-UDP. Also, the code to generate the "entropy" value that you propose as a bogus source port number is no simpler than the code to generate a pseudo-random flow label; in fact it's virtually the same code, except that it generates a 16-bit port number instead of a 20-bit flow label. (The argument is RFC6936 is also false, since it says you need a stateful solution, but you don't; 6438 makes it clear that you use a stateless hash.) > This field contains a 16-bit entropy value that is generated by > the encapsulator to uniquely identify a flow. What constitutes > a flow is locally determined by the encapsulator and therefore > is outside the scope of this document. What algorithm is > actually used by the encapsulator to generate an entropy value > is outside the scope of this document. That is ducking the hard part. I recommend the discussions in RFC 6437 and 6438, where we tried to avoid completely ducking it. You don't even discuss whether the algorithm is stateful or stateless. For a stateless hash, I am quite fond of FNV. > In case the tunnel does not need entropy, this field of all > packets belonging to a given flow SHOULD be set to a randomly > selected constant value so as to avoid packet reordering. That is very confusing. Yes, of course, all packets that belong to the same microflow must have the same ECMP hash, therefore in your model they must carry the same bogus source port number. But what is the difference between "a randomly selected constant value" and the result of your unspecified "entropy value"? They are both pseudorandom values that are held constant for a given microflow. Bottom line, I don't understand why the world needs this hack (pseudorandom source port). It is no easier to deploy than the correct solution (pseudorandom flow label). Brian From nobody Tue Apr 21 01:20:04 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6381B3763 for ; Tue, 21 Apr 2015 01:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMxAwjvgLNj5 for ; Tue, 21 Apr 2015 01:20:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D4D1B3750 for ; Tue, 21 Apr 2015 01:20:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVC50080; Tue, 21 Apr 2015 08:19:58 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 09:19:57 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 16:19:54 +0800 From: Xuxiaohu To: Brian E Carpenter , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt Thread-Index: AQHQe+hivoBeBWzFCUWqrdbvp0uAFZ1XEL5w Date: Tue, 21 Apr 2015 08:19:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326F89@NKGEML512-MBS.china.huawei.com> References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> <5535CC76.4060204@gmail.com> In-Reply-To: <5535CC76.4060204@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 08:20:03 -0000 Hi Brain, Thanks for your comments and please see my response inline. > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Tuesday, April 21, 2015 12:05 PM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt >=20 > Hi, >=20 > > IPv6 flow label has been proposed as an entropy field for load > > balancing in IPv6 network environment [RFC6438]. However, as stated > > in [RFC6936], the end-to-end use of flow labels for load balancing is > > a long-term solution and therefore the use of load balancing using the > > transport header fields would continue until any widespread deployment > > is finally achieved. >=20 > That is a false argument. RFC6438 describes a model where the tunnel end = point > sets the flow label; that is a much smaller fix to a tunnel end point tha= t > converting it to use a new encapsulation such as IP-in-UDP. Also, the cod= e to > generate the "entropy" value that you propose as a bogus source port numb= er is > no simpler than the code to generate a pseudo-random flow label; in fact = it's > virtually the same code, except that it generates a 16-bit port number in= stead of > a 20-bit flow label. Agree with your argument that it's virtually the same code for generating t= he entropy value. > (The argument is RFC6936 is also false, since it says you need a stateful= solution, > but you don't; 6438 makes it clear that you use a stateless > hash.) My guess is that the co-authors of RFC6936 had been fully convinced with th= e logic of RFC6438 (i.e., including transport-layer information as input ke= ys to a hash may be a problem, especially for the IPv6 case and therefore u= sing the {dest addr, source addr, flow label} 3-tuple of the inner packet w= ould be a future-proof option). As such, in the case where the inner packet= use IPv6 with the flow label of zero, to provide good entropy in the flo= w label field of the outer IPv6 header, the only reasonable way that the co= -authors of RFC6936 could think of is to allow the tunnel ingress to create= a random flow label value and keep corresponding state so that all packets= that were associated with a flow would be consistently given the same flow= label. ^_^ > > This field contains a 16-bit entropy value that is generated by the > > encapsulator to uniquely identify a flow. What constitutes a flow is > > locally determined by the encapsulator and therefore is outside the > > scope of this document. What algorithm is actually used by the > > encapsulator to generate an entropy value is outside the scope of this > > document. >=20 > That is ducking the hard part. I recommend the discussions in RFC 6437 an= d > 6438, where we tried to avoid completely ducking it. > You don't even discuss whether the algorithm is stateful or stateless. Fo= r a > stateless hash, I am quite fond of FNV. It's stateless. By the way, I believe the implementers would have enough in= telligence to prefer a statelss algorithm to a stateful algorithm unless th= ere was extraordinary reasons. > > In case the tunnel does not need entropy, this field of all packets > > belonging to a given flow SHOULD be set to a randomly selected > > constant value so as to avoid packet reordering. >=20 > That is very confusing. Yes, of course, all packets that belong to the sa= me > microflow must have the same ECMP hash, therefore in your model they must > carry the same bogus source port number. But what is the difference betwe= en > "a randomly selected constant value" > and the result of your unspecified "entropy value"? They are both > pseudorandom values that are held constant for a given microflow. >=20 > Bottom line, I don't understand why the world needs this hack (pseudorand= om > source port). It is no easier to deploy than the correct solution (pseudo= random > flow label). Bottom line is flow label is only contained in IPv6 header:) By the way, yo= u may be curious to know why the RTG DP Encapsulation design team has the f= ollowing assessment in its report (https://tools.ietf.org/html/draft-rtg-dt= -encap-01#page-7): "It has been suggested that when IPv6 is used it would not be necessary to add a UDP header for entropy, since the IPv6 flow label can be used for entropy.... While such an approach would save 8 bytes of= headers when the underlay is IPv6, it does assume that the underlay routers use the flow label for ECMP, and it also would make the IPv6 approach different than the IPv4 approach. Currently the leaning is towards recommending using the UDP encaps for both IPv4 and IPv6 underlay." Best regards, Xiaohu > Brian >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Apr 21 08:42:27 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548B71ACE3F for ; Tue, 21 Apr 2015 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m5gkhRegS2B for ; Tue, 21 Apr 2015 08:42:25 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 67E111ACE7B for ; Tue, 21 Apr 2015 08:42:22 -0700 (PDT) Received: by igblo3 with SMTP id lo3so18682281igb.0 for ; Tue, 21 Apr 2015 08:42:22 -0700 (PDT) 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:content-type; bh=VQFZqjvaZHefPmj30P2h+DeXdfwsaCzMp4urXVvVxDc=; b=mp10s+0G5yU1TcpFRoaHFfpu852eCChD/vIN+ryFBagzX2w9etntswWaR0FrR54DaY CEY4k45Dz9WS9ZcQvwTgk7iwj6s87WUuetx+Ow0vnsWgjtPstIRQD16JGriy5A8omo+e umpGd54O7NmkbjOjygC9TNfpgh1vdHelK450QYKFAGzZ4Kc/BMt3zX5mogCKZKAkHM6B dsNb5oE0cJ06Y202QXswbVb8xiPSppCzOL34dwOkJg+i8dt01L/xNphxqDcY5bIegiVo qu8XAZ7tx8bNS1fVwsaAytqyUFzMfd/i4ymshbTPJeNyqZ+jTNwEi2em2kURF8aGaJMI TwRQ== X-Gm-Message-State: ALoCoQlROUfJz+39hlbLwkVE40gVoX1hlMOQlfUVs9Mn8Pt3w5QLXQbxomxTj+pXJxS5nlJ0kFP2 MIME-Version: 1.0 X-Received: by 10.107.128.149 with SMTP id k21mr29274888ioi.7.1429630940938; Tue, 21 Apr 2015 08:42:20 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Tue, 21 Apr 2015 08:42:20 -0700 (PDT) In-Reply-To: <5535CC76.4060204@gmail.com> References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> <5535CC76.4060204@gmail.com> Date: Tue, 21 Apr 2015 08:42:20 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 15:42:26 -0000 On Mon, Apr 20, 2015 at 9:05 PM, Brian E Carpenter wrote: > Hi, > >> IPv6 flow label has been proposed as an entropy field for load >> balancing in IPv6 network environment [RFC6438]. However, as stated >> in [RFC6936], the end-to-end use of flow labels for load balancing is >> a long-term solution and therefore the use of load balancing using >> the transport header fields would continue until any widespread >> deployment is finally achieved. > > That is a false argument. RFC6438 describes a model where the > tunnel end point sets the flow label; that is a much smaller fix > to a tunnel end point that converting it to use a new encapsulation > such as IP-in-UDP. Brian, Updating end hosts to set flow labels per RFC6438 is easy (e.g. this is supported in Linux stack now). Upgrading all of our switches in the network to use flow labels for ECMP and updating all of our NICs to use flow labels for RSS is *not* easy-- this assumes that would could even find HW that supports labels and are already using IPv6. Deployed devices commonly support hashing UDP tuple for ECMP and RSS. This works reliably for both IPv6 and IPv4, and in fact is a major motivation for proposed encapsulation protocols using UDP (MPLS-in-UDP, GRE-in-UDP, VXLAN, GUE, Geneve, etc.). Intermediate device support for flow labels is still needed, for instance we only get 14 bits of entropy in UDP source port (ephemeral port range) which is too little for some use cases. Tom From nobody Tue Apr 21 13:43:34 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E861B2B36 for ; Tue, 21 Apr 2015 13:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN6yXLooLxlF for ; Tue, 21 Apr 2015 13:43:30 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 86D621B2B34 for ; Tue, 21 Apr 2015 13:43:30 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so251644413pab.2 for ; Tue, 21 Apr 2015 13:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=grwOEuAAKhmf7g+Z0vtbpa97HGguRb4HcQ/5TZRXYU4=; b=tE1mz7jO5unIbsQ7FGIDJnsadAbxpCc3QkqnLIauUsyHsVQJ6wYJz0LWpHQXSbGQ1S SaYU9wkeRSGu27idF/MXhfgkP5ZjHgCEcvw3ZV5V8wo+E8LrQ6atXZyps5uWoIJ8Ap32 h0VTo/eKBaqa6ifcgXrDnPGvoda7kzlyefYQEit8ARdV+CvezC5+u6SenfwUNYSxjN8Q qK3JpksxRNItqcVsWrFPjr6vlJBIXjdzXeiBiJeXFs0FgiujmTd5NPWBZDWPrErmm8Zs PnIBfv6eY2QGTZvPQwPFVcYD0CZDKsKJRr4jhv27AqOopZbgJ3FB554WLMKSKjCWSmgc 84sQ== X-Received: by 10.66.221.135 with SMTP id qe7mr40113598pac.97.1429649010149; Tue, 21 Apr 2015 13:43:30 -0700 (PDT) Received: from ?IPv6:2406:e007:7ded:1:28cc:dc4c:9703:6781? ([2406:e007:7ded:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id q3sm2906107pds.49.2015.04.21.13.43.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 13:43:28 -0700 (PDT) Message-ID: <5536B673.6080107@gmail.com> Date: Wed, 22 Apr 2015 08:43:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> <5535CC76.4060204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:43:32 -0000 Tom, On 22/04/2015 03:42, Tom Herbert wrote: > On Mon, Apr 20, 2015 at 9:05 PM, Brian E Carpenter > wrote: >> Hi, >> >>> IPv6 flow label has been proposed as an entropy field for load >>> balancing in IPv6 network environment [RFC6438]. However, as stated >>> in [RFC6936], the end-to-end use of flow labels for load balancing is >>> a long-term solution and therefore the use of load balancing using >>> the transport header fields would continue until any widespread >>> deployment is finally achieved. >> >> That is a false argument. RFC6438 describes a model where the >> tunnel end point sets the flow label; that is a much smaller fix >> to a tunnel end point that converting it to use a new encapsulation >> such as IP-in-UDP. > > Brian, > > Updating end hosts to set flow labels per RFC6438 is easy (e.g. this > is supported in Linux stack now). Upgrading all of our switches in the > network to use flow labels for ECMP and updating all of our NICs to > use flow labels for RSS is *not* easy-- this assumes that would could > even find HW that supports labels and are already using IPv6. True. But we only make it less likely to happen by proposing a work-around with bogus port numbers. I don't think that is the IETF showing industry leadership, exactly. (The same goes for Xiaohu's quote from https://tools.ietf.org/html/draft-rtg-dt-encap-01#page-7 .) If we cop out, we can certainly rely on the industry following us. Rgds Brian > Deployed > devices commonly support hashing UDP tuple for ECMP and RSS. This > works reliably for both IPv6 and IPv4, and in fact is a major > motivation for proposed encapsulation protocols using UDP > (MPLS-in-UDP, GRE-in-UDP, VXLAN, GUE, Geneve, etc.). Intermediate > device support for flow labels is still needed, for instance we only > get 14 bits of entropy in UDP source port (ephemeral port range) which > is too little for some use cases. > > Tom > From nobody Wed Apr 22 08:29:25 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9C1AC3D7 for ; Wed, 22 Apr 2015 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGj0NEOikfFv for ; Wed, 22 Apr 2015 08:29:22 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 630C71AC3C0 for ; Wed, 22 Apr 2015 08:29:21 -0700 (PDT) Received: by iejt8 with SMTP id t8so40029444iej.2 for ; Wed, 22 Apr 2015 08:29:21 -0700 (PDT) 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:content-type; bh=GrG3v2XHI0aSfbmhiRFgc52E55LRcdpnf1260PWrjw4=; b=lu0tY66R0yY73qRQAk/Hfxl0G6Ml7tCvFp1McUQYFkQR/BocAJ7f9P5o5aOpeVwLy3 p8Atf0u1IMdxcEdhohcYxRtvQUTXgTMp1k8nZTJEM3dVl7HCVbpbhmp4Hz8sfzBVh8Kd ktwrKIdcHAvddMjgFyUnqfO0eaDrz6xClbpdTS7QX7V8zDP05P5WQaEswvLJUysC8gW2 LyokFTTFK/Wfmmgg1tNEIy4CnTxgZYY9OGF+yC1dP9Bq61yHGA5j9dZRKahE2Drj7JKZ u0DdtTITsMtyJyiJjA/cdT77zbIMFTKtMMGhQ4DDXFeOZUBtwbqwf5VK/MnZl9jtHqzN H8lA== X-Gm-Message-State: ALoCoQmjoCH7mwpg+Z4WV9yBxWb/3gfEKZr6WKp4y+SIvWcH+depUQTXNaADwLZH7FZBlSrML+mS MIME-Version: 1.0 X-Received: by 10.50.97.41 with SMTP id dx9mr5196289igb.1.1429716560856; Wed, 22 Apr 2015 08:29:20 -0700 (PDT) Received: by 10.107.160.2 with HTTP; Wed, 22 Apr 2015 08:29:20 -0700 (PDT) In-Reply-To: <5536B673.6080107@gmail.com> References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> <5535CC76.4060204@gmail.com> <5536B673.6080107@gmail.com> Date: Wed, 22 Apr 2015 08:29:20 -0700 Message-ID: From: Tom Herbert To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 15:29:23 -0000 On Tue, Apr 21, 2015 at 1:43 PM, Brian E Carpenter wrote: >> Updating end hosts to set flow labels per RFC6438 is easy (e.g. this >> is supported in Linux stack now). Upgrading all of our switches in the >> network to use flow labels for ECMP and updating all of our NICs to >> use flow labels for RSS is *not* easy-- this assumes that would could >> even find HW that supports labels and are already using IPv6. > > True. But we only make it less likely to happen by proposing a work-around > with bogus port numbers. I don't think that is the IETF showing industry > leadership, exactly. (The same goes for Xiaohu's quote from > https://tools.ietf.org/html/draft-rtg-dt-encap-01#page-7 .) If we cop > out, we can certainly rely on the industry following us. > Brian, We would have more leverage with the vendors if flow labels were enabled by default on hosts, but the initial ambiguity in their specification has complicated that. In the initially proposed patches for Linux that implemented RFC6438, we had enabled flow labels by default for all IPv6 packets. There was pushback because of concerns that stateless flow labels could conflict with those made by flow label manager which is a stateful mechanism that includes a socket option to set flow labels on connections. This mechanism predated RFC6437 and RFC6438, so the part in section 4, RFC6437 that stateful flow labels can't "disturb" stateless ones was after the fact. The upshot is that we were not able to turn on flow labels by default and that fact limits their potential value. A solution to this might be to split the number space into an RFC6438 range, and stateful labels range. This is a not backwards compatible with possible uses of stateful flow labels, but if the range RFC6438 is indicated by the high order bit that might be workable based on the assumption that most stateful flow labels are probably assigned low values. Tom From nobody Wed Apr 22 13:19:53 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA191B3A09 for ; Wed, 22 Apr 2015 13:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5PuNtDyhO0n for ; Wed, 22 Apr 2015 13:19:50 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A17F1B3A05 for ; Wed, 22 Apr 2015 13:19:50 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so283464047pdb.1 for ; Wed, 22 Apr 2015 13:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TpSopdP9g/Dl1wP5mVNc7+HYvdOYELWX7FaA6Gt9RDk=; b=xT+ySGwF6WGkAwcRg7JnD2gFqcCohgMFrneEMW5L41rqY/crCiFfQjRyyATQjjxNAg kRb4o0SmeNJ4JWZV+pJKFWGWS1NR4uR1Qd4CWdg4Ul6dpO8u3q+TZc6M0BCl4DAmtWWs T0Fue1l6TmdI9LsV28YCxF1UqqJFokpyZIYPUXl1Ci6LDzDzNMaOb/QkyZDWO7xeHaUV oxPs83kRBgUBxQrynquPnhV8s6OKSd41SkIcyxL97yI9pT1+ZrbzNCOdd9YSh7wcRjxm 5R3FIS87cnmmUql6QqGJETnIS/cK0fkVhynY6BFWZ/b0qSJXkWDOA76Bkf4lA2elwWV/ F6lg== X-Received: by 10.68.69.47 with SMTP id b15mr49538567pbu.117.1429733989815; Wed, 22 Apr 2015 13:19:49 -0700 (PDT) Received: from ?IPv6:2406:e007:55fb:1:28cc:dc4c:9703:6781? ([2406:e007:55fb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id z5sm5855398pbt.54.2015.04.22.13.19.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 13:19:48 -0700 (PDT) Message-ID: <55380269.90205@gmail.com> Date: Thu, 23 Apr 2015 08:19:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Herbert References: <20150417071920.13004.72830.idtracker@ietfa.amsl.com> <5535CC76.4060204@gmail.com> <5536B673.6080107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 20:19:51 -0000 Hi Tom, On 23/04/2015 03:29, Tom Herbert wrote: > On Tue, Apr 21, 2015 at 1:43 PM, Brian E Carpenter > wrote: > >>> Updating end hosts to set flow labels per RFC6438 is easy (e.g. this >>> is supported in Linux stack now). Upgrading all of our switches in the >>> network to use flow labels for ECMP and updating all of our NICs to >>> use flow labels for RSS is *not* easy-- this assumes that would could >>> even find HW that supports labels and are already using IPv6. >> >> True. But we only make it less likely to happen by proposing a work-around >> with bogus port numbers. I don't think that is the IETF showing industry >> leadership, exactly. (The same goes for Xiaohu's quote from >> https://tools.ietf.org/html/draft-rtg-dt-encap-01#page-7 .) If we cop >> out, we can certainly rely on the industry following us. >> > > Brian, > > We would have more leverage with the vendors if flow labels were > enabled by default on hosts, but the initial ambiguity in their > specification has complicated that. In the initially proposed patches > for Linux that implemented RFC6438, we had enabled flow labels by > default for all IPv6 packets. There was pushback because of concerns > that stateless flow labels could conflict with those made by flow > label manager which is a stateful mechanism that includes a socket > option to set flow labels on connections. This mechanism predated > RFC6437 and RFC6438, so the part in section 4, RFC6437 that stateful > flow labels can't "disturb" stateless ones was after the fact. The > upshot is that we were not able to turn on flow labels by default and > that fact limits their potential value. > > A solution to this might be to split the number space into an RFC6438 > range, and stateful labels range. I personally might agree, but 6man objected to suggestions along those lines during the process that led to RFC6437. Brian > This is a not backwards compatible > with possible uses of stateful flow labels, but if the range RFC6438 > is indicated by the high order bit that might be workable based on the > assumption that most stateful flow labels are probably assigned low > values. > > Tom > From nobody Wed Apr 22 14:14:32 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B41A8983 for ; Wed, 22 Apr 2015 14:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqN5v51hzuGi for ; Wed, 22 Apr 2015 14:14:29 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2651A89C6 for ; Wed, 22 Apr 2015 14:14:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3MLESsM002198; Wed, 22 Apr 2015 16:14:28 -0500 Received: from XCH-BLV-305.nw.nos.boeing.com (xch-blv-305.nw.nos.boeing.com [130.247.25.217]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3MLENvh001543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 22 Apr 2015 16:14:24 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.248]) with mapi id 14.03.0235.001; Wed, 22 Apr 2015 14:14:23 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3A= Date: Wed, 22 Apr 2015 21:14:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:14:31 -0000 Hi Ron, > Your document Section 3.2 is asking for probing the IPv6 minMTU of 1280 p= lus > the encapsulation overhead. That might work on one path of a multipath bu= t > actual data packets might take a different path. This does not make me ha= ppy > because I also want to do some probing of my own. But, it seems like > something we may need to worry about. I just stumbled across RFC6438 ("Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels") and it seems to be a proposed standard for ensuring that tunneled packets are assigned an appropriate flow label according to the traffic flows they encapsulate. Meaning that ECMP and LAG between the tunnel ingress and egress can spread tunneled traffic over multiple paths. Meaning that probing the tunnel to determine if a particular size is supported only tests one path when there may in fact be many. Based on that, probing from the source via something like RFC4821 should be fine because the probes look exactly like ordinary data packets. But, probing from a tunnel ingress is problematic when there is ECMP/LAG because the ingress may have to tunnel the data packets of many flows. AFAICT, the only way around this is for the tunnel to assign the same flow label for every encapsulated packet (i.e., the "pipe" model). But, that would defeat the ECMP/LAG function that the network operators paid good money for. Sorry I don't have better news, Thanks - Fred fred.l.templin@boeing.com From nobody Wed Apr 22 15:32:28 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76581B3AB8 for ; Wed, 22 Apr 2015 15:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsRI5wMh3pqI for ; Wed, 22 Apr 2015 15:32:19 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CA81B2C3B for ; Wed, 22 Apr 2015 15:32:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3MMW7Xw018307; Wed, 22 Apr 2015 17:32:07 -0500 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3MMW0CZ018265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 22 Apr 2015 17:32:01 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.122]) with mapi id 14.03.0235.001; Wed, 22 Apr 2015 15:32:00 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0A== Date: Wed, 22 Apr 2015 22:31:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:32:26 -0000 Hi Ron, So, this gives way to the following, which may be the best we can do if we can't probe: 1) When there is operational assurance that path MTU discovery between the egress, ingress and original source will work correctly, the ingres= s handles packets as follows: - for packets no larger than 1280-ENCAPS, encapsulate and send without fragmentation - for packets larger than 1280-ENCAPS but no larger than 1280, encapsulate and fragment into two approximately equal-length fragments. (Or, if there is operational assurance that there will be no links with MTU smaller than 1280+ENCAPS in the path, encapsulate and send without fragmentation.) - for packets larger than 1280 but no larger than the tunnel MTU, encapsulate and send without fragmentation 2) When there is no operational assurance that path MTU discovery between the egress, ingress and original source will work correctly, the ingress handles packets as follows: - for packets no larger than 1280-ENCAPS, encapsulate and send without fragmentation - for packets larger than 1280-ENCAPS but no larger than 1500, encapsulate and fragment into two approximately equal-length fragments. (Or, if there is operational assurance that there will be no links with MTU smaller than 1500+ENCAPS in the path, encapsulate and send without fragmentation.) - for packets larger than 1500, encapsulate and send without fragmentation Thanks - Fred fred.l.templin@boeing.com From nobody Wed Apr 22 18:37:51 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FA01B2CF4 for ; Wed, 22 Apr 2015 18:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJKChcPxLmQa for ; Wed, 22 Apr 2015 18:37:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6481B2CDD for ; Wed, 22 Apr 2015 18:37:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRS27932; Thu, 23 Apr 2015 01:37:47 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 02:37:46 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 09:37:43 +0800 From: Xuxiaohu To: "int-area@ietf.org" Thread-Topic: New Version Notification for draft-xu-intarea-ip-in-udp-01.txt Thread-Index: AQHQfWWKBmZ+RLQtFk2POY27rgrIQZ1Z0F4A Date: Thu, 23 Apr 2015 01:37:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08327723@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 01:37:51 -0000 SGkgYWxsLA0KDQpNYWpvciBjaGFuZ2VzIGluY2x1ZGUgOjEpIHJlcXVlc3QgYWxsb2NhdGluZyBk aWZmZXJlbnQgVURQIHBvcnQgbnVtYmVycyBmb3IgSVB2NCBhbmQgSVB2NiByZXNwZWN0aXZlbHk7 IDIpIGFkZCBhIG5ldyBjby1hdXRob3IuDQoNCkFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgOTozNCBBTQ0KPiBUbzog THVjeSB5b25nOyBZaXUgTGVlOyBYdXhpYW9odTsgWW9uZ2JpbmcgRmFuOyBSYWppdiBBc2F0aTsg WHV4aWFvaHU7IEx1Y3kgeW9uZzsNCj4gVG9tIEhlcmJlcnQ7IElsaml0c2NoIHZhbiBCZWlqbnVt OyBZaXUgTGVlOyBUb20gSGVyYmVydDsgUmFqaXYgQXNhdGk7IElsaml0c2NoIHZhbg0KPiBCZWlq bnVtOyBGYW4gWW9uZ2JpbmcNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC14dS1pbnRhcmVhLWlwLWluLXVkcC0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDEudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC14dS1pbnRhcmVhLWlwLWluLXVkcA0K PiBSZXZpc2lvbjoJMDENCj4gVGl0bGU6CQlFbmNhcHN1bGF0aW5nIElQIGluIFVEUA0KPiBEb2N1 bWVudCBkYXRlOgkyMDE1LTA0LTIyDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOgkJMTENCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC14dS1pbnRhcmVhLWlwLWluLXVkcC0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWludGFyZWEtaXAtaW4tdWRw Lw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUt aW50YXJlYS1pcC1pbi11ZHAtMDENCj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LXh1LWludGFyZWEtaXAtaW4tdWRwLTAxDQo+IA0KPiBBYnN0 cmFjdDoNCj4gICAgRXhpc3RpbmcgU29mdHdpcmUgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2dpZXMg YXJlIG5vdCBhZGVxdWF0ZSBmb3INCj4gICAgZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIG9mIFNv ZnR3aXJlIHNlcnZpY2UgdHJhZmZpYyBhY3Jvc3MgSVANCj4gICAgbmV0d29ya3MuICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhZGRpdGlvbmFsIFNvZnR3aXJlIGVuY2Fwc3VsYXRpb24NCj4gICAg dGVjaG5vbG9neSwgcmVmZXJyZWQgdG8gYXMgSVAtaW4tVXNlciBEYXRhZ3JhbSBQcm90b2NvbCAo VURQKSwgd2hpY2gNCj4gICAgY2FuIGZhY2lsaXRhdGUgdGhlIGxvYWQgYmFsYW5jaW5nIG9mIFNv ZnR3aXJlIHNlcnZpY2UgdHJhZmZpYyBhY3Jvc3MNCj4gICAgSVAgbmV0d29ya3MuDQo+IA0KPiAN Cj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Apr 22 19:15:31 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866E51A1B1F for ; Wed, 22 Apr 2015 19:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8qM1vvVtcWv for ; Wed, 22 Apr 2015 19:15:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BA41A0334 for ; Wed, 22 Apr 2015 19:15:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRS29875; Thu, 23 Apr 2015 02:15:24 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 03:15:23 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 10:15:12 +0800 From: Xuxiaohu To: Xuxiaohu , "int-area@ietf.org" Thread-Topic: New Version Notification for draft-xu-intarea-ip-in-udp-01.txt Thread-Index: AQHQfWWKBmZ+RLQtFk2POY27rgrIQZ1Z0F4AgAAIbcA= Date: Thu, 23 Apr 2015 02:15:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832774A@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] New Version Notification for draft-xu-intarea-ip-in-udp-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 02:15:30 -0000 QnkgdGhlIHdheSwgb25lIG1ham9yIHJlYXNvbiBmb3IgYWxsb2NhdGluZyB0d28gZGlmZmVyZW50 IHBvcnQgbnVtYmVycyBmb3IgSVB2NCBhbmQgSVB2NiByZXNwZWN0aXZlbHkgaXMgdG8gcHJvdGVj dCB0aGUgdmVyc2lvbiBmaWVsZCBvZiB0aGUgaW5uZXIgSVAgaGVhZGVyIChpLmUuLCBhIHNpbmds ZS1iaXQgY29ycnVwdGlvbiBvZiB0aGUgdmVyc2lvbiBmaWVsZCBtYXkgY2F1c2UgdjQgKDAxMDAp IHRvIGJlY29tZSB2NiAoMDExMCkgYW5kIHZpY2UgdmVyc2EpLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBYdXhpYW9odQ0K PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgOTozOCBBTQ0KPiBUbzogaW50LWFyZWFA aWV0Zi5vcmcNCj4gU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDEudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBNYWpv ciBjaGFuZ2VzIGluY2x1ZGUgOjEpIHJlcXVlc3QgYWxsb2NhdGluZyBkaWZmZXJlbnQgVURQIHBv cnQgbnVtYmVycyBmb3INCj4gSVB2NCBhbmQgSVB2NiByZXNwZWN0aXZlbHk7IDIpIGFkZCBhIG5l dyBjby1hdXRob3IuDQo+IA0KPiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQo+IA0KPiBCZXN0 IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgOTozNCBBTQ0K PiA+IFRvOiBMdWN5IHlvbmc7IFlpdSBMZWU7IFh1eGlhb2h1OyBZb25nYmluZyBGYW47IFJhaml2 IEFzYXRpOyBYdXhpYW9odTsNCj4gPiBMdWN5IHlvbmc7IFRvbSBIZXJiZXJ0OyBJbGppdHNjaCB2 YW4gQmVpam51bTsgWWl1IExlZTsgVG9tIEhlcmJlcnQ7DQo+ID4gUmFqaXYgQXNhdGk7IElsaml0 c2NoIHZhbiBCZWlqbnVtOyBGYW4gWW9uZ2JpbmcNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+ID4gZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDEudHh0DQo+ ID4NCj4gPg0KPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pbnRhcmVhLWlwLWlu LXVkcC0wMS50eHQgaGFzIGJlZW4NCj4gPiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9o dSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBOYW1lOgkJ ZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHANCj4gPiBSZXZpc2lvbjoJMDENCj4gPiBUaXRsZToJ CUVuY2Fwc3VsYXRpbmcgSVAgaW4gVURQDQo+ID4gRG9jdW1lbnQgZGF0ZToJMjAxNS0wNC0yMg0K PiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gUGFnZXM6CQkxMQ0KPiA+IFVS TDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1pbnRh cmVhLWlwLWluLXVkcC0wMS50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAvDQo+ID4gSHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWludGFyZWEtaXAt aW4tdWRwLTAxDQo+ID4gRGlmZjoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHAtMDENCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAg IEV4aXN0aW5nIFNvZnR3aXJlIGVuY2Fwc3VsYXRpb24gdGVjaG5vbG9naWVzIGFyZSBub3QgYWRl cXVhdGUgZm9yDQo+ID4gICAgZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIG9mIFNvZnR3aXJlIHNl cnZpY2UgdHJhZmZpYyBhY3Jvc3MgSVANCj4gPiAgICBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGFkZGl0aW9uYWwgU29mdHdpcmUgZW5jYXBzdWxhdGlvbg0KPiA+ICAgIHRlY2hu b2xvZ3ksIHJlZmVycmVkIHRvIGFzIElQLWluLVVzZXIgRGF0YWdyYW0gUHJvdG9jb2wgKFVEUCks IHdoaWNoDQo+ID4gICAgY2FuIGZhY2lsaXRhdGUgdGhlIGxvYWQgYmFsYW5jaW5nIG9mIFNvZnR3 aXJlIHNlcnZpY2UgdHJhZmZpYyBhY3Jvc3MNCj4gPiAgICBJUCBuZXR3b3Jrcy4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+ DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Apr 22 19:36:35 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1622D1A8748 for ; Wed, 22 Apr 2015 19:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caKfTy7wWMiS for ; Wed, 22 Apr 2015 19:36:32 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B5A1B2DEF for ; Wed, 22 Apr 2015 19:36:29 -0700 (PDT) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3N2ZYD1020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Apr 2015 19:35:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12F70) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832774A@NKGEML512-MBS.china.huawei.com> Date: Wed, 22 Apr 2015 19:35:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25C9B914-70D1-4855-B3AB-2DD7A5BFB853@isi.edu> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832774A@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] New Version Notification for draft-xu-intarea-ip-in-udp-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 02:36:34 -0000 > On Apr 22, 2015, at 7:15 PM, Xuxiaohu wrote: >=20 > By the way, one major reason for allocating two different port numbers for= IPv4 and IPv6 respectively is to protect the version field of the inner IP h= eader (i.e., a single-bit corruption of the version field may cause v4 (0100= ) to become v6 (0110) and vice versa). The conversion to IPv4 should be caught by the header checksum ( which would= be unlikely to be correct).=20 And single but errors should be caught by L2 anyway. If those happen undetec= ted you have bigger problems.=20 > Best regards, > Xiaohu >=20 >> -----Original Message----- >> From: Xuxiaohu >> Sent: Thursday, April 23, 2015 9:38 AM >> To: int-area@ietf.org >> Subject: FW: New Version Notification for draft-xu-intarea-ip-in-udp-01.t= xt >>=20 >> Hi all, >>=20 >> Major changes include :1) request allocating different UDP port numbers f= or >> IPv4 and IPv6 respectively; 2) add a new co-author. >>=20 >> Any comments are welcome. >>=20 >> Best regards, >> Xiaohu >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, April 23, 2015 9:34 AM >>> To: Lucy yong; Yiu Lee; Xuxiaohu; Yongbing Fan; Rajiv Asati; Xuxiaohu; >>> Lucy yong; Tom Herbert; Iljitsch van Beijnum; Yiu Lee; Tom Herbert; >>> Rajiv Asati; Iljitsch van Beijnum; Fan Yongbing >>> Subject: New Version Notification for >>> draft-xu-intarea-ip-in-udp-01.txt >>>=20 >>>=20 >>> A new version of I-D, draft-xu-intarea-ip-in-udp-01.txt has been >>> successfully submitted by Xiaohu Xu and posted to the IETF repository. >>>=20 >>> Name: draft-xu-intarea-ip-in-udp >>> Revision: 01 >>> Title: Encapsulating IP in UDP >>> Document date: 2015-04-22 >>> Group: Individual Submission >>> Pages: 11 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-xu-intarea-ip-in-udp-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-= udp/ >>> Htmlized: http://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-01= >>> Diff: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-xu-intarea-ip-in-udp-01 >>>=20 >>> Abstract: >>> Existing Softwire encapsulation technologies are not adequate for >>> efficient load balancing of Softwire service traffic across IP >>> networks. This document specifies additional Softwire encapsulation >>> technology, referred to as IP-in-User Datagram Protocol (UDP), which >>> can facilitate the load balancing of Softwire service traffic across >>> IP networks. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ie= tf.org. >>>=20 >>> The IETF Secretariat >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Apr 23 08:18:12 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0B1AC3B2 for ; Thu, 23 Apr 2015 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMReiEfJrKBK for ; Thu, 23 Apr 2015 08:18:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005CB1AC3B7 for ; Thu, 23 Apr 2015 08:17:41 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 23 Apr 2015 15:17:40 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) with mapi id 15.01.0136.026; Thu, 23 Apr 2015 15:17:40 +0000 From: Ronald Bonica To: "Templin, Fred L" , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpw Date: Thu, 23 Apr 2015 15:17:40 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: boeing.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(2656002)(33656002)(86362001)(2900100001)(2950100001)(92566002)(54356999)(230783001)(66066001)(77156002)(62966003)(102836002)(76176999)(50986999)(76576001)(122556002)(40100003)(2501003)(99286002)(93886004)(19580405001)(74316001)(46102003)(5001770100001)(107886001)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; x-forefront-prvs: 0555EC8317 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2015 15:17:40.7915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:18:06 -0000 Fred, If we can't probe a tunnel, we can't do GRE at all. Ever. Not with IPv4, no= t with IPv6, not with anything. MTU issues aside, before activating a tunnel, we must be certain that the t= unnel can carry a 1-byte packet from GRE ingress to egress. If we don't do = that, we risk black-holing traffic. This is why nearly all GRE implementati= ons have some type of proprietary probing mechanism. Beyond suggesting that the probing mechanism use a 1280-byte payload, we ha= ve put the details of that probing mechanism out of scope for this document= . = Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, April 22, 2015 6:32 PM > To: Ronald Bonica; int-area@ietf.org > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Hi Ron, >=20 > So, this gives way to the following, which may be the best we can do if w= e > can't probe: >=20 From nobody Thu Apr 23 08:59:02 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66711A1B2A for ; Thu, 23 Apr 2015 08:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4IJEEKMvjSr for ; Thu, 23 Apr 2015 08:58:59 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3121A1B13 for ; Thu, 23 Apr 2015 08:58:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3NFwoPm016066; Thu, 23 Apr 2015 08:58:50 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3NFwjDQ016019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 23 Apr 2015 08:58:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.24]) with mapi id 14.03.0235.001; Thu, 23 Apr 2015 08:58:44 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugA= Date: Thu, 23 Apr 2015 15:58:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:59:01 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Thursday, April 23, 2015 8:18 AM > To: Templin, Fred L; int-area@ietf.org > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Fred, >=20 > If we can't probe a tunnel, we can't do GRE at all. Ever. Not with IPv4, = not with IPv6, not with anything. >=20 > MTU issues aside, before activating a tunnel, we must be certain that the= tunnel can carry a 1-byte packet from GRE ingress to egress. > If we don't do that, we risk black-holing traffic. This is why nearly all= GRE implementations have some type of proprietary probing > mechanism. I said earlier that I am fine with going ahead and probe with a small packe= t (I said 100 bytes, but 1 byte would be fine too) to see if the GRE ingress = is alive. But, that probe does nothing to test for a particular MTU. > Beyond suggesting that the probing mechanism use a 1280-byte payload, we = have put the details of that probing mechanism out of > scope for this document. If a 1280 byte probe (which becomes 1280+ENCAPS bytes following encapsulation) succeeds along one path of a multipath, but would have failed along another path, then there is possibility for black holing. And, there is no way for the ingress to know that there may be ECMP or LAG on the path to the egress. Hence, having the ingress probe for the purpose of minimum MTU detection is problematic if there may be some kind of multipath. Thanks - Fred fred.l.templin@boeing.com >=20 > = Ron >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, April 22, 2015 6:32 PM > > To: Ronald Bonica; int-area@ietf.org > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi Ron, > > > > So, this gives way to the following, which may be the best we can do if= we > > can't probe: > > From nobody Thu Apr 23 09:16:31 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5DC1A1BCC for ; Thu, 23 Apr 2015 09:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz8m4b78gLKB for ; Thu, 23 Apr 2015 09:16:27 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157C61A1AD9 for ; Thu, 23 Apr 2015 09:16:25 -0700 (PDT) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3NGFlXv004365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2015 09:15:56 -0700 (PDT) Message-ID: <55391AB2.4080701@isi.edu> Date: Thu, 23 Apr 2015 09:15:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Ronald Bonica , "int-area@ietf.org" References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:16:30 -0000 On 4/23/2015 8:58 AM, Templin, Fred L wrote: ... >> Beyond suggesting that the probing mechanism use a 1280-byte payload, we have put the details of that probing mechanism out of >> scope for this document. > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > encapsulation) succeeds along one path of a multipath, but would > have failed along another path, then there is possibility for black > holing. And, there is no way for the ingress to know that there > may be ECMP or LAG on the path to the egress. Hence, having the > ingress probe for the purpose of minimum MTU detection is > problematic if there may be some kind of multipath. Probe success tells you only that. Probe loss tells you only that. IP allows loss, so strictly there's no reason to shut a tunnel down due to loss. Burst lost or patterns of loss might be undesirable, but they're allowed by IP. However, it might be useful to note that probe success isn't the only issue; that probe loss over 1% might be considered problematic (using the typical performance needed for 'reasonable' TCP progress). Joe From nobody Thu Apr 23 09:28:11 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3DE1A8A98 for ; Thu, 23 Apr 2015 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbZXAe-NrK7n for ; Thu, 23 Apr 2015 09:28:09 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D8E1A6F29 for ; Thu, 23 Apr 2015 09:27:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3NGRsqi026921; Thu, 23 Apr 2015 11:27:54 -0500 Received: from XCH-BLV-407.nw.nos.boeing.com (xch-blv-407.nw.nos.boeing.com [130.247.25.165]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3NGRlok026854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 23 Apr 2015 11:27:48 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.213]) with mapi id 14.03.0235.001; Thu, 23 Apr 2015 09:27:47 -0700 From: "Templin, Fred L" To: Joe Touch , Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAD5EnAAAOb1BQ Date: Thu, 23 Apr 2015 16:27:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> In-Reply-To: <55391AB2.4080701@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:28:10 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, April 23, 2015 9:16 AM > To: Templin, Fred L; Ronald Bonica; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 >=20 >=20 > On 4/23/2015 8:58 AM, Templin, Fred L wrote: > ... > >> Beyond suggesting that the probing mechanism use a 1280-byte payload, = we have put the details of that probing mechanism out of > >> scope for this document. > > > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > > encapsulation) succeeds along one path of a multipath, but would > > have failed along another path, then there is possibility for black > > holing. And, there is no way for the ingress to know that there > > may be ECMP or LAG on the path to the egress. Hence, having the > > ingress probe for the purpose of minimum MTU detection is > > problematic if there may be some kind of multipath. >=20 > Probe success tells you only that. Probe loss tells you only that. >=20 > IP allows loss, so strictly there's no reason to shut a tunnel down due > to loss. Burst lost or patterns of loss might be undesirable, but > they're allowed by IP. >=20 > However, it might be useful to note that probe success isn't the only > issue; that probe loss over 1% might be considered problematic (using > the typical performance needed for 'reasonable' TCP progress). That is fine, but the troubling condition is when the tunnel ingress successfully probes for 1280 (or 1500) but that same probe would have failed if it travelled along a different path. And, the ingress has no way of knowing whether there is ECMP or LAG on the path to the egress. Which returns us to fragmentation as I said a couple of messages back. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Thu Apr 23 09:34:50 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FD61A8032 for ; Thu, 23 Apr 2015 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gGi_g84ahFK for ; Thu, 23 Apr 2015 09:34:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9521D1A90AE for ; Thu, 23 Apr 2015 09:34:47 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 23 Apr 2015 16:34:30 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) with mapi id 15.01.0136.026; Thu, 23 Apr 2015 16:34:30 +0000 From: Ronald Bonica To: "Templin, Fred L" , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAAWVa8A== Date: Thu, 23 Apr 2015 16:34:30 +0000 Message-ID: References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: boeing.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.129.241.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(93886004)(77156002)(62966003)(2900100001)(2950100001)(107886001)(76576001)(92566002)(46102003)(99286002)(19580395003)(2501003)(102836002)(19580405001)(66066001)(40100003)(5001770100001)(230783001)(122556002)(2656002)(87936001)(33656002)(76176999)(86362001)(50986999)(74316001)(54356999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-forefront-prvs: 0555EC8317 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2015 16:34:30.5635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:34:49 -0000 Fred, The following are failure modes for a GRE tunnel that includes ECMP/LAG: - one ECMP/LAG member is dropping 100% of traffic, regardless of packet siz= e - one ECMP/LAG member is dropping all packets with MTU > N Why is a probing mechanism OK to detect the first and not the second? Ron > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Thursday, April 23, 2015 11:59 AM > To: Ronald Bonica; int-area@ietf.org > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Hi Ron, >=20 > > -----Original Message----- > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > Sent: Thursday, April 23, 2015 8:18 AM > > To: Templin, Fred L; int-area@ietf.org > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Fred, > > > > If we can't probe a tunnel, we can't do GRE at all. Ever. Not with IPv4= , not > with IPv6, not with anything. > > > > MTU issues aside, before activating a tunnel, we must be certain that t= he > tunnel can carry a 1-byte packet from GRE ingress to egress. > > If we don't do that, we risk black-holing traffic. This is why nearly > > all GRE implementations have some type of proprietary probing > mechanism. >=20 > I said earlier that I am fine with going ahead and probe with a small pac= ket (I > said 100 bytes, but 1 byte would be fine too) to see if the GRE ingress i= s alive. > But, that probe does nothing to test for a particular MTU. >=20 > > Beyond suggesting that the probing mechanism use a 1280-byte payload, > > we have put the details of that probing mechanism out of scope for this > document. >=20 > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > encapsulation) succeeds along one path of a multipath, but would have fai= led > along another path, then there is possibility for black holing. And, ther= e is no > way for the ingress to know that there may be ECMP or LAG on the path to > the egress. Hence, having the ingress probe for the purpose of minimum > MTU detection is problematic if there may be some kind of multipath. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > > > > > Ron > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Wednesday, April 22, 2015 6:32 PM > > > To: Ronald Bonica; int-area@ietf.org > > > Subject: RE: [Int-area] I-D Action: > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > Hi Ron, > > > > > > So, this gives way to the following, which may be the best we can do > > > if we can't probe: > > > From nobody Thu Apr 23 09:49:48 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D611ACC85 for ; Thu, 23 Apr 2015 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5PDch5aPiE1 for ; Thu, 23 Apr 2015 09:49:44 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392FC1AC44E for ; Thu, 23 Apr 2015 09:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3NGnhnP031815; Thu, 23 Apr 2015 11:49:43 -0500 Received: from XCH-BLV-401.nw.nos.boeing.com (xch-blv-401.nw.nos.boeing.com [130.247.25.18]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3NGnFbo031129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 23 Apr 2015 11:49:38 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.205]) with mapi id 14.03.0235.001; Thu, 23 Apr 2015 09:49:23 -0700 From: "Templin, Fred L" To: Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAAWVa8AAAYNgg Date: Thu, 23 Apr 2015 16:49:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E506A1@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:49:46 -0000 Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Thursday, April 23, 2015 9:35 AM > To: Templin, Fred L; int-area@ietf.org > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 > Fred, >=20 > The following are failure modes for a GRE tunnel that includes ECMP/LAG: >=20 > - one ECMP/LAG member is dropping 100% of traffic, regardless of packet s= ize > - one ECMP/LAG member is dropping all packets with MTU > N >=20 > Why is a probing mechanism OK to detect the first and not the second? These are two very different conditions. In the first case, if one or more paths are dropping all packets, then any communications will black hole and not just GRE tunneling. The network operations staff needs to do something to ensure that all paths are working. In the second case, it could black hole even when all paths are working and using standards-compliant MTUs on all links. AFAICT, when there may be ECMP or LAG on the path (which the ingress has no way of knowing) about all you can tell from probing is whether the egress is alive - probing can't be relied on to tell you anything about the path(s). Again , this does not make me happy but AFAICT it is the reality we need to deal with. Thanks - Fred fred.l.templin@boeing.com > Ron >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Thursday, April 23, 2015 11:59 AM > > To: Ronald Bonica; int-area@ietf.org > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:rbonica@juniper.net] > > > Sent: Thursday, April 23, 2015 8:18 AM > > > To: Templin, Fred L; int-area@ietf.org > > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.tx= t > > > > > > Fred, > > > > > > If we can't probe a tunnel, we can't do GRE at all. Ever. Not with IP= v4, not > > with IPv6, not with anything. > > > > > > MTU issues aside, before activating a tunnel, we must be certain that= the > > tunnel can carry a 1-byte packet from GRE ingress to egress. > > > If we don't do that, we risk black-holing traffic. This is why nearly > > > all GRE implementations have some type of proprietary probing > > mechanism. > > > > I said earlier that I am fine with going ahead and probe with a small p= acket (I > > said 100 bytes, but 1 byte would be fine too) to see if the GRE ingress= is alive. > > But, that probe does nothing to test for a particular MTU. > > > > > Beyond suggesting that the probing mechanism use a 1280-byte payload, > > > we have put the details of that probing mechanism out of scope for th= is > > document. > > > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > > encapsulation) succeeds along one path of a multipath, but would have f= ailed > > along another path, then there is possibility for black holing. And, th= ere is no > > way for the ingress to know that there may be ECMP or LAG on the path t= o > > the egress. Hence, having the ingress probe for the purpose of minimum > > MTU detection is problematic if there may be some kind of multipath. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Wednesday, April 22, 2015 6:32 PM > > > > To: Ronald Bonica; int-area@ietf.org > > > > Subject: RE: [Int-area] I-D Action: > > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > Hi Ron, > > > > > > > > So, this gives way to the following, which may be the best we can d= o > > > > if we can't probe: > > > > From nobody Thu Apr 23 09:56:20 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336961ACD54 for ; Thu, 23 Apr 2015 09:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRtIuXhH52ND for ; Thu, 23 Apr 2015 09:56:18 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8640C1A8AB8 for ; Thu, 23 Apr 2015 09:55:40 -0700 (PDT) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3NGsdv5011734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2015 09:54:48 -0700 (PDT) Message-ID: <553923CE.4080504@isi.edu> Date: Thu, 23 Apr 2015 09:54:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Ronald Bonica , "int-area@ietf.org" References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:56:19 -0000 On 4/23/2015 9:27 AM, Templin, Fred L wrote: ... >> Probe success tells you only that. Probe loss tells you only that. >> >> IP allows loss, so strictly there's no reason to shut a tunnel down due >> to loss. Burst lost or patterns of loss might be undesirable, but >> they're allowed by IP. >> >> However, it might be useful to note that probe success isn't the only >> issue; that probe loss over 1% might be considered problematic (using >> the typical performance needed for 'reasonable' TCP progress). > > That is fine, but the troubling condition is when the tunnel ingress > successfully probes for 1280 (or 1500) but that same probe would > have failed if it travelled along a different path. I repeat: Probe success tells you only that. Probe loss tells you only that. What "would have" happened is irrelevant. Joe From nobody Thu Apr 23 10:01:25 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF21ACD08 for ; Thu, 23 Apr 2015 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsQaJ5s_bmud for ; Thu, 23 Apr 2015 10:01:22 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357031ACCF0 for ; Thu, 23 Apr 2015 10:01:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3NH1Lne030837; Thu, 23 Apr 2015 10:01:21 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3NH1Bms030363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 23 Apr 2015 10:01:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.24]) with mapi id 14.03.0235.001; Thu, 23 Apr 2015 10:01:11 -0700 From: "Templin, Fred L" To: Joe Touch , Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAD5EnAAAOb1BQ//+XYQCAAHSM8A== Date: Thu, 23 Apr 2015 17:01:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E506CC@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> <553923CE.4080504@isi.edu> In-Reply-To: <553923CE.4080504@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:01:23 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, April 23, 2015 9:55 AM > To: Templin, Fred L; Ronald Bonica; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 >=20 >=20 > On 4/23/2015 9:27 AM, Templin, Fred L wrote: > ... > >> Probe success tells you only that. Probe loss tells you only that. > >> > >> IP allows loss, so strictly there's no reason to shut a tunnel down du= e > >> to loss. Burst lost or patterns of loss might be undesirable, but > >> they're allowed by IP. > >> > >> However, it might be useful to note that probe success isn't the only > >> issue; that probe loss over 1% might be considered problematic (using > >> the typical performance needed for 'reasonable' TCP progress). > > > > That is fine, but the troubling condition is when the tunnel ingress > > successfully probes for 1280 (or 1500) but that same probe would > > have failed if it travelled along a different path. >=20 > I repeat: Probe success tells you only that. Probe loss tells you only th= at. >=20 > What "would have" happened is irrelevant. Then, let me also repeat that "about all you can tell from probing is wheth= er the egress is alive - probing can't be relied on to tell you anything about= the path(s)" Again, this does not make me happy because I have been trying to figure out for years how to make tunnels probe the MTU. The only alternative I know of is to fragment when necessary per what I said a couple of messages back. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Thu Apr 23 10:14:34 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A35A1ACDC2 for ; Thu, 23 Apr 2015 10:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZedlqcqwQavr for ; Thu, 23 Apr 2015 10:14:32 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573971ACDBC for ; Thu, 23 Apr 2015 10:14:32 -0700 (PDT) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3NHDn8H014789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2015 10:13:58 -0700 (PDT) Message-ID: <5539284C.4020103@isi.edu> Date: Thu, 23 Apr 2015 10:13:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , Ronald Bonica , "int-area@ietf.org" References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> <553923CE.4080504@isi.edu> <2134F8430051B64F815C691A62D9831832E506CC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832E506CC@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:14:33 -0000 On 4/23/2015 10:01 AM, Templin, Fred L wrote: ... >> I repeat: Probe success tells you only that. Probe loss tells you only that. >> >> What "would have" happened is irrelevant. > > Then, let me also repeat that "about all you can tell from probing is whether > the egress is alive - probing can't be relied on to tell you anything about the > path(s)" We're not doing routing. We're determining whether packets make it to the egress. > Again, this does not make me happy because I have been trying to figure > out for years how to make tunnels probe the MTU. If the probe makes it, it makes it. If the probe "would have failed" on another path, you'll either see that over several probes or not. If you do, you have what is isomorphic to a lossy link, and you decide how you want to handle that - if you can fragment to get around it, then you might try that. If you have FEC, you might try that. The cause of the losses is irrelevant. Joe From nobody Thu Apr 23 10:40:37 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF81B3107 for ; Thu, 23 Apr 2015 10:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc566raa2VtK for ; Thu, 23 Apr 2015 10:40:23 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DA41B3108 for ; Thu, 23 Apr 2015 10:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t3NHdsr1023246; Thu, 23 Apr 2015 10:39:54 -0700 Received: from XCH-BLV-104.nw.nos.boeing.com (xch-blv-104.nw.nos.boeing.com [130.247.25.120]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t3NHdpt4023222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 23 Apr 2015 10:39:52 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.139]) with mapi id 14.03.0235.001; Thu, 23 Apr 2015 10:39:51 -0700 From: "Templin, Fred L" To: Joe Touch , Ronald Bonica , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt Thread-Index: AdB4lrxZWs10twsqTRutwXmGaisuPwAHGYjgASLWx3AAAvjv0AAjISpwAAGQugAAD5EnAAAOb1BQ//+XYQCAAHSM8P//kM8AgABx5ZA= Date: Thu, 23 Apr 2015 17:39:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832E5078D@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832E4B1E1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FE45@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E4FF5C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832E50576@XCH-BLV-504.nw.nos.boeing.com> <55391AB2.4080701@isi.edu> <2134F8430051B64F815C691A62D9831832E5062E@XCH-BLV-504.nw.nos.boeing.com> <553923CE.4080504@isi.edu> <2134F8430051B64F815C691A62D9831832E506CC@XCH-BLV-504.nw.nos.boeing.com> <5539284C.4020103@isi.edu> In-Reply-To: <5539284C.4020103@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.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: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:40:27 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, April 23, 2015 10:14 AM > To: Templin, Fred L; Ronald Bonica; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt >=20 >=20 >=20 > On 4/23/2015 10:01 AM, Templin, Fred L wrote: > ... > >> I repeat: Probe success tells you only that. Probe loss tells you only= that. > >> > >> What "would have" happened is irrelevant. > > > > Then, let me also repeat that "about all you can tell from probing is w= hether > > the egress is alive - probing can't be relied on to tell you anything a= bout the > > path(s)" >=20 > We're not doing routing. We're determining whether packets make it to > the egress. >=20 > > Again, this does not make me happy because I have been trying to figure > > out for years how to make tunnels probe the MTU. >=20 > If the probe makes it, it makes it. >=20 > If the probe "would have failed" on another path, you'll either see that > over several probes or not. Only if you craft your probes in such a way that they eventually test all paths in a multipath arrangement. That might require quite a lot of probes (e.g., if every conceivable flow label value needs to be probed). > If you do, you have what is isomorphic to a > lossy link, It would actually be much worse than a lossy link, because some traffic would receive good service while other traffic would be dropped completely. > and you decide how you want to handle that - if you can > fragment to get around it, then you might try that. Fragmentation works in all cases, AFAICT. > If you have FEC, you > might try that. >=20 > The cause of the losses is irrelevant. Sure, but then probing for a specific MTU size is hopeless. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Thu Apr 23 10:51:22 2015 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7C01ACE88; Thu, 23 Apr 2015 10:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBHsIAug9g0I; Thu, 23 Apr 2015 10:51:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 305BD1AD0B6; Thu, 23 Apr 2015 10:50:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150423175056.31517.87279.idtracker@ietfa.amsl.com> Date: Thu, 23 Apr 2015 10:50:56 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-mtu-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:51:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : A Widely-Deployed Solution To The Generic Routing Encapsulation (GRE) Fragmentation Problem Authors : Ron Bonica Carlos Pignataro Joe Touch Filename : draft-ietf-intarea-gre-mtu-03.txt Pages : 10 Date : 2015-04-23 Abstract: This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/do