From mip6-bounces@ietf.org Fri Apr 1 02:16:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14954 for ; Fri, 1 Apr 2005 02:16:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGVj-0005Lp-0Z for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 02:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGIW-0007j3-KO; Fri, 01 Apr 2005 02:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGIQ-0007ia-Iy; Fri, 01 Apr 2005 02:10:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08988; Fri, 1 Apr 2005 02:10:21 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGPh-00056y-3l; Fri, 01 Apr 2005 02:17:53 -0500 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3179xhH025558; Fri, 1 Apr 2005 09:10:08 +0200 (MEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 09:10:03 +0200 Received: from [147.214.181.67] ([147.214.181.67]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 09:10:02 +0200 Message-ID: <424CF3CA.4050100@ericsson.com> Date: Fri, 01 Apr 2005 09:10:02 +0200 From: Conny Larsson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document References: In-Reply-To: X-OriginalArrivalTime: 01 Apr 2005 07:10:02.0773 (UTC) FILETIME=[D2F6B450:01C53689] X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478690238==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 This is a multi-part message in MIME format. --===============0478690238== Content-Type: multipart/alternative; boundary="------------000603010906030403050704" This is a multi-part message in MIME format. --------------000603010906030403050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, I agree with you that there is a need for discussion about the pros and cons of both drafts. I have not read draft-wakikawa-nemo-v4tunnel so I can't make any comments on this draft. However, we have made an implementation of draft-soliman-v4v6-mipv4 and our experience is the same as yours, it works very good and requires small changes to the MIPv6 stack. Regards Conny Larsson Gerardo Giaretta wrote: >Hi Raj, > >I have two general comments about making draft-wakikawa-nemo-v4tunnel a >WG item: > >- I agree with you that the scenario you described is the most >interesting one and I'm favor of focusing on it immediately. However I >think that before having consensus on this solution draft, we should >understand if there is consensus on scenarios we want to address and in >particular if there is consensus to address only this particular >scenario. At least I thought this was the MIP6 WG original intention >since MIP6 charter states that the WG will document a problem statement >related to IPv4/IPv6 transition issues. > >- I wonder why draft-soliman-v4v6-mipv4-01 has not been considered as a >candidate WG item (at least for MIP6). I'd like to see a discussion >about the pros and cons of both drafts. In my view they tackle the same >scenario in a very similar way. The main difference is the BU message >format: based on draft-wakikawa the source address of the IPv6 packet is >the HoA, since the message is treated as a particular de-registration; >in draft-soliman the source address is the CoAv4 mapped in IPv6 address >format. I'd like to understand better the rationale behind the choice in >draft-wakikawa. Personally, I think that the approach of draft-soliman >is a little bit cleaner since the BU is not considered a de-registration >message. BTW, we implemented draft-soliman: it requires few changes in >MIPv6 stack and works great. > >Regards, >--Gerardo > > > >>-----Original Message----- >>From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >>Behalf Of Basavaraj.Patil@nokia.com >>Sent: Wednesday, March 30, 2005 9:33 PM >>To: mip6@ietf.org; nemo@ietf.org >>Subject: [Mip6] Consensus call on making ID >>draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document >> >> >> >>One of the major barriers to the deployment of Mobile IPv6 today is >>the fact that most access networks are IPv4 only. A number of hosts >>are already dual-stack capable. While Mobile IPv6 works well in IPv6 >>networks, it is essential that IPv6 mobility service continue to work >>even when the mobile host is attached to an IPv4 network. The same >>applies to a NEMO mobile router as well. >> >>A number of transition scenarios have been identified in IDs: >>1. draft-larsson-v6ops-mip-scenarios-01 >>2. draft-tsirtsis-dsmip-problem-03 >>While discussion of these scenarios in the larger scope makes sense, >>there is a need to focus on the most critical scenario that would >>address the MIP6 host and router problem. The problem in a single >>sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need >>to be able to reach its (IPv6) home agent and services when roaming in >>and attached to an IPv4 access network." >>It makes sense to focus on just this one scenario and solve the >>problem immediately. >> >>The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 >>mobile node or a NEMO mobile router roaming onto a IPv4 only access >>network in a simple manner. >>It is intended that the standardization of this solution in the IETFs >>MIP6 and/or NEMO working groups proceed. The working group chairs have >>reviewed and discussed this work item. It has also been presented at >>the MIP6 and NEMO WGs at IETF62. >> >>The chairs would like to hear your thoughts in order to see if there >>is consensus to make it a WG document and progress it as a standards >>track RFC. Comments should be sent to both the NEMO and MIP6 WGs. >> >>If we have consensus, then the document will be pursued as a dual WG >>item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt >> >>Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: >> For [ ] >> Against [ ] >> >> >>- MIP6 and NEMO WG chairs >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > >==================================================================== >CONFIDENTIALITY NOTICE >This message and its attachments are addressed solely to the persons >above and may contain confidential information. If you have received >the message in error, be informed that any use of the content hereof >is prohibited. Please return it immediately to the sender and delete >the message. Should you have any questions, please send an e_mail to >MailAdmin@tilab.com. Thank you >==================================================================== > > > --------------000603010906030403050704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Gerardo,

I agree with you that there is a need for discussion about the pros and cons of both drafts. I have not read draft-wakikawa-nemo-v4tunnel so I can't make any comments on this draft. However, we have made an implementation of  draft-soliman-v4v6-mipv4 and our experience is the same as yours, it works very good and requires small changes to the MIPv6 stack.

Regards
Conny Larsson

Gerardo Giaretta wrote: 
Hi Raj,

I have two general comments about making draft-wakikawa-nemo-v4tunnel a
WG item:

- I agree with you that the scenario you described is the most
interesting one and I'm favor of focusing on it immediately. However I
think that before having consensus on this solution draft, we should
understand if there is consensus on scenarios we want to address and in
particular if there is consensus to address only this particular
scenario. At least I thought this was the MIP6 WG original intention
since MIP6 charter states that the WG will document a problem statement
related to IPv4/IPv6 transition issues.

- I wonder why draft-soliman-v4v6-mipv4-01 has not been considered as a
candidate WG item (at least for MIP6). I'd like to see a discussion
about the pros and cons of both drafts. In my view they tackle the same
scenario in a very similar way. The main difference is the BU message
format: based on draft-wakikawa the source address of the IPv6 packet is
the HoA, since the message is treated as a particular de-registration;
in draft-soliman the source address is the CoAv4 mapped in IPv6 address
format. I'd like to understand better the rationale behind the choice in
draft-wakikawa. Personally, I think that the approach of draft-soliman
is a little bit cleaner since the BU is not considered a de-registration
message. BTW, we implemented draft-soliman: it requires few changes in
MIPv6 stack and works great.

Regards,
--Gerardo

  
-----Original Message-----
From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On 
Behalf Of Basavaraj.Patil@nokia.com
Sent: Wednesday, March 30, 2005 9:33 PM
To: mip6@ietf.org; nemo@ietf.org
Subject: [Mip6] Consensus call on making ID 
draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document



One of the major barriers to the deployment of Mobile IPv6 today is
the fact that most access networks are IPv4 only. A number of hosts
are already dual-stack capable. While Mobile IPv6 works well in IPv6
networks, it is essential that IPv6 mobility service continue to work
even when the mobile host is attached to an IPv4 network. The same
applies to a NEMO mobile router as well. 

A number of transition scenarios have been identified in IDs: 
1. draft-larsson-v6ops-mip-scenarios-01
2. draft-tsirtsis-dsmip-problem-03
While discussion of these scenarios in the larger scope makes sense,
there is a need to focus on the most critical scenario that would
address the MIP6 host and router problem. The problem in a single
sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need
to be able to reach its (IPv6) home agent and services when roaming in
and attached to an IPv4 access network."
It makes sense to focus on just this one scenario and solve the
problem immediately. 

The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 
mobile node or a NEMO mobile router roaming onto a IPv4 only access
network in a simple manner. 
It is intended that the standardization of this solution in the IETFs
MIP6 and/or NEMO working groups proceed. The working group chairs have
reviewed and discussed this work item. It has also been presented at
the MIP6 and NEMO WGs at IETF62. 

The chairs would like to hear your thoughts in order to see if there
is consensus to make it a WG document and progress it as a standards
track RFC. Comments should be sent to both the NEMO and MIP6 WGs. 

If we have consensus, then the document will be pursued as a dual WG
item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt 

Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID:
	For 		[  ]
	Against 	[  ]


- MIP6 and NEMO WG chairs


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

    


Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin@tilab.com. Thank you
====================================================================

--------------000603010906030403050704-- --===============0478690238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0478690238==-- From mip6-bounces@ietf.org Fri Apr 1 03:59:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03933 for ; Fri, 1 Apr 2005 03:59:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHI7b-0000qP-Tu for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 04:07:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHza-0001zM-F7; Fri, 01 Apr 2005 03:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHzH-0001yU-LQ; Fri, 01 Apr 2005 03:58:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03859; Fri, 1 Apr 2005 03:58:41 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHI6Y-0000mB-TV; Fri, 01 Apr 2005 04:06:16 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j3190x24022049; Fri, 1 Apr 2005 02:01:00 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j3190Nkm028689; Fri, 1 Apr 2005 03:00:23 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5FBA8865980; Fri, 1 Apr 2005 10:58:39 +0200 (CEST) Message-ID: <424D0D3F.1070109@motorola.com> Date: Fri, 01 Apr 2005 10:58:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> <424C3932.8080005@iprg.nokia.com> In-Reply-To: <424C3932.8080005@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Pekka Savola X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> - you specify UDP encapsulation for NAT traversal, but no keepalive >> > > okay. will fix this. How are you going to fix this Vijay? I use 15s keepalive with ICMP. Would you do similarly? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 04:15:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04948 for ; Fri, 1 Apr 2005 04:15:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIMl-0001MN-7Q for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 04:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIF8-0004jd-ST; Fri, 01 Apr 2005 04:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIF2-0004iL-Q0; Fri, 01 Apr 2005 04:15:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04936; Fri, 1 Apr 2005 04:14:59 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIMK-0001Lj-7i; Fri, 01 Apr 2005 04:22:33 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j319ElA2022955; Fri, 1 Apr 2005 02:14:48 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j319FQUH029365; Fri, 1 Apr 2005 03:15:27 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5C170865980; Fri, 1 Apr 2005 11:14:45 +0200 (CEST) Message-ID: <424D1104.4090000@motorola.com> Date: Fri, 01 Apr 2005 11:14:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424C3EF8.5050507@levkowetz.com> <424C5733.103@iprg.nokia.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Sri Gundavelli wrote: > We have implementations based on draft-thubert-nemo-ipv4-traversal > and some good thinking went in to that proposal and it is > important that we review all these solutions in the context > of the agreed upon problem space. We also have an implementation but it is not documented, however, experiments were reported on Section 3 of expired draft draft-lach-nemo-experiments-overdrive-01.txt http://tinyurl.com/3om6x It uses IPv6 in UDPv4 for NAT traversal. The HA and the Gateway are not co-located. That does not use IPv4 CoA for MIP6 simply because when behind NAT it's little relevant. It uses UDP port scanning to find out open ports and 15s icmp "heart beats" to maintain port state unchnaged in the NAT devices. When sending big packets over asymmetric wireless links (like GPRS and UMTS) the v4 stack fragments but the v6 stack does not fragment. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 04:49:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07017 for ; Fri, 1 Apr 2005 04:49:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIuA-0002Vp-BG for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 04:57:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIlF-00011B-4d; Fri, 01 Apr 2005 04:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIif-0000om-Qj; Fri, 01 Apr 2005 04:45:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06705; Fri, 1 Apr 2005 04:45:35 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIpy-0002Kj-DA; Fri, 01 Apr 2005 04:53:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j31ACKg16107; Fri, 1 Apr 2005 02:12:20 -0800 X-mProtect: <200504011012> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdQISRX8; Thu, 31 Mar 2005 19:51:26 PST Message-ID: <424CBE3F.40200@iprg.nokia.com> Date: Thu, 31 Mar 2005 19:21:35 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424C3EF8.5050507@levkowetz.com> <424C5733.103@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit hi Sri, Sri Gundavelli wrote: >> >>regarding Sri's concerns, we do intend to address them. dont >>worry about that. we have an assumption in the draft. >> >>- the HA's IPv4 address is reachable through the IPv4 internet >> >>Sri is questioning this assumption. he is claiming this is >>not so easy. he doesnt want IPv4 routing inside his IPv6 >>network. the HA is deep inside in the IPv6 network. for the >>HA's IPv4 address to be reachable, you might need a box in >>the DMZ, which traps the packets for the HA's IPv4 address >>and tunnels them to the HA deep in the IPv6 network. but here >>we end with extra tunneling between the box sitting in the >>DMZ and the HA deep in the IPv6 network. another option is to >>place the HA in the DMZ. but he doesnt want to do that. I >>will be discussing with him to see how we can come up with a >>solution. Sri, let me know if I still dont understand the >>issue you are bringing up. > > We need to agree on the most common scenarios that we need to > address and so we need a problem statement. That should be the > basis for defining a solution. Further, we need to have some > gap analysis on each of the three present solutions and > leverage some thing from them. I agree, we cannot afford to > spend too much on that, but at the same time adopting a > solution with out having an understanding of the deployment > models is not right either. here your concern is that we are not looking at enough scenarios. so, you have two issues. 1) how to make the HA's IPv4 address accessible through the IPv4 Internet and 2) we need to step back and look at more scenarios. I agree we need to address 1). and there are some solutions. you havent responded to them in my mail. but for 2) I am afraid you havent given any justification. draft-larsson has an exhaustive catalog of all kinds of scenarios. please point to the scenario which you think is important and we can take it from there. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 08:12:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22357 for ; Fri, 1 Apr 2005 08:12:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM3y-0001KY-GF for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:19:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLuz-0000Sr-Pz; Fri, 01 Apr 2005 08:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkDs-0005WS-4a; Wed, 30 Mar 2005 15:55:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12630; Wed, 30 Mar 2005 15:55:30 -0500 (EST) From: sudhir.dixit@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkKq-0003BI-Ei; Wed, 30 Mar 2005 16:02:45 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2UKshg19732; Wed, 30 Mar 2005 23:54:44 +0300 (EET DST) X-Scanned: Wed, 30 Mar 2005 23:54:27 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j2UKsRRB009727; Wed, 30 Mar 2005 23:54:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00CZXirt; Wed, 30 Mar 2005 23:54:26 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2UKsFU19216; Wed, 30 Mar 2005 23:54:15 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Mar 2005 14:54:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Mar 2005 15:54:12 -0500 Message-ID: Thread-Topic: [ontc] Call for Papers - COMSWARE 2006 Thread-Index: AcU0ksSL2E2HoTWaQkawcRbdp3aRPAA1vXwg To: X-OriginalArrivalTime: 30 Mar 2005 20:54:14.0672 (UTC) FILETIME=[A1C42900:01C5356A] X-Spam-Score: 1.4 (+) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 X-Mailman-Approved-At: Fri, 01 Apr 2005 08:10:32 -0500 Subject: [Mip6] Call for Papers and Proposals for Tutorials and Panels X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0740536795==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.8 (++) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 This is a multi-part message in MIME format. --===============0740536795== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5356A.A0B64840" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5356A.A0B64840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Our apologies if you receive multiple copies of this document) =20 =20 Wireless Personal Multimedia Communications (WPMC'05) Sept 18-22, 2005 - Aalborg, Denmark =20 Share your achievements within wireless with the rest of the world: Submit a paper a tutorial, and/or a panel proposal Deadline for abstract submission: April 15 , 2005 To submit, follow instructions given at = www.iws2005.org Wireless Personal Multimedia Communications (WPMC) this year is a part = of the First International Wireless Summit (IWS) 1000 participants are expected . Up to 8 parellel sessions including = panel and invited paper sessions, selected tutorials and industrial = exhibition.=20 =20 Call for Papers - Deadline extended!=20 The Organizing Committee for WPMC'05 invites you to submit extended = abstracts on the following topics (but not limited to) by electronic = submission in PDF format. * Track I: Antenna and Propagation=20 * Track II: Transmission Technology=20 * Track III: Digital Signal Processing=20 * Track IV: Wireless Access=20 * Track V: Multimedia, Networks and Systems=20 * Track VI: Wireless Security=20 * Track VII: Wireless Sensors and Data Fusion=20 * Track VIII: Modeling and Simulation=20 * Track IX: Satellite and Navigation=20 * Track X: Other topics =20 Description of tracks. Introduction of = abstract submission. Award papers: Six papers will be selected for the "Best Paper Award" among the = contributed papers and there will also be the "Best Student Award". Wireless Personal Communication: An International Journal Twenty papers including the Award Papers will be selected for = publication in a special issue: "Latest Trends in Wireless = Communication". Special Sessions: Special Sessions on "Hot Topics" will be organized. Especially, there = will be special sessions on Wireless Security and Sensors. Panel Sessions & Tutorials: Interested persons are invited to submit proposals for panel sessions = and/or halfday/fullday tutorials to the IWS Secretariat no later than = March 31, 2005. Proposals for tutorials and panel sessions with the following documents = should be send to the organisers at email: organisers@iws2005.org :=20 1. For Tutorials:=20 a. Short CV of the speaker=20 b. Title and abstract of the tutorial c. Halfday or fullday tutorial =20 2. For Panels:=20 a. Short CV of the panel organizer=20 b. Short CVs of the speakers=20 c. Title and abstract of the panel=20 d. Title and abstract from the speakers=20 Deadline: Extended abstracts (up to 1500 words): (Extended deadline ) April 15, = 2005 Notification of acceptance: May 15, 2005 Full paper submission: June 20, 2005 Looking forward to seeing you in Aalborg in September 2005. Leif Heinzl WPMC'05 TPC Chair Neeli Prasad WPMC ' 05 Co-Chair =20 =20 ------_=_NextPart_001_01C5356A.A0B64840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(Our apologies = if you=20 receive multiple copies of this document)
3D""=20
 
Wireless Personal Multimedia = Communications
(WPMC'05)
<= FONT=20 color=3D#3333ff> Sept 18-22, 2005 - Aalborg,=20 Denmark
 
Share = your=20 achievements within wireless with the rest of the=20 world:
=

Submit a paper
  a tutorial, and/or = a panel=20 proposal

Deadline for abstract submission:  April=20 15 ,=20 2005

To submit, = follow=20 instructions given at www.iws2005.org
Wireless Personal Multimedia Communications (WPMC) this = year  is=20  a part of the First International Wireless Summit=20 (IWS)

1000 participants are expected . Up to 8 parellel sessions=20 including panel and invited paper sessions, selected tutorials and = industrial=20 exhibition. 
 
Call for=20 Papers - Deadline=20 extended!

The Organizing Committee for WPMC'05 invites you to submit extended = abstracts=20 on the following topics (but not limited to) by electronic submission in = PDF=20 format.

  • Track I: Antenna and Propagation=20
  • Track II: Transmission Technology=20
  • Track III: Digital Signal Processing=20
  • Track IV: Wireless Access=20
  • Track V: Multimedia, Networks and Systems=20
  • Track VI: Wireless Security=20
  • Track VII: Wireless Sensors and Data Fusion=20
  • Track VIII: Modeling and Simulation=20
  • Track IX: Satellite and Navigation=20
  • Track X: Other topics

Description of tracks.

Introduction = of abstract=20 submission.

Award papers:
Six papers will = be=20 selected for the "Best Paper Award" among the contributed papers and = there will=20 also be the "Best Student Award".

Wireless Personal Communication:
An International=20 Journal
Twenty papers including the Award Papers will be = selected=20 for publication in a special issue: "Latest Trends in Wireless=20 Communication".

Special Sessions:
Special Sessions on "Hot = Topics" will=20 be organized. Especially, there will be special sessions on Wireless = Security=20 and Sensors.

Panel Sessions & Tutorials:
Interested = persons are=20 invited to submit proposals for panel sessions and/or halfday/fullday = tutorials=20 to the IWS Secretariat no later than March 31, 2005.

Proposals for tutorials and panel sessions with the following = documents=20 should be send to the organisers at email: organisers@iws2005.org = :=20

1. For Tutorials:
   a. Short CV of the speaker=20
   b. Title and abstract of the tutorial
   = c.=20 Halfday or fullday tutorial
 
2. For Panels:
   = a.  Short CV of the panel organizer
   b. Short CVs = of the=20 speakers
   c. Title and abstract of the panel =
   d.=20 Title and abstract from the speakers =

Deadline:
Extended abstracts (up to 1500 words):=20 (Extended deadline )   April 15,=20 2005

Notification of acceptance: May = 15,=20 2005

Full paper submission: June 20,=20 2005


Looking forward to = seeing you=20 in Aalborg in September 2005.

Leif Heinzl
WPMC'05 TPC=20 Chair

Neeli =20 Prasad
<= /BIG>
WPMC ' 05 Co-Chair =20

 
------_=_NextPart_001_01C5356A.A0B64840-- --===============0740536795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0740536795==-- From mip6-bounces@ietf.org Fri Apr 1 08:13:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22434 for ; Fri, 1 Apr 2005 08:13:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM4l-0001LP-Bd for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:20:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLv1-0000T1-Fi; Fri, 01 Apr 2005 08:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Mk-0000bx-Th; Thu, 31 Mar 2005 12:21:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13650; Thu, 31 Mar 2005 12:21:56 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3Tu-0007Ez-Ce; Thu, 31 Mar 2005 12:29:22 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA28292; Thu, 31 Mar 2005 09:21:37 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j2VHLZ713466; Thu, 31 Mar 2005 11:21:35 -0600 (CST) Received: from xch-nw-21.nw.nos.boeing.com ([192.48.4.95]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 09:17:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Thu, 31 Mar 2005 09:17:08 -0800 Message-ID: <6E5042539D21AF4E9C457B4DDCC3D6E107DF95B4@xch-nw-21.nw.nos.boeing.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU1v5GuzceS5DXWRkq/HF4w9gVtswAT1K4Q From: "Davis, Terry L" To: , "Sri Gundavelli" , "Vijay Devarapalli" X-OriginalArrivalTime: 31 Mar 2005 17:17:08.0811 (UTC) FILETIME=[782941B0:01C53615] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Apr 2005 08:10:32 -0500 Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable Carl Amen!!! I would be very interested if your requirement were in place: "One requirement that I believe is highly desirable is the ease of deployment of a solution that enables Mobile IPv6 traversal in IPv4 networks." This would allow us to consider v6 for the mobile platform without worrying about installing a full global v6 infrastructure to support them. Sri/Vijay And I'd sure like it if the discussion considered options to "home agents". I fail to comprehend how I move state for routing, QoS, security, and capacity for hundreds of users/applications on mobile platforms around on a global scale through home agents, especially if I'm joining someone else's network (i.e. one airport to the next). Try imagining teleporting an engineering building from your corporate campus instantly onto the campus of your biggest competitor and have all network connections maintained, your VPN's not dropped, routing continue un-interrupted, security maintained, QoS maintained, and you have equivalent network capacity. This is what we are beginning to try to do with large mobile platforms today. Now I don't honestly believe we can achieve all of this; but it seems like this should be our goal. Take care Terry Davis Connexion by Boeing -----Original Message----- From: Carl Williams [mailto:carlw@mcsr-labs.org]=20 Sent: Wednesday, March 30, 2005 10:12 PM To: 'Sri Gundavelli'; 'Vijay Devarapalli' Cc: nemo@ietf.org; mip6@ietf.org; ryuji@sfc.wide.ad.jp; Basavaraj.Patil@nokia.com Subject: RE: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Hi Sri, Looking at things from an operational or deployment perspective: One requirement that I believe is highly desirable is the ease of deployment of a solution that enables Mobile IPv6 traversal in IPv4 networks. Additional network infrastructure and/or a complicated protocol will take us further from the base MIPv6 protocol - which impacts the ease of deployment and possible acceptance.=20 It would be highly desirable for operators and users not to have a requirement that their Mobile IPv6 service be dependent on a separate transition service. =20 Finally, co-existence of Mobile IPv6 (a feature of IPv6:) with IPv4 networks is a mandate that we must adhere to ASAP; otherwise, there will be little acceptance to advance Mobile IPv6 adoption/deployment [just think if we waited for the core IPv6 specifications to become RFCs before working on v6ops stuff - where would will be with IPv6 deployment today]. draft-wakikawa-nemo-v4tunnel-01 limits the scope to what I believe is the minimum scenario and requires little protocol changes. Let's keep in mind the operator's perspective in the debate.=20 Carl -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, March 30, 2005 4:27 PM To: Vijay Devarapalli Cc: nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Hi Vijay, On Wed, 30 Mar 2005, Vijay Devarapalli wrote: > Sri, > > Sri Gundavelli wrote: > > Hi Raj, > > In the last IETF nemo meeting, we raised some > > issues on the approach chosen by this draft. We are > > not convinced that the draft has explored and narrowed > > down on the most common v4 traversal scenarios. The > > basic assumption of the draft that the v6 Home Agent's > > functionality is collapsed in to the transition gateway > > is not valid and just addresses one scenario. The > > requirement the draft imposes on having a V4 network > > terminating on the v6 home agent is probably not > > acceptible. > > if I understood you right, your concern is about how to make > an IPv6 HA with an IPv4 interface accesible through the IPv4 > Internet. right? The question is not about configuring a v4 address on the interface of v6 home agent, it about the termination point of the v4 network and the placement of a v6 home agent. You cannot expect the v6 home agent and the transition gateway service to be co-located. The point is that we should identify the practical deployment sceanarios and go from there. > > > Also, the draft's claim that they are > > avoiding one extra encap layer is not true, the moment > > you move the transition gateway from the home agent, > > indeed an extra encap layer is needed. > > we do want to keep it to just one level of encapsulation. > Other way to say is we would not an extra encap layer, when the home agent and the transition gateway functions are spread out. > Vijay > > > > > There were some other proposals for solving this problem > > and one being "draft-thubert-nemo-ipv4-traversal-01.txt", > > we should look at this work as well. Before we agree on > > a solution, we should atleast semantically agree on the > > problem statement and the scope. I remember you words, > > we should not boil the ocean in the process, Agreed ! > > But, atleast we should have some amount of discussions on > > the problem scope. My 2c. > > > > Regards > > Sri > > > > > > > > > > > > On Wed, 30 Mar 2005 Basavaraj.Patil@nokia.com wrote: > > > > > >>One of the major barriers to the deployment of Mobile IPv6 today is > >>the fact that most access networks are IPv4 only. A number of hosts > >>are already dual-stack capable. While Mobile IPv6 works well in IPv6 > >>networks, it is essential that IPv6 mobility service continue to work > >>even when the mobile host is attached to an IPv4 network. The same > >>applies to a NEMO mobile router as well. > >> > >>A number of transition scenarios have been identified in IDs: > >>1. draft-larsson-v6ops-mip-scenarios-01 > >>2. draft-tsirtsis-dsmip-problem-03 > >>While discussion of these scenarios in the larger scope makes sense, > >>there is a need to focus on the most critical scenario that would > >>address the MIP6 host and router problem. The problem in a single > >>sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need > >>to be able to reach its (IPv6) home agent and services when roaming in > >>and attached to an IPv4 access network." > >>It makes sense to focus on just this one scenario and solve the > >>problem immediately. > >> > >>The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 > >>mobile node or a NEMO mobile router roaming onto a IPv4 only access > >>network in a simple manner. > >>It is intended that the standardization of this solution in the IETFs > >>MIP6 and/or NEMO working groups proceed. The working group chairs have > >>reviewed and discussed this work item. It has also been presented at > >>the MIP6 and NEMO WGs at IETF62. > >> > >>The chairs would like to hear your thoughts in order to see if there > >>is consensus to make it a WG document and progress it as a standards > >>track RFC. Comments should be sent to both the NEMO and MIP6 WGs. > >> > >>If we have consensus, then the document will be pursued as a dual WG > >>item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > >> > >>Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > >> For [ ] > >> Against [ ] > >> > >> > >>- MIP6 and NEMO WG chairs > >> > >> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 08:15:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22701 for ; Fri, 1 Apr 2005 08:15:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM6k-0001SE-VT for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:22:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLv0-0000Sw-VJ; Fri, 01 Apr 2005 08:10:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGp0q-0003C2-O7; Wed, 30 Mar 2005 21:02:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23282; Wed, 30 Mar 2005 21:02:23 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGp7q-0005UR-7J; Wed, 30 Mar 2005 21:09:40 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j2V218Lw006827; Wed, 30 Mar 2005 21:01:08 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D1EA63C815F; Wed, 30 Mar 2005 20:58:31 -0500 (EST) Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.mitl.research.panasonic.com [150.169.1.62])by redwood.research.panasonic.com (Postfix) with ESMTP id C69F23C8157; Wed, 30 Mar 2005 20:58:31 -0500 (EST) Received: from [69.248.17.64] by pintlmail.MITL.Research.Panasonic.COM(mshttpd); Wed, 30 Mar 2005 21:01:07 -0500 From: Brijesh Kumar To: Sri Gundavelli Message-ID: <5e80e5a22c.5a22c5e80e@pintlmail.MITL.Research.Panasonic.COM> Date: Wed, 30 Mar 2005 21:01:07 -0500 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) MIME-Version: 1.0 Content-Language: en Subject: Re: [nemo] Re: [Mip6] Consensus call on makingIDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Apr 2005 08:10:32 -0500 Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Raj: I too would support Sri's excellent analysis. I am very surprised to see this consensus mail, given that during the last IETF meeting, several people had raised the concerns similar to what Sri has described in his mail regarding that draft. Not clear what has changed since then. --bk ----- Original Message ----- From: Sri Gundavelli Date: Wednesday, March 30, 2005 5:38 pm Subject: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document > Hi Raj, > In the last IETF nemo meeting, we raised some > issues on the approach chosen by this draft. We are > not convinced that the draft has explored and narrowed > down on the most common v4 traversal scenarios. The > basic assumption of the draft that the v6 Home Agent's > functionality is collapsed in to the transition gateway > is not valid and just addresses one scenario. The > requirement the draft imposes on having a V4 network > terminating on the v6 home agent is probably not > acceptible. Also, the draft's claim that they are > avoiding one extra encap layer is not true, the moment > you move the transition gateway from the home agent, > indeed an extra encap layer is needed. > > There were some other proposals for solving this problem > and one being "draft-thubert-nemo-ipv4-traversal-01.txt", > we should look at this work as well. Before we agree on > a solution, we should atleast semantically agree on the > problem statement and the scope. I remember you words, > we should not boil the ocean in the process, Agreed ! > But, atleast we should have some amount of discussions on > the problem scope. My 2c. > > Regards > Sri > > > > > > On Wed, 30 Mar 2005 Basavaraj.Patil@nokia.com wrote: > > > > > One of the major barriers to the deployment of Mobile IPv6 today is > > the fact that most access networks are IPv4 only. A number of hosts > > are already dual-stack capable. While Mobile IPv6 works well in IPv6 > > networks, it is essential that IPv6 mobility service continue to > work> even when the mobile host is attached to an IPv4 network. > The same > > applies to a NEMO mobile router as well. > > > > A number of transition scenarios have been identified in IDs: > > 1. draft-larsson-v6ops-mip-scenarios-01 > > 2. draft-tsirtsis-dsmip-problem-03 > > While discussion of these scenarios in the larger scope makes sense, > > there is a need to focus on the most critical scenario that would > > address the MIP6 host and router problem. The problem in a single > > sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) > need> to be able to reach its (IPv6) home agent and services when > roaming in > > and attached to an IPv4 access network." > > It makes sense to focus on just this one scenario and solve the > > problem immediately. > > > > The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a > MIPv6> mobile node or a NEMO mobile router roaming onto a IPv4 > only access > > network in a simple manner. > > It is intended that the standardization of this solution in the > IETFs> MIP6 and/or NEMO working groups proceed. The working group > chairs have > > reviewed and discussed this work item. It has also been > presented at > > the MIP6 and NEMO WGs at IETF62. > > > > The chairs would like to hear your thoughts in order to see if there > > is consensus to make it a WG document and progress it as a standards > > track RFC. Comments should be sent to both the NEMO and MIP6 WGs. > > > > If we have consensus, then the document will be pursued as a > dual WG > > item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > > > > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > > For [ ] > > Against [ ] > > > > > > - MIP6 and NEMO WG chairs > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 08:18:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22920 for ; Fri, 1 Apr 2005 08:18:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMA4-0001Yx-VR for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:26:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLv2-0000T6-00; Fri, 01 Apr 2005 08:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHBdL-0002Bo-2O; Thu, 31 Mar 2005 21:11:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06212; Thu, 31 Mar 2005 21:11:35 -0500 (EST) Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHBkW-0003JU-EE; Thu, 31 Mar 2005 21:19:06 -0500 Received: OTM-MO id j312BNg2015850; Fri, 1 Apr 2005 11:11:23 +0900 (JST) Received: OTM-MIX0 id j312BM24008843; Fri, 1 Apr 2005 11:11:22 +0900 (JST) Received: JC-SMTP from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) id j312BLCi011633; Fri, 1 Apr 2005 11:11:22 +0900 (JST) Date: Fri, 01 Apr 2005 11:10:50 +0900 (JST) Message-Id: <20050401.111050.01527068.keiichi@iijlab.net> To: mip6@ietf.org, nemo@ietf.org Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document From: Keiichi SHIMA In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Apr 2005 08:10:32 -0500 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi all, From: Basavaraj.Patil@nokia.com Date: Wed, 30 Mar 2005 13:33:19 -0600 > The chairs would like to hear your thoughts in order to see if there > is consensus to make it a WG document and progress it as a standards > track RFC. Comments should be sent to both the NEMO and MIP6 WGs. I agree that we need a mechanism for mobile hosts/routers to keep IPv6 mobility functions even if they jump into IPv4 network. Personally, I am not sure if we need to save 40bytes instead of using some other general tunneling mechanism. But, I also personally feel that we need much time if we wait for a general tunneling mechanism to be defined, which we don't want to. Defining a simple traversal mechanism in MIP6/NEMO protocol makes sense to me. The proposal (draft-wakikawa-nemo-v4tunnel) is simple enough and it looks easy to implement from implementor's point of view. It only focuses IPv6 mobility which seems a good tradeoff to me. However, I still don't fully understand the pros and cons between draft-wakikawa-nemo-v4tunnel and draft-soliman-v4v6-mipv6. I want to see which is better for our purpose. --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 08:37:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25076 for ; Fri, 1 Apr 2005 08:37:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMSD-0002Mb-Jy for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 08:44:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMG1-0003Tw-KL; Fri, 01 Apr 2005 08:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMG0-0003Tj-2R; Fri, 01 Apr 2005 08:32:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24483; Fri, 1 Apr 2005 08:32:12 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMNI-0002AW-8n; Fri, 01 Apr 2005 08:39:50 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j31DVsq16081; Fri, 1 Apr 2005 16:31:54 +0300 Date: Fri, 1 Apr 2005 16:31:53 +0300 (EEST) From: Pekka Savola To: Vijay Devarapalli Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <424C3932.8080005@iprg.nokia.com> Message-ID: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> <424C3932.8080005@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 On Thu, 31 Mar 2005, Vijay Devarapalli wrote: >>> we do want to keep it to just one level of encapsulation. >> >> Why, exactly? > > well, if its doable, dont we always want minimal encapsulation? Not necessarily. There's always room for optimization but the tradeoff is worth considering. The question is what level is "good enough". > it is doable if the following assumptions from the draft are valid. > > - HA has v4 and v6 interface > - MN is dual-stack > - HA's v4 address is reachable from the IPv4 Internet. I've no doubt that it's doable,a nd these assumptions seem OK to me. >> There are existing mechanisms out there which have been deployed for years, >> widely implemented, etc. to deal with exactly these issues. > > I am not sure I understood. we are not defining any new tunneling > mechanisms. the idea is to use the existing tunneling mechanisms. But instead of using mechanisms which require no protocol modifications or new code at all, you're plugging v4 tunneling functionality to MIPv6. In other words, inventing something new. That's a bit uncomfortable because MIPv6 was not designed for v4: There are a couple of things why I think this is a problem: - People could even leverage the length of v6 addresses e.g., for CGA-based authorization instead of return routability (or something like that). But extending MIPv6 in a manner that would eliminate that room for expansion. - We may not (yet) be fully aware which parts of the spec this has (non-obvious) implications to - we end up having to re-invent a lot of stuff, like NAT traversal, keepalives, possibly needing to also do NAT traversal to reach the Home Agent, etc. And we have a number of encapsulation mechanisms. All of this seems like something that we do NOT want to re-invent in MIPv6 unless it can be justified that using existing mechanisms and existing configuration methods is not good enough (the crutch appears to be saving 20 or 40 bytes of payload). >> You're arguing we need to design protocol extensions to save 20 or 40 >> bytes. Is it worth it ? > > well, the protocol extension is only to bind an IPv4 CoA to IPv6 > HoA. it is minor enough that we dont have to worry about it. Would the next step be to bind an IPv4 CoA to IPv6 CN ? >> A couple of quick comments on the ID: >> - which encapsulation types are mandatory-to-implement? There must be at >> least one or a couple, to ensure interoperability. > > right. we havent picked a mandatory-to-implement mechanism > yet. IPv6-in-UDP-over-IPv4 and IPv6-over-IPv4? suggestions are > welcome. Those seem OK, though I'm not sure what the security folks would say. >> - I guess it should be possible to discover the v4 home agent address >> without having to use (v6-only) DHAAD? > > DNS is one mechanism to discover the v4 address of the home agent. Yep.. but it's non-standard, right? How can products from different vendors and operators interoperate? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 08:58:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27125 for ; Fri, 1 Apr 2005 08:58:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMmr-0003F7-9n for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 09:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMeC-0006xw-Ny; Fri, 01 Apr 2005 08:57:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMe9-0006xR-TS; Fri, 01 Apr 2005 08:57:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26989; Fri, 1 Apr 2005 08:57:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMlU-0003CS-4K; Fri, 01 Apr 2005 09:04:48 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 15:56:51 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31DuQtL005496; Fri, 1 Apr 2005 15:56:47 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Apr 2005 15:56:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 15:56:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD8234@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2OtFAhmoDk0oHRqikLeb7Xi6iewAhkqmA From: "Pascal Thubert \(pthubert\)" To: "Narayanan Vidya-CVN065" , "Henrik Levkowetz" , "Keiichi SHIMA" X-OriginalArrivalTime: 01 Apr 2005 13:56:44.0993 (UTC) FILETIME=[A3D1FB10:01C536C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable | If most deployments don't have an issue with the placement of the HA in | the DMZ and a small percentage of the cases do, it does not seem too bad | to me to say that a solution is simple since it solves the 90% case. I'd | vote for that rather than make it really complex to also solve the 10% | case. |=20 Hi Vidya I see words about complexity from you and Keiichi. I agree we need to look at how complex the proposals are: - in terms of standardization - in terms of coding - and mostly in terms of deployment Obviously, a solution that has less constraints is easier to deploy. Ending the IPv4 at the HA is a constraint. We have experiments with customers who could not do that for very pragmatic reasons. Details might be given mater. In terms of coding, I guess that people have to read and understand all proposals on the table before they can assess that one thing is more complex than another. I would assert that a solution that does not change the home agent causes less regression testing then one that does. For instance, Doors is a very small footprint hack that leaves the end to end MIP untouched. In terms of standardization, I'd guess that the same applies. Changing MIP inside is not as simple as changing it on the surface. Doors just acts on the transport. The Doors gateway can be installed on the HA, close to the HA, or by an external provider anywhere. I'd just suggest that we, as a group, do not presuppose that because Doors provides additional features it is necessarily more complex. Sometimes, simplicity brings a lot of good things with it. Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 09:00:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27360 for ; Fri, 1 Apr 2005 09:00:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMok-0003Lv-JU for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 09:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMfQ-00075o-5D; Fri, 01 Apr 2005 08:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMfO-00075g-Gt; Fri, 01 Apr 2005 08:58:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27096; Fri, 1 Apr 2005 08:58:27 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMmj-0003EN-9e; Fri, 01 Apr 2005 09:06:05 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 15:58:22 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31DwGt5005881; Fri, 1 Apr 2005 15:58:17 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Apr 2005 15:58:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 15:58:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD8238@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2mjVJH//ngUD5SmSdpe68FgVbVwAKH0FA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" , "Vijay Devarapalli" X-OriginalArrivalTime: 01 Apr 2005 13:58:16.0664 (UTC) FILETIME=[DA75DD80:01C536C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Pekka Savola X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Doors uses the BU as keep alive.=20 Just tune the Binding lifetime according to your needs. In general, 30s was fine with us. Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Alexandru Petrescu | Sent: Friday, April 01, 2005 10:59 AM | To: Vijay Devarapalli | Cc: nemo@ietf.org; mip6@ietf.org; Pekka Savola | Subject: Re: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document |=20 | Vijay Devarapalli wrote: | >> - you specify UDP encapsulation for NAT traversal, but no keepalive | >> | > | > okay. will fix this. |=20 | How are you going to fix this Vijay? I use 15s keepalive with ICMP. | Would you do similarly? |=20 | Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 09:19:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29290 for ; Fri, 1 Apr 2005 09:19:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHN78-000448-AL for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 09:27:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMvD-000138-H7; Fri, 01 Apr 2005 09:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMvB-00012v-V6; Fri, 01 Apr 2005 09:14:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28610; Fri, 1 Apr 2005 09:14:44 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHN2U-0003tX-5r; Fri, 01 Apr 2005 09:22:23 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IE900J6TU3LXX@dns1.cselt.it>; Fri, 01 Apr 2005 16:11:45 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 01 Apr 2005 16:17:04 +0200 Date: Fri, 01 Apr 2005 16:14:12 +0200 From: Gerardo Giaretta Subject: RE: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document To: Vijay Devarapalli Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Thread-Index: AcU2HjT/iZIgLCBqTTikumU1Kx4fvgAo7odQ Content-class: urn:content-classes:message X-OriginalArrivalTime: 01 Apr 2005 14:17:04.0921 (UTC) FILETIME=[7AF43890:01C536C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Hi Vijay, please see below.. >=20 > > Hi Raj, > >=20 > > I have two general comments about making=20 > draft-wakikawa-nemo-v4tunnel a > > WG item: > >=20 > > - I agree with you that the scenario you described is the most > > interesting one and I'm favor of focusing on it immediately.=20 >=20 > great. >=20 > > However I > > think that before having consensus on this solution draft, we should > > understand if there is consensus on scenarios we want to=20 > address and in > > particular if there is consensus to address only this particular > > scenario. At least I thought this was the MIP6 WG original intention > > since MIP6 charter states that the WG will document a=20 > problem statement > > related to IPv4/IPv6 transition issues. >=20 > ah.. you werent at the MIP4 WG meeting. the question about multiple > transition scenarios came up. there was an agreement on the following > scenarios. (if I am wrong, those who were at the MIP4 WG meeting, > please correct me). >=20 > 1) There are people who want to deploy MIPv6 (and NEMO). they dont > use MIPv4 currently. For these folks the most important scenario > is to reach the IPv6 Home Agent (and services) from an IPv4 access > network. >=20 > 2) There are people who have deployed MIPv4. They want to move to > MIPv6. >=20 > then there are other scenarios, for example, an MIPv4 node ending up > on a pure IPv6 access network. I think those scenarios should be > excluded. not realistic. > > I am not sure there was concensus, but the general mood in the meeting > was that the MIP4 WG will look into the second scenario. IMHO, MIP6 > should deal with 1). > Actually I was at the MIP4 WG meeting and I remember the agreement you mention :) Note that, as said in my previous email, I am in favor that MIP6 deals with scenario 1. My point is that, as stated by Henrik, James and others, we need an agreement in MIP6/NEMO WG (and not in MIP4 WG) on the scenario(s) to be considered and in particular if the WG agrees to focus only on the scenario tackled by draft-wakikawa.=20 =20 > > - I wonder why draft-soliman-v4v6-mipv4-01 has not been=20 > considered as a > > candidate WG item (at least for MIP6). I'd like to see a discussion > > about the pros and cons of both drafts. In my view they=20 > tackle the same > > scenario in a very similar way.=20 >=20 > okay. draft-soliman-v4v6 deals with lots of scenarios including > scenario 1) and 2) above. draft-wakikawa talks only about scenario 1). > the idea of binding an IPv4 CoA to an IPv6 HoA is very old. > draft-soliman is not the first one that spoke about it. draft-wakikawa > just explains in *very* detail how to do scenario 1), including a new > mobility option, MN and HA operation to process this new mobility > option, IPsec SPD and SAD entries for securing the IPv6-over-IPv4 > tunnel, NAT traversal, how to negotiate a particular tunneling > mechanism and new binding ack status values. >=20 Actually I'm not sure that draft-soliman-v4v6 deals also with scenario 2. Note that I'm not advocating draft-soliman. I'm just saying that draft-soliman is a possible alternative solution for scenario addressed by draft-wakikawa and we need to consider pros and cons for both of them. Actually, in my view the two drafts are very similar and working on their differences should be very easy.=20 > > The main difference is the BU message > > format: based on draft-wakikawa the source address of the=20 > IPv6 packet is > > the HoA, since the message is treated as a particular=20 > de-registration; > > in draft-soliman the source address is the CoAv4 mapped in=20 > IPv6 address > > format. I'd like to understand better the rationale behind=20 > the choice in > > draft-wakikawa. Personally, I think that the approach of=20 > draft-soliman > > is a little bit cleaner since the BU is not considered a=20 > de-registration > > message.=20 >=20 > hmm.. but you want to remove any existing binding cache entries that > bind the IPv6 HoA to an IPv6 CoA, right? we are just combining > removing an existing BCE with IPv6 CoA and adding a new BCE with IPv4 > CoA. >=20 well, sending a new BU you replace the existing binding cache entry. I don't see the need to do a de-registration for IPv6 CoA and a new registration for IPv4 CoA. Simply sending the IPv4 CoA (mapped in IPv6 format) will cause the BCE to be updated. Am I missing something? --Gerardo > Vijay >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 10:00:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01926 for ; Fri, 1 Apr 2005 10:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHNkY-0005T7-3K for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 10:07:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHNbn-000604-NL; Fri, 01 Apr 2005 09:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHNbm-0005zo-B1; Fri, 01 Apr 2005 09:58:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01795; Fri, 1 Apr 2005 09:58:48 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHNj6-0005NZ-5e; Fri, 01 Apr 2005 10:06:25 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 16:58:40 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31EwTtB026277; Fri, 1 Apr 2005 16:58:36 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 16:58:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 16:58:28 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD82AD@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2SEWgD4Xn2EWvRfqaodUBv14I0gAera6A From: "Pascal Thubert \(pthubert\)" To: "Sri Gundavelli \(sgundave\)" , "Narayanan Vidya-CVN065" X-OriginalArrivalTime: 01 Apr 2005 14:58:33.0949 (UTC) FILETIME=[4687C0D0:01C536CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Agreed... Another angle is that HAs are already being sold and deployed. There is value in incremental features that do not change the HA and the surrounding infrastructure. For instance, in the PE-Based model, corporations only own the routing within their VPN, and the global addresses are owned by the service provider. Unless they deploy a specific exit with DMZ, firewall and so on, they will not have a single box with a global IPv4 address to put an HA on.=20 Do we want to limit the solution to these corps that have a DMZ? Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Sri Gundavelli (sgundave) | Sent: Friday, April 01, 2005 1:18 AM | To: Narayanan Vidya-CVN065 | Cc: nemo@ietf.org; mip6@ietf.org; 'Vijay Devarapalli'; Henrik Levkowetz; | Basavaraj.Patil@nokia.com | Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document |=20 |=20 | Vidya, |=20 | Any transition solution should offer a way for a phased | migration. I do not see how the current solution will | enable the operator to push the v4 network in a phased | manner. The requirements that the HA should be on the | edge or if 90% of the deployments will go for that model | is debatable and can only be answered by going for a | problem statement. |=20 | Regards | Sri |=20 |=20 |=20 | On Thu, 31 Mar 2005, Narayanan Vidya-CVN065 wrote: |=20 | > Sri, | > I also understood your comments exactly as Vijay did. A couple of years | ago, I did hear about some concerns on placing the HA in the DMZ, but I | didn't think any of those were very deep. Is there really a deployment | issue in placing the HA in the DMZ? | > | > Actually, even if you did place the HA deep in the IPv6 network, forcing | the need for a tunneling box in the DMZ that does v4-v6 tunneling, is that | really that bad? | > | > If most deployments don't have an issue with the placement of the HA in | the DMZ and a small percentage of the cases do, it does not seem too bad | to me to say that a solution is simple since it solves the 90% case. I'd | vote for that rather than make it really complex to also solve the 10% | case. | > | > My 2 cents, | > Vidya | > | > -----Original Message----- | > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Vijay Devarapalli | > Sent: Thursday, March 31, 2005 2:02 PM | > To: Henrik Levkowetz | > Cc: nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com | > Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document | > | > | > Henrik, | > | > there is some mis-understanding regarding the relation | > between draft-soliman and draft-wakikawa. both solve the scenario of a | v6 MN or MR accessing its v6 home agent from a v4 only access network. | draft-soliman talks about using a IPv4 mapped IPv6 address to convey the | IPv4 CoA to the HA. draft-wakikawa uses a new mobility option to carry the | IPv4 CoA. I personally prefer carrying it in a separate mobility option, | because it makes processing on the HA easier. we can debate the pros and | cons of this later. but this *does* not impact the scenario. both solve | the same scenario. | > | > there are other scenarios, but IMHO, they are not relevant. | > | > regarding Sri's concerns, we do intend to address them. dont worry about | that. we have an assumption in the draft. | > | > - the HA's IPv4 address is reachable through the IPv4 internet | > | > Sri is questioning this assumption. he is claiming this is | > not so easy. he doesnt want IPv4 routing inside his IPv6 network. the HA | is deep inside in the IPv6 network. for the HA's IPv4 address to be | reachable, you might need a box in the DMZ, which traps the packets for | the HA's IPv4 address and tunnels them to the HA deep in the IPv6 network. | but here we end with extra tunneling between the box sitting in the DMZ | and the HA deep in the IPv6 network. another option is to place the HA in | the DMZ. but he doesnt want to do that. I will be discussing with him to | see how we can come up with a solution. Sri, let me know if I still dont | understand the issue you are bringing up. | > | > Vijay | > | > Henrik Levkowetz wrote: | > > Hi, | > > | > > On 2005-03-30 9:33 pm Basavaraj.Patil@nokia.com said the following: | > > [...] | > > | > >>A number of transition scenarios have been identified in IDs: | > >>1. draft-larsson-v6ops-mip-scenarios-01 | > >>2. draft-tsirtsis-dsmip-problem-03 | > >>While discussion of these scenarios in the larger scope makes sense, | > >>there is a need to focus on the most critical scenario that would | > >>address the MIP6 host and router problem. The problem in a single | > >>sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need | > >>to be able to reach its (IPv6) home agent and services when roaming in | > >>and attached to an IPv4 access network." | > >>It makes sense to focus on just this one scenario and solve the | > >>problem immediately. | > > | > > | > > Given that there already exists at least 3 solution drafts in this | > > area: | > > | > > draft-thubert-nemo-ipv4-traversal | > > draft-soliman-v4v6-mipv6 | > > draft-wakikawa-nemo-v4tunnel | > > | > > and Sri clearly indicates that there are requirements which these | > > don't cover, I think it would be good to have a clear and agreed upon | > > statement of what to achieve before adopting an approach and draft. | > > So I'm not for adopting draft-wakikawa before there is an agreed upon | > > problem statement. | > > | > > That said, I'm very much in favour of doing this work; and doing it by | > > extensions to MIP6 (and MIP4) rather than trying to adapt any of the | > > other approaches which would mix MIP6 with non-MIP tunnels, as listed | > > in draft-larsson-v6ops-mip-scenarios-01. | > > | > > If the decision is to write a problem statement, I'd be willing to | > > work on such a draft, and I also have a potential co-editor who have | > > indicated willingness. | > > | > > | > >>The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 | > >>mobile node or a NEMO mobile router roaming onto a IPv4 only access | > >>network in a simple manner. | > >>It is intended that the standardization of this solution in the IETFs | > >>MIP6 and/or NEMO working groups proceed. The working group chairs have | > >>reviewed and discussed this work item. It has also been presented at | > >>the MIP6 and NEMO WGs at IETF62. | > >> | > >>The chairs would like to hear your thoughts in order to see if there | > >>is consensus to make it a WG document and progress it as a standards | > >>track RFC. Comments should be sent to both the NEMO and MIP6 WGs. | > >> | > >>If we have consensus, then the document will be pursued as a dual WG | > >>item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt | > >> | > >>Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: | > >> For [ ] | > >> Against [ ] | > >> | > > | > > | > > Not currently [ X ] | > > | > > | > > Henrik | > > | > > _______________________________________________ | > > Mip6 mailing list | > > Mip6@ietf.org | > > https://www1.ietf.org/mailman/listinfo/mip6 | > | > | > | > _______________________________________________ | > Mip6 mailing list | > Mip6@ietf.org | > https://www1.ietf.org/mailman/listinfo/mip6 | > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 10:42:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05983 for ; Fri, 1 Apr 2005 10:42:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOPk-0006u8-3J for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 10:50:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOGp-0002hv-0Z; Fri, 01 Apr 2005 10:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOGk-0002hi-Ps; Fri, 01 Apr 2005 10:41:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05880; Fri, 1 Apr 2005 10:41:08 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOO5-0006sG-4i; Fri, 01 Apr 2005 10:48:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j31FeQi18607; Fri, 1 Apr 2005 18:40:26 +0300 Date: Fri, 1 Apr 2005 18:40:26 +0300 (EEST) From: Pekka Savola To: "Pascal Thubert (pthubert)" Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCAD8234@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FCAD8234@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org, mip6@ietf.org, Keiichi SHIMA , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Fri, 1 Apr 2005, Pascal Thubert (pthubert) wrote: > I see words about complexity from you and Keiichi. I agree we need to > look at how complex the proposals are: > - in terms of standardization > - in terms of coding > - and mostly in terms of deployment Don't forget IPR encumburances (if any). A mechanisms without IPR claims is much more likely to actually get implemented by certain communities. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 10:47:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06270 for ; Fri, 1 Apr 2005 10:47:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOUX-00076d-Vc for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 10:55:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOHv-0002lT-Om; Fri, 01 Apr 2005 10:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOHt-0002lG-Id; Fri, 01 Apr 2005 10:42:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05935; Fri, 1 Apr 2005 10:42:19 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOPE-0006tZ-1B; Fri, 01 Apr 2005 10:49:57 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31FgBG00745; Fri, 1 Apr 2005 18:42:11 +0300 (EET DST) X-Scanned: Fri, 1 Apr 2005 18:41:44 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j31FfhqP026783; Fri, 1 Apr 2005 18:41:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00UZphws; Fri, 01 Apr 2005 18:41:23 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31FfKM23613; Fri, 1 Apr 2005 18:41:20 +0300 (EET DST) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Apr 2005 09:40:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 09:40:45 -0600 Message-ID: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQ To: , X-OriginalArrivalTime: 01 Apr 2005 15:40:46.0000 (UTC) FILETIME=[2BC01300:01C536D1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable A couple of clarifications regarding the consensus call: 1. The intention is to address the following scenario: "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 access network need the capability to create a tunnel and be connected to their MIP6 home agents." This is the scenario that is most applicable for MIP6 deployment. There are plenty of other scenarios as well. But they are much more of academic interest at this time and hence not really in the scope of this discussion. So I would suggst that we do not go off on a tangent discussing all these other scenarios. Do you agree/disagree that the above scenario is the one that needs to be solved ASAP? (Note: It does not imply that other scenarios are irrelevant. It simply means that this is the scenario worth working on and has the most=20 significant priority or value for MIP6 deployment.) 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any other. The IDs can be combined w.r.t the parts that address this = scenario. Additionally once it is a WG document, what goes into the ID is decided by the WG. So lets not get into arguments of what or whose draft is the one that should be made the WG document. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 11:12:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09109 for ; Fri, 1 Apr 2005 11:12:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOsp-00085u-Vk for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOja-00074M-8r; Fri, 01 Apr 2005 11:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOjW-00073x-OV; Fri, 01 Apr 2005 11:10:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08918; Fri, 1 Apr 2005 11:10:52 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOqq-00080G-GD; Fri, 01 Apr 2005 11:18:30 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 18:10:43 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31GAUtD016439; Fri, 1 Apr 2005 18:10:38 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Apr 2005 18:10:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 18:10:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD82EF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2LV/56l6sey+6TMmPN6LH2ieZsQApb+Dg From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Henrik Levkowetz" X-OriginalArrivalTime: 01 Apr 2005 16:10:32.0149 (UTC) FILETIME=[5460C850:01C536D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Vijay Devarapalli | Sent: Thursday, March 31, 2005 10:02 PM | To: Henrik Levkowetz | Cc: nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com | Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document |=20 | Henrik, |=20 | there is some mis-understanding regarding the relation | between draft-soliman and draft-wakikawa. both solve the | scenario of a v6 MN or MR accessing its v6 home agent from | a v4 only access network. draft-soliman talks about using a | IPv4 mapped IPv6 address to convey the IPv4 CoA to the | HA. draft-wakikawa uses a new mobility option to carry | the IPv4 CoA. I personally prefer carrying it in a separate | mobility option, because it makes processing on the HA easier. | we can debate the pros and cons of this later. but this *does* | not impact the scenario. both solve the same scenario. |=20 | there are other scenarios, but IMHO, they are not relevant. |=20 | regarding Sri's concerns, we do intend to address them. dont | worry about that. we have an assumption in the draft. |=20 | - the HA's IPv4 address is reachable through the IPv4 internet |=20 | Sri is questioning this assumption. he is claiming this is | not so easy. he doesnt want IPv4 routing inside his IPv6 | network. the HA is deep inside in the IPv6 network. for the | HA's IPv4 address to be reachable, you might need a box in | the DMZ, which traps the packets for the HA's IPv4 address | and tunnels them to the HA deep in the IPv6 network. but here | we end with extra tunneling between the box sitting in the | DMZ and the HA deep in the IPv6 network. another option is to | place the HA in the DMZ. but he doesnt want to do that. I | will be discussing with him to see how we can come up with a | solution. Sri, let me know if I still dont understand the | issue you are bringing up. Even better would be that this "box in the DMZ" terminates V4, and sends packets to the HA in IPv6. Say, doing some NAT-PT instead of tunneling, classical alternates.=20 OH, yes but then if you do it right, you could try to avoid exposing IPv4 to the HA at all, since now we are IPv6. Interesting... Seems to me that the line if thought that starts at your "box in the DMZ" ends up being With Doors. With Doors, the "box in the DMZ" is the Doors gateway between IPv4 and IPv6.=20 The Doors GW is fully stateless and inherits from 6to4.=20 The closest Doors Gateway could be advertised by means of DHCP / IP NCP so most of the way is done via IPv6. Or the MN/MR can be statically configured with a GW from the ISP. Or, providing that the ISP configures a revNAT state in its PE or managed-CE box, the Doors GW can even be deep within the IPv4 private network (works fine ;). Or, if you have one, you can place the GW in the DMZ. Might be easier to turn Doors GW on (one line) then to migrate the HA there. =20 Then again, implementing Doors is in fact a very small piece of code in the MN/MR and the GW. It is mostly a design point. Consider it. Pascal |=20 | Vijay |=20 | Henrik Levkowetz wrote: | > Hi, | > | > On 2005-03-30 9:33 pm Basavaraj.Patil@nokia.com said the following: | > [...] | > | >>A number of transition scenarios have been identified in IDs: | >>1. draft-larsson-v6ops-mip-scenarios-01 | >>2. draft-tsirtsis-dsmip-problem-03 | >>While discussion of these scenarios in the larger scope makes sense, | >>there is a need to focus on the most critical scenario that would | >>address the MIP6 host and router problem. The problem in a single | >>sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need | >>to be able to reach its (IPv6) home agent and services when roaming in | >>and attached to an IPv4 access network." | >>It makes sense to focus on just this one scenario and solve the | >>problem immediately. | > | > | > Given that there already exists at least 3 solution drafts in this area: | > | > draft-thubert-nemo-ipv4-traversal | > draft-soliman-v4v6-mipv6 | > draft-wakikawa-nemo-v4tunnel | > | > and Sri clearly indicates that there are requirements which these | > don't cover, I think it would be good to have a clear and agreed | > upon statement of what to achieve before adopting an approach and | > draft. So I'm not for adopting draft-wakikawa before there is an | > agreed upon problem statement. | > | > That said, I'm very much in favour of doing this work; and doing | > it by extensions to MIP6 (and MIP4) rather than trying to adapt | > any of the other approaches which would mix MIP6 with non-MIP tunnels, | > as listed in draft-larsson-v6ops-mip-scenarios-01. | > | > If the decision is to write a problem statement, I'd be willing to | > work on such a draft, and I also have a potential co-editor who have | > indicated willingness. | > | > | >>The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 | >>mobile node or a NEMO mobile router roaming onto a IPv4 only access | >>network in a simple manner. | >>It is intended that the standardization of this solution in the IETFs | >>MIP6 and/or NEMO working groups proceed. The working group chairs have | >>reviewed and discussed this work item. It has also been presented at | >>the MIP6 and NEMO WGs at IETF62. | >> | >>The chairs would like to hear your thoughts in order to see if there | >>is consensus to make it a WG document and progress it as a standards | >>track RFC. Comments should be sent to both the NEMO and MIP6 WGs. | >> | >>If we have consensus, then the document will be pursued as a dual WG | >>item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt | >> | >>Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: | >> For [ ] | >> Against [ ] | >> | > | > | > Not currently [ X ] | > | > | > Henrik | > | > _______________________________________________ | > Mip6 mailing list | > Mip6@ietf.org | > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 11:19:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09587 for ; Fri, 1 Apr 2005 11:19:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOyk-0008Kg-N7 for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:26:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOqy-00083d-P5; Fri, 01 Apr 2005 11:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOqw-00083Q-CW; Fri, 01 Apr 2005 11:18:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09489; Fri, 1 Apr 2005 11:18:32 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOyI-0008J1-Gd; Fri, 01 Apr 2005 11:26:10 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 18:18:24 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31GI2tL018245; Fri, 1 Apr 2005 18:18:20 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 18:18:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 18:18:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD82F2@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU20TH62thGW7HxS6+hR7inq7RzLQABNQDA From: "Pascal Thubert \(pthubert\)" To: "Pekka Savola" X-OriginalArrivalTime: 01 Apr 2005 16:18:17.0983 (UTC) FILETIME=[6A0968F0:01C536D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Keiichi SHIMA , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Hi Pekka: There's IPR on Doors, not hiding it. For instance, Cisco has published terms that were supposed to allows opensource implementation (same terms as IPR for basic NEMO aspects). If there's still a problem regarding IPR, someone please let us know. We'll work on it as we did in the past. Pascal | -----Original Message----- | From: Pekka Savola [mailto:pekkas@netcore.fi] | Sent: Friday, April 01, 2005 5:40 PM | To: Pascal Thubert (pthubert) | Cc: Narayanan Vidya-CVN065; Henrik Levkowetz; Keiichi SHIMA; | nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com | Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document |=20 | On Fri, 1 Apr 2005, Pascal Thubert (pthubert) wrote: | > I see words about complexity from you and Keiichi. I agree we need to | > look at how complex the proposals are: | > - in terms of standardization | > - in terms of coding | > - and mostly in terms of deployment |=20 | Don't forget IPR encumburances (if any). |=20 | A mechanisms without IPR claims is much more likely to actually get | implemented by certain communities. |=20 | -- | Pekka Savola "You each name yourselves king, yet the | Netcore Oy kingdom bleeds." | Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 11:34:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12584 for ; Fri, 1 Apr 2005 11:34:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPDk-0000xB-Bc for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:42:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP03-00023K-Mg; Fri, 01 Apr 2005 11:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP02-00021p-Sk; Fri, 01 Apr 2005 11:27:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11034; Fri, 1 Apr 2005 11:27:56 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHP7O-0000NR-2b; Fri, 01 Apr 2005 11:35:35 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j31GRpQ0003446; Fri, 1 Apr 2005 09:27:52 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j31GSwZ0002594; Fri, 1 Apr 2005 10:28:59 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 8F05A8637E6; Fri, 1 Apr 2005 18:27:49 +0200 (CEST) Message-ID: <424D7685.3070804@motorola.com> Date: Fri, 01 Apr 2005 18:27:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > A couple of clarifications regarding the consensus call: > > 1. The intention is to address the following scenario: > "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 > access network need the capability to create a tunnel and be connected > to their MIP6 home agents." > This is the scenario that is most applicable for MIP6 deployment. > There are plenty of other scenarios as well. But they are much more > of academic interest at this time and hence not really in the scope > of this discussion. So I would suggst that we do not go off on a tangent > discussing all these other scenarios. > > Do you agree/disagree that the above scenario is the one that needs > to be solved ASAP? Somehow yes. Our implementation works with both MIP6 and MIP4. Our implementation does not use v4 CoA in BC, and does not use double v6 encapsulation if the Gw is co-located with the HA. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 11:34:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12611 for ; Fri, 1 Apr 2005 11:34:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPDn-0000xP-33 for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:42:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOvF-000108-BK; Fri, 01 Apr 2005 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOvC-0000zg-VO; Fri, 01 Apr 2005 11:22:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10192; Fri, 1 Apr 2005 11:22:56 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHP2Z-00007T-2Q; Fri, 01 Apr 2005 11:30:35 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 18:22:48 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31GMQtN019244; Fri, 1 Apr 2005 18:22:45 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Apr 2005 18:22:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 18:22:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD82F3@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQAAG5mPA= From: "Pascal Thubert \(pthubert\)" To: , , X-OriginalArrivalTime: 01 Apr 2005 16:22:41.0836 (UTC) FILETIME=[074E2EC0:01C536D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Hi Raj: I suggest that we agree on whether we want NAT/PAT/RevNAT traversal or not.=20 We had this debate some time ago at NEMO, and I presented this at IETF 56:: http://mobilenetworks.org/nemo/ietf56/slides/ietf56-nemo-ipv4traversal.p pt=20 That day, we voted that IPv4 traversal was a GOAL for the WG. In particular, the discussion turned around NAT which appears to be really centric to this problem.=20 My personal sense is that we DO NEED (all sorts of) NAT traversal. And it's not impossible if we accept that it works in an agreed upon 'MOST CASES'.=20 Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Basavaraj.Patil@nokia.com | Sent: Friday, April 01, 2005 5:41 PM | To: mip6@ietf.org; nemo@ietf.org | Subject: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo- | v4tunnel a MIP6/NEMO WGs document |=20 |=20 | A couple of clarifications regarding the consensus call: |=20 | 1. The intention is to address the following scenario: | "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 | access network need the capability to create a tunnel and be connected | to their MIP6 home agents." | This is the scenario that is most applicable for MIP6 deployment. | There are plenty of other scenarios as well. But they are much more | of academic interest at this time and hence not really in the scope | of this discussion. So I would suggst that we do not go off on a tangent | discussing all these other scenarios. |=20 | Do you agree/disagree that the above scenario is the one that needs | to be solved ASAP? | (Note: It does not imply that other scenarios are irrelevant. It simply | means that this is the scenario worth working on and has the most | significant priority or value for MIP6 deployment.) |=20 | 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It | does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any | other. The IDs can be combined w.r.t the parts that address this scenario. | Additionally once it is a WG document, what goes into the ID is decided | by the WG. So lets not get into arguments of what or whose draft is the | one that should be made the WG document. |=20 | -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 11:51:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14272 for ; Fri, 1 Apr 2005 11:51:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPUL-0001gN-EW for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:59:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPIn-0007gn-5V; Fri, 01 Apr 2005 11:47:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPIl-0007gU-OU; Fri, 01 Apr 2005 11:47:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13924; Fri, 1 Apr 2005 11:47:17 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPQ8-0001Xl-3y; Fri, 01 Apr 2005 11:54:56 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2005 08:47:11 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j31Gl3ZW026357; Fri, 1 Apr 2005 08:47:08 -0800 (PST) Date: Fri, 1 Apr 2005 08:47:03 -0800 (PST) From: Sri Gundavelli To: Vijay Devarapalli Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <424CBE3F.40200@iprg.nokia.com> Message-ID: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424C3EF8.5050507@levkowetz.com> <424C5733.103@iprg.nokia.com> <424CBE3F.40200@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nemo@ietf.org, mip6@ietf.org, Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hi Vijay, On Thu, 31 Mar 2005, Vijay Devarapalli wrote: > hi Sri, > > Sri Gundavelli wrote: > >> > >>regarding Sri's concerns, we do intend to address them. dont > >>worry about that. we have an assumption in the draft. > >> > >>- the HA's IPv4 address is reachable through the IPv4 internet > >> > >>Sri is questioning this assumption. he is claiming this is > >>not so easy. he doesnt want IPv4 routing inside his IPv6 > >>network. the HA is deep inside in the IPv6 network. for the > >>HA's IPv4 address to be reachable, you might need a box in > >>the DMZ, which traps the packets for the HA's IPv4 address > >>and tunnels them to the HA deep in the IPv6 network. but here > >>we end with extra tunneling between the box sitting in the > >>DMZ and the HA deep in the IPv6 network. another option is to > >>place the HA in the DMZ. but he doesnt want to do that. I > >>will be discussing with him to see how we can come up with a > >>solution. Sri, let me know if I still dont understand the > >>issue you are bringing up. > > > > We need to agree on the most common scenarios that we need to > > address and so we need a problem statement. That should be the > > basis for defining a solution. Further, we need to have some > > gap analysis on each of the three present solutions and > > leverage some thing from them. I agree, we cannot afford to > > spend too much on that, but at the same time adopting a > > solution with out having an understanding of the deployment > > models is not right either. > > here your concern is that we are not looking at enough scenarios. > > so, you have two issues. 1) how to make the HA's IPv4 address > accessible through the IPv4 Internet and 2) we need to step back > and look at more scenarios. > > I agree we need to address 1). and there are some solutions. > you havent responded to them in my mail. but for 2) I am afraid > you havent given any justification. draft-larsson has an > exhaustive catalog of all kinds of scenarios. please point to > the scenario which you think is important and we can take it > from there. One Issue #1, You slightly restated #1. The HA need not be configured with IPv4 address. You have made extensive arguments in the previous IETF's regarding doors using a double tunnel by having a NEMO tunnel in a transition tunnel and that this current draft does not do that. You have not made it clear as how you were able to avoid that extra tunnel. The draft does not talk about the scenario where the transition gateway and the home agent functions are decoupled. However, we are now saying that this draft can do all that by what ever schemes. No thoughts went in to see how the Doors solves the same issues and if Doors required the home agent address to be configured. Issue#2, Yes. We need to step back. We cannot just say the current draft is the basis for the solution. Before we narrow down on one solution draft, there have to be some discussions on the problem scope. I'll not just identify the scenario from your list, there has to be some debate and consensus on the problem scope and that will come out when we look at all the current solution drafts that are out there. So, the problem scope will come out when we review all the current solution drafts. This is my view, you are free to disagree. Sri > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 12:06:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15667 for ; Fri, 1 Apr 2005 12:06:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPit-0002Hn-PO for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 12:14:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPaO-0001ly-MH; Fri, 01 Apr 2005 12:05:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPaN-0001lf-2X; Fri, 01 Apr 2005 12:05:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15539; Fri, 1 Apr 2005 12:05:28 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPhj-0002F2-JE; Fri, 01 Apr 2005 12:13:07 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2005 09:05:22 -0800 Received: from alpeshw2k03 (dhcp-128-107-178-187.cisco.com [128.107.178.187]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j31H5J3S014562; Fri, 1 Apr 2005 09:05:19 -0800 (PST) Message-Id: <200504011705.j31H5J3S014562@sj-core-4.cisco.com> From: "Alpesh" To: , , Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Date: Fri, 1 Apr 2005 09:05:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> Thread-Index: AcU1X1N98uBHQOYSR/WoaWzQrwx+tABfOdwg X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Raj: In general I agree that the v4 traversal problem should be solved. My concern is adopting the draft you mention below as the working Group item and adopting it as the basis of the solution. During last ietf, a number of issues were raised. We need to address those issues - is all forms of NAT supported; why should the Solution mandate v4 and v6 collapsed at the HA; what are the pros/cons Of proposed solution vs other proposals - doors draft, draft from Hesham/George et.al? Vote YES for a solution for v4 traversal. Vote NO for adopting this draft as "the base solution". -a > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > Behalf Of Basavaraj.Patil@nokia.com > Sent: Wednesday, March 30, 2005 11:33 AM > To: mip6@ietf.org; nemo@ietf.org > Subject: [Mip6] Consensus call on making ID > draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document > > > One of the major barriers to the deployment of Mobile IPv6 > today is the fact that most access networks are IPv4 only. A > number of hosts are already dual-stack capable. While Mobile > IPv6 works well in IPv6 networks, it is essential that IPv6 > mobility service continue to work even when the mobile host > is attached to an IPv4 network. The same applies to a NEMO > mobile router as well. > > A number of transition scenarios have been identified in IDs: > 1. draft-larsson-v6ops-mip-scenarios-01 > 2. draft-tsirtsis-dsmip-problem-03 > While discussion of these scenarios in the larger scope makes > sense, there is a need to focus on the most critical scenario > that would address the MIP6 host and router problem. The > problem in a single sentence can be stated as: "Mobile IPv6 > hosts and routers (NEMO) need to be able to reach its (IPv6) > home agent and services when roaming in and attached to an > IPv4 access network." > It makes sense to focus on just this one scenario and solve > the problem immediately. > > The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of > a MIPv6 mobile node or a NEMO mobile router roaming onto a > IPv4 only access network in a simple manner. > It is intended that the standardization of this solution in the IETFs > MIP6 and/or NEMO working groups proceed. The working group > chairs have reviewed and discussed this work item. It has > also been presented at the MIP6 and NEMO WGs at IETF62. > > The chairs would like to hear your thoughts in order to see > if there is consensus to make it a WG document and progress > it as a standards track RFC. Comments should be sent to both > the NEMO and MIP6 WGs. > > If we have consensus, then the document will be pursued as a > dual WG item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > For [ ] > Against [ ] > > > - MIP6 and NEMO WG chairs > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 12:25:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18678 for ; Fri, 1 Apr 2005 12:25:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQ0p-0003PD-1F for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 12:32:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPtA-0007DW-FQ; Fri, 01 Apr 2005 12:24:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPt9-0007DJ-1Q; Fri, 01 Apr 2005 12:24:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18622; Fri, 1 Apr 2005 12:24:52 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQ0U-0003Ng-GO; Fri, 01 Apr 2005 12:32:32 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j31HOYc20570; Fri, 1 Apr 2005 20:24:34 +0300 Date: Fri, 1 Apr 2005 20:24:34 +0300 (EEST) From: Pekka Savola To: "Pascal Thubert (pthubert)" Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCAD82EF@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FCAD82EF@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Fri, 1 Apr 2005, Pascal Thubert (pthubert) wrote: > Even better would be that this "box in the DMZ" terminates V4, and sends > packets to the HA in IPv6. Say, doing some NAT-PT instead of tunneling, > classical alternates. Please, don't even consider translation. You may be interested of the following: "Reasons to Move NAT-PT to Experimental" draft-ietf-v6ops-natpt-to-exprmntl-00 AFAIK, that has just recently been forwarded to the IESG for processing. > Seems to me that the line if thought that starts at your "box in the > DMZ" ends up being With Doors. > > With Doors, the "box in the DMZ" is the Doors gateway between IPv4 and > IPv6. Doors does not solve the problem if the strict requirement is avoiding "extra" encapsulation, right? (I may not buy that requirement myself, but we should at least get to consensus whether it's one or not.) Doors is basically Yet Another v6-in-v4 Tunnelbroker (albeit stateless) Solution, AFAICS. If we go down that path, maybe it would be worth using the already specified, implemented and deployed mechanisms, or create one ourselves (there was a Tunnel Configuration BOF at the last IETF.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 12:46:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20411 for ; Fri, 1 Apr 2005 12:46:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQLR-0004BO-If for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 12:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQ8h-0002ep-S0; Fri, 01 Apr 2005 12:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQ8g-0002eh-6g; Fri, 01 Apr 2005 12:40:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20084; Fri, 1 Apr 2005 12:40:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQG3-00042V-2c; Fri, 01 Apr 2005 12:48:35 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 01 Apr 2005 09:40:48 -0800 Received: from alpeshw2k03 (dhcp-128-107-178-187.cisco.com [128.107.178.187]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j31HekgS014055; Fri, 1 Apr 2005 09:40:47 -0800 (PST) Message-Id: <200504011740.j31HekgS014055@sj-core-3.cisco.com> From: "Alpesh" To: , , Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Date: Fri, 1 Apr 2005 09:40:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQAATIhLA= X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Raj: If you are seeking a re-vote on this: 1. Agree - vote YES 2. NO to starting with a presumed base. Looking at the discussion and position being taken, I would prefer to start with a clean slate as a base. Definitely, this implies that all inputs should be weighed in judiciously. -a > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > Behalf Of Basavaraj.Patil@nokia.com > Sent: Friday, April 01, 2005 7:41 AM > To: mip6@ietf.org; nemo@ietf.org > Subject: RE: [Mip6] Consensus call on making ID > draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document > > > A couple of clarifications regarding the consensus call: > > 1. The intention is to address the following scenario: > "MIPv6 and NEMO capable Mobile hosts/routers attaching to an > IPv4 access network need the capability to create a tunnel > and be connected to their MIP6 home agents." > This is the scenario that is most applicable for MIP6 deployment. > There are plenty of other scenarios as well. But they are > much more of academic interest at this time and hence not > really in the scope of this discussion. So I would suggst > that we do not go off on a tangent discussing all these other > scenarios. > > Do you agree/disagree that the above scenario is the one that > needs to be solved ASAP? > (Note: It does not imply that other scenarios are irrelevant. > It simply means that this is the scenario worth working on > and has the most significant priority or value for MIP6 deployment.) > > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the > baseline. It does not imply that we are ruling out > draft-soliman-v4v6-mipv6 or any other. The IDs can be > combined w.r.t the parts that address this scenario. > Additionally once it is a WG document, what goes into the ID > is decided by the WG. So lets not get into arguments of what > or whose draft is the one that should be made the WG document. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 12:47:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20515 for ; Fri, 1 Apr 2005 12:47:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQMn-0004G5-Rl for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 12:55:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQCf-0002vC-Jq; Fri, 01 Apr 2005 12:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQCc-0002tO-UD; Fri, 01 Apr 2005 12:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20346; Fri, 1 Apr 2005 12:45:00 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQJy-00049y-Rc; Fri, 01 Apr 2005 12:52:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2005 09:44:52 -0800 X-IronPort-AV: i="3.91,141,1110182400"; d="scan'208"; a="625079417:sNHT560487066" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j31HiogF025597; Fri, 1 Apr 2005 09:44:50 -0800 (PST) Date: Fri, 1 Apr 2005 09:44:50 -0800 (PST) From: Sri Gundavelli To: Basavaraj.Patil@nokia.com Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> Message-ID: References: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Raj, We do want to solve the IPv4 traversal, however NAT/PAT traversal support is the critical requirement for that. Based on our Mobile IPv4 deployment experience, we have seen lot of interest for NAT Traversal and MIPv4 WG standardised on RFC 3519. The same requirement is central to the problem statement here. On your question, if we can adopt draft-wakikawa-nemo-v4tunnel as the basis for the solution, my answer to that is "NO". There are other solution documents out there and we need to review them as well. Regards. Sri On Fri, 1 Apr 2005 Basavaraj.Patil@nokia.com wrote: > > A couple of clarifications regarding the consensus call: > > 1. The intention is to address the following scenario: > "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 > access network need the capability to create a tunnel and be connected > to their MIP6 home agents." > This is the scenario that is most applicable for MIP6 deployment. > There are plenty of other scenarios as well. But they are much more > of academic interest at this time and hence not really in the scope > of this discussion. So I would suggst that we do not go off on a tangent > discussing all these other scenarios. > > Do you agree/disagree that the above scenario is the one that needs > to be solved ASAP? > (Note: It does not imply that other scenarios are irrelevant. It simply > means that this is the scenario worth working on and has the most > significant priority or value for MIP6 deployment.) > > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It > does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any > other. The IDs can be combined w.r.t the parts that address this scenario. > Additionally once it is a WG document, what goes into the ID is decided > by the WG. So lets not get into arguments of what or whose draft is the > one that should be made the WG document. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 13:07:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22604 for ; Fri, 1 Apr 2005 13:07:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQfO-00058s-8n for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 13:14:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQVc-00075i-B2; Fri, 01 Apr 2005 13:04:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQVa-00075a-7p; Fri, 01 Apr 2005 13:04:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22475; Fri, 1 Apr 2005 13:04:35 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQcw-00053V-Bn; Fri, 01 Apr 2005 13:12:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2005 10:03:59 -0800 X-IronPort-AV: i="3.91,141,1110182400"; d="scan'208"; a="625088265:sNHT5651333394" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j31I3ugF013136; Fri, 1 Apr 2005 10:03:57 -0800 (PST) Date: Fri, 1 Apr 2005 10:03:56 -0800 (PST) From: Sri Gundavelli To: Pekka Savola Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FCAD82EF@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nemo@ietf.org, mip6@ietf.org, "Pascal Thubert \(pthubert\)" , Vijay Devarapalli , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Fri, 1 Apr 2005, Pekka Savola wrote: > On Fri, 1 Apr 2005, Pascal Thubert (pthubert) wrote: > > Even better would be that this "box in the DMZ" terminates V4, and sends > > packets to the HA in IPv6. Say, doing some NAT-PT instead of tunneling, > > classical alternates. > > Please, don't even consider translation. > > You may be interested of the following: > > "Reasons to Move NAT-PT to Experimental" > draft-ietf-v6ops-natpt-to-exprmntl-00 > > AFAIK, that has just recently been forwarded to the IESG for > processing. > > > Seems to me that the line if thought that starts at your "box in the > > DMZ" ends up being With Doors. > > > > With Doors, the "box in the DMZ" is the Doors gateway between IPv4 and > > IPv6. > > Doors does not solve the problem if the strict requirement is avoiding > "extra" encapsulation, right? (I may not buy that requirement myself, > but we should at least get to consensus whether it's one or not.) > Hi Pekka, I agree with you that saving the extra encap should not be the central focus. If saving few bytes is of paramount interest, there are header compression techniques that we can apply to doors. Choosing a solution by basing this as the central argument is not right. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 15:00:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00686 for ; Fri, 1 Apr 2005 15:00:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSR0-0000fq-Us for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 15:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSFp-0007Ds-56; Fri, 01 Apr 2005 14:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSFk-0007Dj-Ub for mip6@megatron.ietf.org; Fri, 01 Apr 2005 14:56:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00458 for ; Fri, 1 Apr 2005 14:56:21 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSN8-0000Yk-Rf for mip6@ietf.org; Fri, 01 Apr 2005 15:04:03 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j31KPkJ30883; Fri, 1 Apr 2005 12:25:46 -0800 X-mProtect: <200504012025> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdRaMGpf; Fri, 01 Apr 2005 12:25:44 PST Message-ID: <424DA74C.4000204@iprg.nokia.com> Date: Fri, 01 Apr 2005 11:55:56 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org Subject: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit hi Gerardo, thanks for the review. Gerardo Giaretta wrote: > Hi Vijay, > > I have some comments on draft-ietf-mip6-ikev2-ipsec-01. > > Overall, the draft looks good. In my opinion, the unique general issue > is that it is tied very much to rfc 3776 and as a result it is not > self-contained. I mean that it is not possible to read the draft without > having also rfc3776 in front of you. This is ok to me, but I wonder if > it is acceptable in general. I guess it can be difficult. I was worried about this too, but didnt want repeat all the requirements. will ask the working group about this. > Some more detailed comments: > > - section 3.2: I don't understand very well how this list should be > read. The draft states: "The mobile node and the Home Agent MUST support > the requirements listed in Section 4 of RFC 3776 with the following > exceptions" (btw, s/support/fulfill). I'd expect a clear reference to > requirements in rfc3776, but I found sometimes difficult to match the > requirements and to understand what really changes. Isn't much clearer > to state all the requirements (old and new ones)? More details below. > > - section 3.2, bullet 1: in order to be more adherent to rfc 3776, I'd > say "It is not required to configure security policies security policy > database entries specifically for the tunnel interface in order to > protect return routability signaling messages". okay. > - section 3.2, bullet 2: how is this requirement different from the one > specified in rfc 3776 (4th bullet page at page 12)? Could you clarify > please? the text on dynamic keying part has changed. for IKEv1 we talk about Phase 1. for IKEv2, we talk about IKE_AUTH exchange. but we cant just state that. need to explain why the HA needs to check if the identity presented in IKE_AUTH exchange is allowed to create security associations for a particular home address. suggestions to improve this are welcome. > > - section 3.2, bullet 3: maybe I am missing something here, but how this > is different from IKEv1 and rfc 3776? not different. I see the problem very well now. some requirements I am repeating from 3776. will fix this, based on what the working group decides. > - section 5.1.1, last paragraph at page 11: "In the examples shown > above, the home address of the mobile node might not be available all > the time." Are you referring to the case where the HoA is dynamically > allocated? If yes, I'd mention it at least as an example. yes. > Moreover, the draft continues: "When the mobile node acquires a new home > address, it must add the address to the corresponding SPD entries." What > about the HA? Does the HA need to add the address to the corresponding > SPD entries or can it keep generic entries? I think it should add the > HoA in SPD entries. no. if the MN initiates IKE exchange, the HA can just populate the SPD from the IKE exchange. it doesnt need to create a SPD entry for a specific HoA. > - section 7: this section refers to dynamic HoA assignment. I wonder if > this procedure should be explained in this document or in the > bootstrapping document. Maybe the latter, if needed, can simply point to > this one. I prefer the bootstrapping document just pointing to this section for HoA configuration. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 15:08:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01567 for ; Fri, 1 Apr 2005 15:08:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSYk-0000wX-CJ for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 15:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSQ8-0008Eg-2C; Fri, 01 Apr 2005 15:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSQ6-0008Eb-Ns for mip6@megatron.ietf.org; Fri, 01 Apr 2005 15:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01440 for ; Fri, 1 Apr 2005 15:07:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSXU-0000s8-69 for mip6@ietf.org; Fri, 01 Apr 2005 15:14:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j31KaYa06589; Fri, 1 Apr 2005 12:36:34 -0800 X-mProtect: <200504012036> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpd660YE8; Fri, 01 Apr 2005 12:36:32 PST Message-ID: <424DA9D4.8060001@iprg.nokia.com> Date: Fri, 01 Apr 2005 12:06:44 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Gopal Dommety , "Basavaraj.Patil@nokia.com" Subject: [Mip6] Issue list for MIPv6 and IKEv2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit hello all, I have created an online list of issues for draft-ietf-mip6-ikev2-ipsec. http://people.nokia.net/vijayd/mipsec/issues.html. one can open new issues by sending a mail to the WG mailing list. I would like to hear WG opinion on Issue 1. currently, the draft makes a lot of references to RFC 3776, especially with respect to requirements on the MN and the HA. I seemed to have repeated a few too. my intention was to only list exceptions and new requirements in this draft. there are pros and cons. a lot of work went into RFC 3776 to come up with a set of requirements that make sense. if we attempt to list them in this draft, we might end in a state where the requirements in the draft conflict with the requirements in RFC 3776. since we already have an RFC we can refer to, no reason to repeat the text. OTOH, it makes this draft self contained without having to refer to RFC 3776 for the requirements. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 15:22:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05474 for ; Fri, 1 Apr 2005 15:22:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSmJ-0001Tr-SL for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 15:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHScW-0001i7-GA; Fri, 01 Apr 2005 15:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHScU-0001hi-JI for mip6@megatron.ietf.org; Fri, 01 Apr 2005 15:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05129 for ; Fri, 1 Apr 2005 15:19:50 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSjr-0001QD-Nc for mip6@ietf.org; Fri, 01 Apr 2005 15:27:33 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31KJnp08914; Fri, 1 Apr 2005 23:19:49 +0300 (EET DST) X-Scanned: Fri, 1 Apr 2005 23:19:28 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j31KJS7V013353; Fri, 1 Apr 2005 23:19:28 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00H7gPVy; Fri, 01 Apr 2005 23:19:27 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31KJPM16294; Fri, 1 Apr 2005 23:19:26 +0300 (EET DST) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Apr 2005 14:19:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2005 14:19:21 -0600 Message-ID: <456943D540CFC14A8D7138E64843F8535BAD63@daebe101.NOE.Nokia.com> Thread-Topic: Issue list for MIPv6 and IKEv2 Thread-Index: AcU29mhrMeF5oJfRTcy7XpmDn2oibQAAYkLg To: , X-OriginalArrivalTime: 01 Apr 2005 20:19:21.0195 (UTC) FILETIME=[16C86BB0:01C536F8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com Subject: [Mip6] RE: Issue list for MIPv6 and IKEv2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Vijay, You should be using the issue tracker at: http://www.mip4.org/issues/tracker/mip6/ That is the location for dealing with issues related to WG IDs. Please use the above issue tracker for I-D: draft-ietf-mip6-ikev2-ipsec -Basavaraj > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, April 01, 2005 2:07 PM > To: mip6@ietf.org > Cc: Patil Basavaraj (Nokia-NET/Dallas); Gopal Dommety > Subject: Issue list for MIPv6 and IKEv2 >=20 >=20 > hello all, >=20 > I have created an online list of issues for=20 > draft-ietf-mip6-ikev2-ipsec.=20 > http://people.nokia.net/vijayd/mipsec/issues.html. > one can open new issues by sending a mail to the WG mailing list. >=20 > I would like to hear WG opinion on Issue 1. currently, the=20 > draft makes a=20 > lot of references to RFC 3776, especially with respect to=20 > requirements=20 > on the MN and the HA. I seemed to have repeated a few too. my=20 > intention=20 > was to only list exceptions and new requirements in this draft. >=20 > there are pros and cons. a lot of work went into RFC 3776 to come up=20 > with a set of requirements that make sense. if we attempt to=20 > list them=20 > in this draft, we might end in a state where the requirements in the=20 > draft conflict with the requirements in RFC 3776. since we=20 > already have=20 > an RFC we can refer to, no reason to repeat the text. >=20 > OTOH, it makes this draft self contained without having to=20 > refer to RFC=20 > 3776 for the requirements. >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 15:54:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15012 for ; Fri, 1 Apr 2005 15:54:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTHo-00059Y-EF for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 16:02:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT2H-0002Nb-CC; Fri, 01 Apr 2005 15:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT2E-0002Mq-Qi; Fri, 01 Apr 2005 15:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12262; Fri, 1 Apr 2005 15:46:26 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHT9c-0003v7-Sk; Fri, 01 Apr 2005 15:54:09 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 15:46:16 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2005 15:46:16 -0500 Message-ID: Thread-Topic: [nemo] Re: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2SEWgD4Xn2EWvRfqaodUBv14I0gAera6AAA2pKYA= From: "Soliman, Hesham" To: , , "Vijay Devarapalli" , "Henrik Levkowetz" , X-OriginalArrivalTime: 01 Apr 2005 20:46:16.0299 (UTC) FILETIME=[D975BBB0:01C536FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Mip6] transition issues X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Folks,=20 Sorry for the late reply, I've been trying to catch up with the concensus thread as I've been travelling.=20 I think there are a number of issues there and the discussion seems to confuse those issues. draf-wakikawa is only addressing one scenario and should not be seen as _the_ transition solution. I think that would be a mistake.=20 But let's take a step back, draft-larsson has outlined basically all scenarios that might exist. Before we make a WG draft, shouldn't we discuss what scenarios we want to address? and why? If we decide=20 on the scenarios, then draft-wakikawa might be included as one tool, that is part of the overall solution.=20 Personally, I see no reason for having another MIP-based traveral=20 solution, and I'll explain why. There are already multiple NAT traversal solutions that are not=20 specific to MIP. And there are others based on MIPv4. when it comes to enabling IPv6 in a private IPv4 cloud, I think it makes sense to used MIPv4 with its built-in traversal techniques. In this case,=20 I think draft-tsirtsis makes sense, or another draft along the same=20 lines.=20 If you want to use MIPv6 only, then there are two cases:=20 A. MIP6 only through a private IPv4 network B. MIP6 only through a public v4 or DS network Personally, I'm not interested in solving scenario A and I think it's questionable whether it makes any sense in a cellular network. This is because it involves keepalives which pretty much eliminates dormancy and chews battery lifetime. Others might see a need in = non-cellular networks, that's fine, but I wonder why not rely on any other VPN = technology for those scenarios. Basically, I don't see the practical need for this solution. However, I'm not interested in blocking it. So, _if_ there is agreement on the need for draft-wakikawa then we=20 need to be clear that it is not a complete solution. Given the absence of a detailed scenarios discussion I feel that this discussion is = ill-informed.=20 If there is a concensus call now, I'd vote NO. Simply because if we want to address transition issues, this should not be the first scenario to address. I have other comments on the way it's solved too, but this is = not the right email for them.=20 Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 16:05:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18208 for ; Fri, 1 Apr 2005 16:05:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTRZ-0006M8-7H for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 16:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTFn-0000Yt-4L; Fri, 01 Apr 2005 16:00:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTFi-0000Xh-OO; Fri, 01 Apr 2005 16:00:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16884; Fri, 1 Apr 2005 16:00:24 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTN7-0005qW-GI; Fri, 01 Apr 2005 16:08:05 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 16:00:17 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Date: Fri, 1 Apr 2005 16:00:17 -0500 Message-ID: Thread-Topic: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Thread-Index: AcU2HzAt/9qCl3SgS1Ssy/x7BEwdBgA3kU6g From: "Soliman, Hesham" To: "Vijay Devarapalli" , "Gerardo Giaretta" X-OriginalArrivalTime: 01 Apr 2005 21:00:17.0841 (UTC) FILETIME=[CF0EDA10:01C536FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable > okay. draft-soliman-v4v6 deals with lots of scenarios including > scenario 1) and 2) above. draft-wakikawa talks only about=20 > scenario 1). > the idea of binding an IPv4 CoA to an IPv6 HoA is very old. > draft-soliman is not the first one that spoke about it.=20 =3D> As a side note, for my own research, Vijay, I'd appreciate a = pointer to some prior art in this area. I don't believe Doors does that binding. Doors does something different. thx, Hesham > draft-wakikawa > just explains in *very* detail how to do scenario 1), including a new > mobility option, MN and HA operation to process this new mobility > option, IPsec SPD and SAD entries for securing the IPv6-over-IPv4 > tunnel, NAT traversal, how to negotiate a particular tunneling > mechanism and new binding ack status values. >=20 > > The main difference is the BU message > > format: based on draft-wakikawa the source address of the=20 > IPv6 packet is > > the HoA, since the message is treated as a particular=20 > de-registration; > > in draft-soliman the source address is the CoAv4 mapped in=20 > IPv6 address > > format. I'd like to understand better the rationale behind=20 > the choice in > > draft-wakikawa. Personally, I think that the approach of=20 > draft-soliman > > is a little bit cleaner since the BU is not considered a=20 > de-registration > > message.=20 >=20 > hmm.. but you want to remove any existing binding cache entries that > bind the IPv6 HoA to an IPv6 CoA, right? we are just combining > removing an existing BCE with IPv6 CoA and adding a new BCE with IPv4 > CoA. >=20 > Vijay >=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 16:05:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18238 for ; Fri, 1 Apr 2005 16:05:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTRe-0006Mc-E0 for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 16:12:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTD9-0007Yl-59; Fri, 01 Apr 2005 15:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTD7-0007YZ-W2; Fri, 01 Apr 2005 15:57:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15983; Fri, 1 Apr 2005 15:57:44 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTKW-0005Vr-Nx; Fri, 01 Apr 2005 16:05:24 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 15:57:37 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Fri, 1 Apr 2005 15:57:36 -0500 Message-ID: Thread-Topic: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQAAuhshA= From: "Soliman, Hesham" To: , , X-OriginalArrivalTime: 01 Apr 2005 20:57:37.0183 (UTC) FILETIME=[6F4C62F0:01C536FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > Do you agree/disagree that the above scenario is the one that needs > to be solved ASAP? =3D> I agree. > (Note: It does not imply that other scenarios are=20 > irrelevant. It simply > means that this is the scenario worth working on and has the most=20 > significant priority or value for MIP6 deployment.) >=20 > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It > does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any > other.=20 =3D> I don't see how it doesn't imply that. I think we should agree on the scenario first, without associating it with either draft-wakikawa or draft-soliman. Once we agreed, we can discuss how to solve the=20 problem. I disagree with making draft-wakikawa a baseline.=20 Hesham The IDs can be combined w.r.t the parts that address=20 > this scenario. > Additionally once it is a WG document, what goes into the ID=20 > is decided > by the WG. So lets not get into arguments of what or whose=20 > draft is the > one that should be made the WG document. >=20 > -Basavaraj >=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 16:44:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24978 for ; Fri, 1 Apr 2005 16:44:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHU3Q-0000dG-G1 for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 16:51:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHToM-0000RN-Ax; Fri, 01 Apr 2005 16:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHToL-0000RA-Aa for mip6@megatron.ietf.org; Fri, 01 Apr 2005 16:36:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23835 for ; Fri, 1 Apr 2005 16:36:11 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTvi-000072-TH for mip6@ietf.org; Fri, 01 Apr 2005 16:43:52 -0500 Message-ID: <08d701c53702$f8d83b70$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" , References: <424DA9D4.8060001@iprg.nokia.com> Subject: Re: [Mip6] Issue list for MIPv6 and IKEv2 Date: Fri, 1 Apr 2005 13:37:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Gopal Dommety , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Vijay, Given the antiquated state of IETF's electronic publication technology (early 1980's vintage), I think it makes sense to have the draft be more self-contained. Now if we had hyperlinked documents for RFCs like the rest of the world... jak ----- Original Message ----- From: "Vijay Devarapalli" To: Cc: "Gopal Dommety" ; Sent: Friday, April 01, 2005 12:06 PM Subject: [Mip6] Issue list for MIPv6 and IKEv2 > hello all, > > I have created an online list of issues for draft-ietf-mip6-ikev2-ipsec. > http://people.nokia.net/vijayd/mipsec/issues.html. > one can open new issues by sending a mail to the WG mailing list. > > I would like to hear WG opinion on Issue 1. currently, the draft makes a > lot of references to RFC 3776, especially with respect to requirements > on the MN and the HA. I seemed to have repeated a few too. my intention > was to only list exceptions and new requirements in this draft. > > there are pros and cons. a lot of work went into RFC 3776 to come up > with a set of requirements that make sense. if we attempt to list them > in this draft, we might end in a state where the requirements in the > draft conflict with the requirements in RFC 3776. since we already have > an RFC we can refer to, no reason to repeat the text. > > OTOH, it makes this draft self contained without having to refer to RFC > 3776 for the requirements. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 17:32:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28261 for ; Fri, 1 Apr 2005 17:32:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUoJ-0002JJ-E4 for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 17:40:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUfX-0003Cg-TI; Fri, 01 Apr 2005 17:31:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUfW-0003Bf-Da for mip6@megatron.ietf.org; Fri, 01 Apr 2005 17:31:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28208 for ; Fri, 1 Apr 2005 17:31:07 -0500 (EST) Received: from av9-2-sn4.m-sp.skanova.net ([81.228.10.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUmu-0002Ek-Gh for mip6@ietf.org; Fri, 01 Apr 2005 17:38:49 -0500 Received: by av9-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0191F37E51; Sat, 2 Apr 2005 00:30:54 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av9-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id E731937E42 for ; Sat, 2 Apr 2005 00:30:54 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id CADD837E44 for ; Sat, 2 Apr 2005 00:30:54 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DHUfF-0005mn-Au for mip6@ietf.org; Sat, 02 Apr 2005 00:30:54 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Fri, 01 Apr 2005 22:30:53 +0000 MIME-Version: 1.0 Message-Id: <1112394653.29.0.86575240771.issue15@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue15] Dynamic HoA and SPD entries X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable New submission from Vijay Devarapalli : Gerardo Giaretta wrote: - section 5.1.1, last paragraph at page 11: "In the examples shown above, the home address of the mobile node might not be available all the time." Are you referring to the case where the HoA is dynamically allocated? If yes, I'd mention it at least as an example.=20 Moreover, the draft continues: "When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries." What about the HA? Does the HA need to add the address to the corresponding SPD entries or can it keep generic entries? I think it should add the HoA in SPD entries. --------------------------------------------------------------------------- Vijay Devarapalli wrote: > - section 5.1.1, last paragraph at page 11: "In the examples shown > above, the home address of the mobile node might not be available all > the time." Are you referring to the case where the HoA is dynamically > allocated? If yes, I'd mention it at least as an example.=20 yes. > Moreover, the draft continues: "When the mobile node acquires a new home > address, it must add the address to the corresponding SPD entries." What > about the HA? Does the HA need to add the address to the corresponding > SPD entries or can it keep generic entries? I think it should add the > HoA in SPD entries. no. if the MN initiates IKE exchange, the HA can just populate the=20 SPD from the IKE exchange. it doesnt need to create a SPD entry for=20 a specific HoA.=20 --------------------------------------------------------------------------- ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 51 nosy: vijay priority: Must fix status: Pending title: Dynamic HoA and SPD entries _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 17:37:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28710 for ; Fri, 1 Apr 2005 17:37:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUsw-0002TK-5i for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 17:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUiL-0003Y9-7b; Fri, 01 Apr 2005 17:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUiJ-0003Y4-VB for mip6@megatron.ietf.org; Fri, 01 Apr 2005 17:34:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28406 for ; Fri, 1 Apr 2005 17:34:01 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHUpi-0002LV-Bf for mip6@ietf.org; Fri, 01 Apr 2005 17:41:43 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j31N3TK26836; Fri, 1 Apr 2005 15:03:29 -0800 X-mProtect: <200504012303> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdcl83jc; Fri, 01 Apr 2005 15:03:27 PST Message-ID: <424DCC43.8020304@iprg.nokia.com> Date: Fri, 01 Apr 2005 14:33:39 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] RE: Issue list for MIPv6 and IKEv2 References: <456943D540CFC14A8D7138E64843F8535BAD63@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD63@daebe101.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: gdommety@cisco.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit okay. the issues list for draft-ietf-mip6-ikev2-ipsec is now at http://www.mip4.org/issues/tracker/mip6/ please remove your bookmarks for the URL I sent earlier. :) Vijay Basavaraj.Patil@nokia.com wrote: > Vijay, > > You should be using the issue tracker at: > http://www.mip4.org/issues/tracker/mip6/ > > That is the location for dealing with issues related to WG IDs. > Please use the above issue tracker for I-D: draft-ietf-mip6-ikev2-ipsec > > -Basavaraj > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Friday, April 01, 2005 2:07 PM >>To: mip6@ietf.org >>Cc: Patil Basavaraj (Nokia-NET/Dallas); Gopal Dommety >>Subject: Issue list for MIPv6 and IKEv2 >> >> >>hello all, >> >>I have created an online list of issues for >>draft-ietf-mip6-ikev2-ipsec. >>http://people.nokia.net/vijayd/mipsec/issues.html. >>one can open new issues by sending a mail to the WG mailing list. >> >>I would like to hear WG opinion on Issue 1. currently, the >>draft makes a >>lot of references to RFC 3776, especially with respect to >>requirements >>on the MN and the HA. I seemed to have repeated a few too. my >>intention >>was to only list exceptions and new requirements in this draft. >> >>there are pros and cons. a lot of work went into RFC 3776 to come up >>with a set of requirements that make sense. if we attempt to >>list them >>in this draft, we might end in a state where the requirements in the >>draft conflict with the requirements in RFC 3776. since we >>already have >>an RFC we can refer to, no reason to repeat the text. >> >>OTOH, it makes this draft self contained without having to >>refer to RFC >>3776 for the requirements. >> >>Vijay >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 17:59:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00027 for ; Fri, 1 Apr 2005 17:59:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVEf-0003DO-HF for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 18:07:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHV5A-000878-Q0; Fri, 01 Apr 2005 17:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHV58-000873-QX for mip6@megatron.ietf.org; Fri, 01 Apr 2005 17:57:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29853 for ; Fri, 1 Apr 2005 17:57:36 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVCY-00037b-Ch for mip6@ietf.org; Fri, 01 Apr 2005 18:05:18 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j31NR1n10752; Fri, 1 Apr 2005 15:27:01 -0800 X-mProtect: <200504012327> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdbc29Hg; Fri, 01 Apr 2005 15:27:00 PST Message-ID: <424DD1C7.4000007@iprg.nokia.com> Date: Fri, 01 Apr 2005 14:57:11 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <424DA74C.4000204@iprg.nokia.com> In-Reply-To: <424DA74C.4000204@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit hi Gerardo, >> - section 5.1.1, last paragraph at page 11: "In the examples shown >> above, the home address of the mobile node might not be available all >> the time." Are you referring to the case where the HoA is dynamically >> allocated? If yes, I'd mention it at least as an example. > > > yes. > >> Moreover, the draft continues: "When the mobile node acquires a new home >> address, it must add the address to the corresponding SPD entries." What >> about the HA? Does the HA need to add the address to the corresponding >> SPD entries or can it keep generic entries? I think it should add the >> HoA in SPD entries. > > > no. if the MN initiates IKE exchange, the HA can just populate the > SPD from the IKE exchange. it doesnt need to create a SPD entry for > a specific HoA. here is some new text. In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might have not configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address. The SPD entries on the home agent are created when the mobile node initiates IKE exchange. The home agent can also have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. does this look good? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 18:37:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04020 for ; Fri, 1 Apr 2005 18:37:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVpK-0004TA-NM for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 18:45:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVg9-0006gP-UB; Fri, 01 Apr 2005 18:35:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVg8-0006gF-FQ for mip6@megatron.ietf.org; Fri, 01 Apr 2005 18:35:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03937 for ; Fri, 1 Apr 2005 18:35:49 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVnY-0004Od-Am for mip6@ietf.org; Fri, 01 Apr 2005 18:43:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3205K306113 for ; Fri, 1 Apr 2005 16:05:20 -0800 X-mProtect: <200504020005> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdlW4RO6; Fri, 01 Apr 2005 16:05:18 PST Message-ID: <424DDAC2.1050802@iprg.nokia.com> Date: Fri, 01 Apr 2005 15:35:30 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Mip6] draft-soliman and draft-wakikawa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Gerardo, Keiichi, Hesham and Henrik, draft-soliman and draft-wakikawa both talk about binding a v4 CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between the MN and the HA. the difference is in the way, the CoA is conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 address as the source address in the inner header. I believe the packet format looks like the following. IPv4 hdr (src=CoA_v4, dst=HA_v4) IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) Dst opts hdr HoA_v6 Mobility hdr Binding Update Hesham, let me know if this is not correct? the HA extracts the IPv4 address from the v4-mapped-v6-CoA. draft-wakikawa uses a mobility option for carrying the IPv4 address. IPv4 hdr (src=CoA_v4, dst=HA_v4) IPv6 hdr (src=HoA_v6, dst=HA_v6) Mobility hdr Binding Update IPv4 CoA mobility option this is the main difference. apart from this, is there is anything else in draft-soliman that you think is important for the specific scenario we are talking about (v6 MN/MR accessing v6 HA from a v4 only access network). draft-wakikawa, OTOH, also talks about the following. detailed MN and HA behavior, IPsec SPD and SAD entries for securing the IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a particular tunneling mechanism and new binding ack status values. personally, I prefer a new mobility option to carry the IPv4 CoA, because it makes processing on the HA simple. but we can have the WG decide on this. I am open. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 18:53:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04836 for ; Fri, 1 Apr 2005 18:53:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHW4m-0004yd-Sc for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:01:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVwk-0001Yh-LU; Fri, 01 Apr 2005 18:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVwi-0001YH-57 for mip6@megatron.ietf.org; Fri, 01 Apr 2005 18:53:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04821 for ; Fri, 1 Apr 2005 18:52:57 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHW48-0004wr-6w for mip6@ietf.org; Fri, 01 Apr 2005 19:00:40 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 18:52:51 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Fri, 1 Apr 2005 18:52:50 -0500 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU3FQdIYwv5l9QfQdegpsmIerZWAQAAC00w From: "Soliman, Hesham" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 01 Apr 2005 23:52:51.0013 (UTC) FILETIME=[EA078750:01C53715] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Vijay,=20 I've expressed my opinion on the genreal issue before. Regarding this topic of comparison, I don't think the=20 difference you expressed is worth writing new drafts about. It would be much easier if you just suggest this to us and we would discuss it. Instead, now we end up with discussing very similar drafts for no apparent reason, which takes more cycles. I respect your right to write a new draft about whatever you want. But for such a small differemce, you were welcome to send a comment and discuss it... FWIW I prefer not introducing a new option, the current approach in draft-soliman fits easily within an implementation as Conny already explained. Anyway, this is a secondary issue and something that can be fine tuned much later in the process. Hesham > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On=20 > Behalf Of > Vijay Devarapalli > Sent: Friday, April 01, 2005 6:36 PM > To: mip6@ietf.org > Subject: [Mip6] draft-soliman and draft-wakikawa >=20 >=20 > Gerardo, Keiichi, Hesham and Henrik, >=20 > draft-soliman and draft-wakikawa both talk about binding a v4 > CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > the MN and the HA. the difference is in the way, the CoA is > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > address as the source address in the inner header. I believe > the packet format looks like the following. >=20 > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > Dst opts hdr > HoA_v6 > Mobility hdr > Binding Update >=20 > Hesham, let me know if this is not correct? >=20 > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. >=20 > draft-wakikawa uses a mobility option for carrying the IPv4 > address. >=20 > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > Mobility hdr > Binding Update > IPv4 CoA mobility option >=20 > this is the main difference. >=20 > apart from this, is there is anything else in draft-soliman > that you think is important for the specific scenario we are > talking about (v6 MN/MR accessing v6 HA from a v4 only access > network). >=20 > draft-wakikawa, OTOH, also talks about the following. detailed > MN and HA behavior, IPsec SPD and SAD entries for securing the > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > particular tunneling mechanism and new binding ack status > values. >=20 > personally, I prefer a new mobility option to carry the IPv4 > CoA, because it makes processing on the HA simple. but we can > have the WG decide on this. I am open. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 19:03:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05329 for ; Fri, 1 Apr 2005 19:03:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWDx-0005H8-1t for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:10:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHW6N-0003EE-Be; Fri, 01 Apr 2005 19:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHW6L-0003E6-Ik for mip6@megatron.ietf.org; Fri, 01 Apr 2005 19:02:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05319 for ; Fri, 1 Apr 2005 19:02:54 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWDl-0005Go-V9 for mip6@ietf.org; Fri, 01 Apr 2005 19:10:38 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 19:02:48 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Fri, 1 Apr 2005 19:02:48 -0500 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU3FQdIYwv5l9QfQdegpsmIerZWAQAAa1hg From: "Soliman, Hesham" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 02 Apr 2005 00:02:48.0849 (UTC) FILETIME=[4E5E1010:01C53717] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable More specific response: > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > Dst opts hdr > HoA_v6 > Mobility hdr > Binding Update >=20 > Hesham, let me know if this is not correct? =3D> Correct in the scenario you mentioned. This draft also supports another scenario: using IPv4 home address and IPv6 CoA. This is very practical if you want to use=20 MIPv6 all the time while having a DS host. >=20 > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. >=20 > draft-wakikawa uses a mobility option for carrying the IPv4 > address. >=20 > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > Mobility hdr > Binding Update > IPv4 CoA mobility option >=20 > this is the main difference. >=20 > apart from this, is there is anything else in draft-soliman > that you think is important for the specific scenario we are > talking about (v6 MN/MR accessing v6 HA from a v4 only access > network). =3D> The ToCs are nearly identical with the exception of the=20 section talking about NAT traversal. This is actually not useful in draft wakikawa. Anything that talks about NAT traveral without keepalives is not useful. draft-soliman intentionally does not talk about NAT traversal. The idea was that if NAT traversal is needed it should be used optionally on top. We can discuss reasons for that if you want. Hesham >=20 > draft-wakikawa, OTOH, also talks about the following. detailed > MN and HA behavior, IPsec SPD and SAD entries for securing the > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > particular tunneling mechanism and new binding ack status > values. >=20 > personally, I prefer a new mobility option to carry the IPv4 > CoA, because it makes processing on the HA simple. but we can > have the WG decide on this. I am open. >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 19:41:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07301 for ; Fri, 1 Apr 2005 19:41:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWp0-0006Tk-5i for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWgS-0000eJ-Vp; Fri, 01 Apr 2005 19:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWgQ-0000eE-PK for mip6@megatron.ietf.org; Fri, 01 Apr 2005 19:40:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07195 for ; Fri, 1 Apr 2005 19:40:11 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWnp-0006PI-8L for mip6@ietf.org; Fri, 01 Apr 2005 19:47:55 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3219do09046; Fri, 1 Apr 2005 17:09:39 -0800 X-mProtect: <200504020109> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdPxrvai; Fri, 01 Apr 2005 17:09:36 PST Message-ID: <424DE9D4.60203@iprg.nokia.com> Date: Fri, 01 Apr 2005 16:39:48 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hesham, Soliman, Hesham wrote: > Vijay, > > I've expressed my opinion on the genreal issue before. > Regarding this topic of comparison, I don't think the > difference you expressed is worth writing new drafts > about. It would be much easier if you just suggest this to > us and we would discuss it. Instead, now we end up with > discussing very similar drafts for no apparent reason, which > takes more cycles. > I respect your right to write a new draft about whatever you > want. But for such a small differemce, you were welcome to > send a comment and discuss it... I was saying the opposite. show me something of value from draft-soliman that is not there in draft-wakikawa and we will take it up from there.. :) > FWIW I prefer not introducing a new option, the current > approach in draft-soliman fits easily within an implementation > as Conny already explained. FWIW, we have implementations of draft-wakikawa too... > Anyway, this is a secondary issue > and something that can be fine tuned much later in the process. I agree. Vijay > > Hesham > > > > -----Original Message----- > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On > > Behalf Of > > Vijay Devarapalli > > Sent: Friday, April 01, 2005 6:36 PM > > To: mip6@ietf.org > > Subject: [Mip6] draft-soliman and draft-wakikawa > > > > > > Gerardo, Keiichi, Hesham and Henrik, > > > > draft-soliman and draft-wakikawa both talk about binding a v4 > > CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > > the MN and the HA. the difference is in the way, the CoA is > > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > > address as the source address in the inner header. I believe > > the packet format looks like the following. > > > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) > > Dst opts hdr > > HoA_v6 > > Mobility hdr > > Binding Update > > > > Hesham, let me know if this is not correct? > > > > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. > > > > draft-wakikawa uses a mobility option for carrying the IPv4 > > address. > > > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > > IPv6 hdr (src=HoA_v6, dst=HA_v6) > > Mobility hdr > > Binding Update > > IPv4 CoA mobility option > > > > this is the main difference. > > > > apart from this, is there is anything else in draft-soliman > > that you think is important for the specific scenario we are > > talking about (v6 MN/MR accessing v6 HA from a v4 only access > > network). > > > > draft-wakikawa, OTOH, also talks about the following. detailed > > MN and HA behavior, IPsec SPD and SAD entries for securing the > > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > > particular tunneling mechanism and new binding ack status > > values. > > > > personally, I prefer a new mobility option to carry the IPv4 > > CoA, because it makes processing on the HA simple. but we can > > have the WG decide on this. I am open. > > > > Vijay > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 19:43:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07422 for ; Fri, 1 Apr 2005 19:43:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWrB-0006WJ-JL for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:51:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWi4-0000rq-99; Fri, 01 Apr 2005 19:41:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWi2-0000r4-Da for mip6@megatron.ietf.org; Fri, 01 Apr 2005 19:41:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07344 for ; Fri, 1 Apr 2005 19:41:51 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWpS-0006UF-Vg for mip6@ietf.org; Fri, 01 Apr 2005 19:49:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j321BLK09718; Fri, 1 Apr 2005 17:11:21 -0800 X-mProtect: <200504020111> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdivcMGT; Fri, 01 Apr 2005 17:11:20 PST Message-ID: <424DEA3C.20205@iprg.nokia.com> Date: Fri, 01 Apr 2005 16:41:32 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Soliman, Hesham wrote: > More specific response: > > > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) > > Dst opts hdr > > HoA_v6 > > Mobility hdr > > Binding Update > > > > Hesham, let me know if this is not correct? > > => Correct in the scenario you mentioned. This draft also > supports another scenario: using IPv4 home address and > IPv6 CoA. which we are not interested in and out of scope for this discussion. > Anything that talks about NAT traveral > without keepalives is not useful. that was an oversight. will fix this. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 19:45:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07562 for ; Fri, 1 Apr 2005 19:45:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWt6-0006bq-KS for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:53:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWkA-0001PN-9a; Fri, 01 Apr 2005 19:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWk8-0001On-A5 for mip6@megatron.ietf.org; Fri, 01 Apr 2005 19:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07474 for ; Fri, 1 Apr 2005 19:44:01 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWrY-0006Zw-UP for mip6@ietf.org; Fri, 01 Apr 2005 19:51:45 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 19:43:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Fri, 1 Apr 2005 19:43:55 -0500 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU3HIJtMbqZ5ngZTKyj2eCI4ehxWQAAC3Vw From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 02 Apr 2005 00:43:55.0474 (UTC) FILETIME=[0C972B20:01C5371D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable > > I've expressed my opinion on the genreal issue before. > > Regarding this topic of comparison, I don't think the=20 > > difference you expressed is worth writing new drafts > > about. It would be much easier if you just suggest this to > > us and we would discuss it. Instead, now we end up with > > discussing very similar drafts for no apparent reason, which > > takes more cycles. > > I respect your right to write a new draft about whatever you > > want. But for such a small differemce, you were welcome to > > send a comment and discuss it... >=20 > I was saying the opposite. show me something of value from > draft-soliman that is not there in draft-wakikawa and we will > take it up from there.. :) =3D> This is funny indeed, worth the smile :). So a draft comes=20 out call it draft A, then draft B comes out much later and the=20 argument for having draft B is that it contains everything in draft A.... No I won't start from this assumption of course. FWIW, I already mentioned that draft-soliman supports other scenarios. Hesham >=20 > > FWIW I prefer not introducing a new option, the current > > approach in draft-soliman fits easily within an implementation > > as Conny already explained.=20 >=20 > FWIW, we have implementations of draft-wakikawa too... >=20 > > Anyway, this is a secondary issue > > and something that can be fine tuned much later in the process. >=20 > I agree. >=20 > Vijay >=20 > >=20 > > Hesham > >=20 > >=20 > > > -----Original Message----- > > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On=20 > > > Behalf Of > > > Vijay Devarapalli > > > Sent: Friday, April 01, 2005 6:36 PM > > > To: mip6@ietf.org > > > Subject: [Mip6] draft-soliman and draft-wakikawa > > >=20 > > >=20 > > > Gerardo, Keiichi, Hesham and Henrik, > > >=20 > > > draft-soliman and draft-wakikawa both talk about binding a v4 > > > CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > > > the MN and the HA. the difference is in the way, the CoA is > > > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > > > address as the source address in the inner header. I believe > > > the packet format looks like the following. > > >=20 > > > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > > > IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > > > Dst opts hdr > > > HoA_v6 > > > Mobility hdr > > > Binding Update > > >=20 > > > Hesham, let me know if this is not correct? > > >=20 > > > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. > > >=20 > > > draft-wakikawa uses a mobility option for carrying the IPv4 > > > address. > > >=20 > > > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > > > IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > > > Mobility hdr > > > Binding Update > > > IPv4 CoA mobility option > > >=20 > > > this is the main difference. > > >=20 > > > apart from this, is there is anything else in draft-soliman > > > that you think is important for the specific scenario we are > > > talking about (v6 MN/MR accessing v6 HA from a v4 only access > > > network). > > >=20 > > > draft-wakikawa, OTOH, also talks about the following. detailed > > > MN and HA behavior, IPsec SPD and SAD entries for securing the > > > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > > > particular tunneling mechanism and new binding ack status > > > values. > > >=20 > > > personally, I prefer a new mobility option to carry the IPv4 > > > CoA, because it makes processing on the HA simple. but we can > > > have the WG decide on this. I am open. > > >=20 > > > Vijay > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > This email may contain confidential and privileged=20 > material for the sole use > > of the intended recipient. Any review or distribution by=20 > others is strictly > > prohibited. If you are not the intended recipient please=20 > contact the sender > > and delete all copies. > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 1 19:47:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07693 for ; Fri, 1 Apr 2005 19:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWuy-0006hS-Kx for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 19:55:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWlv-0001Ys-6M; Fri, 01 Apr 2005 19:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWlt-0001Yn-Vg for mip6@megatron.ietf.org; Fri, 01 Apr 2005 19:45:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07583 for ; Fri, 1 Apr 2005 19:45:50 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWtJ-0006c1-Pb for mip6@ietf.org; Fri, 01 Apr 2005 19:53:34 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Apr 2005 19:45:41 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Fri, 1 Apr 2005 19:45:41 -0500 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU3HL8TPVQncb1pQZC1VuUK/YO9OAAAF9SA From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 02 Apr 2005 00:45:42.0022 (UTC) FILETIME=[4C191A60:01C5371D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable =20 > > =3D> Correct in the scenario you mentioned. This draft also > > supports another scenario: using IPv4 home address and > > IPv6 CoA.=20 >=20 > which we are not interested in and out of scope for this > discussion. =3D> Who decided it's out of scope?? This is what we should be=20 discussing... Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 2 01:29:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02819 for ; Sat, 2 Apr 2005 01:29:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcFe-0004yB-Px for mip6-web-archive@ietf.org; Sat, 02 Apr 2005 01:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHc5v-0006ae-Ck; Sat, 02 Apr 2005 01:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHc5t-0006aW-NK for mip6@megatron.ietf.org; Sat, 02 Apr 2005 01:26:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02701 for ; Sat, 2 Apr 2005 01:26:50 -0500 (EST) Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcDJ-0004nO-VA for mip6@ietf.org; Sat, 02 Apr 2005 01:34:35 -0500 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 6D7CE37E58; Sat, 2 Apr 2005 08:26:40 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5ACB837E43 for ; Sat, 2 Apr 2005 08:26:40 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4737838003 for ; Sat, 2 Apr 2005 08:26:40 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DHc5f-0000xc-16 for mip6@ietf.org; Sat, 02 Apr 2005 08:26:39 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Alpesh Patel Date: Sat, 02 Apr 2005 06:26:35 +0000 MIME-Version: 1.0 Message-Id: <1112423195.2.0.833465398194.issue16@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.7 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue16] Specify checksum handling - comment from Christian Vogt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable New submission from Alpesh Patel : -------- Original Message -------- Subject: Re: [Mip6] I-D ACTION:draft-ietf-mip6-auth-protocol-00.txt Date: Thu, 29 Jul 2004 13:44:59 +0200 From: Christian Vogt To: alpesh@cisco.com, kleung@cisco.com, mkhalil@nortelnetworks.com,=20 haseebak@nortelnetworks.com, chowdury@nortelnetworks.com CC: mip6@ietf.org References: <200407091531.LAA05802@ietf.org> Hi, in section 6 (and sub-sections) of draft-ietf-mip6-auth-protocol-00.txt, you explain how an authenticator is built. The authenticator spans the Mobi= lity Header up to (and excluding) the Authenticator field. As far as I understand, the MH Checksum field must be treated as zero when calculating the authenticator because the authenticator is calculated befor= e the checksum. Wouldn't it be good to add a sentence on this? Kind regards, - Christian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Accepted. The current version has the fix for this. Alpesh ---------- category: Technical draft: draft-ietf-mip6-auth-protocol messages: 54 nosy: alpesh priority: Must fix status: Accepted title: Specify checksum handling - comment from Christian Vogt _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 2 02:06:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11219 for ; Sat, 2 Apr 2005 02:06:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcpy-0006WH-QP for mip6-web-archive@ietf.org; Sat, 02 Apr 2005 02:14:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcf6-0004GF-Es; Sat, 02 Apr 2005 02:03:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcf2-0004EA-Ln; Sat, 02 Apr 2005 02:03:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07618; Sat, 2 Apr 2005 02:03:10 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcmU-0006Ow-Kz; Sat, 02 Apr 2005 02:10:55 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2005 23:03:01 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3272qgU010321; Fri, 1 Apr 2005 23:02:53 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn6-582.cisco.com [10.21.122.70]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BDO76920; Fri, 1 Apr 2005 23:02:51 -0800 (PST) Message-Id: <4.3.2.7.2.20050401170850.03088ea0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Apr 2005 17:13:18 -0800 To: Basavaraj.Patil@nokia.com From: Kent Leung Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.7 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 My vote. #1 Yes. #2 No. PS is needed. Then baseline draft can be selected or written up. Kent At 09:40 AM 4/1/2005 -0600, Basavaraj.Patil@nokia.com wrote: >A couple of clarifications regarding the consensus call: > >1. The intention is to address the following scenario: >"MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 >access network need the capability to create a tunnel and be connected >to their MIP6 home agents." >This is the scenario that is most applicable for MIP6 deployment. >There are plenty of other scenarios as well. But they are much more >of academic interest at this time and hence not really in the scope >of this discussion. So I would suggst that we do not go off on a tangent >discussing all these other scenarios. > >Do you agree/disagree that the above scenario is the one that needs >to be solved ASAP? >(Note: It does not imply that other scenarios are irrelevant. It simply >means that this is the scenario worth working on and has the most >significant priority or value for MIP6 deployment.) > >2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It >does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any >other. The IDs can be combined w.r.t the parts that address this scenario. >Additionally once it is a WG document, what goes into the ID is decided >by the WG. So lets not get into arguments of what or whose draft is the >one that should be made the WG document. > >-Basavaraj > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: Internet Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 2 03:10:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03466 for ; Sat, 2 Apr 2005 03:10:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHdpN-0001sH-6Z for mip6-web-archive@ietf.org; Sat, 02 Apr 2005 03:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHdgA-0007Xd-71; Sat, 02 Apr 2005 03:08:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHdg7-0007Tb-Ne for mip6@megatron.ietf.org; Sat, 02 Apr 2005 03:08:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03369 for ; Sat, 2 Apr 2005 03:08:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHdna-0001qu-UC for mip6@ietf.org; Sat, 02 Apr 2005 03:16:08 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3287m303059; Sat, 2 Apr 2005 11:07:48 +0300 Date: Sat, 2 Apr 2005 11:07:48 +0300 (EEST) From: Pekka Savola To: Vijay Devarapalli Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 In-Reply-To: <424DA74C.4000204@iprg.nokia.com> Message-ID: References: <424DA74C.4000204@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Fri, 1 Apr 2005, Vijay Devarapalli wrote: > Gerardo Giaretta wrote: >> Hi Vijay, >> >> I have some comments on draft-ietf-mip6-ikev2-ipsec-01. >> >> Overall, the draft looks good. In my opinion, the unique general issue >> is that it is tied very much to rfc 3776 and as a result it is not >> self-contained. I mean that it is not possible to read the draft without >> having also rfc3776 in front of you. This is ok to me, but I wonder if >> it is acceptable in general. > > I guess it can be difficult. I was worried about this too, but didnt > want repeat all the requirements. will ask the working group about this. A higher-level comment, not having read the draft properly, I don't see this as a problem as long as the list of exceptions is clear enough (I don't have an opinion about this because I didn't look closely enough). In particular, as long as we put RFC3776 in as a normative reference, it's OK to just reference a section of it. This won't become a problem before we want to recycle this spec to Draft Standard, but not move forward with RFC3776 -- and we could make the document self-contained then. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 2 03:35:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05165 for ; Sat, 2 Apr 2005 03:35:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeDd-0003P4-G4 for mip6-web-archive@ietf.org; Sat, 02 Apr 2005 03:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe2a-0002BB-6U; Sat, 02 Apr 2005 03:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe1K-000293-Oe for mip6@megatron.ietf.org; Sat, 02 Apr 2005 03:30:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04838 for ; Sat, 2 Apr 2005 03:30:16 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHe8p-0002zZ-7d for mip6@ietf.org; Sat, 02 Apr 2005 03:38:03 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j328U7803447; Sat, 2 Apr 2005 11:30:07 +0300 Date: Sat, 2 Apr 2005 11:30:07 +0300 (EEST) From: Pekka Savola To: Samita Chakrabarti Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt In-Reply-To: <200501242159.j0OLxMnZ156853@jurassic.eng.sun.com> Message-ID: References: <200501242159.j0OLxMnZ156853@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, vnuorval@tcs.hut.fi X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Mon, 24 Jan 2005, Samita Chakrabarti wrote: >> Btw, now that the NEMO RFC is out, have you considered adding the NEMO >> definitions to the draft? >> > > The question was brought up before. Currently mip6api draft is in the AD review. > It is up to the Chairs and ADs to decide whether NEMO API should be bound > with this document or they should be published separately. I happened to get across this while perusing the issue tracker. IMHO, it would seem to make sense to add the NEMO basic support APIs here. As it is NEMO is already an RFC, and as it seems that the updates would be fairly trivial. However, the problem here is whether the proposed NEMO APIs have been sufficiently reviewed by NEMO WG. If NEMO WG chairs would say that there is rough consensus for these and these inclusions, this would be an "OK" signal for us. What we want to avoid is adding NEMO APIs here if such would later be called out to not have been sufficiently reviewed at NEMO WG or lacking consensus there. Obviously, all this still requires some form of approval of the AD, but as the document is still at AD review, i.e., hasn't been passed to the IESG as a whole yet, I don't think it is procedurally too late to kill two birds with one stone. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Apr 2 03:37:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05342 for ; Sat, 2 Apr 2005 03:37:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeFl-0003Rt-0p for mip6-web-archive@ietf.org; Sat, 02 Apr 2005 03:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe2b-0002BG-1a; Sat, 02 Apr 2005 03:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe2F-0002Ah-N1; Sat, 02 Apr 2005 03:31:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04889; Sat, 2 Apr 2005 03:31:13 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHe9h-00030B-Ij; Sat, 02 Apr 2005 03:39:00 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 2 Apr 2005 03:31:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: [Mip6] Consensus call on makingIDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Sat, 2 Apr 2005 03:31:03 -0500 Message-ID: Thread-Topic: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnelaMIP6/NEMO WGs document Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQAAuhshAAGDKocA== From: "Soliman, Hesham" To: , , X-OriginalArrivalTime: 02 Apr 2005 08:31:03.0551 (UTC) FILETIME=[4EA050F0:01C5375E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Hi Raj,=20 I misunderstood your question, so I take back the yes below about the scenario. I don't see how or why you picked this=20 scenario in the first place. I do think we need a list of=20 priorities for scenarios to consider but we need=20 to do that in the context of draft-larsson which is the only doc that lists all scenarios. Once we have that discussion we can pick scenarios to consider for solutions. Hesham > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On=20 > Behalf Of > Soliman, Hesham > Sent: Friday, April 01, 2005 3:58 PM > To: Basavaraj.Patil@nokia.com; mip6@ietf.org; nemo@ietf.org > Subject: RE: [nemo] RE: [Mip6] Consensus call on > makingIDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document >=20 >=20 >=20 > > Do you agree/disagree that the above scenario is the one=20 > that needs > > to be solved ASAP? >=20 > =3D> I agree. >=20 > > (Note: It does not imply that other scenarios are=20 > > irrelevant. It simply > > means that this is the scenario worth working on and has the most=20 > > significant priority or value for MIP6 deployment.) > >=20 > > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the=20 > baseline. It > > does not imply that we are ruling out=20 > draft-soliman-v4v6-mipv6 or any > > other.=20 >=20 > =3D> I don't see how it doesn't imply that. I think we should agree > on the scenario first, without associating it with either=20 > draft-wakikawa > or draft-soliman. Once we agreed, we can discuss how to solve the=20 > problem. I disagree with making draft-wakikawa a baseline.=20 >=20 > Hesham >=20 > The IDs can be combined w.r.t the parts that address=20 > > this scenario. > > Additionally once it is a WG document, what goes into the ID=20 > > is decided > > by the WG. So lets not get into arguments of what or whose=20 > > draft is the > > one that should be made the WG document. > >=20 > > -Basavaraj > >=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > This email may contain confidential and privileged material=20 > for the sole use > of the intended recipient. Any review or distribution by=20 > others is strictly > prohibited. If you are not the intended recipient please=20 > contact the sender > and delete all copies. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 3 05:14:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06743 for ; Sun, 3 Apr 2005 05:14:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1JN-0007m7-GD for mip6-web-archive@ietf.org; Sun, 03 Apr 2005 05:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI14a-0004OO-60; Sun, 03 Apr 2005 05:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI14X-0004OA-LB; Sun, 03 Apr 2005 05:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06438; Sun, 3 Apr 2005 05:07:07 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1CE-00079y-Gi; Sun, 03 Apr 2005 05:15:07 -0400 Received: from [192.168.0.4] (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j3396aFj023236; Sun, 3 Apr 2005 18:06:37 +0900 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCAD82AD@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FCAD82AD@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Sat, 2 Apr 2005 18:33:31 +0900 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Vijay Devarapalli , Basavaraj.Patil@nokia.com, Henrik Levkowetz , "Sri Gundavelli \(sgundave\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: 7bit Hello Pascal I don't think we should exclude your scenario by this consensus call. The mail sent by Chairs did not say exclusion of this scenario. We look at the different scenario. regards, ryuji On 2005/04/01, at 23:58, Pascal Thubert (pthubert) wrote: > Agreed... > > Another angle is that HAs are already being sold and deployed. There is > value in incremental features that do not change the HA and the > surrounding infrastructure. > > For instance, in the PE-Based model, corporations only own the routing > within their VPN, and the global addresses are owned by the service > provider. Unless they deploy a specific exit with DMZ, firewall and so > on, they will not have a single box with a global IPv4 address to put > an > HA on. > > Do we want to limit the solution to these corps that have a DMZ? > > Pascal > > | -----Original Message----- > | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf > Of > | Sri Gundavelli (sgundave) > | Sent: Friday, April 01, 2005 1:18 AM > | To: Narayanan Vidya-CVN065 > | Cc: nemo@ietf.org; mip6@ietf.org; 'Vijay Devarapalli'; Henrik > Levkowetz; > | Basavaraj.Patil@nokia.com > | Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID > draft-wakikawa- > | nemo-v4tunnel a MIP6/NEMO WGs document > | > | > | Vidya, > | > | Any transition solution should offer a way for a phased > | migration. I do not see how the current solution will > | enable the operator to push the v4 network in a phased > | manner. The requirements that the HA should be on the > | edge or if 90% of the deployments will go for that model > | is debatable and can only be answered by going for a > | problem statement. > | > | Regards > | Sri > | > | > | > | On Thu, 31 Mar 2005, Narayanan Vidya-CVN065 wrote: > | > | > Sri, > | > I also understood your comments exactly as Vijay did. A couple of > years > | ago, I did hear about some concerns on placing the HA in the DMZ, but > I > | didn't think any of those were very deep. Is there really a > deployment > | issue in placing the HA in the DMZ? > | > > | > Actually, even if you did place the HA deep in the IPv6 network, > forcing > | the need for a tunneling box in the DMZ that does v4-v6 tunneling, is > that > | really that bad? > | > > | > If most deployments don't have an issue with the placement of the > HA > in > | the DMZ and a small percentage of the cases do, it does not seem too > bad > | to me to say that a solution is simple since it solves the 90% case. > I'd > | vote for that rather than make it really complex to also solve the > 10% > | case. > | > > | > My 2 cents, > | > Vidya > | > > | > -----Original Message----- > | > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On > Behalf > Of > | Vijay Devarapalli > | > Sent: Thursday, March 31, 2005 2:02 PM > | > To: Henrik Levkowetz > | > Cc: nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com > | > Subject: [nemo] Re: [Mip6] Consensus call on making ID > draft-wakikawa- > | nemo-v4tunnel a MIP6/NEMO WGs document > | > > | > > | > Henrik, > | > > | > there is some mis-understanding regarding the relation > | > between draft-soliman and draft-wakikawa. both solve the scenario > of > a > | v6 MN or MR accessing its v6 home agent from a v4 only access > network. > | draft-soliman talks about using a IPv4 mapped IPv6 address to convey > the > | IPv4 CoA to the HA. draft-wakikawa uses a new mobility option to > carry > the > | IPv4 CoA. I personally prefer carrying it in a separate mobility > option, > | because it makes processing on the HA easier. we can debate the pros > and > | cons of this later. but this *does* not impact the scenario. both > solve > | the same scenario. > | > > | > there are other scenarios, but IMHO, they are not relevant. > | > > | > regarding Sri's concerns, we do intend to address them. dont worry > about > | that. we have an assumption in the draft. > | > > | > - the HA's IPv4 address is reachable through the IPv4 internet > | > > | > Sri is questioning this assumption. he is claiming this is > | > not so easy. he doesnt want IPv4 routing inside his IPv6 network. > the HA > | is deep inside in the IPv6 network. for the HA's IPv4 address to be > | reachable, you might need a box in the DMZ, which traps the packets > for > | the HA's IPv4 address and tunnels them to the HA deep in the IPv6 > network. > | but here we end with extra tunneling between the box sitting in the > DMZ > | and the HA deep in the IPv6 network. another option is to place the > HA > in > | the DMZ. but he doesnt want to do that. I will be discussing with him > to > | see how we can come up with a solution. Sri, let me know if I still > dont > | understand the issue you are bringing up. > | > > | > Vijay > | > > | > Henrik Levkowetz wrote: > | > > Hi, > | > > > | > > On 2005-03-30 9:33 pm Basavaraj.Patil@nokia.com said the > following: > | > > [...] > | > > > | > >>A number of transition scenarios have been identified in IDs: > | > >>1. draft-larsson-v6ops-mip-scenarios-01 > | > >>2. draft-tsirtsis-dsmip-problem-03 > | > >>While discussion of these scenarios in the larger scope makes > sense, > | > >>there is a need to focus on the most critical scenario that would > | > >>address the MIP6 host and router problem. The problem in a single > | > >>sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) > need > | > >>to be able to reach its (IPv6) home agent and services when > roaming in > | > >>and attached to an IPv4 access network." > | > >>It makes sense to focus on just this one scenario and solve the > | > >>problem immediately. > | > > > | > > > | > > Given that there already exists at least 3 solution drafts in > this > | > > area: > | > > > | > > draft-thubert-nemo-ipv4-traversal > | > > draft-soliman-v4v6-mipv6 > | > > draft-wakikawa-nemo-v4tunnel > | > > > | > > and Sri clearly indicates that there are requirements which these > | > > don't cover, I think it would be good to have a clear and agreed > upon > | > > statement of what to achieve before adopting an approach and > draft. > | > > So I'm not for adopting draft-wakikawa before there is an agreed > upon > | > > problem statement. > | > > > | > > That said, I'm very much in favour of doing this work; and doing > it by > | > > extensions to MIP6 (and MIP4) rather than trying to adapt any of > the > | > > other approaches which would mix MIP6 with non-MIP tunnels, as > listed > | > > in draft-larsson-v6ops-mip-scenarios-01. > | > > > | > > If the decision is to write a problem statement, I'd be willing > to > | > > work on such a draft, and I also have a potential co-editor who > have > | > > indicated willingness. > | > > > | > > > | > >>The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a > MIPv6 > | > >>mobile node or a NEMO mobile router roaming onto a IPv4 only > access > | > >>network in a simple manner. > | > >>It is intended that the standardization of this solution in the > IETFs > | > >>MIP6 and/or NEMO working groups proceed. The working group chairs > have > | > >>reviewed and discussed this work item. It has also been presented > at > | > >>the MIP6 and NEMO WGs at IETF62. > | > >> > | > >>The chairs would like to hear your thoughts in order to see if > there > | > >>is consensus to make it a WG document and progress it as a > standards > | > >>track RFC. Comments should be sent to both the NEMO and MIP6 WGs. > | > >> > | > >>If we have consensus, then the document will be pursued as a dual > WG > | > >>item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > | > >> > | > >>Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > | > >> For [ ] > | > >> Against [ ] > | > >> > | > > > | > > > | > > Not currently [ X ] > | > > > | > > > | > > Henrik > | > > > | > > _______________________________________________ > | > > Mip6 mailing list > | > > Mip6@ietf.org > | > > https://www1.ietf.org/mailman/listinfo/mip6 > | > > | > > | > > | > _______________________________________________ > | > Mip6 mailing list > | > Mip6@ietf.org > | > https://www1.ietf.org/mailman/listinfo/mip6 > | > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 3 06:04:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09688 for ; Sun, 3 Apr 2005 06:04:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI26F-000216-W3 for mip6-web-archive@ietf.org; Sun, 03 Apr 2005 06:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1vF-0003od-F7; Sun, 03 Apr 2005 06:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1vC-0003oX-Jn for mip6@megatron.ietf.org; Sun, 03 Apr 2005 06:01:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09228 for ; Sun, 3 Apr 2005 06:01:30 -0400 (EDT) Received: from bundit.graduate.kmitl.ac.th ([161.246.39.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI22q-0001oO-75 for mip6@ietf.org; Sun, 03 Apr 2005 06:09:31 -0400 Received: from graduate.kmitl.ac.th ([161.246.39.95]) by bundit.graduate.kmitl.ac.th (8.12.8/8.12.5) with ESMTP id j339uMDO006686 for ; Sun, 3 Apr 2005 16:56:23 +0700 Message-ID: <424FBF59.4090705@graduate.kmitl.ac.th> Date: Sun, 03 Apr 2005 17:03:05 +0700 From: Warodom Werapun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: th, en-us, en MIME-Version: 1.0 To: mip6@ietf.org X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=TIS-620; format=flowed Content-Transfer-Encoding: 7bit X-Graduate-MailScanner-Information: Please contact the ISP for more information X-Graduate-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Mip6] Why we need Duplicated Address Detection for MIPv6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit When mobile node config new IPv6 addr by using network interface concat with MAC addr-EUI64 format? Which case that mobile node can be duplicated because MAC addr. in LAN card was unique? Or this process design to protect from the faking MAC created by the intruder? -- Warodom Werapun PGP: http://plex.coe.psu.ac.th/myPGP.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 3 09:57:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25427 for ; Sun, 3 Apr 2005 09:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5iw-0007Jc-92 for mip6-web-archive@ietf.org; Sun, 03 Apr 2005 10:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5aB-0003Kp-S3; Sun, 03 Apr 2005 09:56:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5aA-0003JT-6h for mip6@megatron.ietf.org; Sun, 03 Apr 2005 09:56:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25287 for ; Sun, 3 Apr 2005 09:56:04 -0400 (EDT) Received: from av4-2-sn3.vrr.skanova.net ([81.228.9.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5ht-0007Hd-KK for mip6@ietf.org; Sun, 03 Apr 2005 10:04:06 -0400 Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id CF9FA37E53; Sun, 3 Apr 2005 15:55:55 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BF60F37E45; Sun, 3 Apr 2005 15:55:55 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B0FB038007; Sun, 3 Apr 2005 15:55:55 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DI5Zz-0004Di-Gh; Sun, 03 Apr 2005 15:55:55 +0200 Message-ID: <424FF5EA.5000602@levkowetz.com> Date: Sun, 03 Apr 2005 15:55:54 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: <424DEA3C.20205@iprg.nokia.com> In-Reply-To: <424DEA3C.20205@iprg.nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit on 2005-04-02 2:41 am Vijay Devarapalli said the following: > Soliman, Hesham wrote: >> More specific response: >> >> >> > IPv4 hdr (src=CoA_v4, dst=HA_v4) >> > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) >> > Dst opts hdr >> > HoA_v6 >> > Mobility hdr >> > Binding Update >> > >> > Hesham, let me know if this is not correct? >> >> => Correct in the scenario you mentioned. This draft also >> supports another scenario: using IPv4 home address and >> IPv6 CoA. > > which we are not interested in and out of scope for this > discussion. Whoops! You individually may not be interested in it, but I individually do - and I see no reason why this should be out of scope for this discussion. > > Anything that talks about NAT traveral >> without keepalives is not useful. > > that was an oversight. will fix this. Mph. There is quite a bit more to say about NAT traversal. That the current wakikawa draft is under-specifying this is putting it mildly ,:-) Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 3 09:57:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25586 for ; Sun, 3 Apr 2005 09:57:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5jU-0007Kx-6d for mip6-web-archive@ietf.org; Sun, 03 Apr 2005 10:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5Qh-0002vq-KC; Sun, 03 Apr 2005 09:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5Qf-0002vi-E5; Sun, 03 Apr 2005 09:46:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24669; Sun, 3 Apr 2005 09:46:15 -0400 (EDT) Received: from av4-1-sn3.vrr.skanova.net ([81.228.9.111]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5YP-0006iJ-8W; Sun, 03 Apr 2005 09:54:17 -0400 Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id DB66B37E52; Sun, 3 Apr 2005 15:46:04 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CA5B937E42; Sun, 3 Apr 2005 15:46:04 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B8E0D38008; Sun, 3 Apr 2005 15:46:04 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DI5QO-0003ze-Uq; Sun, 03 Apr 2005 15:46:00 +0200 Message-ID: <424FF398.6060006@levkowetz.com> Date: Sun, 03 Apr 2005 15:46:00 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F8535BAD50@daebe101.NOE.Nokia.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit on 2005-04-01 5:40 pm Basavaraj.Patil@nokia.com said the following: > A couple of clarifications regarding the consensus call: > > 1. The intention is to address the following scenario: > "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 > access network need the capability to create a tunnel and be connected > to their MIP6 home agents." > This is the scenario that is most applicable for MIP6 deployment. > There are plenty of other scenarios as well. But they are much more > of academic interest at this time and hence not really in the scope > of this discussion. So I would suggst that we do not go off on a tangent > discussing all these other scenarios. > > Do you agree/disagree that the above scenario is the one that needs > to be solved ASAP? > (Note: It does not imply that other scenarios are irrelevant. It simply > means that this is the scenario worth working on and has the most > significant priority or value for MIP6 deployment.) 1. - I agree on what you specify above, but also think this is so wide, or general in nature if you wish, that it doesn't work as a problem statement. > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It > does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any > other. The IDs can be combined w.r.t the parts that address this scenario. > Additionally once it is a WG document, what goes into the ID is decided > by the WG. So lets not get into arguments of what or whose draft is the > one that should be made the WG document. 2. - I think it's premature to pick a particular document as baseline. I don't see an agreement on a sufficiently detailed problem statement currently, so how can we sensibly pick a particular solution? Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:43:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26795 for ; Mon, 4 Apr 2005 00:43:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJZ2-000717-Ha for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:51:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIN-0002Vf-L8; Mon, 04 Apr 2005 00:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIM-0002VS-1B for mip6@megatron.ietf.org; Mon, 04 Apr 2005 00:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26179 for ; Mon, 4 Apr 2005 00:34:35 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQ2-0006Pj-To for mip6@ietf.org; Mon, 04 Apr 2005 00:42:46 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344XVFj029209; Mon, 4 Apr 2005 13:33:36 +0900 Date: Mon, 04 Apr 2005 13:13:17 +0900 Message-ID: From: Ryuji Wakikawa To: henrik@levkowetz.com Subject: Re: [Mip6] draft-soliman and draft-wakikawa In-Reply-To: <424FF5EA.5000602@levkowetz.com> References: <424DEA3C.20205@iprg.nokia.com> <424FF5EA.5000602@levkowetz.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Henrik At Sun, 03 Apr 2005 15:55:54 +0200, Henrik Levkowetz wrote: > > on 2005-04-02 2:41 am Vijay Devarapalli said the following: > > Soliman, Hesham wrote: > >> More specific response: > >> > >> > >> > IPv4 hdr (src=CoA_v4, dst=HA_v4) > >> > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) > >> > Dst opts hdr > >> > HoA_v6 > >> > Mobility hdr > >> > Binding Update > >> > > >> > Hesham, let me know if this is not correct? > >> > >> => Correct in the scenario you mentioned. This draft also > >> supports another scenario: using IPv4 home address and > >> IPv6 CoA. > > > > which we are not interested in and out of scope for this > > discussion. > > Whoops! You individually may not be interested in it, but > I individually do - and I see no reason why this should be > out of scope for this discussion. I individually don't. Using MIPv4 in IPv6 networks should be discussed in MIPv4 WG. > > > Anything that talks about NAT traveral > >> without keepalives is not useful. > > > > that was an oversight. will fix this. > > Mph. There is quite a bit more to say about NAT traversal. > That the current wakikawa draft is under-specifying this is > putting it mildly ,:-) Your updates would be always appreciated. ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:46:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26979 for ; Mon, 4 Apr 2005 00:46:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJbK-000748-8t for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:54:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIG-0002VE-PG; Mon, 04 Apr 2005 00:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIF-0002V6-3Z; Mon, 04 Apr 2005 00:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26160; Mon, 4 Apr 2005 00:34:28 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQ4-0006Qm-VV; Mon, 04 Apr 2005 00:42:39 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344Y5Fj029232; Mon, 4 Apr 2005 13:34:05 +0900 Date: Mon, 04 Apr 2005 13:24:31 +0900 Message-ID: From: Ryuji Wakikawa To: sgundave@cisco.com Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, vijayd@iprg.nokia.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi Sri my understanding is that this mechanism willnot be solo solution for transition scenario. Your concerns are correct for some deployment scenarios. However, our approach is a way to solve the transition problem and provides additional features such as less tunnel overhead and no infrastructure supports. These features are important for service providers. regards, ryuji At Wed, 30 Mar 2005 22:21:04 -0800 (PST), Sri Gundavelli wrote: > > Hi Ryuji, > Please see inline ... > > > On Thu, 31 Mar 2005, Ryuji Wakikawa wrote: > > > Hello Sri > > > > > Other way to say is we would not an extra encap layer, when > > > the home agent and the transition gateway functions are spread > > > out. > > > > OK, but there is a problem, "double tunneling". > > Packets have, at least, three IP headers when MN roams to v4 network. > > Extra bits and processing costs are burden for MIP6/NEMO in IPv4. > > > > That is the cost for going over a transition gateway. The > transition solutions should not expect the networks to > overlap, they should provide a way for the network > administrators to systematically move the v4 network > out from the v6 cloud in a segmented approach. The solution > we are debating is about the tight coupling of the v4 and > v6 networks and requiring fundamental changes to the binding > cache entries for associating v4 addresses. If the solution > requires a v4 network all the way to the Home Agent, > a dual stacked Mobile Router, a modified home agent to > understand v4 address semantics, wonder why we can't go to > the next step of replacing the v6 home agent with a v4 home > agent. Clearly, the solution cannot disregard the problem > scenarios such as a home agent in a v6 cloud and disjointed > transition gateway to the v4 cloud. > > All I'm saying is that we should agree up on the problem > scenarios, review the current solutions including doors and > work towards a solution. > > Regards > Sri > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:47:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27131 for ; Mon, 4 Apr 2005 00:47:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJcH-0007C7-9D for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJKX-0002ZG-DW; Mon, 04 Apr 2005 00:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJKV-0002Z6-Q7; Mon, 04 Apr 2005 00:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26307; Mon, 4 Apr 2005 00:36:48 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJSL-0006bn-Cb; Mon, 04 Apr 2005 00:45:00 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YXFj029242; Mon, 4 Apr 2005 13:34:33 +0900 Date: Mon, 04 Apr 2005 13:26:59 +0900 Message-ID: From: Ryuji Wakikawa To: pekkas@netcore.fi Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com, sgundave@cisco.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hello Pekka At Thu, 31 Mar 2005 09:43:41 +0300 (EEST), Pekka Savola wrote: > > On Wed, 30 Mar 2005, Vijay Devarapalli wrote: > >> Also, the draft's claim that they are > >> avoiding one extra encap layer is not true, the moment > >> you move the transition gateway from the home agent, > >> indeed an extra encap layer is needed. > > > > we do want to keep it to just one level of encapsulation. > > Why, exactly? > > There are existing mechanisms out there which have been deployed for > years, widely implemented, etc. to deal with exactly these issues. If there are exiting transition mechanisms and MN gets v6 address, MN can operate without changes. This is fine if we forget redundant tunnel overheads. However, what happen when a mobile node roams to just v4 networks. Can we expect that all wireless networks will deploy with v6 or some transition mechanism? It makes sense that MIP6 has some way to handle v4 address by itself (no infrastructure supports). > You're arguing we need to design protocol extensions to save 20 or 40 > bytes. Is it worth it ? > > A couple of quick comments on the ID: > - which encapsulation types are mandatory-to-implement? There must > be at least one or a couple, to ensure interoperability. I got similar comments from several people. We'll limit one or two encapsulation types in the next version. > - you specify UDP encapsulation for NAT traversal, but no keepalive > - I guess it should be possible to discover the v4 home agent address > without having to use (v6-only) DHAAD? I'm not sure if we need an original dynamic discovery mechanism only for this. For example, if a mobile node knows a home agent's FQDN while in v6 network, it can also gets v4 address by DNS. thanks ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:47:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27209 for ; Mon, 4 Apr 2005 00:47:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJcs-0007D9-De for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIi-0002WX-B2; Mon, 04 Apr 2005 00:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJId-0002WP-MZ; Mon, 04 Apr 2005 00:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26204; Mon, 4 Apr 2005 00:34:52 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQV-0006aJ-Fv; Mon, 04 Apr 2005 00:43:04 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YhFj029250; Mon, 4 Apr 2005 13:34:43 +0900 Date: Mon, 04 Apr 2005 13:27:11 +0900 Message-ID: From: Ryuji Wakikawa To: pthubert@cisco.com Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCAD8234@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FCAD8234@xmb-ams-337.emea.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nemo@ietf.org, mip6@ietf.org, keiichi@iijlab.net, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Hello Pascal At Fri, 1 Apr 2005 15:56:39 +0200, pascal wrote: > > | If most deployments don't have an issue with the placement of the HA > in > | the DMZ and a small percentage of the cases do, it does not seem too > bad > | to me to say that a solution is simple since it solves the 90% case. > I'd > | vote for that rather than make it really complex to also solve the 10% > | case. > | > > Hi Vidya > > I see words about complexity from you and Keiichi. I agree we need to > look at how complex the proposals are: > - in terms of standardization > - in terms of coding > - and mostly in terms of deployment Hmm, I feel that Doors, itself, is complicated. My major comments to Doors are - Doors brought security vulenerability in terms of IP header modification at intermediate gateways. Do we really want another NAT like mechanism in IPv6? - IPsec operation is not clear to me. > Obviously, a solution that has less constraints is easier to deploy. > Ending the IPv4 at the HA is a constraint. We have experiments with > customers who could not do that for very pragmatic reasons. Details > might be given mater. You customers are not only clients using MIP6:-) There are also requirements such as no infrastructure support and less tunnel overheads. I don't have customers like cisco, but I know there are companies seeking a solution for the requirements. > In terms of coding, I guess that people have to read and understand all > proposals on the table before they can assess that one thing is more > complex than another. I would assert that a solution that does not > change the home agent causes less regression testing then one that does. > For instance, Doors is a very small footprint hack that leaves the end > to end MIP untouched. Goal of Doors and our solution is cleary different. We assume different deployment scenarios. We should not compare doors or other transition mechanism in this thread. > In terms of standardization, I'd guess that the same applies. Changing > MIP inside is not as simple as changing it on the surface. Doors just > acts on the transport. The Doors gateway can be installed on the HA, > close to the HA, or by an external provider anywhere. > > I'd just suggest that we, as a group, do not presuppose that because > Doors provides additional features it is necessarily more complex. > Sometimes, simplicity brings a lot of good things with it. Agree. I always like similicity:-) ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:48:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27381 for ; Mon, 4 Apr 2005 00:48:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJdz-0007FU-RF for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIY-0002W5-2k; Mon, 04 Apr 2005 00:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIW-0002Vx-Os; Mon, 04 Apr 2005 00:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26191; Mon, 4 Apr 2005 00:34:45 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQO-0006aE-Gl; Mon, 04 Apr 2005 00:42:57 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YcFj029245; Mon, 4 Apr 2005 13:34:38 +0900 Date: Mon, 04 Apr 2005 13:27:03 +0900 Message-ID: From: Ryuji Wakikawa To: pekkas@netcore.fi Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> <424C3932.8080005@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Hello Pekka I agree that we should not re-invent NAT traversal and encapsulation mechanisms. And if this is your concern, we can simply say using IKEv2 and RFC3948 for NAT traversal and using v4-v6 tunnel for non NAT networks. We'll use the BU/BA for tunnel end points establishment, but this is same as MIP6. This is simple extension to MIP6 (for me). regards, ryuji At Fri, 1 Apr 2005 16:31:53 +0300 (EEST), Pekka Savola wrote: > > On Thu, 31 Mar 2005, Vijay Devarapalli wrote: > >>> we do want to keep it to just one level of encapsulation. > >> > >> Why, exactly? > > > > well, if its doable, dont we always want minimal encapsulation? > > Not necessarily. There's always room for optimization but the > tradeoff is worth considering. The question is what level is "good > enough". > > > it is doable if the following assumptions from the draft are valid. > > > > - HA has v4 and v6 interface > > - MN is dual-stack > > - HA's v4 address is reachable from the IPv4 Internet. > > I've no doubt that it's doable,a nd these assumptions seem OK to me. > > >> There are existing mechanisms out there which have been deployed for years, > >> widely implemented, etc. to deal with exactly these issues. > > > > I am not sure I understood. we are not defining any new tunneling > > mechanisms. the idea is to use the existing tunneling mechanisms. > > But instead of using mechanisms which require no protocol > modifications or new code at all, you're plugging v4 tunneling > functionality to MIPv6. In other words, inventing something new. > > That's a bit uncomfortable because MIPv6 was not designed for v4: > There are a couple of things why I think this is a problem: > - People could even leverage the length of v6 addresses e.g., for > CGA-based authorization instead of return routability (or something > like that). But extending MIPv6 in a manner that would eliminate that > room for expansion. > - We may not (yet) be fully aware which parts of the spec this has > (non-obvious) implications to > - we end up having to re-invent a lot of stuff, like NAT traversal, > keepalives, possibly needing to also do NAT traversal to reach the > Home Agent, etc. And we have a number of encapsulation mechanisms. > All of this seems like something that we do NOT want to re-invent in > MIPv6 unless it can be justified that using existing mechanisms and > existing configuration methods is not good enough (the crutch appears > to be saving 20 or 40 bytes of payload). > > >> You're arguing we need to design protocol extensions to save 20 or 40 > >> bytes. Is it worth it ? > > > > well, the protocol extension is only to bind an IPv4 CoA to IPv6 > > HoA. it is minor enough that we dont have to worry about it. > > Would the next step be to bind an IPv4 CoA to IPv6 CN ? > > >> A couple of quick comments on the ID: > >> - which encapsulation types are mandatory-to-implement? There must be at > >> least one or a couple, to ensure interoperability. > > > > right. we havent picked a mandatory-to-implement mechanism > > yet. IPv6-in-UDP-over-IPv4 and IPv6-over-IPv4? suggestions are > > welcome. > > Those seem OK, though I'm not sure what the security folks would say. > > >> - I guess it should be possible to discover the v4 home agent address > >> without having to use (v6-only) DHAAD? > > > > DNS is one mechanism to discover the v4 address of the home agent. > > Yep.. but it's non-standard, right? How can products from different > vendors and operators interoperate? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:50:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27580 for ; Mon, 4 Apr 2005 00:50:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJfA-0007I9-OG for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:58:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIP-0002Vn-6r; Mon, 04 Apr 2005 00:34:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIN-0002VX-69; Mon, 04 Apr 2005 00:34:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26185; Mon, 4 Apr 2005 00:34:36 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQE-0006Qq-WA; Mon, 04 Apr 2005 00:42:47 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YBFj029235; Mon, 4 Apr 2005 13:34:12 +0900 Date: Mon, 04 Apr 2005 13:24:52 +0900 Message-ID: From: Ryuji Wakikawa To: pekkas@netcore.fi Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com, sgundave@cisco.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hello Pekka At Thu, 31 Mar 2005 09:43:41 +0300 (EEST), Pekka Savola wrote: > > On Wed, 30 Mar 2005, Vijay Devarapalli wrote: > >> Also, the draft's claim that they are > >> avoiding one extra encap layer is not true, the moment > >> you move the transition gateway from the home agent, > >> indeed an extra encap layer is needed. > > > > we do want to keep it to just one level of encapsulation. > > Why, exactly? > > There are existing mechanisms out there which have been deployed for > years, widely implemented, etc. to deal with exactly these issues. If there are exiting transition mechanisms and MN gets v6 address, MN can operate without changes. This is fine if we forget redundant tunnel overheads. However, what happen when a mobile node roams to just v4 networks. Can we expect that all wireless networks will deploy with v6 or some transition mechanism? It makes sense that MIP6 has some way to handle v4 address by itself (no infrastructure supports). > You're arguing we need to design protocol extensions to save 20 or 40 > bytes. Is it worth it ? > > A couple of quick comments on the ID: > - which encapsulation types are mandatory-to-implement? There must > be at least one or a couple, to ensure interoperability. I got similar comments from several people. We'll limit one or two encapsulation types in the next version. > - you specify UDP encapsulation for NAT traversal, but no keepalive > - I guess it should be possible to discover the v4 home agent address > without having to use (v6-only) DHAAD? I'm not sure if we need an original dynamic discovery mechanism only for this. For example, if a mobile node knows a home agent's FQDN while in v6 network, it can also gets v4 address by DNS. thanks ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:50:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27679 for ; Mon, 4 Apr 2005 00:50:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJfq-0007JP-7v for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:58:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIZ-0002WK-Vc; Mon, 04 Apr 2005 00:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIY-0002WD-KM for mip6@megatron.ietf.org; Mon, 04 Apr 2005 00:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26197 for ; Mon, 4 Apr 2005 00:34:47 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQQ-0006aF-EU for mip6@ietf.org; Mon, 04 Apr 2005 00:42:59 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YHFj029238; Mon, 4 Apr 2005 13:34:17 +0900 Date: Mon, 04 Apr 2005 13:26:13 +0900 Message-ID: From: Ryuji Wakikawa To: pekkas@netcore.fi Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt In-Reply-To: References: <200501242159.j0OLxMnZ156853@jurassic.eng.sun.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, vnuorval@tcs.hut.fi, Samita.Chakrabarti@eng.sun.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Hello Pekka NEMO added only a mobility header option and flags for BU, BA, etc. Therefore, modifications for NEMO can be very small. I sent examples of NEMO APIs to Samita a while ago. We did implement and use the NEMO APIs in KAME NEMO implementation. It works fine. regards, ryuji At Sat, 2 Apr 2005 11:30:07 +0300 (EEST), Pekka Savola wrote: > > On Mon, 24 Jan 2005, Samita Chakrabarti wrote: > >> Btw, now that the NEMO RFC is out, have you considered adding the NEMO > >> definitions to the draft? > >> > > > > The question was brought up before. Currently mip6api draft is in the AD review. > > It is up to the Chairs and ADs to decide whether NEMO API should be bound > > with this document or they should be published separately. > > I happened to get across this while perusing the issue tracker. > > IMHO, it would seem to make sense to add the NEMO basic support APIs > here. As it is NEMO is already an RFC, and as it seems that the > updates would be fairly trivial. > > However, the problem here is whether the proposed NEMO APIs have been > sufficiently reviewed by NEMO WG. If NEMO WG chairs would say that > there is rough consensus for these and these inclusions, this would be > an "OK" signal for us. > > What we want to avoid is adding NEMO APIs here if such would later be > called out to not have been sufficiently reviewed at NEMO WG or > lacking consensus there. > > Obviously, all this still requires some form of approval of the AD, > but as the document is still at AD review, i.e., hasn't been passed to > the IESG as a whole yet, I don't think it is procedurally too late to > kill two birds with one stone. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 00:51:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27751 for ; Mon, 4 Apr 2005 00:51:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJg7-0007Ku-D8 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 00:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIn-0002Xk-0w; Mon, 04 Apr 2005 00:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIk-0002Ww-QR; Mon, 04 Apr 2005 00:35:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26215; Mon, 4 Apr 2005 00:34:59 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIJQc-0006aU-FZ; Mon, 04 Apr 2005 00:43:11 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j344YoFj029261; Mon, 4 Apr 2005 13:34:50 +0900 Date: Mon, 04 Apr 2005 13:27:29 +0900 Message-ID: From: Ryuji Wakikawa To: H.Soliman@flarion.com Subject: Re: [Mip6] draft-soliman and draft-wakikawa In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Hesham and Vijay Here is the history. draft-heshams does not support NAT traversal, and I don't see any solution to solve NAT traversal by using mapped address. We will design an extension using mobility option to solve NAT issue and throw away MIPv4 support which is not our goal in the draft. ryuji At Fri, 1 Apr 2005 19:43:55 -0500, Soliman, Hesham wrote: > > > > > I've expressed my opinion on the genreal issue before. > > > Regarding this topic of comparison, I don't think the > > > difference you expressed is worth writing new drafts > > > about. It would be much easier if you just suggest this to > > > us and we would discuss it. Instead, now we end up with > > > discussing very similar drafts for no apparent reason, which > > > takes more cycles. > > > I respect your right to write a new draft about whatever you > > > want. But for such a small differemce, you were welcome to > > > send a comment and discuss it... > > > > I was saying the opposite. show me something of value from > > draft-soliman that is not there in draft-wakikawa and we will > > take it up from there.. :) > > => This is funny indeed, worth the smile :). So a draft comes > out call it draft A, then draft B comes out much later and the > argument for having draft B is that it contains everything in > draft A.... No I won't start from this assumption of course. > FWIW, I already mentioned that draft-soliman supports other > scenarios. > > Hesham > > > > > > FWIW I prefer not introducing a new option, the current > > > approach in draft-soliman fits easily within an implementation > > > as Conny already explained. > > > > FWIW, we have implementations of draft-wakikawa too... > > > > > Anyway, this is a secondary issue > > > and something that can be fine tuned much later in the process. > > > > I agree. > > > > Vijay > > > > > > > > Hesham > > > > > > > > > > -----Original Message----- > > > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On > > > > Behalf Of > > > > Vijay Devarapalli > > > > Sent: Friday, April 01, 2005 6:36 PM > > > > To: mip6@ietf.org > > > > Subject: [Mip6] draft-soliman and draft-wakikawa > > > > > > > > > > > > Gerardo, Keiichi, Hesham and Henrik, > > > > > > > > draft-soliman and draft-wakikawa both talk about binding a v4 > > > > CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > > > > the MN and the HA. the difference is in the way, the CoA is > > > > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > > > > address as the source address in the inner header. I believe > > > > the packet format looks like the following. > > > > > > > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > > > > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) > > > > Dst opts hdr > > > > HoA_v6 > > > > Mobility hdr > > > > Binding Update > > > > > > > > Hesham, let me know if this is not correct? > > > > > > > > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. > > > > > > > > draft-wakikawa uses a mobility option for carrying the IPv4 > > > > address. > > > > > > > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > > > > IPv6 hdr (src=HoA_v6, dst=HA_v6) > > > > Mobility hdr > > > > Binding Update > > > > IPv4 CoA mobility option > > > > > > > > this is the main difference. > > > > > > > > apart from this, is there is anything else in draft-soliman > > > > that you think is important for the specific scenario we are > > > > talking about (v6 MN/MR accessing v6 HA from a v4 only access > > > > network). > > > > > > > > draft-wakikawa, OTOH, also talks about the following. detailed > > > > MN and HA behavior, IPsec SPD and SAD entries for securing the > > > > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > > > > particular tunneling mechanism and new binding ack status > > > > values. > > > > > > > > personally, I prefer a new mobility option to carry the IPv4 > > > > CoA, because it makes processing on the HA simple. but we can > > > > have the WG decide on this. I am open. > > > > > > > > Vijay > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > =========================================================== > > > This email may contain confidential and privileged > > material for the sole use > > > of the intended recipient. Any review or distribution by > > others is strictly > > > prohibited. If you are not the intended recipient please > > contact the sender > > > and delete all copies. > > > =========================================================== > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 01:14:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00010 for ; Mon, 4 Apr 2005 01:14:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIK2Z-0000GU-7Y for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 01:22:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJtu-0007Af-LL; Mon, 04 Apr 2005 01:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJtt-0007AX-I3 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 01:13:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29965 for ; Mon, 4 Apr 2005 01:13:25 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIK1k-0008Vp-IA for mip6@ietf.org; Mon, 04 Apr 2005 01:21:34 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j345D7o19201; Mon, 4 Apr 2005 08:13:07 +0300 Date: Mon, 4 Apr 2005 08:13:07 +0300 (EEST) From: Pekka Savola To: Ryuji Wakikawa Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt In-Reply-To: Message-ID: References: <200501242159.j0OLxMnZ156853@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org, vnuorval@tcs.hut.fi, Samita.Chakrabarti@eng.sun.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi, On Mon, 4 Apr 2005, Ryuji Wakikawa wrote: > NEMO added only a mobility header option and flags for BU, BA, etc. > Therefore, modifications for NEMO can be very small. > > I sent examples of NEMO APIs to Samita a while ago. > We did implement and use the NEMO APIs in KAME NEMO implementation. > It works fine. Sorry -- this was not the point I was trying to make. I was taking a procedural approach to this.. It does not matter all that much what you (as an individual) decide to do, or what you (as an individual) choose to implement. Of course, it's nice to see there's interest and implementation of those, though. (Nothing against you of course personally :) The critical thing is whether NEMO WG has reached the rough consensus that those modifications you (as an individual) proposed are good, and NEMO WG is fine with them. For that, I guess NEMO WG chairs would need to put on a hat and take the sense of the "room", solicit review, etc. That doesn't need to take long, but if we are going to add anything about NEMO in the spec, our AD will want us to be double-careful that those modifications reflect the consensus of the NEMO WG. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 01:22:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00869 for ; Mon, 4 Apr 2005 01:22:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKAl-0000ig-QL for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 01:30:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK1b-00084W-Hf; Mon, 04 Apr 2005 01:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK1Z-00084F-A8 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 01:21:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00787 for ; Mon, 4 Apr 2005 01:21:20 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIK9R-0000Vc-Di for mip6@ietf.org; Mon, 04 Apr 2005 01:29:30 -0400 Received: from [192.168.0.4] (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j345L8Fj029723; Mon, 4 Apr 2005 14:21:08 +0900 In-Reply-To: References: <200501242159.j0OLxMnZ156853@jurassic.eng.sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt Date: Mon, 4 Apr 2005 14:21:02 +0900 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, vnuorval@tcs.hut.fi, Samita.Chakrabarti@eng.sun.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Hi Pekka On 2005/04/04, at 14:13, Pekka Savola wrote: > Hi, > > On Mon, 4 Apr 2005, Ryuji Wakikawa wrote: >> NEMO added only a mobility header option and flags for BU, BA, etc. >> Therefore, modifications for NEMO can be very small. >> >> I sent examples of NEMO APIs to Samita a while ago. >> We did implement and use the NEMO APIs in KAME NEMO implementation. >> It works fine. > > Sorry -- this was not the point I was trying to make. I was taking a > procedural approach to this.. No pb. and I did not try to push anything here:-) > It does not matter all that much what you (as an individual) decide to > do, or what you (as an individual) choose to implement. Of course, > it's nice to see there's interest and implementation of those, though. > (Nothing against you of course personally :) what i wanted to say is that we implemented both NEMO and MIP6 API. MIP6 API is already defined and ready for RFC, but we are also waiting for NEMO API. > The critical thing is whether NEMO WG has reached the rough consensus > that those modifications you (as an individual) proposed are good, and > NEMO WG is fine with them. I don't think there was consensus in NEMO WG. I haven't seen discussion on this. maybe better to post your initial mail to NEMO ML. > For that, I guess NEMO WG chairs would need to put on a hat and take > the sense of the "room", solicit review, etc. agree. > That doesn't need to take long, but if we are going to add anything > about NEMO in the spec, our AD will want us to be double-careful that > those modifications reflect the consensus of the NEMO WG. ok. regards, ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 01:26:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01133 for ; Mon, 4 Apr 2005 01:26:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKEI-0000sM-6h for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 01:34:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK2z-0008CC-6K; Mon, 04 Apr 2005 01:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK2x-0008C4-JX; Mon, 04 Apr 2005 01:22:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00889; Mon, 4 Apr 2005 01:22:47 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKAp-0000if-Q8; Mon, 04 Apr 2005 01:30:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j345MV719370; Mon, 4 Apr 2005 08:22:31 +0300 Date: Mon, 4 Apr 2005 08:22:31 +0300 (EEST) From: Pekka Savola To: Ryuji Wakikawa Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: Message-ID: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com, sgundave@cisco.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Mon, 4 Apr 2005, Ryuji Wakikawa wrote: > If there are exiting transition mechanisms and MN gets v6 address, MN > can operate without changes. This is fine if we forget redundant > tunnel overheads. > > However, what happen when a mobile node roams to just v4 networks. > Can we expect that all wireless networks will deploy with v6 or some > transition mechanism? It makes sense that MIP6 has some way to handle > v4 address by itself (no infrastructure supports). I expect that those nodes might end up running in a network without MIPv6 Home Agent support (e.g., a WLAN interface at home). I assume it would be "really important" for those nodes to obtain IPv6 connectivity (even without Mobile IPv6) in those cases as well. (This is because the node has IPv6 applications which it will continue need to support.) So, I expect the vendors would implement IPv4-IPv6 tunneling/transition mechanisms on the nodes as well (and this has already happened, e.g., look at the Symbian stack). I do not expect that all such wireless networks deploy a transition mechanism, but if a node ends up in one which doesn't, it can always use Teredo, 6to4, a tunnel broker, IPsec tunneling or some other alternative to obtain IPv6 access. However, your scenario does not really differ from here at all. Instead of assuming that the Home Agent is reachable from anywhere at all using v4 (+NAT traversal), we're assuming that a tunnel server is available from anywhere at all using v4 (+NAT traversal) _or_ that the host implements/is able to use 6to4, Teredo, or a number of other mechanisms. Hence, if we don't need to restrict the solution space based on the encapsulation overhead, decoupling the tunneling configuration from Mobile IP protocols seems to make a lot of sense -- because re-using transition mechanisms gives you the superset of functionality. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 01:29:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01386 for ; Mon, 4 Apr 2005 01:29:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKHA-0000wY-Vo for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 01:37:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK5B-0008L1-81; Mon, 04 Apr 2005 01:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK58-0008KO-VN; Mon, 04 Apr 2005 01:25:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01044; Mon, 4 Apr 2005 01:25:02 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKD0-0000l1-6Z; Mon, 04 Apr 2005 01:33:11 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j345OpZ19402; Mon, 4 Apr 2005 08:24:51 +0300 Date: Mon, 4 Apr 2005 08:24:51 +0300 (EEST) From: Pekka Savola To: nemo@ietf.org Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 (I'm not subscribed to nemo, sorry) It was pointed out this should be posted on NEMO WG as well. Does the NEMO WG want to get to the rough consensus on the APIs for NEMO basic support? ---------- Forwarded message ---------- Date: Sat, 2 Apr 2005 11:30:07 +0300 (EEST) From: Pekka Savola To: Samita Chakrabarti Cc: mip6@ietf.org, vnuorval@tcs.hut.fi Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt On Mon, 24 Jan 2005, Samita Chakrabarti wrote: >> Btw, now that the NEMO RFC is out, have you considered adding the NEMO >> definitions to the draft? >> > > The question was brought up before. Currently mip6api draft is in the AD > review. > It is up to the Chairs and ADs to decide whether NEMO API should be bound > with this document or they should be published separately. I happened to get across this while perusing the issue tracker. IMHO, it would seem to make sense to add the NEMO basic support APIs here. As it is NEMO is already an RFC, and as it seems that the updates would be fairly trivial. However, the problem here is whether the proposed NEMO APIs have been sufficiently reviewed by NEMO WG. If NEMO WG chairs would say that there is rough consensus for these and these inclusions, this would be an "OK" signal for us. What we want to avoid is adding NEMO APIs here if such would later be called out to not have been sufficiently reviewed at NEMO WG or lacking consensus there. Obviously, all this still requires some form of approval of the AD, but as the document is still at AD review, i.e., hasn't been passed to the IESG as a whole yet, I don't think it is procedurally too late to kill two birds with one stone. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 01:58:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03206 for ; Mon, 4 Apr 2005 01:58:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKjg-0002S8-0W for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 02:06:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKat-0003I9-Kj; Mon, 04 Apr 2005 01:57:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKar-0003I0-8C; Mon, 04 Apr 2005 01:57:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03142; Mon, 4 Apr 2005 01:57:48 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKik-0002LR-0q; Mon, 04 Apr 2005 02:05:58 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j345vaG21046; Mon, 4 Apr 2005 08:57:37 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 09:14:58 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j346EwJA030814; Mon, 4 Apr 2005 09:14:58 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00F4dtwh; Mon, 04 Apr 2005 09:14:56 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j345vHU21271; Mon, 4 Apr 2005 08:57:17 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 00:57:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnela MIP6/NEMO WGs document Date: Sun, 3 Apr 2005 22:57:16 -0700 Message-ID: Thread-Topic: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnela MIP6/NEMO WGs document Thread-Index: AcU42CAPOE2FW5A9S1Sf//0VDCaU0wAAYszg To: , X-OriginalArrivalTime: 04 Apr 2005 05:57:16.0676 (UTC) FILETIME=[27CE6C40:01C538DB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable hi Pekka, > However, your scenario does not really differ from here at all.=20 > Instead of assuming that the Home Agent is reachable from anywhere at=20 > all using v4 (+NAT traversal), we're assuming that a tunnel server is=20 > available from anywhere at all using v4 (+NAT traversal) _or_=20 > that the=20 > host implements/is able to use 6to4, Teredo, or a number of other=20 > mechanisms. >=20 > Hence, if we don't need to restrict the solution space based on the=20 > encapsulation overhead, decoupling the tunneling configuration from=20 > Mobile IP protocols seems to make a lot of sense -- because re-using=20 > transition mechanisms gives you the superset of functionality. if you see the slides we presented at the IETF, we do emphasize that the mechanism described in draft-wakikawa is to used only when MIPv6 or NEMO is used. instead of setting up a MIP tunnel=20 inside a transition tunnel, we combine the tunnel.=20 I do expect the MN or MR to also implement regular tunneling=20 mechanisms. these mechanisms are used when MIPv6/NEMO is not=20 used for a particular session or if the Home Agent does not=20 support the mechanism in draft-wakikawa. Vijay >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 02:42:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27107 for ; Mon, 4 Apr 2005 02:42:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DILPd-0004VK-1I for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 02:50:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DILGd-0001Eg-KK; Mon, 04 Apr 2005 02:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DILGb-0001Eb-66 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 02:40:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26978 for ; Mon, 4 Apr 2005 02:40:56 -0400 (EDT) Received: from av3-1-sn1.fre.skanova.net ([81.228.11.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DILOT-0004TO-9S for mip6@ietf.org; Mon, 04 Apr 2005 02:49:06 -0400 Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id 11D123813A; Mon, 4 Apr 2005 08:40:46 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 02DC2380FD; Mon, 4 Apr 2005 08:40:46 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id DA2EA37E48; Mon, 4 Apr 2005 08:40:45 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DILGP-0006km-4J; Mon, 04 Apr 2005 08:40:45 +0200 Message-ID: <4250E16C.7060602@levkowetz.com> Date: Mon, 04 Apr 2005 08:40:44 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: <424DEA3C.20205@iprg.nokia.com> <424FF5EA.5000602@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit on 2005-04-04 6:13 am Ryuji Wakikawa said the following: > Hi Henrik > > At Sun, 03 Apr 2005 15:55:54 +0200, > Henrik Levkowetz wrote: >> >> on 2005-04-02 2:41 am Vijay Devarapalli said the following: >> > Soliman, Hesham wrote: >> >> More specific response: >> >> >> >> >> >> > IPv4 hdr (src=CoA_v4, dst=HA_v4) >> >> > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) >> >> > Dst opts hdr >> >> > HoA_v6 >> >> > Mobility hdr >> >> > Binding Update >> >> > >> >> > Hesham, let me know if this is not correct? >> >> >> >> => Correct in the scenario you mentioned. This draft also >> >> supports another scenario: using IPv4 home address and >> >> IPv6 CoA. >> > >> > which we are not interested in and out of scope for this >> > discussion. >> >> Whoops! You individually may not be interested in it, but >> I individually do - and I see no reason why this should be >> out of scope for this discussion. > > I individually don't. > Using MIPv4 in IPv6 networks should be discussed in MIPv4 WG. I didn't interpret Hesham's statement as being about MIPv4. There is a separate draft (draft-tsirtsis-v4v6-mipv4-00.txt) from the same authors which cover mip4. However I agree that if this was the case, it wouldn't belong in MIP6. >> > > Anything that talks about NAT traveral >> >> without keepalives is not useful. >> > >> > that was an oversight. will fix this. >> >> Mph. There is quite a bit more to say about NAT traversal. >> That the current wakikawa draft is under-specifying this is >> putting it mildly ,:-) > > Your updates would be always appreciated. We covered a lot of area in RFC 3519. You could start by checking off the issues covered there, and how they are to be handled. For MIP6 there is the additional issue of how to handle various types of NAT when you're doing route optimization - many of those are the same as those covered quite well in draft-huitema-v6ops-teredo-04.txt . I expect NAT traversal to be important for MIP6 over IPv4, but I don't expect it to be trivial. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 04:11:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04029 for ; Mon, 4 Apr 2005 04:11:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMoA-0008DK-AH for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 04:19:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMfY-000088-0g; Mon, 04 Apr 2005 04:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMfU-00007m-SX; Mon, 04 Apr 2005 04:10:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03979; Mon, 4 Apr 2005 04:10:43 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMnN-0008CX-Jq; Mon, 04 Apr 2005 04:18:55 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IEE00689WU450@dns2.cselt.it>; Mon, 04 Apr 2005 09:58:52 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 04 Apr 2005 10:09:44 +0200 Date: Mon, 04 Apr 2005 10:10:29 +0200 From: Gerardo Giaretta Subject: RE: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document To: Basavaraj.Patil@nokia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [nemo] RE: [Mip6] Consensus call on making IDdraft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU2v5I6v6wC3vU1ROuQO8Y2kW4a4QADu+tQAIfNijA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 08:09:44.0953 (UTC) FILETIME=[A9593E90:01C538ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable >=20 > A couple of clarifications regarding the consensus call: >=20 > 1. The intention is to address the following scenario: > "MIPv6 and NEMO capable Mobile hosts/routers attaching to an IPv4 > access network need the capability to create a tunnel and be connected > to their MIP6 home agents." > This is the scenario that is most applicable for MIP6 deployment. > There are plenty of other scenarios as well. But they are much more > of academic interest at this time and hence not really in the scope > of this discussion. So I would suggst that we do not go off=20 > on a tangent > discussing all these other scenarios. >=20 > Do you agree/disagree that the above scenario is the one that needs > to be solved ASAP? > (Note: It does not imply that other scenarios are irrelevant.=20 > It simply > means that this is the scenario worth working on and has the most=20 > significant priority or value for MIP6 deployment.) > I agree on the priority of this scenario. --Gerardo =20 > 2. ID: draft-wakikawa-nemo-v4tunnel can be used as the baseline. It > does not imply that we are ruling out draft-soliman-v4v6-mipv6 or any > other. The IDs can be combined w.r.t the parts that address=20 > this scenario. > Additionally once it is a WG document, what goes into the ID=20 > is decided > by the WG. So lets not get into arguments of what or whose=20 > draft is the > one that should be made the WG document. >=20 > -Basavaraj >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 05:01:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08262 for ; Mon, 4 Apr 2005 05:01:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINaP-0001e1-7m for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 05:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINQF-0004Ig-B8; Mon, 04 Apr 2005 04:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINQC-0004IP-Hn for mip6@megatron.ietf.org; Mon, 04 Apr 2005 04:59:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08036 for ; Mon, 4 Apr 2005 04:58:58 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINY6-0001bE-UG for mip6@ietf.org; Mon, 04 Apr 2005 05:07:11 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IEE0081MZ2OJ6@dns2.cselt.it> for mip6@ietf.org; Mon, 04 Apr 2005 10:47:12 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 04 Apr 2005 10:58:04 +0200 Date: Mon, 04 Apr 2005 10:58:49 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] draft-soliman and draft-wakikawa To: Vijay Devarapalli Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU3FRBuB09BYks8SgmtqV5TqXDRbwB3NHkw Content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 08:58:04.0937 (UTC) FILETIME=[69DFAF90:01C538F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Hi Vijay, please see below.. >=20 > Gerardo, Keiichi, Hesham and Henrik, >=20 > draft-soliman and draft-wakikawa both talk about binding a v4 > CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > the MN and the HA. the difference is in the way, the CoA is > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > address as the source address in the inner header. I believe > the packet format looks like the following. >=20 > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > Dst opts hdr > HoA_v6 > Mobility hdr > Binding Update >=20 > Hesham, let me know if this is not correct? >=20 > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. >=20 > draft-wakikawa uses a mobility option for carrying the IPv4 > address. >=20 > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > Mobility hdr > Binding Update > IPv4 CoA mobility option >=20 > this is the main difference. >=20 > apart from this, is there is anything else in draft-soliman > that you think is important for the specific scenario we are > talking about (v6 MN/MR accessing v6 HA from a v4 only access > network). >=20 > draft-wakikawa, OTOH, also talks about the following. detailed > MN and HA behavior, IPsec SPD and SAD entries for securing the > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > particular tunneling mechanism and new binding ack status > values. >=20 > personally, I prefer a new mobility option to carry the IPv4 > CoA, because it makes processing on the HA simple. but we can > have the WG decide on this. I am open. >=20 my point was that I'd like to understand the rationale behind this choice (is it only that it makes processing on HA simpler? how do you measure this simpleness?). As stated before, I'm not adovacting any draft, just trying to understand the best approach to register a IPv4 CoA. However, I think this is a secondary issue and we should address it after we all agree on the scenario(s) to be considered.=20 --Gerardo > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 05:06:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08626 for ; Mon, 4 Apr 2005 05:06:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINfH-0001uD-Cm for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 05:14:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINUs-0004WP-T7; Mon, 04 Apr 2005 05:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINUn-0004WB-62; Mon, 04 Apr 2005 05:03:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08479; Mon, 4 Apr 2005 05:03:43 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINch-0001kp-E3; Mon, 04 Apr 2005 05:11:56 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2005 11:03:37 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3493FtF001154; Mon, 4 Apr 2005 11:03:31 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Apr 2005 11:03:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Mon, 4 Apr 2005 11:03:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD857D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Thread-Index: AcU4z8q1ZotHx8JoRpSkjA5U21K/+QAIk+Iw From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 04 Apr 2005 09:03:20.0597 (UTC) FILETIME=[26059450:01C538F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, keiichi@iijlab.net, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] | Sent: Monday, April 04, 2005 6:27 AM | To: Pascal Thubert (pthubert) | Cc: vidya@motorola.com; henrik@levkowetz.com; keiichi@iijlab.net; | nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com | Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa- | nemo-v4tunnel a MIP6/NEMO WGs document |=20 |=20 | Hello Pascal |=20 | At Fri, 1 Apr 2005 15:56:39 +0200, | pascal wrote: | > | > | If most deployments don't have an issue with the placement of the HA | > in | > | the DMZ and a small percentage of the cases do, it does not seem too | > bad | > | to me to say that a solution is simple since it solves the 90% case. | > I'd | > | vote for that rather than make it really complex to also solve the 10% | > | case. | > | | > | > Hi Vidya | > | > I see words about complexity from you and Keiichi. I agree we need to | > look at how complex the proposals are: | > - in terms of standardization | > - in terms of coding | > - and mostly in terms of deployment |=20 | Hmm, I feel that Doors, itself, is complicated. |=20 | My major comments to Doors are | - Doors brought security vulenerability in terms of IP header | modification at intermediate gateways. Do we really want another NAT | like mechanism in IPv6? Note that (but for DHAAD) the careof address is not the source address and does not interact with the upper layer checksum. So changing the careof is not the same thing as a NAT, by far. Also, this happens only in the case of a NAT/PAT/RNAT on the way. Otherwise, the CoA is not changed. Finally, there is a threat coming from the IPv4 NAT when it is present. The source address is changed. We have to cope with that if we find a valid attack against the mechanism that we propose.=20 Now, Doors shows that there's value in combining MIP6 and NAT traversal as opposed to doing them separately. MIP6 provides the keep alive and the states (hidden in the COA), and an evolution from 6to4 provides the gateway and the routing within the IPv6 network. This results in a very little footprint in terms of implementation (once you have MIP6 or NEMO to start with) and yet features like NAT traversal ... even for reverse and symmetrical NATs. | - IPsec operation is not clear to me. |=20 Yes. If there is to be a new version, we'll have to detail this. Then again, the study of the risk that the IPv4 NAT introduces might be necessary as part of the problem statement for IPv5 traversal, regardless of the solution. | > Obviously, a solution that has less constraints is easier to deploy. | > Ending the IPv4 at the HA is a constraint. We have experiments with | > customers who could not do that for very pragmatic reasons. Details | > might be given mater. |=20 | You customers are not only clients using MIP6:-) | There are also requirements such as no infrastructure support and | less tunnel overheads. I don't have customers like cisco, but I know | there are companies seeking a solution for the requirements. |=20 The customers we have been dealing with had more addressing and routing constraints then they had with bandwidth. The only place where bandwidth is critical is over the radio between the MN/MR and the fixed infrastructure using a PPP over your 2.5/3G telephone. This problem exists today and is usually dealt with using Van Jacobson Header Compression and RFC 1976.=20 We could easily include the MRHA header in the Van Jacobson Header Compression. But it might be a little complex to deploy widely. Depends on the success of MIP6 in the first place.=20 | > In terms of coding, I guess that people have to read and understand all | > proposals on the table before they can assess that one thing is more | > complex than another. I would assert that a solution that does not | > change the home agent causes less regression testing then one that does. | > For instance, Doors is a very small footprint hack that leaves the end | > to end MIP untouched. |=20 | Goal of Doors and our solution is cleary different. We assume | different deployment scenarios. We should not compare doors or other | transition mechanism in this thread. |=20 | > In terms of standardization, I'd guess that the same applies. Changing | > MIP inside is not as simple as changing it on the surface. Doors just | > acts on the transport. The Doors gateway can be installed on the HA, | > close to the HA, or by an external provider anywhere. | > | > I'd just suggest that we, as a group, do not presuppose that because | > Doors provides additional features it is necessarily more complex. | > Sometimes, simplicity brings a lot of good things with it. |=20 | Agree. I always like similicity:-) :) Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 05:09:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08910 for ; Mon, 4 Apr 2005 05:09:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINhs-000217-I9 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 05:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINZr-0004yu-Et; Mon, 04 Apr 2005 05:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINZp-0004yh-5D; Mon, 04 Apr 2005 05:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08893; Mon, 4 Apr 2005 05:08:55 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINhh-00020o-Dd; Mon, 04 Apr 2005 05:17:08 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3498KTA025580; Mon, 4 Apr 2005 11:08:48 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 11:08:48 +0200 Received: from emyklnt163.ao.ericsson.se ([150.236.92.63]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 11:08:47 +0200 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Apr 2005 17:08:46 +0800 Message-ID: <2D255349D9B1A04683757BFAD6D367960A556228@ejptont100.nrj.ericsson.se> From: "Shinta Sugimoto (TO/NRJ)" To: mip6@ietf.org, nemo@ietf.org Date: Mon, 4 Apr 2005 17:08:37 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 Apr 2005 09:08:47.0566 (UTC) FILETIME=[E8E916E0:01C538F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Mip6] RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 I will vote for NO at the moment. Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: For [ ] Against [X] Reasons and some random thoughts: - I agree v4 traversal is quite important issue and see benefits in both draft-soliman and draft-wakikawa. However, I agree to some other folks who address a need for more discussions on target scenarios. - I have implemented draft-soliman. From implementor's perspective, I don't see technical difference between the methods to carry IPv4 CoA stated in the two drafts. I would say both methods have no problem and easy to implement. Thus, discussions of complexity wrt implementation does not make sense, IMHO. - Regarding the elimination of redundant IPv6 header proposed in draft-wakikawa, I pretty much agree with the proposal. Saving 40 bytes would greatly help us. - I personally feel that IPv4 HoA support proposed in draft-soliman is a strong feature that can benefit mobile users, which may accelerate deployment of MIPv6. Note that we don't need MIPv4 signaling in such case, but we just need small modifications to the MIPv6 stack. Regards, Shinta > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] > Sent: Thursday, March 31, 2005 4:33 AM > To: mip6@ietf.org; nemo@ietf.org > Subject: [nemo] Consensus call on making ID > draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document > > > > One of the major barriers to the deployment of Mobile IPv6 today is > the fact that most access networks are IPv4 only. A number of hosts > are already dual-stack capable. While Mobile IPv6 works well in IPv6 > networks, it is essential that IPv6 mobility service continue to work > even when the mobile host is attached to an IPv4 network. The same > applies to a NEMO mobile router as well. > > A number of transition scenarios have been identified in IDs: > 1. draft-larsson-v6ops-mip-scenarios-01 > 2. draft-tsirtsis-dsmip-problem-03 > While discussion of these scenarios in the larger scope makes sense, > there is a need to focus on the most critical scenario that would > address the MIP6 host and router problem. The problem in a single > sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need > to be able to reach its (IPv6) home agent and services when roaming in > and attached to an IPv4 access network." > It makes sense to focus on just this one scenario and solve the > problem immediately. > > The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 > mobile node or a NEMO mobile router roaming onto a IPv4 only access > network in a simple manner. > It is intended that the standardization of this solution in the IETFs > MIP6 and/or NEMO working groups proceed. The working group chairs have > reviewed and discussed this work item. It has also been presented at > the MIP6 and NEMO WGs at IETF62. > > The chairs would like to hear your thoughts in order to see if there > is consensus to make it a WG document and progress it as a standards > track RFC. Comments should be sent to both the NEMO and MIP6 WGs. > > If we have consensus, then the document will be pursued as a dual WG > item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > For [ ] > Against [ ] > > > - MIP6 and NEMO WG chairs > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 05:42:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11382 for ; Mon, 4 Apr 2005 05:42:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIOEg-00039j-20 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 05:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIO5A-0007lG-Re; Mon, 04 Apr 2005 05:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIO58-0007l8-3q for mip6@megatron.ietf.org; Mon, 04 Apr 2005 05:41:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11259 for ; Mon, 4 Apr 2005 05:41:16 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIOD2-00037Z-JA for mip6@ietf.org; Mon, 04 Apr 2005 05:49:29 -0400 Received: from [192.168.0.4] (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j349f3Fj031664; Mon, 4 Apr 2005 18:41:03 +0900 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [Mip6] draft-soliman and draft-wakikawa Date: Mon, 4 Apr 2005 18:40:56 +0900 To: Gerardo Giaretta X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit On 2005/04/04, at 17:58, Gerardo Giaretta wrote: > Hi Vijay, > > please see below.. > >> >> Gerardo, Keiichi, Hesham and Henrik, >> >> draft-soliman and draft-wakikawa both talk about binding a v4 >> CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between >> the MN and the HA. the difference is in the way, the CoA is >> conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 >> address as the source address in the inner header. I believe >> the packet format looks like the following. >> >> IPv4 hdr (src=CoA_v4, dst=HA_v4) >> IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) >> Dst opts hdr >> HoA_v6 >> Mobility hdr >> Binding Update >> >> Hesham, let me know if this is not correct? >> >> the HA extracts the IPv4 address from the v4-mapped-v6-CoA. >> >> draft-wakikawa uses a mobility option for carrying the IPv4 >> address. >> >> IPv4 hdr (src=CoA_v4, dst=HA_v4) >> IPv6 hdr (src=HoA_v6, dst=HA_v6) >> Mobility hdr >> Binding Update >> IPv4 CoA mobility option >> >> this is the main difference. >> >> apart from this, is there is anything else in draft-soliman >> that you think is important for the specific scenario we are >> talking about (v6 MN/MR accessing v6 HA from a v4 only access >> network). >> >> draft-wakikawa, OTOH, also talks about the following. detailed >> MN and HA behavior, IPsec SPD and SAD entries for securing the >> IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a >> particular tunneling mechanism and new binding ack status >> values. >> >> personally, I prefer a new mobility option to carry the IPv4 >> CoA, because it makes processing on the HA simple. but we can >> have the WG decide on this. I am open. >> > > my point was that I'd like to understand the rationale behind this > choice (is it only that it makes processing on HA simpler? how do you > measure this simpleness?). As stated before, I'm not adovacting any > draft, just trying to understand the best approach to register a IPv4 > CoA. However, I think this is a secondary issue and we should address > it > after we all agree on the scenario(s) to be considered. Hello Gerardo Supporting NAT traversal or not. For mobile node, it's simpler to clear out MIP6 tunnel and use v4-v6 tunnel. It also removes HoA option from packets while MN is in Ipv4 networks. IPsec protection is also different. In our draft, MN establishes SA for IPv4 addresses. what else.. regards, ryuji > > --Gerardo > >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 06:01:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12899 for ; Mon, 4 Apr 2005 06:01:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIOWq-0003rk-9F for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 06:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIOK0-0000PO-Nw; Mon, 04 Apr 2005 05:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIOJy-0000PB-CR; Mon, 04 Apr 2005 05:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12374; Mon, 4 Apr 2005 05:56:36 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIORs-0003iI-Pk; Mon, 04 Apr 2005 06:04:49 -0400 Received: from [192.168.0.4] (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j349uLFj031767; Mon, 4 Apr 2005 18:56:22 +0900 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCAD857D@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FCAD857D@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document Date: Mon, 4 Apr 2005 18:56:15 +0900 To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, keiichi@iijlab.net, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Hello Pascal On 2005/04/04, at 18:03, Pascal Thubert (pthubert) wrote: > | -----Original Message----- > | From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > | Sent: Monday, April 04, 2005 6:27 AM > | To: Pascal Thubert (pthubert) > | Cc: vidya@motorola.com; henrik@levkowetz.com; keiichi@iijlab.net; > | nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com > | Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID > draft-wakikawa- > | nemo-v4tunnel a MIP6/NEMO WGs document > | > | > | Hello Pascal > | > | At Fri, 1 Apr 2005 15:56:39 +0200, > | pascal wrote: > | > > | > | If most deployments don't have an issue with the placement of the > HA > | > in > | > | the DMZ and a small percentage of the cases do, it does not seem > too > | > bad > | > | to me to say that a solution is simple since it solves the 90% > case. > | > I'd > | > | vote for that rather than make it really complex to also solve > the > 10% > | > | case. > | > | > | > > | > Hi Vidya > | > > | > I see words about complexity from you and Keiichi. I agree we need > to > | > look at how complex the proposals are: > | > - in terms of standardization > | > - in terms of coding > | > - and mostly in terms of deployment > | > | Hmm, I feel that Doors, itself, is complicated. > | > | My major comments to Doors are > | - Doors brought security vulenerability in terms of IP header > | modification at intermediate gateways. Do we really want another > NAT > | like mechanism in IPv6? > > Note that (but for DHAAD) the careof address is not the source address > and does not interact with the upper layer checksum. So changing the > careof is not the same thing as a NAT, by far. OK > Also, this happens only in the case of a NAT/PAT/RNAT on the way. > Otherwise, the CoA is not changed. Well, but it happens when MN moves to NAT network. Most of IPv4 address which I can get in Japan is NAT address... Do we really need address translation in IPv6 for NAT traversal.. > Finally, there is a threat coming from the IPv4 NAT when it is present. > The source address is changed. We have to cope with that if we find a > valid attack against the mechanism that we propose. > > Now, Doors shows that there's value in combining MIP6 and NAT traversal > as opposed to doing them separately. MIP6 provides the keep alive and > the states (hidden in the COA), and an evolution from 6to4 provides the > gateway and the routing within the IPv6 network. > This results in a very little footprint in terms of implementation > (once > you have MIP6 or NEMO to start with) and yet features like NAT > traversal > ... even for reverse and symmetrical NATs. > | - IPsec operation is not clear to me. > | > > Yes. If there is to be a new version, we'll have to detail this. Then > again, the study of the risk that the IPv4 NAT introduces might be > necessary as part of the problem statement for IPv5 traversal, > regardless of the solution. Do you have any section for the study in doors draft?! > > | > Obviously, a solution that has less constraints is easier to > deploy. > | > Ending the IPv4 at the HA is a constraint. We have experiments with > | > customers who could not do that for very pragmatic reasons. Details > | > might be given mater. > | > | You customers are not only clients using MIP6:-) > | There are also requirements such as no infrastructure support and > | less tunnel overheads. I don't have customers like cisco, but I know > | there are companies seeking a solution for the requirements. > | > > The customers we have been dealing with had more addressing and routing > constraints then they had with bandwidth. The only place where > bandwidth > is critical is over the radio between the MN/MR and the fixed > infrastructure using a PPP over your 2.5/3G telephone. This problem > exists today and is usually dealt with using Van Jacobson Header > Compression and RFC 1976. > We could easily include the MRHA header in the Van Jacobson Header > Compression. But it might be a little complex to deploy widely. Depends > on the success of MIP6 in the first place. Header compression is one way. Compression processing cost may be burden though. We need IPv4 traversal to use MIP6 at this point. People said that IPv6 is deployed in japan, but not in wireless networks. regards, ryuji > | > In terms of coding, I guess that people have to read and understand > all > | > proposals on the table before they can assess that one thing is > more > | > complex than another. I would assert that a solution that does not > | > change the home agent causes less regression testing then one that > does. > | > For instance, Doors is a very small footprint hack that leaves the > end > | > to end MIP untouched. > | > | Goal of Doors and our solution is cleary different. We assume > | different deployment scenarios. We should not compare doors or other > | transition mechanism in this thread. > | > | > In terms of standardization, I'd guess that the same applies. > Changing > | > MIP inside is not as simple as changing it on the surface. Doors > just > | > acts on the transport. The Doors gateway can be installed on the > HA, > | > close to the HA, or by an external provider anywhere. > | > > | > I'd just suggest that we, as a group, do not presuppose that > because > | > Doors provides additional features it is necessarily more complex. > | > Sometimes, simplicity brings a lot of good things with it. > | > | Agree. I always like similicity:-) > > :) > > Pascal > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 06:05:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13276 for ; Mon, 4 Apr 2005 06:05:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIOaL-00044o-3m for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 06:13:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIORE-00018B-81; Mon, 04 Apr 2005 06:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIORC-00016u-HH; Mon, 04 Apr 2005 06:04:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13164; Mon, 4 Apr 2005 06:04:04 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIOZ3-0003vB-UB; Mon, 04 Apr 2005 06:12:17 -0400 Received: from [192.168.0.4] (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j34A3bFj031800; Mon, 4 Apr 2005 19:03:37 +0900 In-Reply-To: <2D255349D9B1A04683757BFAD6D367960A556228@ejptont100.nrj.ericsson.se> References: <2D255349D9B1A04683757BFAD6D367960A556228@ejptont100.nrj.ericsson.se> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Date: Mon, 4 Apr 2005 19:03:31 +0900 To: "Shinta Sugimoto (TO/NRJ)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org Subject: [Mip6] Re: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Hi Shinta On 2005/04/04, at 18:08, Shinta Sugimoto (TO/NRJ) wrote: > I will vote for NO at the moment. > > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > For [ ] > Against [X] OK for solution, but do you agree on the scenario? > Reasons and some random thoughts: > > - I agree v4 traversal is quite important issue and see benefits in > both > draft-soliman and draft-wakikawa. However, I agree to some other folks > who address a need for more discussions on target scenarios. If we see clear scenario which we have to deal with. Why we have to start from problem statement... > - I have implemented draft-soliman. From implementor's perspective, > I don't see technical difference between the methods to carry IPv4 CoA > stated in the two drafts. I would say both methods have no problem and > easy to implement. Thus, discussions of complexity wrt implementation > does not make sense, IMHO. Both drafts are small modifications to MIP6. I don't think draft-hesham is complex. We believe that NAT traversal and less tunnelings are important. > - Regarding the elimination of redundant IPv6 header proposed in > draft-wakikawa, I pretty much agree with the proposal. Saving 40 bytes > would greatly help us. :-) > - I personally feel that IPv4 HoA support proposed in draft-soliman is > a strong feature that can benefit mobile users, which may accelerate > deployment of MIPv6. Note that we don't need MIPv4 signaling in such > case, but we just need small modifications to the MIPv6 stack. I still think this IPv4 mobility support in IPv6 should be discussed in MIP4 WG. If people use v6 applications, v4 mobility is not important. regards, ryuji > > > Regards, > Shinta > >> -----Original Message----- >> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] >> Sent: Thursday, March 31, 2005 4:33 AM >> To: mip6@ietf.org; nemo@ietf.org >> Subject: [nemo] Consensus call on making ID >> draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document >> >> >> >> One of the major barriers to the deployment of Mobile IPv6 today is >> the fact that most access networks are IPv4 only. A number of hosts >> are already dual-stack capable. While Mobile IPv6 works well in IPv6 >> networks, it is essential that IPv6 mobility service continue to work >> even when the mobile host is attached to an IPv4 network. The same >> applies to a NEMO mobile router as well. >> >> A number of transition scenarios have been identified in IDs: >> 1. draft-larsson-v6ops-mip-scenarios-01 >> 2. draft-tsirtsis-dsmip-problem-03 >> While discussion of these scenarios in the larger scope makes sense, >> there is a need to focus on the most critical scenario that would >> address the MIP6 host and router problem. The problem in a single >> sentence can be stated as: "Mobile IPv6 hosts and routers (NEMO) need >> to be able to reach its (IPv6) home agent and services when roaming in >> and attached to an IPv4 access network." >> It makes sense to focus on just this one scenario and solve the >> problem immediately. >> >> The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of a MIPv6 >> mobile node or a NEMO mobile router roaming onto a IPv4 only access >> network in a simple manner. >> It is intended that the standardization of this solution in the IETFs >> MIP6 and/or NEMO working groups proceed. The working group chairs have >> reviewed and discussed this work item. It has also been presented at >> the MIP6 and NEMO WGs at IETF62. >> >> The chairs would like to hear your thoughts in order to see if there >> is consensus to make it a WG document and progress it as a standards >> track RFC. Comments should be sent to both the NEMO and MIP6 WGs. >> >> If we have consensus, then the document will be pursued as a dual WG >> item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt >> >> Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: >> For [ ] >> Against [ ] >> >> >> - MIP6 and NEMO WG chairs >> >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 07:02:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17516 for ; Mon, 4 Apr 2005 07:02:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIPTJ-0005zg-DQ for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 07:10:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIPFQ-0005tj-Vm; Mon, 04 Apr 2005 06:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIPFP-0005tb-Kh for mip6@megatron.ietf.org; Mon, 04 Apr 2005 06:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17077 for ; Mon, 4 Apr 2005 06:55:57 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIPNJ-0005mE-Qd for mip6@ietf.org; Mon, 04 Apr 2005 07:04:11 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j34AtZC26434; Mon, 4 Apr 2005 13:55:35 +0300 Date: Mon, 4 Apr 2005 13:55:35 +0300 (EEST) From: Pekka Savola To: Henrik Levkowetz Subject: v4 CoA and route optimization [Re: [Mip6] draft-soliman and draft-wakikawa] In-Reply-To: <4250E16C.7060602@levkowetz.com> Message-ID: References: <424DEA3C.20205@iprg.nokia.com> <424FF5EA.5000602@levkowetz.com> <4250E16C.7060602@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: vijayd@iprg.nokia.com, mip6@ietf.org, Ryuji Wakikawa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Mon, 4 Apr 2005, Henrik Levkowetz wrote: >>> Mph. There is quite a bit more to say about NAT traversal. >>> That the current wakikawa draft is under-specifying this is >>> putting it mildly ,:-) >> >> Your updates would be always appreciated. > > We covered a lot of area in RFC 3519. You could start by > checking off the issues covered there, and how they are to be > handled. > > For MIP6 there is the additional issue of how to handle various > types of NAT when you're doing route optimization - many of those > are the same as those covered quite well in > draft-huitema-v6ops-teredo-04.txt . Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel is likely going to be rather simple (if keepalives are considered OK in the scenario; as Hesham points out, they might be completely unacceptable in some sceanrios [but that's why it could be possible to turn them off it there is no NAT on the path]). NAT traversal for route optimization would be reinventing Teredo (i.e., rather complex and definitely not worth the effort), but as far as I understand, the authors are not proposing addressing this particular thing. MNs could only use the bidirectional tunnel, and if they wanted to do route optimization, they would have to initiate regular transition mechanism on the side. Authors, is this understanding correct? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 07:30:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19790 for ; Mon, 4 Apr 2005 07:30:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIPuU-000745-Ih for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 07:38:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIPhC-00085h-Cw; Mon, 04 Apr 2005 07:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPyA-0000Zh-Nt; Fri, 01 Apr 2005 12:30:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19040; Fri, 1 Apr 2005 12:30:03 -0500 (EST) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQ5U-0003bQ-Vx; Fri, 01 Apr 2005 12:37:43 -0500 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id 9690E2EE13; Fri, 1 Apr 2005 19:29:50 +0200 (CEST) Received: from mx.iit.cnr.it ([127.0.0.1]) by localhost (mx.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11121-20; Fri, 1 Apr 2005 19:29:46 +0200 (CEST) Received: from delmastro1 (delmastrof.iit.cnr.it [146.48.98.74]) by mx.iit.cnr.it (Postfix) with ESMTP id DA8002EE0C; Fri, 1 Apr 2005 19:29:45 +0200 (CEST) Message-ID: <004001c536e0$8943e6f0$4a623092@delmastro1> From: "Franca Delmastro" To: "Franca Delmastro" Date: Fri, 1 Apr 2005 19:30:44 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 0.6 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b X-Mailman-Approved-At: Mon, 04 Apr 2005 07:24:41 -0400 Subject: [Mip6] HICSS-39 minitrack on Wireless Sensor Networks and Applications X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1964893547==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 This is a multi-part message in MIME format. --===============1964893547== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C536F1.4C1EC3B0" This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C536F1.4C1EC3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Apologies for possible multiple copies] --------------------------------------------------------------------- Minitrack on =20 WIRELESS SENSOR NETWORKS AND APPLICATIONS http://www.cs.odu.edu/~olariu/s-minitrack.html =20 to be held within The Software Technology Track of the 39th HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES (HICSS-39) January 4-7, 2006 Hyatt Regency, Kauai (Hawaii) --------------------------------------------------------------------- CALL FOR PAPER Developments in computing and sensing hardware and in wireless = communications have=20 made it technologically feasible and economically viable to develop = low-power sensor=20 nodes that integrate general-purpose computing with multi-purpose = sensing and=20 wireless communications capabilities. Aggregating sensor nodes into = sophisticated=20 sensing, computational and communication infrastructures to form = wireless sensor=20 networks will have a significant impact on a wide array of applications = ranging=20 from military, to scientific, to industrial, to health-care, to = domestic,=20 establishing ubiquitous computing that will pervade society redefining = the way=20 in which we live and work.=20 This minitrack focuses on fundamental challenges arising in the design = of wireless=20 sensor networks and their applications. Our goal is to offer a forum for = high caliber=20 research and experimentation in this booming area. We will provide the = participants=20 with an up-to-date survey on wireless sensor networks and applications.=20 Topics of interest include, but are not limited to: * Sensor-based systems and applications * Visualization of sensor data=20 * Middleware and software tools * Data gathering, aggregation and dissemination * Embedded network-oriented operating systems * Networking architectures and protocols * Hardware aspects of sensor design * Self-organization and governance * Location and mobility management * Topology control and time synchronization * Power Management and energy-efficient design * Cross-layer architectures * Intelligent sensors * Security and dependability issues * Scalability of wireless sensor networks * Interfacing with other wireless/mobile systems * Work models for wireless sensor networks * Modeling and performance evaluation * Implementation experience and measurements * Demos and prototypes PAPER SUBMISSION 1. Manuscript submission is a two-steps process. By April 15, 2005, the = authors are=20 expected to submit a 300-word abstract to the minitrack co-chairs for = guidance and=20 indication of appropriate content. By June 15, 2005 the authors = submit the full=20 manuscript. All the submissions will undergo a rigorous peer review. 2. For the submission of the full manuscript the authors must follow the = instructions=20 available on the HICSS-39 web site = (http://www.hicss.hawaii.edu/HICSS39/apahome39.htm). 3. The manuscript should be no longer than 25 double-spaced pages, = including figures,=20 tables, etc. (the final paper will be 10 pages, double-column, = single-spaced.) 4. The manuscripts are submitted with the understanding that the = material therein is=20 original, and neither previously published nor currently submitted = for consideration=20 elsewhere. 5. Each manuscript must have a title page to include title of the paper, = full name of=20 all authors, and complete addresses including affiliation(s), = telephone number(s)=20 and e-mail address(es). 6. At least one author of each accepted paper must register to attend = the conference=20 (by September 15, 2005). IMPORTANT DATES Preliminary abstract submission April 15, 2005 Submission of full manuscript June 15, 2005 Acceptance/Reject notifications August 15, 2005 Submission of final version September 15, 2005 MINITRACK CO-CHAIRS Giuseppe Anastasi Dept. of Information Engineering University of Pisa Via Diotisalvi 2, 56126 Pisa, Italy E-mail: g.anastasi@iet.unipi.it Edoardo Biagioni Dept. of Information and Computer Science University of Hawaii Honolulu, HI 96822 E-mail: esb@hawaii.edu Stephan Olariu Dept. of Computer Science Old Dominion University Norfolk, VA 23529-0162 E-mail: olariu@cs.odu.edu ************************************************************ Franca Delmastro Pervasive Computing & Networking Lab. (PerLab) IIT- National Research Council via G. Moruzzi,1 56124 Pisa, Italy phone: +39 050 3152407 (direct) ******************************************************** ------=_NextPart_000_003B_01C536F1.4C1EC3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Apologies for possible multiple copies]
 

----------------------------------------------------------------= -----
          &nbs= p;            = ;    =20 Minitrack on  =
         =20 WIRELESS SENSOR NETWORKS AND=20 APPLICATIONS
        http://www.cs.odu.edu/~olariu/s-minitrack.html
          =20
           &nb= sp;           &nbs= p;=20 to be held = within
          The=20 Software Technology Track of the
  39th HAWAII INTERNATIONAL = CONFERENCE=20 ON SYSTEM SCIENCES (HICSS-39)
 
          &nbs= p;            = ;=20 January 4-7,=20 2006
           = ;      =20 Hyatt Regency, Kauai=20 (Hawaii)
-------------------------------------------------------------= --------
 

CALL FOR PAPER
 
Developments in computing and = sensing hardware=20 and in wireless communications have
made it technologically feasible = and=20 economically viable to develop low-power sensor
nodes that integrate = general-purpose computing with multi-purpose sensing and
wireless=20 communications capabilities. Aggregating sensor nodes into sophisticated =
sensing, computational and communication infrastructures to form = wireless=20 sensor
networks will have a significant impact on a wide array of=20 applications ranging
from military, to scientific, to industrial, to = health-care, to domestic,
establishing ubiquitous computing that = will=20 pervade society redefining the way
in which we live and work. =
 
This minitrack focuses on = fundamental challenges=20 arising in the design of wireless
sensor networks and their = applications.=20 Our goal is to offer a forum for high caliber
research and = experimentation=20 in this booming area. We will provide the participants
with an = up-to-date=20 survey on wireless sensor networks and applications.
Topics of = interest=20 include, but are not limited to:
 
* Sensor-based systems and = applications
*=20 Visualization of sensor data
* Middleware and software tools
* = Data=20 gathering, aggregation and dissemination
* Embedded network-oriented=20 operating systems
* Networking architectures and protocols
* = Hardware=20 aspects of sensor design
* Self-organization and governance
* = Location and=20 mobility management
* Topology control and time synchronization
* = Power=20 Management and energy-efficient design
* Cross-layer = architectures
*=20 Intelligent sensors
* Security and dependability issues
* = Scalability of=20 wireless sensor networks
* Interfacing with other wireless/mobile=20 systems
* Work models for wireless sensor networks
* Modeling and=20 performance evaluation
* Implementation experience and = measurements
*=20 Demos and prototypes
 

PAPER SUBMISSION
 
1. Manuscript submission is a = two-steps process.=20 By April 15, 2005, the authors are
   expected to submit a = 300-word abstract to the minitrack co-chairs for guidance and =
  =20 indication of appropriate content. By June 15, 2005 the authors submit = the full=20
   manuscript. All the submissions will undergo a rigorous = peer=20 review.
 
2. For the submission of the full = manuscript the=20 authors must follow the instructions
   available on the = HICSS-39=20 web site (http://www.hicss.hawaii.edu/HICSS39/apahome39.htm).
 
3. The manuscript should be no = longer than 25=20 double-spaced pages, including figures,
   tables, etc. = (the final=20 paper will be 10 pages, double-column, single-spaced.)
 
4. The manuscripts are submitted = with the=20 understanding that the material therein is
   original, = and=20 neither previously published  nor currently submitted for = consideration=20
   elsewhere.
 
5. Each manuscript must have a title = page to=20 include title of the paper, full name of
   all authors, = and=20 complete addresses including affiliation(s), telephone number(s)=20
   and e-mail address(es).
 
6. At least one author of each = accepted paper=20 must register to attend the conference
   (by September = 15,=20 2005).
 

IMPORTANT DATES
 
Preliminary abstract submission =  April 15,=20 2005
Submission of full manuscript  June 15,=20 2005
Acceptance/Reject notifications  August 15, = 2005
Submission=20 of final version  September 15, 2005
 
 
 
MINITRACK CO-CHAIRS
 

Giuseppe Anastasi
Dept. of = Information=20 Engineering
University of Pisa
Via Diotisalvi 2, 56126 Pisa,  = Italy
E-mail: g.anastasi@iet.unipi.it
 
Edoardo Biagioni
Dept. of = Information
and=20 Computer Science
University of Hawaii
Honolulu, HI = 96822
E-mail:=20 esb@hawaii.edu
 
Stephan Olariu
Dept. of Computer=20 Science
Old Dominion University
Norfolk, VA 23529-0162
E-mail:=20 olariu@cs.odu.edu
 
 
 
 
************************************************************
= Franca=20 Delmastro
Pervasive Computing & Networking Lab. = (PerLab)
 
IIT- National Research = Council
via G.=20 Moruzzi,1
56124 Pisa, Italy
phone: +39 050 3152407=20 (direct)
********************************************************
------=_NextPart_000_003B_01C536F1.4C1EC3B0-- --===============1964893547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1964893547==-- From mip6-bounces@ietf.org Mon Apr 4 07:37:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20316 for ; Mon, 4 Apr 2005 07:37:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQ1D-0007FT-Ac for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 07:45:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIPck-0007xh-Kd; Mon, 04 Apr 2005 07:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIPcj-0007xR-S3 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 07:20:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18987 for ; Mon, 4 Apr 2005 07:20:03 -0400 (EDT) Received: from av4-2-sn3.vrr.skanova.net ([81.228.9.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIPkd-0006f4-FW for mip6@ietf.org; Mon, 04 Apr 2005 07:28:17 -0400 Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5229837E5A; Mon, 4 Apr 2005 13:19:54 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 41C3B37E43; Mon, 4 Apr 2005 13:19:54 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 2A7373800C; Mon, 4 Apr 2005 13:19:53 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DIPcX-0007FZ-NX; Mon, 04 Apr 2005 13:19:53 +0200 Message-ID: <425122D8.9090509@levkowetz.com> Date: Mon, 04 Apr 2005 13:19:52 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-soliman and draft-wakikawa] References: <424DEA3C.20205@iprg.nokia.com> <424FF5EA.5000602@levkowetz.com> <4250E16C.7060602@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hi Pekka, On 2005-04-04 12:55 pm Pekka Savola said the following: > On Mon, 4 Apr 2005, Henrik Levkowetz wrote: >>>> Mph. There is quite a bit more to say about NAT traversal. >>>> That the current wakikawa draft is under-specifying this is >>>> putting it mildly ,:-) >>> >>> Your updates would be always appreciated. >> >> We covered a lot of area in RFC 3519. You could start by >> checking off the issues covered there, and how they are to be >> handled. >> >> For MIP6 there is the additional issue of how to handle various >> types of NAT when you're doing route optimization - many of those >> are the same as those covered quite well in >> draft-huitema-v6ops-teredo-04.txt . > > Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel > is likely going to be rather simple (if keepalives are considered OK > in the scenario; as Hesham points out, they might be completely > unacceptable in some sceanrios [but that's why it could be possible to > turn them off it there is no NAT on the path]). In this case, you'll come pretty close to what's covered in NAT traversal for MIPv4 - not complex, but a number of details to keep track of. I think this work should be done. > NAT traversal for route optimization would be reinventing Teredo > (i.e., rather complex and definitely not worth the effort), but as far > as I understand, the authors are not proposing addressing this > particular thing. There is no more, or less, "re-inventing" in this case than in the MN-HA NAT traversal case, and what is required in addition, in order to do route optimization is probably not that much more complex. I think it would be a pity not to look at this, too; but I think that the most sensible split between 'worth doing' and 'not worth doing' might turn out be to solve this for connections with IPv6 hosts, but not for connections with IPv4 hosts. > MNs could only use the bidirectional tunnel, and if they wanted to do > route optimization, they would have to initiate regular transition > mechanism on the side. I think it's premature to try to pin down this as the way to go. (I also think it could be the wrong way to go). Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 08:15:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24650 for ; Mon, 4 Apr 2005 08:15:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQcQ-0000eN-Ch for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 08:23:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQPz-0003wQ-3B; Mon, 04 Apr 2005 08:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQPx-0003wL-9h for mip6@megatron.ietf.org; Mon, 04 Apr 2005 08:10:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24205 for ; Mon, 4 Apr 2005 08:10:56 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQXs-0000WA-SI for mip6@ietf.org; Mon, 04 Apr 2005 08:19:09 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IEF00L977Y954@dns2.cselt.it> for mip6@ietf.org; Mon, 04 Apr 2005 13:58:57 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 04 Apr 2005 14:09:50 +0200 Date: Mon, 04 Apr 2005 14:10:35 +0200 From: Gerardo Giaretta To: Vijay Devarapalli Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Comments on draft-ietf-mip6-ikev2-ipsec-01 Thread-Index: AcU29OUtmrrvbhRSQOWX0p5Fh0EKGwCGeTCQ Content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 12:09:50.0281 (UTC) FILETIME=[3397DB90:01C5390F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] RE: Comments on draft-ietf-mip6-ikev2-ipsec-01 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Hi Vijay, >=20 > hi Gerardo, >=20 > thanks for the review. >=20 > Gerardo Giaretta wrote: > > Hi Vijay, > >=20 > > I have some comments on draft-ietf-mip6-ikev2-ipsec-01. > >=20 > > Overall, the draft looks good. In my opinion, the unique=20 > general issue > > is that it is tied very much to rfc 3776 and as a result it is not > > self-contained. I mean that it is not possible to read the=20 > draft without > > having also rfc3776 in front of you. This is ok to me, but=20 > I wonder if > > it is acceptable in general. >=20 > I guess it can be difficult. I was worried about this too, but didnt > want repeat all the requirements. will ask the working group=20 > about this. > ok.=20 =20 > > Some more detailed comments: > >=20 > > - section 3.2: I don't understand very well how this list should be > > read. The draft states: "The mobile node and the Home Agent=20 > MUST support > > the requirements listed in Section 4 of RFC 3776 with the following > > exceptions" (btw, s/support/fulfill). I'd expect a clear=20 > reference to > > requirements in rfc3776, but I found sometimes difficult to=20 > match the > > requirements and to understand what really changes. Isn't=20 > much clearer > > to state all the requirements (old and new ones)? More=20 > details below. > >=20 > > - section 3.2, bullet 1: in order to be more adherent to=20 > rfc 3776, I'd > > say "It is not required to configure security policies=20 > security policy > > database entries specifically for the tunnel interface in order to > > protect return routability signaling messages". >=20 > okay. >=20 > > - section 3.2, bullet 2: how is this requirement different=20 > from the one > > specified in rfc 3776 (4th bullet page at page 12)? Could=20 > you clarify > > please? >=20 > the text on dynamic keying part has changed. for IKEv1 we talk about > Phase 1. for IKEv2, we talk about IKE_AUTH exchange. but we cant just > state that. need to explain why the HA needs to check if the identity > presented in IKE_AUTH exchange is allowed to create security > associations for a particular home address. >=20 but this is true also for IKEv1, just replacing Phase 1 with IKE_AUTH. Am I wrong? If so, I don't see any real change, only a terminology one. > suggestions to improve this are welcome. >=20 > >=20 > > - section 3.2, bullet 3: maybe I am missing something here,=20 > but how this > > is different from IKEv1 and rfc 3776? >=20 > not different. I see the problem very well now. some requirements I > am repeating from 3776. will fix this, based on what the working > group decides. >=20 okay. My issue is just that with current text it's not clear how some requirements change. > > - section 5.1.1, last paragraph at page 11: "In the examples shown > > above, the home address of the mobile node might not be=20 > available all > > the time." Are you referring to the case where the HoA is=20 > dynamically > > allocated? If yes, I'd mention it at least as an example.=20 >=20 > yes. >=20 > > Moreover, the draft continues: "When the mobile node=20 > acquires a new home > > address, it must add the address to the corresponding SPD=20 > entries." What > > about the HA? Does the HA need to add the address to the=20 > corresponding > > SPD entries or can it keep generic entries? I think it=20 > should add the > > HoA in SPD entries. >=20 > no. if the MN initiates IKE exchange, the HA can just populate the > SPD from the IKE exchange. it doesnt need to create a SPD entry for > a specific HoA. >=20 I saw the proposed text in another email. I'll reply to that one. > > - section 7: this section refers to dynamic HoA assignment.=20 > I wonder if > > this procedure should be explained in this document or in the > > bootstrapping document. Maybe the latter, if needed, can=20 > simply point to > > this one.=20 >=20 > I prefer the bootstrapping document just pointing to this section > for HoA configuration. >=20 sounds good to me. --Gerardo > Vijay >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 08:16:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24705 for ; Mon, 4 Apr 2005 08:16:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQcn-0000f8-E5 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 08:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQQX-000424-QW; Mon, 04 Apr 2005 08:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQQW-00041z-4O for mip6@megatron.ietf.org; Mon, 04 Apr 2005 08:11:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24244 for ; Mon, 4 Apr 2005 08:11:31 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQYS-0000Wq-7V for mip6@ietf.org; Mon, 04 Apr 2005 08:19:44 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IEF00L8L7ZJRJ@dns2.cselt.it> for mip6@ietf.org; Mon, 04 Apr 2005 13:59:43 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 04 Apr 2005 14:10:36 +0200 Date: Mon, 04 Apr 2005 14:11:21 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 To: Vijay Devarapalli Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 Thread-Index: AcU3DjcQn5TTvE1vRs2+zg/9G1F1qgCATj4Q Content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 12:10:36.0765 (UTC) FILETIME=[4F4CC0D0:01C5390F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Hi Vijay, see below... >=20 > hi Gerardo, >=20 > >> - section 5.1.1, last paragraph at page 11: "In the examples shown > >> above, the home address of the mobile node might not be=20 > available all > >> the time." Are you referring to the case where the HoA is=20 > dynamically > >> allocated? If yes, I'd mention it at least as an example.=20 > >=20 > >=20 > > yes. > >=20 > >> Moreover, the draft continues: "When the mobile node=20 > acquires a new home > >> address, it must add the address to the corresponding SPD=20 > entries." What > >> about the HA? Does the HA need to add the address to the=20 > corresponding > >> SPD entries or can it keep generic entries? I think it=20 > should add the > >> HoA in SPD entries. > >=20 > >=20 > > no. if the MN initiates IKE exchange, the HA can just populate the > > SPD from the IKE exchange. it doesnt need to create a SPD entry for > > a specific HoA. >=20 > here is some new text. >=20 > In the examples shown above, the home address of the mobile node > might not be available all the time. For instance, the=20 > mobile node > might have not configured a home address yet. When the=20 > mobile node > acquires a new home address, it must either add the address to the > corresponding SPD entries or create the SPD entries for the home > address. > =20 >=20 > The SPD entries on the home agent are created when the mobile node > initiates IKE exchange. The home agent can also have generic SPD > entries to prevent mobility header traffic that requires IPsec > protection from bypassing the IPsec filters. >=20 > does this look good? >=20 looks good. Thanks, --Gerardo > Vijay >=20 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 08:16:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24777 for ; Mon, 4 Apr 2005 08:16:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQdM-0000jG-On for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 08:24:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQUI-0004QN-K8; Mon, 04 Apr 2005 08:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQUH-0004Py-2J for mip6@megatron.ietf.org; Mon, 04 Apr 2005 08:15:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24632 for ; Mon, 4 Apr 2005 08:15:24 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQcB-0000dm-7j for mip6@ietf.org; Mon, 04 Apr 2005 08:23:37 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2005 14:15:13 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34CEvtH022385; Mon, 4 Apr 2005 14:15:10 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 14:14:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Date: Mon, 4 Apr 2005 14:14:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD86C9@xmb-ams-337.emea.cisco.com> Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Thread-Index: AcU5By6b4LUbf025SCerfU71GDmOjwABq99A From: "Pascal Thubert \(pthubert\)" To: "Pekka Savola" , "Henrik Levkowetz" X-OriginalArrivalTime: 04 Apr 2005 12:14:55.0916 (UTC) FILETIME=[E9C40EC0:01C5390F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, vijayd@iprg.nokia.com, Ryuji Wakikawa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of | Pekka Savola | Sent: Monday, April 04, 2005 12:56 PM | To: Henrik Levkowetz | Cc: vijayd@iprg.nokia.com; mip6@ietf.org; Ryuji Wakikawa | Subject: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft- | wakikawa] |=20 | On Mon, 4 Apr 2005, Henrik Levkowetz wrote: | >>> Mph. There is quite a bit more to say about NAT traversal. | >>> That the current wakikawa draft is under-specifying this is | >>> putting it mildly ,:-) | >> | >> Your updates would be always appreciated. | > | > We covered a lot of area in RFC 3519. You could start by | > checking off the issues covered there, and how they are to be | > handled. | > | > For MIP6 there is the additional issue of how to handle various | > types of NAT when you're doing route optimization - many of those | > are the same as those covered quite well in | > draft-huitema-v6ops-teredo-04.txt . |=20 | Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel | is likely going to be rather simple (if keepalives are considered OK | in the scenario; as Hesham points out, they might be completely | unacceptable in some sceanrios [but that's why it could be possible to | turn them off it there is no NAT on the path]). |=20 Note that MIP has a periodic rebinding, which is the heartbeat of the tunnel. Maybe we need some practical recommendations on how to use it in the face of a NAT but it has a few properties, one being that it can change overtime: - because the MN uses a different interface - because a network condition occurs - you name it In particular, in the face of a NAT, the lifetime can be adapted to be used as a keep alive. In our tests, we usually use 30s as a lifetime, in order to detect the MR unreachability quickly enough from the HA standpoint. This appears to work fine with the NATs we faced. | NAT traversal for route optimization would be reinventing Teredo | (i.e., rather complex and definitely not worth the effort), but as far | as I understand, the authors are not proposing addressing this | particular thing. |=20 | MNs could only use the bidirectional tunnel, and if they wanted to do | route optimization, they would have to initiate regular transition | mechanism on the side. |=20 | Authors, is this understanding correct? |=20 It is true that Doors only deals with MRHA. Note that NEMO does not have RO in the first place, so it's hard to say what it's going to be at that point.=20 Some of the proposed NEMO RO schemes have to do with nested NEMO, and that much can be all IPv6. Others happen fully in the IPv6 Infrastructure (as opposed to end to end) and could be limited to the fully IPv6 part of the way...=20 Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 08:25:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25389 for ; Mon, 4 Apr 2005 08:25:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQlb-0000zZ-9K for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 08:33:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQdI-0006GS-TC; Mon, 04 Apr 2005 08:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIQdH-0006GN-H9 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 08:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25370 for ; Mon, 4 Apr 2005 08:24:42 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIQlA-0000z9-CZ for mip6@ietf.org; Mon, 04 Apr 2005 08:32:56 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 537968129; Mon, 4 Apr 2005 14:24:27 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1DIQbZ-00080G-5h; Mon, 04 Apr 2005 14:22:57 +0200 Date: Mon, 4 Apr 2005 14:22:57 +0200 From: Julien Bournelle To: Vijay Devarapalli Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 Message-ID: <20050404122257.GH30459@ipv6-3.int-evry.fr> References: <424DA74C.4000204@iprg.nokia.com> <424DD1C7.4000007@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424DD1C7.4000007@iprg.nokia.com> User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi vijay, one comment inline, On Fri, Apr 01, 2005 at 02:57:11PM -0800, Vijay Devarapalli wrote: > > >>- section 5.1.1, last paragraph at page 11: "In the examples shown > >>above, the home address of the mobile node might not be available all > >>the time." Are you referring to the case where the HoA is dynamically > >>allocated? If yes, I'd mention it at least as an example. > > > > > >yes. > > > >>Moreover, the draft continues: "When the mobile node acquires a new home > >>address, it must add the address to the corresponding SPD entries." What > >>about the HA? Does the HA need to add the address to the corresponding > >>SPD entries or can it keep generic entries? I think it should add the > >>HoA in SPD entries. > > > > > >no. if the MN initiates IKE exchange, the HA can just populate the > >SPD from the IKE exchange. it doesnt need to create a SPD entry for > >a specific HoA. > > here is some new text. > > In the examples shown above, the home address of the mobile node > might not be available all the time. For instance, the mobile node > might have not configured a home address yet. When the mobile node > acquires a new home address, it must either add the address to the > corresponding SPD entries or create the SPD entries for the home > address. > > > The SPD entries on the home agent are created when the mobile node > initiates IKE exchange. The home agent can also have generic SPD > entries to prevent mobility header traffic that requires IPsec > protection from bypassing the IPsec filters. I'm not sure to well understand this part. Do you mean that the home agent creates the SPD entries for the mobile node after receiving the first IKE packet ? > > does this look good? > > Vijay > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 -- julien.bournelle at int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 10:23:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12165 for ; Mon, 4 Apr 2005 10:23:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DISbq-0007ad-4C for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 10:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DISTS-0000Vp-7R; Mon, 04 Apr 2005 10:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DISTQ-0000VW-CQ for mip6@megatron.ietf.org; Mon, 04 Apr 2005 10:22:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12128 for ; Mon, 4 Apr 2005 10:22:38 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DISbK-0007a6-NI for mip6@ietf.org; Mon, 04 Apr 2005 10:30:53 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IEF00H1NEH490@dns1.cselt.it> for mip6@ietf.org; Mon, 04 Apr 2005 16:19:52 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 04 Apr 2005 16:25:13 +0200 Date: Mon, 04 Apr 2005 16:22:20 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] draft-soliman and draft-wakikawa To: Ryuji Wakikawa Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU4+pkVSmzLnqC8SlW/DAa7Ve6bLgAJsX0g Content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 14:25:13.0296 (UTC) FILETIME=[1D499500:01C53922] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Hi Ryuji, please see below.. > > Hi Vijay, > > > > please see below.. > > > >> > >> Gerardo, Keiichi, Hesham and Henrik, > >> > >> draft-soliman and draft-wakikawa both talk about binding a v4 > >> CoA to a v6 HoA and setting an IPv6 over IPv4 tunnel between > >> the MN and the HA. the difference is in the way, the CoA is > >> conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > >> address as the source address in the inner header. I believe > >> the packet format looks like the following. > >> > >> IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > >> IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > >> Dst opts hdr > >> HoA_v6 > >> Mobility hdr > >> Binding Update > >> > >> Hesham, let me know if this is not correct? > >> > >> the HA extracts the IPv4 address from the v4-mapped-v6-CoA. > >> > >> draft-wakikawa uses a mobility option for carrying the IPv4 > >> address. > >> > >> IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > >> IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > >> Mobility hdr > >> Binding Update > >> IPv4 CoA mobility option > >> > >> this is the main difference. > >> > >> apart from this, is there is anything else in draft-soliman > >> that you think is important for the specific scenario we are > >> talking about (v6 MN/MR accessing v6 HA from a v4 only access > >> network). > >> > >> draft-wakikawa, OTOH, also talks about the following. detailed > >> MN and HA behavior, IPsec SPD and SAD entries for securing the > >> IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > >> particular tunneling mechanism and new binding ack status > >> values. > >> > >> personally, I prefer a new mobility option to carry the IPv4 > >> CoA, because it makes processing on the HA simple. but we can > >> have the WG decide on this. I am open. > >> > > > > my point was that I'd like to understand the rationale behind this > > choice (is it only that it makes processing on HA simpler?=20 > how do you > > measure this simpleness?). As stated before, I'm not adovacting any > > draft, just trying to understand the best approach to=20 > register a IPv4 > > CoA. However, I think this is a secondary issue and we=20 > should address=20 > > it > > after we all agree on the scenario(s) to be considered. >=20 > Hello Gerardo >=20 > Supporting NAT traversal or not. ok=20 > For mobile node, it's simpler to clear out MIP6 tunnel and use v4-v6=20 > tunnel. > It also removes HoA option from packets while MN is in Ipv4 networks. could you clarify this please? > IPsec protection is also different. In our draft, MN=20 > establishes SA for=20 > IPv4 addresses. >=20 Based on rfc3776 and draft-ietf-mip6-ikev2-ipsec-01, the SA must be created for the HoA, that is always an IPv6 address in your scenario. So, what do you mean by "MN establishes SA for IPv4 adresses"? Regards, --Gerardo > what else.. >=20 > regards, > ryuji >=20 > > > > --Gerardo > > > >> Vijay > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia=20 > > S.p.A. > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 11:28:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18468 for ; Mon, 4 Apr 2005 11:28:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITdM-0002ih-Qr for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 11:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITR4-0006QA-UX; Mon, 04 Apr 2005 11:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITR2-0006Q2-Sw for mip6@megatron.ietf.org; Mon, 04 Apr 2005 11:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17821 for ; Mon, 4 Apr 2005 11:24:15 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITYz-0002HQ-Ld for mip6@ietf.org; Mon, 04 Apr 2005 11:32:31 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 11:24:02 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Mon, 4 Apr 2005 11:24:02 -0400 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU44q9EoslHvTVbSvCrFbvjHY7g8wAR3E8A From: "Soliman, Hesham" To: "Henrik Levkowetz" , "Ryuji Wakikawa" X-OriginalArrivalTime: 04 Apr 2005 15:24:02.0680 (UTC) FILETIME=[54F6D780:01C5392A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable > >> >> > Hesham, let me know if this is not correct? > >> >>=20 > >> >> =3D> Correct in the scenario you mentioned. This draft also > >> >> supports another scenario: using IPv4 home address and > >> >> IPv6 CoA.=20 > >> >=20 > >> > which we are not interested in and out of scope for this > >> > discussion. > >>=20 > >> Whoops! You individually may not be interested in it, but > >> I individually do - and I see no reason why this should be > >> out of scope for this discussion. > >=20 > > I individually don't. > > Using MIPv4 in IPv6 networks should be discussed in MIPv4 WG. >=20 > I didn't interpret Hesham's statement as being about MIPv4. > There is a separate draft (draft-tsirtsis-v4v6-mipv4-00.txt) > from the same authors which cover mip4. =3D> Exactly, I wasn't talking about MIP4.I was talking about having=20 an IPv4 HoA, IPv6 CoA and using MIP6.=20 Hesham >=20 > However I agree that if this was the case, it wouldn't belong > in MIP6. >=20 > >> > > Anything that talks about NAT traveral > >> >> without keepalives is not useful.=20 > >> >=20 > >> > that was an oversight. will fix this. > >>=20 > >> Mph. There is quite a bit more to say about NAT traversal. > >> That the current wakikawa draft is under-specifying this is > >> putting it mildly ,:-) > >=20 > > Your updates would be always appreciated.=20 >=20 > We covered a lot of area in RFC 3519. You could start by > checking off the issues covered there, and how they are to be > handled. >=20 > For MIP6 there is the additional issue of how to handle various > types of NAT when you're doing route optimization - many of those > are the same as those covered quite well in > draft-huitema-v6ops-teredo-04.txt . >=20 > I expect NAT traversal to be important for MIP6 over IPv4, but I > don't expect it to be trivial. >=20 > Henrik >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 11:30:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18566 for ; Mon, 4 Apr 2005 11:30:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITeg-0002kF-1L for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 11:38:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITWR-0006oa-1Q; Mon, 04 Apr 2005 11:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITWO-0006o8-SD for mip6@megatron.ietf.org; Mon, 04 Apr 2005 11:29:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18545 for ; Mon, 4 Apr 2005 11:29:46 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITeK-0002jf-Qg for mip6@ietf.org; Mon, 04 Apr 2005 11:38:02 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 11:29:37 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Date: Mon, 4 Apr 2005 11:29:31 -0400 Message-ID: Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Thread-Index: AcU5BxiALtb08RnjRXCUanCQDFCXdgAI5ssg From: "Soliman, Hesham" To: "Pekka Savola" , "Henrik Levkowetz" X-OriginalArrivalTime: 04 Apr 2005 15:29:37.0591 (UTC) FILETIME=[1C963470:01C5392B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, vijayd@iprg.nokia.com, Ryuji Wakikawa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable > Note that AFAIK, NAT traversal between the bidirectional=20 > MN-HA tunnel=20 > is likely going to be rather simple (if keepalives are considered OK=20 > in the scenario; as Hesham points out, they might be completely=20 > unacceptable in some sceanrios [but that's why it could be=20 > possible to=20 > turn them off it there is no NAT on the path]). =3D> Exactly right. This is why in draft-soliman the choice was made to not include the NAT traversal by default. It would be nice=20 if something can be added/removed when needed. For instance,=20 when managing local mobility there is no need for NAT traversal,=20 when managing global mobility you might need it.=20 I haven't read doors/teredo in a looong time and can't remember if there is anything that can be used to turn this on/off. Hesham > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 12:32:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25364 for ; Mon, 4 Apr 2005 12:32:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUdD-00064T-LU for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 12:40:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUUK-0005Yc-MM; Mon, 04 Apr 2005 12:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUUJ-0005YG-8I for mip6@megatron.ietf.org; Mon, 04 Apr 2005 12:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25118 for ; Mon, 4 Apr 2005 12:31:41 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUcG-000601-4x for mip6@ietf.org; Mon, 04 Apr 2005 12:39:58 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34GVKG23426; Mon, 4 Apr 2005 19:31:20 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 19:31:04 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j34GV4Hl001661; Mon, 4 Apr 2005 19:31:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00glK9o8; Mon, 04 Apr 2005 19:31:03 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34GV2M02957; Mon, 4 Apr 2005 19:31:02 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 11:30:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Date: Mon, 4 Apr 2005 09:30:51 -0700 Message-ID: Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] Thread-Index: AcU5CFbaFVZX3xYORO2wyO9v0tywygAKzLOg To: , X-OriginalArrivalTime: 04 Apr 2005 16:30:53.0099 (UTC) FILETIME=[AB5C37B0:01C53933] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, ryuji@sfc.wide.ad.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable > >>> Mph. There is quite a bit more to say about NAT traversal. > >>> That the current wakikawa draft is under-specifying this is > >>> putting it mildly ,:-) > >> > >> Your updates would be always appreciated. > > > > We covered a lot of area in RFC 3519. You could start by > > checking off the issues covered there, and how they are to be > > handled. > > > > For MIP6 there is the additional issue of how to handle various > > types of NAT when you're doing route optimization - many of those > > are the same as those covered quite well in > > draft-huitema-v6ops-teredo-04.txt . >=20 > Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel=20 > is likely going to be rather simple (if keepalives are considered OK=20 > in the scenario; as Hesham points out, they might be completely=20 > unacceptable in some sceanrios [but that's why it could be=20 > possible to=20 > turn them off it there is no NAT on the path]). >=20 > NAT traversal for route optimization would be reinventing Teredo=20 > (i.e., rather complex and definitely not worth the effort),=20 > but as far=20 > as I understand, the authors are not proposing addressing this=20 > particular thing. >=20 > MNs could only use the bidirectional tunnel, and if they wanted to do=20 > route optimization, they would have to initiate regular transition=20 > mechanism on the side. >=20 > Authors, is this understanding correct? yes. thats right. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 12:34:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25566 for ; Mon, 4 Apr 2005 12:34:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUex-0006Bh-E4 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 12:42:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUTz-0005U6-2W; Mon, 04 Apr 2005 12:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUTw-0005Tn-8c for mip6@megatron.ietf.org; Mon, 04 Apr 2005 12:31:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25012 for ; Mon, 4 Apr 2005 12:31:18 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUbt-0005z0-FT for mip6@ietf.org; Mon, 04 Apr 2005 12:39:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2005 18:31:08 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34GV2t5012912; Mon, 4 Apr 2005 18:31:02 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Apr 2005 18:31:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Date: Mon, 4 Apr 2005 18:30:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCAD8858@xmb-ams-337.emea.cisco.com> Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU5BxiALtb08RnjRXCUanCQDFCXdgAI5ssgAAF1JqA= From: "Pascal Thubert \(pthubert\)" To: "Soliman, Hesham" , "Pekka Savola" , "Henrik Levkowetz" X-OriginalArrivalTime: 04 Apr 2005 16:31:01.0284 (UTC) FILETIME=[B03D2640:01C53933] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, vijayd@iprg.nokia.com, Ryuji Wakikawa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Hi Hesham: Since the subject was dormant for a long time, Doors was not updated, maybe since you last read it :) To answer your question, we saw that there are a few operations associated to NAT traversal. In the context of doors: a) as we said, keep alive, which doors associates with the BU lifetime. We have a BU lifetime, the question is the duration, and whether we can afford to turn it to a relatively low value in order to keep NATs active. The MN has heuristics to select a roaming interface, and the cost/bandwidth of that interface is used in that computation.=20 After that, it's the node's policy: If the MN really wants to connect and the only solution is via a NAT, or simply if it's the best way for its seletion algorithm, then it'll pay the cost of a short lifetime and go via the NAT. b) MN operation: it restores its CareOf from the IPv4/UDP headers. Just a few memory copies. The MN can see both the private and the public addresses and ports being used, and compute whether they were NATed by a simple comparison between those. c) Doors gateway operation. Same, plus a specific operation on DHAAD since the upper layer checksum is impacted by the CareOf modification. ~d) There's no impact on the HA or on the MIP6/NEMO protocol being run. As Pekka says, Doors is not a MIP modification but yet another automatic tunneling mechanism, that takes advantage of existing MIP6 mechanisms and states. Out of all this, there's nothing much to turn off. I'd say it automatic. The lifetime adjustment is a MN algorithm based on its config and policy. Same for accepting a NAT on the way. Pascal | -----Original Message----- | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of | Soliman, Hesham | Sent: Monday, April 04, 2005 5:30 PM | To: Pekka Savola; Henrik Levkowetz | Cc: mip6@ietf.org; vijayd@iprg.nokia.com; Ryuji Wakikawa | Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft- | solimananddraft-wakikawa] |=20 |=20 |=20 | > Note that AFAIK, NAT traversal between the bidirectional | > MN-HA tunnel | > is likely going to be rather simple (if keepalives are considered OK | > in the scenario; as Hesham points out, they might be completely | > unacceptable in some sceanrios [but that's why it could be | > possible to | > turn them off it there is no NAT on the path]). |=20 | =3D> Exactly right. This is why in draft-soliman the choice was made | to not include the NAT traversal by default. It would be nice | if something can be added/removed when needed. For instance, | when managing local mobility there is no need for NAT traversal, | when managing global mobility you might need it. | I haven't read doors/teredo in a looong time and can't remember | if there is anything that can be used to turn this on/off. |=20 | Hesham |=20 | > -- | > Pekka Savola "You each name yourselves king, yet the | > Netcore Oy kingdom bleeds." | > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings | > | > _______________________________________________ | > Mip6 mailing list | > Mip6@ietf.org | > https://www1.ietf.org/mailman/listinfo/mip6 | > |=20 | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D | This email may contain confidential and privileged material for the sole | use | of the intended recipient. Any review or distribution by others is | strictly | prohibited. If you are not the intended recipient please contact the | sender | and delete all copies. | = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |=20 |=20 | _______________________________________________ | Mip6 mailing list | Mip6@ietf.org | https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 12:51:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27355 for ; Mon, 4 Apr 2005 12:51:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUv9-00077d-HG for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 12:59:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUcm-0006hM-Ex; Mon, 04 Apr 2005 12:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUcj-0006hD-PS for mip6@megatron.ietf.org; Mon, 04 Apr 2005 12:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26193 for ; Mon, 4 Apr 2005 12:40:23 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUkc-0006dh-HR for mip6@ietf.org; Mon, 04 Apr 2005 12:48:40 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34Ge8g18831; Mon, 4 Apr 2005 19:40:08 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 19:57:32 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j34GvWtb009838; Mon, 4 Apr 2005 19:57:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00qtN3bd; Mon, 04 Apr 2005 19:57:32 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34GdpU21526; Mon, 4 Apr 2005 19:39:51 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 11:39:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Mon, 4 Apr 2005 09:39:46 -0700 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU4+pkVSmzLnqC8SlW/DAa7Ve6bLgAJsX0gAASvSsA= To: , X-OriginalArrivalTime: 04 Apr 2005 16:39:47.0524 (UTC) FILETIME=[E9E70040:01C53934] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > > IPsec protection is also different. In our draft, MN=20 > > establishes SA for=20 > > IPv4 addresses. > >=20 >=20 > Based on rfc3776 and draft-ietf-mip6-ikev2-ipsec-01, the SA must be > created for the HoA, that is always an IPv6 address in your scenario. > So, what do you mean by "MN establishes SA for IPv4 adresses"? the SPD entries will have v4 addresses as tunnel end points. from section 5.2.1 of draft-wakikawa Mobile Router SPD OUT - IF source =3D mr_hoa & destination =3D ha_ipv6 & proto =3D mh & mhtype =3D BU Then use SA ESP Tunnel mode outer src addr =3D mr_ipv4_coA outer dst addr =3D ha_ipv4 Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 12:57:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27876 for ; Mon, 4 Apr 2005 12:57:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIV10-0007MR-9j for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 13:05:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUnj-0007RS-VO; Mon, 04 Apr 2005 12:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUni-0007RJ-OG for mip6@megatron.ietf.org; Mon, 04 Apr 2005 12:51:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27446 for ; Mon, 4 Apr 2005 12:51:44 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUvg-00078X-8I for mip6@ietf.org; Mon, 04 Apr 2005 13:00:01 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34GpUF13285; Mon, 4 Apr 2005 19:51:30 +0300 (EET DST) X-Scanned: Mon, 4 Apr 2005 19:50:59 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j34GoxCM021345; Mon, 4 Apr 2005 19:50:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 009euzSM; Mon, 04 Apr 2005 19:50:57 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j34GonM19956; Mon, 4 Apr 2005 19:50:49 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Apr 2005 11:50:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Date: Mon, 4 Apr 2005 09:50:37 -0700 Message-ID: Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU5BxiALtb08RnjRXCUanCQDFCXdgAI5ssgAAKfhHA= To: , , X-OriginalArrivalTime: 04 Apr 2005 16:50:38.0416 (UTC) FILETIME=[6DDD3D00:01C53936] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, ryuji@sfc.wide.ad.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable =20 > > Note that AFAIK, NAT traversal between the bidirectional=20 > > MN-HA tunnel=20 > > is likely going to be rather simple (if keepalives are=20 > considered OK=20 > > in the scenario; as Hesham points out, they might be completely=20 > > unacceptable in some sceanrios [but that's why it could be=20 > > possible to=20 > > turn them off it there is no NAT on the path]). >=20 > =3D> Exactly right. This is why in draft-soliman the choice was made > to not include the NAT traversal by default. It would be nice=20 > if something can be added/removed when needed. For instance,=20 > when managing local mobility there is no need for NAT traversal,=20 > when managing global mobility you might need it.=20 > I haven't read doors/teredo in a looong time and can't remember > if there is anything that can be used to turn this on/off. draft-wakikawa specifies one mechanism to detect NATs based=20 on IKEv2. and the NAT traversal mechanism can be used only=20 when a NAT is detected. see the draft. so for local mobility,=20 for e.g. if no NAT is detected between the MN and the MAP,=20 NAT traversal is not used. if a NAT is detected between the=20 MN and the HA, NAT traversal is used. we have two options for NAT traversal. if all traffic through=20 the tunnel is protected by ESP, then we use RFC 3948. if ESP is not used, then IPv6-in-UDP-over-IPv4 tunneling is used. and in the slides we presented at the IETF, we had a question for the WG, if we need to come up with another NAT detection mechanisn based on MIPv6 (similar to what MIPv4 does), but we didnt get any response. if the WG thinks we need one based on MIPv6, I have an idea on how to do it. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 13:44:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03851 for ; Mon, 4 Apr 2005 13:44:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIVkq-0001xj-FV for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 13:52:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVbG-0006l8-MK; Mon, 04 Apr 2005 13:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVbF-0006l0-GJ; Mon, 04 Apr 2005 13:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03758; Mon, 4 Apr 2005 13:42:54 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIVjE-0001v3-Jq; Mon, 04 Apr 2005 13:51:12 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2005 10:42:48 -0700 X-IronPort-AV: i="3.91,147,1110182400"; d="scan'208"; a="245206038:sNHT29437610" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j34HgBgF028911; Mon, 4 Apr 2005 10:42:20 -0700 (PDT) Date: Mon, 4 Apr 2005 10:42:11 -0700 (PDT) From: Sri Gundavelli To: Ryuji Wakikawa Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: Message-ID: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Ryuji, > > Hi Sri > > my understanding is that this mechanism willnot be solo solution for > transition scenario. Your concerns are correct for some deployment > scenarios. However, our approach is a way to solve the transition > problem and provides additional features such as less tunnel overhead > and no infrastructure supports. These features are important for > service providers. Sure. The problem you are trying to address and what the doors draft is addressing is not totally different, just the constraints are different. It is better if we first agree up on the problem and look at all these solutions in perspective. Sri > > regards, > ryuji > > > > > At Wed, 30 Mar 2005 22:21:04 -0800 (PST), > Sri Gundavelli wrote: > > > > Hi Ryuji, > > Please see inline ... > > > > > > On Thu, 31 Mar 2005, Ryuji Wakikawa wrote: > > > > > Hello Sri > > > > > > > Other way to say is we would not an extra encap layer, when > > > > the home agent and the transition gateway functions are spread > > > > out. > > > > > > OK, but there is a problem, "double tunneling". > > > Packets have, at least, three IP headers when MN roams to v4 network. > > > Extra bits and processing costs are burden for MIP6/NEMO in IPv4. > > > > > > > That is the cost for going over a transition gateway. The > > transition solutions should not expect the networks to > > overlap, they should provide a way for the network > > administrators to systematically move the v4 network > > out from the v6 cloud in a segmented approach. The solution > > we are debating is about the tight coupling of the v4 and > > v6 networks and requiring fundamental changes to the binding > > cache entries for associating v4 addresses. If the solution > > requires a v4 network all the way to the Home Agent, > > a dual stacked Mobile Router, a modified home agent to > > understand v4 address semantics, wonder why we can't go to > > the next step of replacing the v6 home agent with a v4 home > > agent. Clearly, the solution cannot disregard the problem > > scenarios such as a home agent in a v6 cloud and disjointed > > transition gateway to the v4 cloud. > > > > All I'm saying is that we should agree up on the problem > > scenarios, review the current solutions including doors and > > work towards a solution. > > > > Regards > > Sri > > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 13:47:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04149 for ; Mon, 4 Apr 2005 13:47:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIVng-00027h-66 for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 13:55:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVaP-0006fy-6n; Mon, 04 Apr 2005 13:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVaO-0006fq-3H for mip6@megatron.ietf.org; Mon, 04 Apr 2005 13:42:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03640 for ; Mon, 4 Apr 2005 13:42:01 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIViM-0001tn-5W for mip6@ietf.org; Mon, 04 Apr 2005 13:50:19 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2005 10:41:52 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j34HfUDs003776; Mon, 4 Apr 2005 10:41:38 -0700 (PDT) Date: Mon, 4 Apr 2005 10:41:23 -0700 (PDT) From: Sri Gundavelli To: "Soliman, Hesham" Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org, vijayd@iprg.nokia.com, Pekka Savola , Ryuji Wakikawa , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Hesham, On Mon, 4 Apr 2005, Soliman, Hesham wrote: > > > > Note that AFAIK, NAT traversal between the bidirectional > > MN-HA tunnel > > is likely going to be rather simple (if keepalives are considered OK > > in the scenario; as Hesham points out, they might be completely > > unacceptable in some sceanrios [but that's why it could be > > possible to > > turn them off it there is no NAT on the path]). > > => Exactly right. This is why in draft-soliman the choice was made > to not include the NAT traversal by default. It would be nice > if something can be added/removed when needed. For instance, > when managing local mobility there is no need for NAT traversal, > when managing global mobility you might need it. > I haven't read doors/teredo in a looong time and can't remember > if there is anything that can be used to turn this on/off. Not sure, if I understood what you mean by "turn of NAT traversal". NAT traversal is based on the need. Doors applies some what similar to 3519 NAT detection logic. We plan to revise the Doors draft and clarify text where ever needed. Sri > > Hesham > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 15:39:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15784 for ; Mon, 4 Apr 2005 15:39:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXXp-00089v-Lt for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 15:47:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXHj-0003Is-9v; Mon, 04 Apr 2005 15:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXHh-0003Ik-GB; Mon, 04 Apr 2005 15:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14944; Mon, 4 Apr 2005 15:30:52 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXPh-0007iG-IC; Mon, 04 Apr 2005 15:39:09 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 15:30:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Mon, 4 Apr 2005 15:30:44 -0400 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU4z6UJmxlLfN3WR1qMTaXhvLN/xwAfMAAA From: "Soliman, Hesham" To: "Ryuji Wakikawa" X-OriginalArrivalTime: 04 Apr 2005 19:30:44.0401 (UTC) FILETIME=[CB7A3A10:01C5394C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable > Hesham and Vijay >=20 > Here is the history. > draft-heshams does not support NAT traversal, and I don't see any > solution to solve NAT traversal by using mapped address. =3D> I think you're confusing different issues. The use of mapped=20 addresses is not the issue here. > We will design an extension using mobility option to solve NAT issue > and throw away MIPv4 support which is not our goal in the draft. =3D> MIPv4? I don't see how this is relevant to the discussion. Hesham >=20 > ryuji >=20 > At Fri, 1 Apr 2005 19:43:55 -0500, > Soliman, Hesham wrote: > >=20 > >=20 > > > > I've expressed my opinion on the genreal issue before. > > > > Regarding this topic of comparison, I don't think the=20 > > > > difference you expressed is worth writing new drafts > > > > about. It would be much easier if you just suggest this to > > > > us and we would discuss it. Instead, now we end up with > > > > discussing very similar drafts for no apparent reason, which > > > > takes more cycles. > > > > I respect your right to write a new draft about whatever you > > > > want. But for such a small differemce, you were welcome to > > > > send a comment and discuss it... > > >=20 > > > I was saying the opposite. show me something of value from > > > draft-soliman that is not there in draft-wakikawa and we will > > > take it up from there.. :) > >=20 > > =3D> This is funny indeed, worth the smile :). So a draft comes=20 > > out call it draft A, then draft B comes out much later and the=20 > > argument for having draft B is that it contains everything in > > draft A.... No I won't start from this assumption of course. > > FWIW, I already mentioned that draft-soliman supports other > > scenarios. > >=20 > > Hesham > >=20 > > >=20 > > > > FWIW I prefer not introducing a new option, the current > > > > approach in draft-soliman fits easily within an implementation > > > > as Conny already explained.=20 > > >=20 > > > FWIW, we have implementations of draft-wakikawa too... > > >=20 > > > > Anyway, this is a secondary issue > > > > and something that can be fine tuned much later in=20 > the process. > > >=20 > > > I agree. > > >=20 > > > Vijay > > >=20 > > > >=20 > > > > Hesham > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: mip6-bounces@ietf.org=20 > [mailto:mip6-bounces@ietf.org]On=20 > > > > > Behalf Of > > > > > Vijay Devarapalli > > > > > Sent: Friday, April 01, 2005 6:36 PM > > > > > To: mip6@ietf.org > > > > > Subject: [Mip6] draft-soliman and draft-wakikawa > > > > >=20 > > > > >=20 > > > > > Gerardo, Keiichi, Hesham and Henrik, > > > > >=20 > > > > > draft-soliman and draft-wakikawa both talk about=20 > binding a v4 > > > > > CoA to a v6 HoA and setting an IPv6 over IPv4=20 > tunnel between > > > > > the MN and the HA. the difference is in the way, the CoA is > > > > > conveyed to the HA. draft-soliman uses IPv4 mapped IPv6 > > > > > address as the source address in the inner header.=20 > I believe > > > > > the packet format looks like the following. > > > > >=20 > > > > > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > > > > > IPv6 hdr (src=3Dv4-mapped-v6-CoA, dst=3DHA_v6) > > > > > Dst opts hdr > > > > > HoA_v6 > > > > > Mobility hdr > > > > > Binding Update > > > > >=20 > > > > > Hesham, let me know if this is not correct? > > > > >=20 > > > > > the HA extracts the IPv4 address from the v4-mapped-v6-CoA. > > > > >=20 > > > > > draft-wakikawa uses a mobility option for carrying the IPv4 > > > > > address. > > > > >=20 > > > > > IPv4 hdr (src=3DCoA_v4, dst=3DHA_v4) > > > > > IPv6 hdr (src=3DHoA_v6, dst=3DHA_v6) > > > > > Mobility hdr > > > > > Binding Update > > > > > IPv4 CoA mobility option > > > > >=20 > > > > > this is the main difference. > > > > >=20 > > > > > apart from this, is there is anything else in draft-soliman > > > > > that you think is important for the specific=20 > scenario we are > > > > > talking about (v6 MN/MR accessing v6 HA from a v4=20 > only access > > > > > network). > > > > >=20 > > > > > draft-wakikawa, OTOH, also talks about the=20 > following. detailed > > > > > MN and HA behavior, IPsec SPD and SAD entries for=20 > securing the > > > > > IPv6-over-IPv4 tunnel, NAT traversal, how to negotiate a > > > > > particular tunneling mechanism and new binding ack status > > > > > values. > > > > >=20 > > > > > personally, I prefer a new mobility option to=20 > carry the IPv4 > > > > > CoA, because it makes processing on the HA simple.=20 > but we can > > > > > have the WG decide on this. I am open. > > > > >=20 > > > > > Vijay > > > > >=20 > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > >=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > This email may contain confidential and privileged=20 > > > material for the sole use > > > > of the intended recipient. Any review or distribution by=20 > > > others is strictly > > > > prohibited. If you are not the intended recipient please=20 > > > contact the sender > > > > and delete all copies. > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 15:47:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18035 for ; Mon, 4 Apr 2005 15:47:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXfu-0000g2-1u for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 15:55:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXV6-0005hO-Bu; Mon, 04 Apr 2005 15:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXV4-0005gd-Ae; Mon, 04 Apr 2005 15:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16828; Mon, 4 Apr 2005 15:44:40 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXd2-0000HS-J8; Mon, 04 Apr 2005 15:52:56 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Apr 2005 15:44:31 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2005 15:44:31 -0400 Message-ID: Thread-Topic: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn elaMIP6/NEMO WGs document Thread-Index: AcU4/cfsr0Z5JNPZQSeWwO+755A/SwAUENuw From: "Soliman, Hesham" To: "Ryuji Wakikawa" , "Shinta Sugimoto \(TO/NRJ\)" X-OriginalArrivalTime: 04 Apr 2005 19:44:31.0474 (UTC) FILETIME=[B8738D20:01C5394E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org Subject: [Mip6] RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn elaMIP6/NEMO WGs document X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable > > - I personally feel that IPv4 HoA support proposed in=20 > draft-soliman is > > a strong feature that can benefit mobile users, which may=20 > accelerate > > deployment of MIPv6. Note that we don't need MIPv4=20 > signaling in such > > case, but we just need small modifications to the MIPv6 stack. >=20 > I still think this IPv4 mobility support in IPv6 should be=20 > discussed in=20 > MIP4 WG. > If people use v6 applications, v4 mobility is not important. >=20 =3D> Are you assuming that People will use MIPv4 for their v4 apps and MIPv6 for their v6 apps? If that you're assumption I can understand why you reached that solution. I don't agree with that assumption, or rather I think we should avoid this scenario. It's=20 very inefficient if you're really using MIP for mobility management. = I.e. local and global all handoffs ...etc.=20 So it seems like this kind of disagreement can be discussed in the=20 context of scenarios and problem statement. I hope we can avoid this early rush into "solutions discussions" without understanding=20 the problems. It hasn't worked before. There is no reason why it=20 would work now. Hesham > regards, > ryuji >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 18:06:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17430 for ; Mon, 4 Apr 2005 18:06:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZqZ-0003Qp-JP for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 18:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZhO-0008Nz-I6; Mon, 04 Apr 2005 18:05:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZhN-0008Nr-N9 for mip6@megatron.ietf.org; Mon, 04 Apr 2005 18:05:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17253 for ; Mon, 4 Apr 2005 18:05:30 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZpN-0003PM-Dy for mip6@ietf.org; Mon, 04 Apr 2005 18:13:50 -0400 Received: from jurassic.eng.sun.com ([129.146.88.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j34M5TRr004350; Mon, 4 Apr 2005 16:05:30 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j34M5Tsi782278; Mon, 4 Apr 2005 15:05:29 -0700 (PDT) Message-Id: <200504042205.j34M5Tsi782278@jurassic.eng.sun.com> Date: Mon, 4 Apr 2005 15:02:44 -0700 (PDT) From: Samita Chakrabarti Subject: Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt To: pekkas@netcore.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vQD6dst2W4We3VktOlIJbQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, vnuorval@tcs.hut.fi, ryuji@sfc.wide.ad.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi Pekka, Thanks for comments. See below. > > > > The question was brought up before. Currently mip6api draft is in the AD review. > > It is up to the Chairs and ADs to decide whether NEMO API should be bound > > with this document or they should be published separately. > > I happened to get across this while perusing the issue tracker. > > IMHO, it would seem to make sense to add the NEMO basic support APIs > here. As it is NEMO is already an RFC, and as it seems that the > updates would be fairly trivial. > > However, the problem here is whether the proposed NEMO APIs have been > sufficiently reviewed by NEMO WG. If NEMO WG chairs would say that > there is rough consensus for these and these inclusions, this would be > an "OK" signal for us. > > What we want to avoid is adding NEMO APIs here if such would later be > called out to not have been sufficiently reviewed at NEMO WG or > lacking consensus there. > > Obviously, all this still requires some form of approval of the AD, > but as the document is still at AD review, i.e., hasn't been passed to > the IESG as a whole yet, I don't think it is procedurally too late to > kill two birds with one stone. It is a procedural decision. So far the decision by MIP6 chairs is to move forward with the MIP6 document without the NEMO changes, and NEMO changes would go on a separate doc. when they are ready. Personally, I am OK with whatever makes best sense for the MIP6 community without too much delay of the MIP6 API document, as it is quite ready and well discussed in the MIP6 wg. Regards, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 4 22:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09467 for ; Mon, 4 Apr 2005 22:50:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIeH7-0004Dw-JL for mip6-web-archive@ietf.org; Mon, 04 Apr 2005 22:58:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIe2E-0001tC-UY; Mon, 04 Apr 2005 22:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIe2D-0001sz-4q; Mon, 04 Apr 2005 22:43:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08781; Mon, 4 Apr 2005 22:43:19 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIeAG-00042b-KK; Mon, 04 Apr 2005 22:51:41 -0400 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j352h6OM019796; Tue, 5 Apr 2005 04:43:19 +0200 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 04:43:13 +0200 Received: from emyklnt163.ao.ericsson.se ([150.236.92.63]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 04:43:12 +0200 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Apr 2005 10:43:10 +0800 Message-ID: <2D255349D9B1A04683757BFAD6D367960A556234@ejptont100.nrj.ericsson.se> From: "Shinta Sugimoto (TO/NRJ)" To: "'Ryuji Wakikawa'" Date: Tue, 5 Apr 2005 10:43:07 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 05 Apr 2005 02:43:12.0766 (UTC) FILETIME=[35E881E0:01C53989] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: nemo@ietf.org, mip6@ietf.org Subject: [Mip6] RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Hi Ryuji, Please find my responses inline. > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: Monday, April 04, 2005 7:04 PM > To: Shinta Sugimoto (TO/NRJ) > Cc: mip6@ietf.org; nemo@ietf.org > Subject: Re: [nemo] Consensus call on making ID > draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document > > > Hi Shinta > > On 2005/04/04, at 18:08, Shinta Sugimoto (TO/NRJ) wrote: > > > I will vote for NO at the moment. > > > > Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > > For [ ] > > Against [X] > > OK for solution, but do you agree on the scenario? No. I assume that the scenario we are talking about is based on assumptions that HA and MN are dual stack nodes and only IPv6 is included as target of mobility support. I am personally OK with the assumption on network model. However I don't agree with the latter one. > > Reasons and some random thoughts: > > > > - I agree v4 traversal is quite important issue and see benefits in > > both > > draft-soliman and draft-wakikawa. However, I agree to some > other folks > > who address a need for more discussions on target scenarios. > > If we see clear scenario which we have to deal with. > Why we have to start from problem statement... I stated the reason above. > > - I have implemented draft-soliman. From implementor's perspective, > > I don't see technical difference between the methods to > carry IPv4 CoA > > stated in the two drafts. I would say both methods have no > problem and > > easy to implement. Thus, discussions of complexity wrt > implementation > > does not make sense, IMHO. > > Both drafts are small modifications to MIP6. > I don't think draft-hesham is complex. > We believe that NAT traversal and less tunnelings are important. OK. > > - Regarding the elimination of redundant IPv6 header proposed in > > draft-wakikawa, I pretty much agree with the proposal. > Saving 40 bytes > > would greatly help us. > > :-) > > > - I personally feel that IPv4 HoA support proposed in > draft-soliman is > > a strong feature that can benefit mobile users, which may accelerate > > deployment of MIPv6. Note that we don't need MIPv4 signaling in such > > case, but we just need small modifications to the MIPv6 stack. > > I still think this IPv4 mobility support in IPv6 should be > discussed in > MIP4 WG. > If people use v6 applications, v4 mobility is not important. The reason why I think MIP6 WG should not exclude IPv4 HoA support is that it simply helps MIPv6 to deploy. OTOH, I do not think that MIP6 WG should discuss running MIPv4 in IPv6 network. That should be discussed in MIP4 WG. I clearly see the difference between the two cases. What do you think? Regards, Shinta > > regards, > ryuji > > > > > > > > > Regards, > > Shinta > > > >> -----Original Message----- > >> From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] > >> Sent: Thursday, March 31, 2005 4:33 AM > >> To: mip6@ietf.org; nemo@ietf.org > >> Subject: [nemo] Consensus call on making ID > >> draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document > >> > >> > >> > >> One of the major barriers to the deployment of Mobile IPv6 today is > >> the fact that most access networks are IPv4 only. A number of hosts > >> are already dual-stack capable. While Mobile IPv6 works > well in IPv6 > >> networks, it is essential that IPv6 mobility service > continue to work > >> even when the mobile host is attached to an IPv4 network. The same > >> applies to a NEMO mobile router as well. > >> > >> A number of transition scenarios have been identified in IDs: > >> 1. draft-larsson-v6ops-mip-scenarios-01 > >> 2. draft-tsirtsis-dsmip-problem-03 > >> While discussion of these scenarios in the larger scope > makes sense, > >> there is a need to focus on the most critical scenario that would > >> address the MIP6 host and router problem. The problem in a single > >> sentence can be stated as: "Mobile IPv6 hosts and routers > (NEMO) need > >> to be able to reach its (IPv6) home agent and services > when roaming in > >> and attached to an IPv4 access network." > >> It makes sense to focus on just this one scenario and solve the > >> problem immediately. > >> > >> The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem > of a MIPv6 > >> mobile node or a NEMO mobile router roaming onto a IPv4 only access > >> network in a simple manner. > >> It is intended that the standardization of this solution > in the IETFs > >> MIP6 and/or NEMO working groups proceed. The working group > chairs have > >> reviewed and discussed this work item. It has also been > presented at > >> the MIP6 and NEMO WGs at IETF62. > >> > >> The chairs would like to hear your thoughts in order to > see if there > >> is consensus to make it a WG document and progress it as a > standards > >> track RFC. Comments should be sent to both the NEMO and MIP6 WGs. > >> > >> If we have consensus, then the document will be pursued as > a dual WG > >> item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt > >> > >> Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID: > >> For [ ] > >> Against [ ] > >> > >> > >> - MIP6 and NEMO WG chairs > >> > >> > >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 05:36:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29426 for ; Tue, 5 Apr 2005 05:36:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIkcC-0001D1-0C for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 05:44:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIkQ7-0001VN-Ue; Tue, 05 Apr 2005 05:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIkPy-0001TG-H7 for mip6@megatron.ietf.org; Tue, 05 Apr 2005 05:32:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28919 for ; Tue, 5 Apr 2005 05:32:16 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIkY3-00013n-Ux for mip6@ietf.org; Tue, 05 Apr 2005 05:40:42 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j359VqW07174; Tue, 5 Apr 2005 11:31:52 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j359Vqkr093974; Tue, 5 Apr 2005 11:31:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200504050931.j359Vqkr093974@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Gerardo Giaretta Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 In-reply-to: Your message of Wed, 30 Mar 2005 10:12:16 +0200. Date: Tue, 05 Apr 2005 11:31:52 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 In your previous mail you wrote: I have some comments on draft-ietf-mip6-ikev2-ipsec-01. Overall, the draft looks good. In my opinion, the unique general issue is that it is tied very much to rfc 3776 and as a result it is not self-contained. I mean that it is not possible to read the draft without having also rfc3776 in front of you. This is ok to me, but I wonder if it is acceptable in general. => as the 2401bis is deeply different, for instance it has a syntax for SPD entries, IMHO the document should be rewritten from scratch (and if possible by an IPsec person, ideally someone who participated to 2401bis/IKEv2 development). Some more detailed comments: - section 3.2, bullet 3: maybe I am missing something here, but how this is different from IKEv1 and rfc 3776? => there is a wrong lower case should in place of the MUST for using the care-of address as the source address of packets. Regards Francis.Dupont@enst-bretagne.fr PS: I still believe the document goes to the wrong direction, for instance requiring support for MH type selectors when it is expected than the common policy will be to protect all the packets on the MN-HA tunnel (better for privacy, simpler, and easy to implement by BITW). Another issue is the total lack of implicit or explicit references to the pki4ipsec work... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 16:17:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10609 for ; Tue, 5 Apr 2005 16:17:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIucG-0003mh-2j for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 16:25:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIu5W-000579-Bi; Tue, 05 Apr 2005 15:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIu5U-00053M-9N for mip6@megatron.ietf.org; Tue, 05 Apr 2005 15:51:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01148 for ; Tue, 5 Apr 2005 15:51:45 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuDf-0000E4-8F for mip6@ietf.org; Tue, 05 Apr 2005 16:00:17 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j35JphG15434 for ; Tue, 5 Apr 2005 22:51:43 +0300 (EET DST) X-Scanned: Tue, 5 Apr 2005 22:51:40 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j35Jpe5K018431 for ; Tue, 5 Apr 2005 22:51:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00g8vUtN; Tue, 05 Apr 2005 22:51:39 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j35JpbM26907 for ; Tue, 5 Apr 2005 22:51:37 +0300 (EET DST) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Apr 2005 14:51:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2005 14:51:34 -0500 Message-ID: <456943D540CFC14A8D7138E64843F8535BADAC@daebe101.NOE.Nokia.com> Thread-Topic: Draft version of WG (from IETF62) meeting minutes Thread-Index: AcU6GN8FGi98GQ8xQAaMaH9N9HW5IQ== To: X-OriginalArrivalTime: 05 Apr 2005 19:51:35.0397 (UTC) FILETIME=[DF8AD150:01C53A18] X-Spam-Score: 0.3 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Draft version of WG (from IETF62) meeting minutes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Content-Transfer-Encoding: quoted-printable Minutes of MIP6 WG meeting -------------------------- IETF62 Minneapolis, MN USA Monday, March 7th 2005, 1930-2200 Chairs: Basavaraj Patil and Gopal Dometty Minutes provided by: Suresh Krishnan Agenda bashing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Alper: wants to change the order of item 4 and 5 since framework needs = to be=20 covered before the solutions. Patil: Thinks the order is fine as 4 is = very=20 specific and will not be affected by the choice of the framework Document Status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Raj presenting * Authentication protocol and MN Identity options drafts completed WGLC. Security ADs have raised DISCUSSes=20 IDs to be revised to clarify the motivation (why do we need these?) 3gpp2 has a critical dependency (already past deadlines) * Preconfigured kbm draft is awaiting AD review and feedback * RO security was reviewed by Elywn. Gabriel and Pekka to do the fixes * Lots of comments about bootstrapping in the ML * CN IPSEC draft needs WF review before going to WGLC * IKEv2 ipsec needs reviews from ikev2 experts Extension to Sockets API for Mobile IPv6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D samita presenting No major issues left, just editorial ones. New ID to be issued to fix = WGLC =20 issues working with cairs and ADs AD evaluation comments pointed out that a clearer applicability = statement=20 is needed.and a switch is required on the socket apis to do source = address=20 selection. say CoA vs HoA Needs implementation info to make progress maybe from HUT or WIDE).=20 Implementors need to contact chairs/authors Targeted for INFORMATIONAL miv6 operation with ikev2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Vijay presenting A whole bunch of requirements have been relaxed=20 -> Support for Peer Authorization database, HoA configuration and EAP = changed=20 to MAY -> Clarified that there is no need to use public key mechanism to = authenticate=20 HA if the chosen eap method already is mutual. Open Issues: SA for the BU is not created until the first CREATE_CHILD_SA (requires 3 = rtt rather than 2rtt) SPD entries and dynamically allocated HoA (SPD uses HoA) 3 options -> update SPD when the HoA changes -> reinstall policy entries when the HoA changes -> use a name in SPD and have name point to HoA Jee wants a clarification about use of preshared keys as the method. = Jari talks about adding a reference to a draft Hannes and Pasi have written about = not=20 needing to use PK when EAP mutual authentication is used.He also = mentions that the draft has no home currently. Vijay will add the reference mip6 AAA framework =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Alper presenting The goal of the draft is to identify various frameworks where AAA is = used=20 for mip6 service and agree on one or more to standardize Alper talks about 4 different frameworks and the characteristics of each Framework 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jee is concerened about preconfiguring the HA address and thinks = dynamic=20 assignment of HA is very important. Alper will talk about it later. Framework 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Vijay wants to know how DHCP server know which domain the MN belongs to? Alper thinks that it is immaterial. Will use DHCP ID to correlate Vidya wants to know what happens if the NAS and HA do not belong to the = same=20 domain as the NAS shares SA only with AAA-L(visited)? Greg thinks that = this can work transparently as there is a transitive trust rel between AAA-L and = AAA-H Raj has the same view as Greg. Gopal wants to add info about AAA-H and = AAA-L. Framework 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jari wants to know how MN can know CoA and HA before initiating the = procedure. Greg thinks that there is no need to know as the AAA can do the BU James wants to know how the AAA server can know where the prefix is.Greg = thinks that it will come from the NAS. Alper thinks that this framework is = workeable=20 but complex. There are three requirements for a solution to fulfill. HA discovery, = HoA=20 discovery, and MN-HA key generation Hannes and Alper talk about how these frameworks can be mix-n-matched=20 to satisfy these requirements Jari is concerened about the impact caused on network since the goal is = to=20 reuse the exisiting AAA relationship. Client software, DHCP and NAS need = to be=20 updated to implement these solution. Summary: Framework4: requires new aaa-mip6 application Framework1: requires confirmation from ip conf sec bof Framework2: needs new AAA attributes and PANA/DHCP options (*3gpp2 = prefers this approach) Framework3: Very complex and may not be justifiable Alper wants direction from the WG to know which way to go. Gopal wants = people=20 to read the drafts and discuss on the ML MIP6 Bootstrapping james kempf presenting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tries to address situations where loose trust between serving network = access=20 provider and Mobility Service Provider(MSP).e.g. enterprise networks,=20 hotspots (As most of them use Credit Cards to authorize and not AAA), = and for=20 infrastructureless deployments very well) John thinks that UAM (universal access method) is popular now but there = are=20 still backend AAA networks. He also thinks that 802.1x means more and = more=20 RADIUS as UAM does not work on small devices. James believes that CC = based=20 authentication is not going away and we need to support it. Jari thinks = that this method does not fit a mobility scenario since the CC based = authentication is used maily for wireless nodes in hostpots (usually immobile). The basic idea is for the MN to ask for DNS SRV records a to get the HA = address Then IKEv2 is used to extablish MN-HA keying. Replay protection provided = by=20 Message identity code in DNS (RFC1035) and data integrity and origin = auth=20 provided by DNSSEC. Alper wants to know how the HA will authenticate the MN. James thinks it = will be preprovisioned credentials like EAP username/password, preshared keyz = etc. Alper is concerned about sharing the HA address with external networks.=20 James is not worried even though DNS has no authentication. He also = clarifies that this is meant to be used in the absence of RADIUS=20 Raj is worried about DNS caching HA address. Thomas is also concerned.=20 Hannes wants to decouple the two problems addressed in the draft 1) use = IKEv2 for bootstrapping and 2) use DNS for discovery. He also suggests the=20 possiblity of using multi hop PANA James wants to use DNS TSIG (RFC2845) for protecting HA addresses. = Thomas thinks that nobody needs this. James thinks that if addresses are hard = to get it makes DoS harder. Thomas thinks that James is very unclear. He wants = to know what is really being protected. MN from bogus DNS replies or the DNS = server=20 from bogus DNS requests? James says both scenarios are protected againt. Samita clarifies that DNSSEC is not deault and is optinal.=20 Raj thinks this makes DOS attacks easier Thomas disagrees and states = that he likes this solution. This is nice and simple instead of the other = complex=20 solutions. He likens publishing the HA address to Wells Fargo = advertising its 1-800 Number. Goals for AAA-HA interface: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Gerardo presenting The document describes design goals and requirements on interface = between=20 AAA and the HA. The purpose of the document is to allow matching goals = and=20 frameworks.=20 Raj wants to know if the draft should become a wg item in its current = form? James supports the document but wants to wait for the output of the=20 Bootstrapping Design Team(BSDT) to proceed further. Vijay disagrees (he = does=20 not want to wait). Alper wants to choose framework before doing this as = he thinks that we cannot choose anything other than Framework with this.=20 Gopal wants to know if the goals are related mainly to bootstrapping. Gerardo says there are other goals like accounting. Patil and Gopal = think that it is a good idea to do this independently as there are other goals. Location privacy=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Rajeev presenting=20 koodli-mip6 Intro- specific scope for MIPv6 HOa - visible in all packets the MN uses it home or visited network COA - visible at visited networks Problem Hoa COA could be profiled for activity COA reveals roaming of a mobile node node when HoA is used Profile: -can use privacy ext, to IPv6 (rfc3041) - Can introduce additional MIP6 signalling ( when coa changes ) Profiling problem Using 3041 introduces DNS and IPSec considerations DNS , IPsec (rekeying for change in Hoa) Roaming problem - reverse tunnel data packets (to solve COA problem) Privacy Label Computation Don't send HoA in the BU in the clear - use in label Label should be computable without the knowledge of HoA Mobopts will discuss this initially and similar other proposals. It will be adopted by MIpv6 wg. ipv4 traversal for mip6 protocols =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Vijay presenting This is useful if the MN lands on v4 only network. The MN registers ipv4 address as CoA using a new mobility option and can setup all types of tunnels. 6 over 4, ESP, UDP etc. use same=20 mechanism for mip6 and nemo Is there interest to do this in the wg? Gopal thinks that we should discuss this for the next IETF. Greg thinks = that=20 it looks interesting. He thinks we should have a bar bof.(Not just = looking to get to the bar, he says) Raj wants to know if the wg should work on location privacy: (CONSENSUS CALL) yes? about 30 hands no? no hands (CONSENSUS IN FAVOR) Next steps for WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Gopal presenting -> Address AD/IESG comments on auth option -> Bootstrapping solution solution ID by next IETF.=20 Close design team shortly after next IETF last call and IESG by IETF64 -> mip6 transition issues Gopal wants an ID to document transition issues Vijay thinks it is a bad idea to write an all encompassing problem = statement. Raj and Gopal agree with Vijay. Thomas thinks that this problem has been = around for long and v6 v4 transition issues should be documented by = someone=20 who ACTUALLY has a problem. Otherwise we will have a huge problem space Gopal wants to define the problem space to be as narrow as possible. = Thomas=20 wants to agree on the scope of the problem before solving it ->work with mobopts to define and suggest privacy solutions ->propose revision to milestones Rajeev wants to know the timeline for the mobopts work. Gopal mentions = that it should be done before the next IETF. mobile firewalls =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiu presenting The idea is for the HA to control the activities of the MN in a visited network. Raj wants to know if this is applicable only with HMIP. Qiu says it is. = He also mentions that it is a scenario to illustrate out a general scheme. PF_KEY between mipv6 and ipsec =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Shinta presenting MIP6 uses IPSEC to protect signalling messages. SA pairs need to be = established and tunnel mode SAs need to be updated when the CoA changes. MIP6 may = not have direct access to the SADB. Defines a new PF_KEY message called MIGRATE PF_KEY MIGRATE requires update of SAD and SPD This has already been implemented Vijay thinks this is very good work. Hannes has worked on a similar = document=20 which is more generic and wants a slot to talk about it (OUT OF TIME) Raj mentions a draft from James/Vijay about HA unavailable message which = is=20 sent when a HA is going down. It needs to be discussed in the ML (END OF MEETING) People referenced in minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Basavaraj Patil (Raj) Gabriel Montenegro (Gabriel) Pekka Nikander (Pekka) Elwyn Davies (Elwyn) Vijay Devarapalli (Vijay) Junghoon Jee (Jee) Jari Arkko (Jari) Hannes Tschofenning (Hannes) Pasi Eronen (Pasi) Alper Yegin (Alper) Vidya Narayanan (Vidya) Greg Daley (Greg) James Kempf (James) John Loughney (John) Thomas Narten (Thomas) Gerardo Giaretta (Gerardo) Rajeev Koodli (Rajeev) Gopal Dommetty (Gopal) Qiu Ying (Qiu) Shinta Sugimoto (Shinta) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 20:17:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04156 for ; Tue, 5 Apr 2005 20:17:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyMw-00051q-Jb for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 20:26:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyDZ-0004MJ-Fm; Tue, 05 Apr 2005 20:16:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyDX-0004MB-K1 for mip6@megatron.ietf.org; Tue, 05 Apr 2005 20:16:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04088 for ; Tue, 5 Apr 2005 20:16:19 -0400 (EDT) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyLl-00050T-JL for mip6@ietf.org; Tue, 05 Apr 2005 20:24:54 -0400 Received: from shiraz.levkowetz.com (213.64.174.195) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 41E3200D00B5E397 for mip6@ietf.org; Wed, 6 Apr 2005 02:16:12 +0200 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DIyDK-0000B5-TV for mip6@ietf.org; Wed, 06 Apr 2005 02:16:11 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Wed, 06 Apr 2005 00:16:06 +0000 MIME-Version: 1.0 Message-Id: <1112746566.85.0.870100930868.issue17@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue17] Requirement for CoA as source address during IKE exchange X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable New submission from Vijay Devarapalli : Francis Dupont wrote: =3D> there is a wrong lower case should in place of the MUST for using the care-of address as the source address of packets. ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 58 nosy: vijay priority: Must fix status: Pending title: Requirement for CoA as source address during IKE exchange _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 20:23:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04584 for ; Tue, 5 Apr 2005 20:23:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIySw-0005EC-DY for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 20:32:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyFT-0004XX-MO; Tue, 05 Apr 2005 20:18:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyFS-0004XS-G8 for mip6@megatron.ietf.org; Tue, 05 Apr 2005 20:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04235 for ; Tue, 5 Apr 2005 20:18:18 -0400 (EDT) Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyNh-00053C-R7 for mip6@ietf.org; Tue, 05 Apr 2005 20:26:54 -0400 Received: from shiraz.levkowetz.com (213.64.174.195) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 41E3200D00B5E3D8 for mip6@ietf.org; Wed, 6 Apr 2005 02:18:13 +0200 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DIyFI-0001ze-M7 for mip6@ietf.org; Wed, 06 Apr 2005 02:18:13 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Wed, 06 Apr 2005 00:18:12 +0000 MIME-Version: 1.0 Message-Id: <1112746692.64.0.116233013619.issue18@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue18] Tunnel mode SPD should be the default X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable New submission from Vijay Devarapalli : Francis Dupont wrote: PS: I still believe the document goes to the wrong direction, for instance requiring support for MH type selectors when it is expected than the common policy will be to protect all the packets on the MN-HA tunnel (better for privacy, simpler, and easy to implement by BITW). ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 60 nosy: vijay priority: Should fix status: Pending title: Tunnel mode SPD should be the default _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 20:35:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05434 for ; Tue, 5 Apr 2005 20:35:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyea-0005cQ-AX for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 20:44:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyRE-0007Ro-I7; Tue, 05 Apr 2005 20:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyRB-0007RZ-LZ for mip6@megatron.ietf.org; Tue, 05 Apr 2005 20:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04948 for ; Tue, 5 Apr 2005 20:30:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyZP-0005PU-UI for mip6@ietf.org; Tue, 05 Apr 2005 20:39:01 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3600kK11444; Tue, 5 Apr 2005 17:00:46 -0700 X-mProtect: <200504060000> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpd9UPPzk; Tue, 05 Apr 2005 17:00:45 PDT Message-ID: <42531F78.1060009@iprg.nokia.com> Date: Tue, 05 Apr 2005 16:30:00 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <200504050931.j359Vqkr093974@givry.rennes.enst-bretagne.fr> In-Reply-To: <200504050931.j359Vqkr093974@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > Some more detailed comments: > > - section 3.2, bullet 3: maybe I am missing something here, but how this > is different from IKEv1 and rfc 3776? > > => there is a wrong lower case should in place of the MUST for using > the care-of address as the source address of packets. the MN cant use anything other than CoA as source address of IKE exchange. so why is there a need for a MUST? thats the only way to do it. > PS: I still believe the document goes to the wrong direction, for instance > requiring support for MH type selectors when it is expected than the > common policy will be to protect all the packets on the MN-HA tunnel > (better for privacy, simpler, and easy to implement by BITW). the MN can always negotiate SAs so that all traffic is sent through the MN-HA tunnel. but I find it wierd not to take advantage of the additional selectors provided by 2401bis. it is better for privacy I agree. see section 2.1 of http://www.ietf.org/internet-drafts/draft-koodli-mip6-location-privacy-solutions-00.txt but that shouldnt be the default mode, IMHO. > Another issue is the total lack of implicit or explicit references to > the pki4ipsec work... what should we be in specific referring to? to draft-ietf-pki4ipsec-ikecert-profile or to some section in it? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 5 20:41:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05824 for ; Tue, 5 Apr 2005 20:41:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIykY-0005og-Rj for mip6-web-archive@ietf.org; Tue, 05 Apr 2005 20:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIya6-0002Qt-TI; Tue, 05 Apr 2005 20:39:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIya6-0002Pa-1s for mip6@megatron.ietf.org; Tue, 05 Apr 2005 20:39:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05629 for ; Tue, 5 Apr 2005 20:39:40 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyiK-0005jF-ET for mip6@ietf.org; Tue, 05 Apr 2005 20:48:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j360A0R19112; Tue, 5 Apr 2005 17:10:00 -0700 X-mProtect: <200504060010> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdgQMtjK; Tue, 05 Apr 2005 17:09:58 PDT Message-ID: <425321A1.2090502@iprg.nokia.com> Date: Tue, 05 Apr 2005 16:39:13 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <424DA74C.4000204@iprg.nokia.com> <424DD1C7.4000007@iprg.nokia.com> <20050404122257.GH30459@ipv6-3.int-evry.fr> In-Reply-To: <20050404122257.GH30459@ipv6-3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Julien Bournelle wrote: >> >>here is some new text. >> >> In the examples shown above, the home address of the mobile node >> might not be available all the time. For instance, the mobile node >> might have not configured a home address yet. When the mobile node >> acquires a new home address, it must either add the address to the >> corresponding SPD entries or create the SPD entries for the home >> address. >> >> >> The SPD entries on the home agent are created when the mobile node >> initiates IKE exchange. The home agent can also have generic SPD >> entries to prevent mobility header traffic that requires IPsec >> protection from bypassing the IPsec filters. > > > I'm not sure to well understand this part. > Do you mean that the home agent creates the SPD entries for the mobile > node after receiving the first IKE packet ? yes. in the case of a dynamically assigned/auto-configured home address an SPD entry for a specific home address is created only when the HA gets to know about the home address of the MN. the HA itself could be allocating the home address during the IKE exchange. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 06:34:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25511 for ; Wed, 6 Apr 2005 06:34:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ80B-0000ZF-Ht for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 06:43:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7kQ-00049n-Di; Wed, 06 Apr 2005 06:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7kO-00049i-KE for mip6@megatron.ietf.org; Wed, 06 Apr 2005 06:26:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23800 for ; Wed, 6 Apr 2005 06:26:53 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ7sh-0000CS-Ps for mip6@ietf.org; Wed, 06 Apr 2005 06:35:33 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j36AQbU24187; Wed, 6 Apr 2005 12:26:37 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j36AQb3N099177; Wed, 6 Apr 2005 12:26:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200504061026.j36AQb3N099177@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 In-reply-to: Your message of Tue, 05 Apr 2005 16:30:00 PDT. <42531F78.1060009@iprg.nokia.com> Date: Wed, 06 Apr 2005 12:26:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 In your previous mail you wrote: > Some more detailed comments: > > - section 3.2, bullet 3: maybe I am missing something here, but how this > is different from IKEv1 and rfc 3776? > > => there is a wrong lower case should in place of the MUST for using > the care-of address as the source address of packets. the MN cant use anything other than CoA as source address of IKE exchange. so why is there a need for a MUST? thats the only way to do it. => so we agree the draft should be fixed. > PS: I still believe the document goes to the wrong direction, for instance > requiring support for MH type selectors when it is expected than the > common policy will be to protect all the packets on the MN-HA tunnel > (better for privacy, simpler, and easy to implement by BITW). the MN can always negotiate SAs so that all traffic is sent through the MN-HA tunnel. but I find it wierd not to take advantage of the additional selectors provided by 2401bis. => I am not against to take advantage, only to make this mandatory. it is better for privacy but that shouldnt be the default mode, IMHO. => I agree, the default mode should be the same than in 3776, i.e., MH protocol as the selector. But the two others (all traffic and only the critical MH types) have to be allowed. > Another issue is the total lack of implicit or explicit references to > the pki4ipsec work... what should we be in specific referring to? to draft-ietf-pki4ipsec-ikecert-profile or to some section in it? => IMHO the most of the text is relevant, for instance 3.1.1 o the administrator intends the implementation to verify that the peer source address matches the IP address in the ID received, and that in the iPAddress field in the peer certificate's SubjectAltName extension. ... In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header. If ID is one of the IP address types, then implementations MUST perform this verification by default. If this default is enabled, then a mismatch MUST be treated as an error and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e. local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as today implementations vary greatly in how they behave on the topic of verification of source IP. So in your draft section 5.2 the first option should not be recommended (i.e., it should be used only when the two (and far better) others are not available). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 06:36:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25828 for ; Wed, 6 Apr 2005 06:36:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ822-0000ex-2W for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 06:45:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7t3-0005fr-RR; Wed, 06 Apr 2005 06:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7t2-0005eo-7o for mip6@megatron.ietf.org; Wed, 06 Apr 2005 06:35:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25725 for ; Wed, 6 Apr 2005 06:35:49 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ81M-0000dC-UF for mip6@ietf.org; Wed, 06 Apr 2005 06:44:29 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j36AZbU24616; Wed, 6 Apr 2005 12:35:37 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j36AZbmY099217; Wed, 6 Apr 2005 12:35:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200504061035.j36AZbmY099217@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 In-reply-to: Your message of Tue, 05 Apr 2005 16:39:13 PDT. <425321A1.2090502@iprg.nokia.com> Date: Wed, 06 Apr 2005 12:35:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Gerardo Giaretta , Julien Bournelle , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 In your previous mail you wrote: > I'm not sure to well understand this part. > Do you mean that the home agent creates the SPD entries for the mobile > node after receiving the first IKE packet ? yes. in the case of a dynamically assigned/auto-configured home address an SPD entry for a specific home address is created only when the HA gets to know about the home address of the MN. the HA itself could be allocating the home address during the IKE exchange. => IMHO the verb "create" is too strong because an SPD entry can exist without addresses (addresses are only a form of selectors), quoting 2401bis draft: - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: 1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors." The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names. I believe we are in this case (and note its support is mandatory) even in the real world one can't see the difference with your proposal. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 07:41:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00416 for ; Wed, 6 Apr 2005 07:41:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ92p-0003V5-9C for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 07:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8nw-0004L4-8h; Wed, 06 Apr 2005 07:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8nu-0004Ku-Ex; Wed, 06 Apr 2005 07:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29686; Wed, 6 Apr 2005 07:34:37 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ8wE-0003E1-Js; Wed, 06 Apr 2005 07:43:15 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j36Bgp8E011074; Wed, 6 Apr 2005 04:42:54 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j36BZiQG012570; Wed, 6 Apr 2005 06:35:45 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 69B23865980; Wed, 6 Apr 2005 13:34:28 +0200 (CEST) Message-ID: <4253C944.5080906@motorola.com> Date: Wed, 06 Apr 2005 13:34:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document References: <7892795E1A87F04CADFCCF41FADD00FCAD857D@xmb-ams-337.emea.cisco.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, "Pascal Thubert \(pthubert\)" , henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >> Also, this happens only in the case of a NAT/PAT/RNAT on the way. >> Otherwise, the CoA is not changed. > > Well, but it happens when MN moves to NAT network. > Most of IPv4 address which I can get in Japan is NAT address... > Do we really need address translation in IPv6 for NAT traversal.. We don't need IPv6 NAT but we're imposed NAT when v6 traverses v4 networks... >> Finally, there is a threat coming from the IPv4 NAT when it is present. >> The source address is changed. We have to cope with that if we find a >> valid attack against the mechanism that we propose. Yes, and securing this excludes IPsec, and can only rely on tokens in UDP messages, eventually within the non-BU keepalives. >> We could easily include the MRHA header in the Van Jacobson Header >> Compression. But it might be a little complex to deploy widely. Depends >> on the success of MIP6 in the first place. > > Header compression is one way. Isn't header compression a non-end-to-end feature? I thought HC happens only between the terminal and the first hop. So if the requirement is not to touch the v4 network (just traverse it) then HC is no use. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 07:46:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00972 for ; Wed, 6 Apr 2005 07:46:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ97l-0003ig-U2 for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 07:55:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8u4-0005Bu-Ea; Wed, 06 Apr 2005 07:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8u3-0005Bp-Jw for mip6@megatron.ietf.org; Wed, 06 Apr 2005 07:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00349 for ; Wed, 6 Apr 2005 07:40:58 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ92O-0003Tc-2R for mip6@ietf.org; Wed, 06 Apr 2005 07:49:37 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36BhI24014547; Wed, 6 Apr 2005 04:43:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j36Bgoam015329; Wed, 6 Apr 2005 06:42:50 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 96927865980; Wed, 6 Apr 2005 13:40:55 +0200 (CEST) Message-ID: <4253CAC7.9090008@motorola.com> Date: Wed, 06 Apr 2005 13:40:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: <424DEA3C.20205@iprg.nokia.com> In-Reply-To: <424DEA3C.20205@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> Anything that talks about NAT traveral without keepalives is not >> useful. > > that was an oversight. will fix this. Yes, but how? When you say "will fix this" and give no detail or potential idea about how this could be done, it sounds like you already know how to do it and not care very much about the scoping or requirements (that don't yet exist anyways). I may be wrong with my interpretation of "will fix this" - sorry - but that's what it sounds to me at this second affirmation. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 07:48:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01213 for ; Wed, 6 Apr 2005 07:48:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ99l-0003mD-5S for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 07:57:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8yt-0005kK-Ca; Wed, 06 Apr 2005 07:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8yr-0005gg-Q4 for mip6@megatron.ietf.org; Wed, 06 Apr 2005 07:45:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00904 for ; Wed, 6 Apr 2005 07:45:56 -0400 (EDT) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ97D-0003hg-Aj for mip6@ietf.org; Wed, 06 Apr 2005 07:54:35 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j36BZH73022442; Wed, 6 Apr 2005 04:35:17 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j36BkvEo011009; Wed, 6 Apr 2005 06:46:58 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4627D865980; Wed, 6 Apr 2005 13:45:54 +0200 (CEST) Message-ID: <4253CBF1.60601@motorola.com> Date: Wed, 06 Apr 2005 13:45:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] draft-soliman and draft-wakikawa References: <424DDAC2.1050802@iprg.nokia.com> In-Reply-To: <424DDAC2.1050802@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I believe the [draft-soliman] packet format looks like the following. > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > IPv6 hdr (src=v4-mapped-v6-CoA, dst=HA_v6) > Dst opts hdr > HoA_v6 > Mobility hdr > Binding Update > [...] > draft-wakikawa uses a mobility option for carrying the IPv4 > address. > > IPv4 hdr (src=CoA_v4, dst=HA_v4) > IPv6 hdr (src=HoA_v6, dst=HA_v6) > Mobility hdr > Binding Update > IPv4 CoA mobility option Vijay, thank you for posting this. My headers for v4-traversal for MIP6 look like this: > IPv4 hdr (src=CoA_v4, dst=GW_v4) > UDPv4 (src port, dst port) > IPv6 hdr (src=v6-CoA, dst=HA_v6) > Dst opts hdr > HoA_v6 > Mobility hdr > Binding Update The src of the v4 header and the src/dst ports change if NAT is present. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 07:53:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01801 for ; Wed, 6 Apr 2005 07:53:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9Ed-00048U-I8 for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:02:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ95f-0007fx-Lf; Wed, 06 Apr 2005 07:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ95e-0007eu-CV; Wed, 06 Apr 2005 07:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01702; Wed, 6 Apr 2005 07:52:56 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9Dx-00046O-CQ; Wed, 06 Apr 2005 08:01:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j36Bq9k16252; Wed, 6 Apr 2005 14:52:09 +0300 Date: Wed, 6 Apr 2005 14:52:09 +0300 (EEST) From: Pekka Savola To: Alexandru Petrescu Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: <4253C944.5080906@motorola.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FCAD857D@xmb-ams-337.emea.cisco.com> <4253C944.5080906@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nemo@ietf.org, mip6@ietf.org, "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa , henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Wed, 6 Apr 2005, Alexandru Petrescu wrote: >>> We could easily include the MRHA header in the Van Jacobson Header >>> Compression. But it might be a little complex to deploy widely. Depends >>> on the success of MIP6 in the first place. >> >> Header compression is one way. > > Isn't header compression a non-end-to-end feature? I thought HC > happens only between the terminal and the first hop. So if the > requirement is not to touch the v4 network (just traverse it) then > HC is no use. For v4 header compression, sure. (But very constrained environments probably employ v4 and UDP HC on their own in any case). HC for v6 headers is still possible without touching v4 network, of course. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 07:56:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02200 for ; Wed, 6 Apr 2005 07:56:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9H6-0004HV-RF for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:04:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ988-0001KM-5S; Wed, 06 Apr 2005 07:55:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ987-0001GO-22; Wed, 06 Apr 2005 07:55:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02093; Wed, 6 Apr 2005 07:55:29 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9GR-0004FO-Jo; Wed, 06 Apr 2005 08:04:08 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36Bvo24019440; Wed, 6 Apr 2005 04:57:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j36BvZnt019419; Wed, 6 Apr 2005 06:57:36 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 31BEA8637E6; Wed, 6 Apr 2005 13:55:27 +0200 (CEST) Message-ID: <4253CE2F.1030109@motorola.com> Date: Wed, 06 Apr 2005 13:55:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, nemo@ietf.org, vijayd@iprg.nokia.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > We will design an extension using mobility option to solve NAT issue > and throw away MIPv4 support which is not our goal in the draft. Ryuji, how are you going to design this extension with a mobility option? I know of a NAT that blocks all IP-in-IP and as long as the mobility option is deep below IP it's going to be of no use. MIP4 has a nice feature for NAT traversal, that I know implemented. That feature could be re-used. I don't understand why you would throw it away and design a new option in the mobility header? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 08:08:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03695 for ; Wed, 6 Apr 2005 08:08:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9TA-0004qv-Hf for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9JC-0005uW-5A; Wed, 06 Apr 2005 08:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9JA-0005uJ-AR; Wed, 06 Apr 2005 08:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03538; Wed, 6 Apr 2005 08:06:54 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9RU-0004pC-Vv; Wed, 06 Apr 2005 08:15:34 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j36C6rQ0007128; Wed, 6 Apr 2005 05:06:53 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j36C8FEZ022549; Wed, 6 Apr 2005 07:08:16 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4EF748637F6; Wed, 6 Apr 2005 14:06:50 +0200 (CEST) Message-ID: <4253D0DA.1060505@motorola.com> Date: Wed, 06 Apr 2005 14:06:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] RE: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Ryuji Wakikawa , vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Soliman, Hesham wrote: >> We will design an extension using mobility option to solve NAT >> issue and throw away MIPv4 support which is not our goal in the >> draft. > > => MIPv4? I don't see how this is relevant to the discussion. MIP4 has NAT traversal based on UDP, which could be used for MIP6 too. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 08:09:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03875 for ; Wed, 6 Apr 2005 08:09:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9U6-0004sA-GU for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:18:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9Gb-0005bW-Ej; Wed, 06 Apr 2005 08:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9GZ-0005b9-QL for mip6@megatron.ietf.org; Wed, 06 Apr 2005 08:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03226 for ; Wed, 6 Apr 2005 08:04:14 -0400 (EDT) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9Ov-0004hO-9p for mip6@ietf.org; Wed, 06 Apr 2005 08:12:53 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j36CCXOH001619; Wed, 6 Apr 2005 05:12:33 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j36C5CQm021941; Wed, 6 Apr 2005 07:05:13 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6D93A865980; Wed, 6 Apr 2005 14:04:09 +0200 (CEST) Message-ID: <4253D039.8020004@motorola.com> Date: Wed, 06 Apr 2005 14:04:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay.Devarapalli@nokia.com Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, mip6@ietf.org, ryuji@sfc.wide.ad.jp, pekkas@netcore.fi, henrik@levkowetz.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Vijay.Devarapalli@nokia.com wrote: > draft-wakikawa specifies one mechanism to detect NATs based on IKEv2. Vijay, I'm not sure NATs need to be detected. I'm not sure it's necessary to impose the use of IKEv2 in order to detect being behind a NAT. Being behind a NAT or not can be detected very simply by the GW by checking the src address and some address that MN puts in the payload. > we have two options for NAT traversal. if all traffic through the > tunnel is protected by ESP, then we use RFC 3948. if ESP is not used, > then IPv6-in-UDP-over-IPv4 tunneling is used. I kind of agree with this. I was thinking though that if the outer v4 packet is not ESP'ed then the inner v6 packet could be ESP'ed, or alternatively - if UDP tunneling is used - RFC 3948. At which point it would make no sense to use both RFC 3948 _and_ RFC 3776, because that would give double ESP encapsulation... > and in the slides we presented at the IETF, we had a question for the > WG, if we need to come up with another NAT detection mechanisn based > on MIPv6 (similar to what MIPv4 does), but we didnt get any response. > if the WG thinks we need one based on MIPv6, I have an idea on how to > do it. How? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 08:14:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04738 for ; Wed, 6 Apr 2005 08:14:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9YY-0005BI-IH for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9PO-00018i-ON; Wed, 06 Apr 2005 08:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ05r-0000WB-Cx; Tue, 05 Apr 2005 22:16:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13251; Tue, 5 Apr 2005 22:16:32 -0400 (EDT) Received: from gator9.hostgator.com ([67.18.141.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ0E4-0000S8-VW; Tue, 05 Apr 2005 22:25:07 -0400 Received: from pool-71-96-155-36.dfw.dsl-w.verizon.net ([71.96.155.36]:1728 helo=cow) by gator9.hostgator.com with esmtpa (Exim 4.44) id 1DJ05A-0006Nu-QH; Tue, 05 Apr 2005 21:16:03 -0500 From: "Dawn " To: , , , , , , , , , , , , , , , , , , , , , , , , , Date: Tue, 5 Apr 2005 21:16:14 -0500 Message-ID: <000e01c53a4e$9cb588d0$f922fea9@cow> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000F_01C53A24.B3DF80D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator9.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 0.8 (/) X-Scan-Signature: df64132ced23e1406f6445adc987904f X-Mailman-Approved-At: Wed, 06 Apr 2005 08:13:20 -0400 Subject: [Mip6] Call for Papers - COMSWARE 2006f X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 79ec343be022ef2fd7588aba961c8f67 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C53A24.B3DF80D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C53A24.B3DF80D0" ------=_NextPart_001_0010_01C53A24.B3DF80D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ***We apologize if you receive multiple copies of this announcement*** ------=_NextPart_001_0010_01C53A24.B3DF80D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
***We = apologize if you=20 receive multiple copies of this=20 announcement***
------=_NextPart_001_0010_01C53A24.B3DF80D0-- ------=_NextPart_000_000F_01C53A24.B3DF80D0 Content-Type: application/pdf; name="Comsware 06.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Comsware 06.pdf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO1dCZgV1ZXGUSG0jNGAEdQ4zzVo6KL2hSiRTUARBRpRo7I2+04DIjIuIa6Y uKAmKjrucYmOe1xj1MQlJhB3EbeEETVkZtRIGP2Mc+vVe923+v733VPLa18D5jNfW6/q1r3nnvOf 9Z6aV9A1wyzo4f/Kf0ycVTevrvfIoDBlQd28gu0ZQfGy5dkF0/QLruEY4T29Rxp6YeCcuhF1RvH3 kYNLf8yfwh7zNSv8p3iB/3virEL/hvBZNpiu6XahYXKdrgWBb+h+8Qaj4ASW5toFz/LDGTXMqutZ OKhhet2ghsIINrBhel7xRtNh/5pOwfECqzQfJ5oPW0ngsvW4bHhds9jfbG7iRdo8g4Lht0yyNEXD 1zXTLriBoxlucYoN4RQNU9NDEumFhkl1PaeGlwIt8PzwxcVLjeElX9MdxypdKS7N1hzXd8vPHV4c ytB01yhdmRbdFJiB5ZUuzRdGWhBecdnrLEaU6FJTdEk3DNuUv2+o+OBscepgLHE1xVl5WmA5ui8f anx0STc8w5KPXly0w1gkcILSpTnig7ThZ4pjAUIMKO1h4NteojdOJtMmdkW8B4w9kfAYWAtt4qUH bdu3HflYle9ychwrdldJ4E3PieQ9cAq2GeicwJslAEorxo7taT4vxfx7LcONcE8PCrarm/x7zYzv DfTwja1fXG97DPJsv1DPoJEhIJ0nZxXvYgxu+q780kKRAQBPALkTebDKIgxYYpR415LokmF5VvkS DQRFCQLUAkPRpgWWCACiKaKNHxhGmTaLi5OwNIMRTE5nCY7EURfMFAwFKD+JtBlHFWfqabrHtKB0 r8FYpUu+43sVsBksqEwbpvENfkE+o6Dry7WiBCyLMh4JY2gbFP8g2QOMFwybt1v0wC5Jtcmm5zOj wHGYpi5K9dTo5bZRNDpatl15aa54qY94qTfp0uK0lzTx0kTx0hzx0izx0gLSG8eLl+aLlxpJUwXz AmNNaWYGozCNcbTPYN62mIHnMuOW2WAB2+HC/Ma6ydlYw9a98AeONXguDBmQxHt+wSoP7gVume28 gmszufZbxjXZf3t2zNIpqiI/NruSXi2NoDOdXBxhcIRVpmPGKc6Mct0NypdmN+txx5PfNT+6ZPuu F5NaRibfa5baIgKYTBXahsfPmVnTttU81oAIJzzPMMpjTRUnMT56Y+B6bgyZTM307VbT4me6ILpk mKGmj9GNcUOZbvUOU8Q6I2R9UHRN2E3HRlNgpnkzvcX3TRTJ0CTcNEckTGmeus5MDzlh+kcPMnYz XTmRp4qEmRktkLFVeYGxCfUSX1V8O5MKs9kPOSqCaj2wXFe1foEzTGblOHrMNIjPEOwKuGuyOJZI XkC4kRFH2UzfxiyD+E6BOYC7xpOWCAgxVdyqjBrKryTnJiNKUcwniO8dLy4LzA5I62ERE9gMOsum 0iwRRaaJD9YCY2giY4BpgdHBEtOgOsMXk9svL7ANbr8M9gjnIsTgCGyvwRyHSBH0pwDTdHFLZFgf X/skElgBGBIRZLgohQDExX0DgAZk/AiSBgKsOVsAx/gjvYSFFMRBhkaXHNNudivApQYRwGXYG780 MCId8yGsVqqaXy8QWCDWInNUE4Z0o2xuABwC/DZdmF0JcyzLNspsA8SWBt4AAgBHiBRqEm8CggFG B3MAuDdbHAs8KEG0GGuKUwdj5w5eTuBpdOxy/KBsHA8RTT0aLIFVyUQ7ftcUEpiMEu+SafT4XQsl xldsS04VeXW+eEm2HiUhGgVAi09bCmjACOfBGmhGgDgLxQmV9KdhGX55lwEYgPUCWyuKnxk6o5XD m+ejRU6S8wi3F4vERdFkFgCOFDe4K0uix3zbsw1+SdWBX8czNMdtCVEoZQGsCth8cvzljYLU9lbb cxUNuSdJ5L3a6Op6mmfS4dWN0m3s9n6iaSii0WThCjDwACoDatCQdC5J2wFWAVpY5ku3gj+en5PY c7Zuu+VwYn8REUs+sWlYfsxtj42+FTqfjqOXNTyYMVhqVpZoHV2JMxwgETAqgSjTQA1ADAAi4ESK 5lub+qNhlJGN27yF3P7ZDiMpjzgVY4oOm39476ho1XyUrkkkPYASeUCRvyS1bS3Tt8pSOkXC6NC6 cR3dj+VR4Za5hulZ8Ut20Jwqkip9EIxITgYQmnR9zQwMh7N9hoqjzxLNIbmJWTmAR3O/SxQ1i1FT KeYAzQ6cdDB5AP3gQRB+7SVoA6WzLTMlVcHmWjEl46uhRcvAgyBYUZq75zpWBSUF7G4STFdTIRl+ Mc8+i6ocZYwafxCYoOJKwXOAT2lWNmAempUgTgs8Vy+OnigywVOLpicl0ftcrWfDjqXiVNaz7pWL 0UZGa+etZ4A5tMgqINoiCdrHDIJR4gsBHsszSgp7cok4hxSAmc1YrpFUjZAMiTFKm5nOdhDZXWCF YO5ghWIAFVBGzo48WwFMIsUXKWHJCSSztqZTNnZgx6q6FMjCiM0IXrz9GBFZgLwCsAEOCbgLWCsS oBUzvK7mWWa8wik+EoAfMIW5pLvEWclyS2nyM9tsuoZiqDTQfKYAmbtgcpWGMA/HCxWwgMQFgLfS /G9a/B5MK1G+jPfvwFhgc8UlyupFqgT/bnMtPIiJ0DQAmDFI+MutdEXCH+hL8EZRB4D4ChgKpNUy 7pwieiOL88bnkFOcl/nGFfSJayeJutgOQZ8o1CSIltAqucQ4SLZCLlWaJn0hl6vppsdnioBJDcoQ gHgASx+QFJjUgDSlHVOUcsmyiYpSLpUyHBa9yfUD3SpI+RsYWmmdfVp0gRbxBc46mAMtqySTCBWy 0DySaqqJliNTcrRXpNBFR0HOzbw9AlQCLWGXI0PVtl9gMYCjuwWmW87uDRbxEiwUCBOoTaVRdgYJ 7IFdAEIcQN1OFcAKmO7K1YG0Qj/RvgN3HSneNUik1HCR6iAhuCXgFUV7VgmvDK9sq4AJ00IPNKAD d80QyS2TjvgkahtlDKsc0ibBjO4Uc32zmislK6fWQA5GjBiMidapiBiAS8DCBr4ACGsC+s8QQAZk gKhJHx4r2lX9UE5Jn+PFbac59EDIqognVuCGJ7BCbhbNGAkzx/M0iaqaBMc2TjSwJ6mJBoanJZDA g8B9UGxT9tIBKzA0k+zDWr5ZTs40RJzHR6UWiiodJNLlyQ+ePCJTAKdPLI5K5NXydQi02nPg1iIf Vtdcw+Mz/qCwCwSQacl8mvNLCheTomdpQ7xbRxrq6yvasly7XCuabcaQvRTOaKJ6LAUcJ6rH4nVC 7vZekeJyE85y9bIWSwnCFcZ2/PLBCxIQO3rZmhwTbUVgOWaF2qiSFHumZ5TvKukWU/cryAcIAILR 54p3VSG+qEBiWoDRNbQiC9UHMmSWUSHOQ4tFxKGdaACEGSwas7IC6jj5aClHSTFJ1iMHh4taFMxa au9VrisBmwDMo22aoAgGllkKYNEcbDC7xSIHkkoHQHQAqAZSRJZ2CWA+zXaXHSTK08dnolBWyRQf 3zKZPvFloURZfiHN4c5FIiFptf+06gFgy8rAqhXo8AMncvy3wsqAwNN8l9kfLZUBAOvAgDR8ooEk qS4RELGa6KeHh3ZlsUoa/NGAHpiNIFEPIhW0yDMN7WjH8Gthz7/u5H1Fe9sM/PKBfIq9bQbNUD1Q BCAQrxcT7sBsBsTuLRB7kCjkp0iAOm5IS4r4VDeBkE2bN30BdrsXtlrT+aAKOIwMOAcc3qWpUZqC lGtDStFfZm2YqI8B7+QkqstS8HoN9jEwPbPsH9PyULRSLXkkJHlgWgb3ikJckvcEznp+Pc0OlJGe tmh3YLq+5pOtctM1yrUaIPNGQjRQeUQxGcWYLegVQ7PIQQlA6iNZMntJiXqgtCofH+BoEZbk8quw ugB4AfauJlQ5Rtm0EGMlAIOAEKWMsYhwA+KutBCxnN/ExVAKMJQvBPsNPC7wIMBrWgBBntZLzk5t HblmtkC5x0DKMtgK/GsXW25L6lpBThBYoWIij9Srj2S8LhGpWKtNDJtrX3mrjX8/gOIlIlkAOgPP OEkPMP6YMO0AC7BAaNOSZReUSdA8mibWTPFtfcBuMw0u1rMlFLQJgYYqaFQ3CAsdTJMraqi3mV1i mwFHTUnXOihaCoUiEy2l2slahWu5rl2h9omi76urdPQgi9KpbKTrRrn9IjgfADJFAKLAYQpgewAj Vja8CkxpPRfABkxLB23KslwgluDtgClpjYFBpS4wAUU+FfEDzApsKO1UXPmYHfPyoq4cJUjY1pEM CZrhm2XvBMyXpm5kHK08ugZy2WBLgDjmWZUHSvBkCQ4FIBpeIH7PIidANLxmQASFXjR/naYNaM1k gBlHOuaMoI7nkpoIix4jQimplE7WH7FKouuaZcdMnrlKXtsAWCK1O0tnCYgVlWsMSG1h5VNXGO60 hBe9h4oKO8L6sCpBh6OXTzSBeCOtv6vccVK4z4CyJEdflvPP/6iltA6GK5wDj8myB7RKWTEKHM8A Au4jHaimNZenhfyrCV22UT5/BGZM86xpHhctJSFvL6WYRJ6BPtF9Azwmy52r4MXyNK9apokZlI8y 5dlIRV7GkVjDyFU8mKmQ11UelaKlbHJNCG8rqk8JPGZziTfo5yFv8cGblWCpIBoqZ1/FKUeAa+2/ FaoKngyvStikB5qVpLc9rQg7ZUcn0OmHhh1gt2eIc5d5ga1Ahx+FBjrgeLckLaL65ov4GAivApqQ MB3Eo0iVDKA4OvV5wbY9x23oulb6/hit/I/mKJLYmwQRtGSv7JB4miwxcB3lSXYS+1Yu80jLv2nL bqrMrECJpO45CkSUogwCN/blpTxz2X7zIazDRftP6ggqTi+BrtfypI6iD1HbH2a1A61Ig1JS+khR RdGCi6njCLQaRBA0ABpQ1rg8swYEZjdQ5qUUjOM2iybI6lZRHXh66aw3kHUaetIacQATldS6nHR2 LfcTQAq4casHN07zcaFhIrPQqvrTnorvJ0oVOIUPIIIGcCC3SiqSp33QFFT5yOyqNj2BCuAzYNMM fKcMn7RkNYghgAmAshhpzZ0CY0spI/7LCTQiSDvCCvGcry+ykbXUvcY/2WfrZQ8WyADNnqdvrLIk Up6ZUYRY23F0wmpu7Jl/nUu5cl2WTUlzQJRmiqVsQQ02DSgD8D4wqyYBODIkg7f8kCigRJXCCkH5 7Fyi726Abw5XdpTT+sCk9DCtgVzNYFDyw48B3/FJ98zS/hkus8wLruWXEz4NLW8sm2ElDmPeb8ww i/DH56flaI6lN39hfKJ415zoLt0Omk2L2cLoiyjvKyFZWPYYM+nRc6GLZUhfB6ZJWx9YzORoVqbt xj04KmEMl6kTfu89ZjDaviW/tFB8UFxiiW/DT/9Y8jmMFy81iQ+CsWS7Gr9UwsGwVC32Nb8oX+LJ yQXeCIYHpAfz4twaM05Ux7NbFUjxbJONELHNACsEowMWnChOSxRNQBkwq5mkuYsCBdYMJgp2Giwa sJtIrEnirOT0833HcaWUoQn1UBFXxFlV3q/yXQCixKEARIHRwUTFBQK2XdCiUiqw30JhKPAciaBg yeAu2qbKxF4lTICvSoX/JtPmhl2oN4xijwjyfEWFRBMpka6JYKQyphdaDIhW0smLAem5TOITtREr U29xBKZ6YLmt1ArPlksos5or0hjMAewEeBBsjnw9/CRoNkwiVa1Qk3nq6tR7BjgJDD9VIsdxEoJJ gNmDNYo8CEYHu5GWnYFtoEkMlPgcMtnM8aFmUBRESXzCPEGFWZGMX7ATE9KKDwBTwG2V7TRDORYA LoEnkc3Cs4PMQKHKfmVkTuK/8Mwm9V8qm0hy/4XferC+JBaEQCqkTQHngBWQFlWaLkj+pNVSoAOL wiYR9xHQJ+1+AP0gIwxEN8E6jK9Q7psCkeIfBPsNmB4IMdgeuTGQ3GYsTTWMolWghNxrEhSLyk3L 5jXFL0ntHZ7ySaw3ngxSNlUQmea/AqNFjp7C+SFqkMM3HL1C3ENmOX0NQQ6SUc5vD6AWjUvBtOQB DX5jW95otcp6ATtGAYsyBxLkEIDPpLRsAeqS1AMNBCeIW0aSxIyaht99kjkiKn6ZZY20Ls04Ixkl YCiZsMfN3QSh0PiDNE9ALqE8GcUlAo4DeyvhifhE6dGI+HOZeIk2hTjdgUhJ4zv8rgIaAxsVuB4y bEmz0TTDTG5OcUFcQC0weurJ00OV8aFolCcZmpNEeKNpfjBTmpgDA38OhQ6pw8a07aEFaUQpSBwo SrbVi6NL7J7WFe0KQJIEPtocWFRuDc1yl1sV/E7LrF9VRkJUi3YCy4IWYyTJekZfXdiiONcnULDx B/MOkcRHT5DiVfnWeed44+9LTXiaFQ4eBARMq4eBBNGdxfisMmmy+FBgCsB1AxIGthWQlMQhYFoi h8jfx6tOEKygQ3N8CuCFqeP1NDlMwg6u7citJpnhQYpnpMEGzrWXWzpy21QR0EhNULkhxVvDJCsj rXyRkFsuE9w2A9amRRKANQTmLkuSFOuOuKKj0AhqqTlyfLvcS6jl7opVSoxNy8WtpIwL4Ada6IqU pQdEBf4/zWejQQGpnqC68S0wOuCRRNFAhaEArBxaNiVveyy+r/KcKU+ImSIs08iVo9ZMHXWjBQgB bRJVYvHrAWFeYFHIA3YUIy0+VbDsUyhMQkqdkfwXGuFTbyLN+aKFh7NVqcnC97YnX+M8in4F2Jx6 iUniLoC1FDFxkbVo/mdqWydtcjIB/VBEGlBRtDRp8C9x+Ivt5Uw5eWh2H01ewPCkSkzaRiaqiuUW TdMQWcPrIFCVRwlsdUmTf4iVX03uIdbY3GmonjaZQyuWS7074nIy4amK32kZenlamFJSFZ3uqWCN AHaYkYDfeYuVRNGKnr4tF4qMJdLcSKCORK6NeBrTvEnxhYnOWVTGAVpZTFuUsoCQdbZ6FtUpgIzm FSWEomQKacEEv5FbS+GIUjvIi095cmUsPqVRvjIBE/noCuHI6KPzo9PqmgEqyX10fokgGUoz1Olm bvyFIJpAs2BpGVmR8qRZbWnWN1hiRSumWefK3UJ+rK3TbgeESKseUqvdjMXNtF2iCFGmVHfcZATI S8t2if44GL0K51Tb8PBLngdVAXESWZdtXyjNTzVT0pe66pooD6ckAIhnXCvnUmnnGvK3BxTbCraH 5uDTtAtNMhL4a0nwJtYToep4w6uJ3PFGVQPSjgQvSVw4UZqGj6WTqjsBgIFL8gI/RXI3GzTFNyBT WCwFNDWJJAXFibR2CWJ0K5M9E38udd6Txlo0B5dWBS/zzuMLyuSdx4f6urzz3LqnAAbMM4Mev4t2 FhE8SEtVi9xMkmmwwlNJBKSBQaJiRbrcVSBNdesNQGyWtj1yzFXsfs7ndeLP0ehAKmCk2Z9STZzI RONRLzWCgku0s+e0Da+uiSYvHlBY2jSjgTZTQHpwF20SebrLgBIZHU5+KFrsEuhnYMeT+tzIzybk GUlInpQCD2Y8p8ivug0OEROdHn5WNH0GWJ4mPrTtSVLNokjySN16ftGVndkKyVTaKcl6EeeldZ75 dUBTIpI859JOIZZUxS47Xo10dt6xXlhtng5L4GGEypF9cHgx4zFVBSzReE6m6WP19KIYpz2/Iivp VhbBknwz2lEiuT9VpYNDbXMUmKcWTdRph7jarHmDMtJQ+XwFe00ROejnK2zfLX+ar9gaP2oBX97b oyOymoYVlCld7JLsaz7TSuW7RkWL5PvxjQkvBWws34l9byA+1kjxjYOiS4Zl+K3UM617mcL9kGuc xD31AAOQ2gEmcoz5WckL8XnS0PxGEc3EidK8N1rTLpr6TF2XCN5I0xk0WBLDn7TtSeL/JB5Kzre1 1iyiCrvDY7+4O23ewa8ye2cu/JcTkDNQ8uduAXGVfQ2+LsTln2sDxEWWOukoImgTJj4H1iQ5ext9 cafVt5MUdgutc1CO/XhkpI4+n13B08zhnFHmak8Z98YnnyiDxXs/pLAvKRYhg7z4RDNBXnyotI0y ayYzpRSerEcNFBEF4HzLYlNxytN8Chn6JC97yeZEp5EU0ukXWtU1ybLhELc8FAlxSZXmYMnipOT9 d/m9oQXBSRItM0Tj21Wjdb5SJZy66YFoA9HOjrbJgU9Ft5XULWRTH+wHbwTJi9RHwmlFaKnbW9Jc otQH9PMs485mpLTvs8m0pA2oHEjOcLRz72kbT+d9xKu6lm1OPSmqb9kWmzqULtR46DJ1ExGaI63A O1ppG7CdZGcWaSa8vAKhsreeqPabvyttio7mJIMXbqFlCqnPmijSV4CCwKfLUSclKmZPXq8PHqzR hrfymaZtepKcWjXTojj+YCKPoXJJNOn7WbRSFhqbVkQ3whFFxfF30pesUgcjUisqMPlECklR30JS SKS4CQj2ygkvGJpKMJA6wan7i9IMVVBLJD+Uwq8UPJjEyubXDoZKXRKUNhsBnsu/oC5xKIuWa0uU F+AJ374/jZbp653xfFgtnQRVSAbNoKZl+8HsEwQXldm1PJuLy/1GXo2nzYgk8lLyTqTKaZrgBEz8 wbQGKMApGirlWC4hi2ypEq2A7oB+tO4KSYo6SVqPhmg0izZrBxQFl5NcNoCOtLwBzVhNEpxT+PCp laP0fFhyI0v+CSaFNSM/W5t4ExOlMRVlAQn6zChCOrTwA8nbTHT+XbEVGeFMUQ1aE6e+E01Vkcms 6leSqxDaIrVR4Y9NkmRAxqVKmMxaipdjo5B2EP4qWYJcrZxUNefYWC31OSYwVtbyWb5oIWtHLMXu 0hJ6YKo0xUhruJVIMaYNSCj2fws4uk9rrJc6b6VorEcjc8byGoXdQorppmbTHNuhgbumi8shHdNM +8kJQFG5D86P3k9krRwCAc3fQQWkodlTCXYsDZSlLq6S+4GJmQtkInM8xCJPwShEH1hBwLiVavGs bXv4CZM+Ei3bkfhQNMghWTnZlGWar531kSyxeMTMKp8v84Jw0uHxMsvzC7ZuaGbscz/MCpEdR/Mc jQ0U6IzVi088KLJmeRCjeZAYnUAViDw4zRdzgEu5B6eVDJN7Jj++y6PEB2UBayWrLRYJDdY4X5yX TORijMEE2dcM32cSbTKgKN6VnBlKBTp8NQ6t6irBJ4qUGwhSgICxAKEAOWk2jBzUbN127fbADEq+ lWUz43eVtpZ3fWaQ1CviSFvXdC8bQ7YjmoNKNlljCyUeggcT9dFUFDvR5gXW2E9c49fUSJP20Vel dbFN+8XbOZu6rjm2x9uFNS2CccSxfc03bCMb5NBYIrUDcwqJ7UsZad7y7i/KHqAdLT2UoP2EKvJC G2qouB4gQbTPjGc9PFYtSJAFVdKIcQKEbqV03YCtJtK6hplSBBqiV/EF3nkeit2aEVZpp9GU+iIS w2c7J0IDA9qZoPhYI8StnSMAC6ANGAqJgBe6w8FWY3iCScgLTBW7DJRM6oB1noZnntx3jLhGmtks 1zJcliz1EqEHxVyxIKNPP1oUNpqRQOMYoNmzBnf5NwLmlrutNQd0VSYOjRIJ1Jp4bk65xNL5MPZY kKy0hGZR0PYMagFLMx07m+yAxQEbJFGHSYWVDzxsAB+pTy/TbJAlJNmhsS0w42jho8DW2O9u7s4c TVOlpjDY0zytvNQ4DRgLOCx5emA1YWEjZDANzWMol8lFosEerTI2UUQ6T1XFR7errKoADNA8dNob aVMFhAZQlzomACZBC+TSlHbqOE6Niz5nPGeT/EENhRF1I+rm1VmmaxVMywgKs9jfgRf9PbP0t2k6 xb/De6K/p9aNKcyum1fwNSv8pxAmV/m/J84q9G+Ig0GrRCzjaoYeBdMNNLsldds8IcLQihyv6Xia 4abM8dYEWA0UEYDGJuAumh1Kg0dwF83iApAGKgdT22VQc+mazRgjb5u2Ct+I4gnV9snOrSGIlshT yIUjaWFhWU8W5bJpreNEP5WWUk29Z0gOAyY/7jY5zDcOydkBYyLaMNXnVTgbQJspjTa0xiGp0Ydm xaQO2w4XdxZMghaapk1ihsjv6cXJZwBlONvEqWphfRDyNsWxwF3tKF5kmD6DED93t34bF5XHOlzk D1qCm1a+R1tQ1oody7INVSvSGswn1xLo52JDsa3R/CCjDUULWqWWAcBFbb/NpTUKn6FSrpGWMEp0 UJK/CwgPLY6VJxrk6VDRLDmwRtqCaOFOWTyydXLL0NwgY6FbTa+3BtP/IFxAS8DK16gIwAPZBJfA dqR2dlMX0gKqpg7C0FCKtkMyGKk3XGYmBhZf6dreKv/ah10eGFrgeVY2rKoJWwcQHTTMlVe/8+ul Kee2z5fmibQJQvLiMdl8I/K5VErAclvmdPoZc8kAO/P8jEbbq1gQvkstdED9yKLC8eGB5IPaDJD0 qnJV/RYBZckL02qi9MPU2Z9mxkgj7ZAkTVxpRxZpadg8DW5gTACLRlZFoDr5DTgmda1arVZli9wX sD/C7vum46TXFTTmo+UWaH5cguYntZOR9ytMNbX+T9DhPO7atT/nyGZa0nC3HOcI7ICsd6tyXknD iVaFE2/pc2a6yXYo4+nqWqqZya+WWaV9EquHClZNTeRlaJZbto8nKX2REnBYTMh0kweO9p2bdizN 0a2MkdZaMvm5KgtaWSAtI5boKwf09gSxLrFpQmDtxzxkssOQK1skocpF3LRqZhpUJ4g3iJ3dlKes aKUME4TRK1pXVoUmWHmmmGqiVBEyqKe5bkbvGZQBA5eUZnPQDhUAqtTq1lSud6jgytHsblo78UT9 qnNJcWeLPTK+9JmSjjUtAVxGa6hKiy0Cjs3dso3Lnmtorufnf6i9Jngc7Faib8IpmkukPkZHi5Vx ZlTmsmiaJNCIAwqeMkB/oPkZc3hjWuhUobYua1GvwuoHl3pHY/GVxTVxYKaytDpyelVZWreAqEG9 4RiaHZjc9znzzH/RtA8thF9l8EKqxtN8I2vjvpqQoN6S7VdmK2v1sEGexuDWXKHC5F/XPM8Q+h/n BAA1YWilVvauq3mmn7HzQuqcR5WrdcGeptaEoOUnLWMjaxceD3rlnkVXBVKyHfBTNY8BE51HgqVc YxjMkXKyVs4OE+kESF4ThwRopkiV2zqAgG7bUwIxA0N/y2qT6q22j7Pk3n5NJd801QgwBqRKaYXV IMuR56oTwSF/wjr3887K2Wc78Cz2T3T1/ENNNP2cujaIhnTt4My/IR+r7akK3iiWeInwkI2AYhdE x8jIj7Tu7Kn1oPybiwrET/A5zwxlpMLXDTPmlCt8DDbX/pc627GsCafUjgitiI4W55IVTChbetDC DrQWOXmUISRrVQAUdHrL3bA03cjYDDXPBDlg67YvhQbVhqnPcMkDYfQAfbK28FU+dJAojKf4nBdN fckDTpYTtrPcggqj2B22YSX2neKro9GA9s0EMO/BonFESxzUxDGHxBBe4bPAbc8zW3c8ldmroVSU u/mFyqbYzM/1NLtgGEaxk9/ACLJch82Ff6+jmYEes+ZdpvoMO1Zs5GqeFUZpOcSKFFuM7+KXZosP ii8srrPYutAoTKtjouMUAt0u2IYXCnEQMHid31g3mdDUkBHB4psalohgGowILVTgKGawLW4hWpGm LVQLm25F38UrmXS+YxmtfB7mq8erO4rWVGumCT/uzPNM0XWxW/EfYxAz1sE3PtRC8dKE5p0qi1jR OQs00/E8I74rhukEMcayNVP3dSd+ie2T6csfnCMuerYwhz7Rc57pGRVWWNoE9rbmTQA35HvJtR3d bQ/Dl4QhZMaRg0t/zJ9CEQBbytNmELAXcUx9VMQrDG+aZRMw9RIpv/LLNcUHe5GWCx7USZecZjqZ NuNPX9cLtusxoiQDDDm9LCdsg9pCrrbhIcwKemEw+5fCAMzwkS6IKeKW5ZzYMxJTV3fL7xsqCu5s kfAAPJpEpJgv4kkp0WIbutUqasPBIxgqAQ7FRweYBqgMeL40CV13PEf+4FTSg2BBc8UH+wib0Vt8 Dlwqfe/bsmzdolwqXdDE1YhbAYhciv0FlmP4ciKDGYwXdwdwSKOINWCmYF5grCniXSceJCr+GM0j z8kK3Obwn2+3WMHxdYNZNInyM01kiMnSu/iNnSiSAtCQ9ka51uaNCcDhc8Q3Tm62Sa0KKFj6Vrhv 2K0DtPyCwCXAAXMFAwOsGggxWKLI4+B9MvOlOjrZC81V3wnN0xCVgd0nIwnkBJ6FRNuzKL6R+d/q s9484aQ2qwJInfxtAH6FChvAtwpuEP7rxG0Auuqs4A9YvsHcGm6f2kLz52uJtrXd0r4v1Zu+1dxx 2eMOJMeVAIAd4IEBCQZeIID3ehGKwIOivIJpTRKBZYl4FyAHeBB4ouIcatcLzNOZSylV1dIlzFzx In5NqksUVqxUl3ie67VqbcNzsJz1FcoE6ARXHL4NfUzfLDiM1mEoLqGPyTO3oFdczfe5Pcud0+pN K/w4ZQRkTIU1/+AW/2tY+F/frRWZS3lJGvczmEiwfXJafyFF14zw5Awz/ZlDpDF7P5RC8SJJIsPd lcZdTaPoQZRfHsmUzc9926UYJs4rOLoekZDJhRF+NStMTU+cVdd/aF3vAaN6j7Scut5jCr5e13tI wWL/3/+YAQW7rvfhvQ+fWTd0YOGUqy9rOGn2k3qX2c/s3GG78167f2OHGaNWvnbdwE+2+9nTTkfj k882XHtftwOP2rj0P1e97F+7qvcuh3a+q/udj787sKnbr6/t+98fftT5e4OW3Vn3Udf6VxZcuey0 mwbsecShP3jl03Gfvd517fFN6x+dMnfTmVdetu9dBy4f/tbZH+gdl/Y/YNRj66c/uemGNdcfNG5/ 3Tq1/047/qLzrXdMWPFw0OUF95nuTd/b+Z6nug894tMjjj16c8Ptk54ctHHC83+9ctXmR6e//fOH F5x414Iuz07wVp/8esPq+49dff/s/5r5pwdXXLj2rRXXrtv1pOePW/8fD952wrEXNI5evXneX9YG N/99xwOGD933fv33P7rklp5G3/cv3HDNlA2fnHj90/P6XvHASVf0XXvz/TsuvujG8z7Y+Oav1yy9 67PTnlncbdnuDc/M/d9lT7y9+n9mrZ/yrbuXbv8Td0nfK6b+evzHHW/96NKZS87r8GXDNxt36bDD n7uuvXHyHbvMmn7zS5+PuMV5956zT3vp1mlvffniocfce/OJTV91evffz5umv7Lzfps7d+u0fN+N DTfPX31Xx6V9z3z8wZVzzte+2vP/Nr1w6ymH7Hrnl7PMo9/r9MVvpzTVDRpa3NmUkmR6TlpJKrGU 50YvYs5RwbQ8XWApN2QpwzRDnjJLPOXHeOryN37yVKHLoB2HDu33YZezvvrqte3+/F99drn1L7d0 W/HTMR88funMu1894aMDxt+x4p2DZj4y4I1/nLJo1aMXf+vI/Y88s+8jv933qqtmXnLGc0OOPOrN n/545j/69ekdjNjjz9PuenPnT5x5n5x1xwVHbJpd/6/Lnrzu/Y1n/3Onh9bMPuPSxgO/3/nK5z7c buO6Zy6a8f5n9+7xyb5PTNz13s+fWv/uNfvvcc8ZB81y3z9h7NwX9zT/scvSac+t6/Dy927sPGn4 hfe9eeGw235z3UN/PWf53mPWT/9xt9PPO/HZK4YfvNi88tNht97Us8eLo7+93rz4nf6XX7Jin4N3 MpcsGrKx+72bRv7+5McvXvDLrsd/1Ovdrg0r1y2b123+e9s9O+TylUuu3jDlk6ueO2TxgcYJG3pd /siUlWv/cFFjYezYV3/+7AnrG1/41ieO1++xY8xFb3hv3Pz5kAs273Z874u7nHOOdtGOq/45asMd b/18srlxj2D6+Gce+edzfx37mfuC9doJ13zj3J9fcErXfcY+6bzZK9jnipVnXP23GeP/2utP6/a/ cuZrb8669YaPRi/fbs7oP/2ox/Q9J/Ud02+/Hifvdc/8Q1bNWLK5Z49lww+c/Pz17/R7duGen/59 et8zf7jg+e8sCuqHdxza76JPF5zz8LROP7y7x5dLClO+6Dvx0r8vPeu5i1f95uNzp37j1X1+M+DQ tV/1f2rNKWOGvXDo9IV9rDeO/84lt286vXHpUbtl5FKLcSlTGW0L+CX+9p0IMsMPjIVVoQJ/e0X+ Dtl8SME2AWb+7bIRR+7Zb5dnfvDUenf9ozcs3/TYysN2vG75Pd88q2e/by+113T6wYC9T9v1/L3u /9XBx+7wbztMO2Cgscv+T/d9edNFp5398pDtr1u/38qnOr60fGKfR3Zfpn/36vtW9vWXD1u06P3F X61atV+Hf2w6/YS1nV7vdv9V4189+b2Pe2zo8M5vh7x+8Ot/njbzd31+ttt71l2Nd75y8rXfHvm3 A2ee8ujbdz44ZqL14rprdv33y1cPty8d23VD8DP3go0vfHvxn8Y/ZD3wv2POPKrbL/+l1x+1AX22 b7zqzX21f3nxjnlDunQe93DDpvO/89mLHUZ+eO7qM479UfcZ44Y/dPlOM7rcEwzv89+/O+76DV8c /fTZDzVe/d2rPt3Xe9vufOQTv5r8lNX3gTV/+OpXL+w+7vOdply27LhDnlsx74b5X5yx8dS3h8zs etlnE2+/a7+3n3zin2PHjXtvdffGN/rNPOO9b+ymXx08ZjRduvNnv5u3ef9vdu02cf7s5fsULvjg qh36dPhZ4bXnD7vn/M0Xdjxnr8s7jJhw1AGnjVzR4+mf3rCi07m7L1x4/YTrb1jXY+NBY8zbPr96 r7vPf+bUW258Se/euGbMD0///IFFZ57nfzDu9GHfXzey8Zbx/zOg4yd7dpnVsN1Pd/U+3v3Gjt+/ t/sh97188LO73Gm8EHTe7ovlC/fr/uXOJx828qtev+7wiwm7f6vpwA2/vPiWk0c0XbX/mb/sunf9 IOvtY85f3Oe0t5/427h3l7y8/wO3v/r0B8bT1z6x17Len97QZXoHrcvvl1532+2je17T/aQXPxj7 h8E7DLjoge1v+tEdm2Yft/cvdvvOaYW/GNdcOv2AV46599N7ru9xhX1yj7Xrjji7y4Afv7B6+l77 9bj82Le2f/isV6ePCF457Objn+zS47D65yct7HnJxft+2K33mFd26/T9Pc9tevjVTietuW3nHt32 +KDHuZPXWHMP3thfa/rL+FHvf/zwLeNOWhxceffgUY/fOHL6HTesm9d/jDf6pCv63NT9vc2PjFjx 6Mq9br6x6Y0+Hf/+x5t+cp81dXTH457Ze+zFvx+pvfTVO0u7PNDviFtf3HHdm499udMX/7p4Yn8r oxjbQbXFOGE+h83Tj/kORZcsnKpj6PGpRhmdyFMo28el0lnmcTTXCzRGE7N9tzlAMVu8a1J0V3hi sDz9Uh2D6du2/Lkp4nNR2L2EVVZp/iZzZmzH8MpYxVDKLwycU0fcOxlNfC/8odX2Rd625xec8Nvm Vsl7s3gvTvFr6PyFvxqG2/ony674pOWUHrXCw/qx3+yg4qOKn8MZh4dmyxeZT2Twv1iVHpP9yNYZ /ihZpuR10U+yIUMCFH/F68djln6SjFn5VxL/mBz/eIFtNNuabNzwu5qtv6g5ou7/AcfKAs1lbmRz dHJlYW0KZW5kb2JqCjYgMCBvYmoKMTE2MTMKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0NvbG9yU3BhY2UgMzkgMCBSCi9F eHRHU3RhdGUgNDAgMCBSCi9YT2JqZWN0IDQxIDAgUgovRm9udCA0MiAwIFIKPj4KL0NvbnRlbnRz IDUgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjQgMCBSCl0g L0NvdW50IDEKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFn ZXMgMyAwIFIKPj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUvTmFtZS9SOS9UUi9J ZGVudGl0eS9CRyA3IDAgUi9VQ1IgOCAwIFIvT1BNIDEvU00gMC4wMj4+CmVuZG9iagoxMSAwIG9i agpbL0luZGV4ZWQKL0RldmljZVJHQgoyNTUKPDI4MkQzMTJBMzY0QjNBM0Y1MTM3NDUzNjM5NDU2 NzQ0NDg2QTRENEI3NjQ0NEM3MTQ3NEM3NjQ3NEQ3MTRENEUKNjY0MzUzNzY0NjUzNkE1NTU2NTg1 MzU3N0MzRTVCODQ0OTVCODg1QzVENjc0OTYxOTE1RTYyNzU0OTYzOTk1MAo2MzMxNUM2Mzg3NTA2 NDc5NTI2OTk2Njg2OTZCNEE2QUExNTI2QkExNEI2QzUyNUM2RjhDNDM3Mjk1NEQ3MkE5CjU4NzI5 QjU0NzZBQTcyNzc4RTRFNzhCMTUzN0NCNjAzN0QwOTREN0VCQzYxN0VBODdEODE5MzEyODQzQjU1 ODQKQkI2Qzg0NEE1ODhBQzQ2QThBQjI4OThBOEE1NzhCOEI0RThDQzU1NjhGQ0M1RjhGQzU2Mjkx RDA0RTkzQ0Y1Qwo5M0NDOEQ5M0E4NjI5NkNENUE5OEQ0NzE5OEM1NTA5OUQ5NjQ5Q0Q0OUI5QzlB NTg5REUyOEE5RUMwNzI5RkQ0CjZBQTBEMDY0QTFFMzVFQTJEQzEyQTM4MTU5QTRFODZBQTREQjc2 QTRBN0E0QTRBMkEwQTVCODdCQTZEMTY3QTgKRTQ4REE5NTE3MEFBREY2M0FDRUU3MkFFRTI2REFG REY4REFGRDZBQ0FGQjY2RkIwRTk3NkIyRTI3N0I0RTk2RQpCN0YzQjRCOEM2N0NCQ0YwMUZCREQ0 OUZCRDk1ODZCRUVDQTJCRkUyQkZDM0QzOTlDNUM4OEVDQ0Y3MDRDRUFECkFGQ0Y1RkI2RDBFRENE RDJERUNFRDlGMDk4REJGQkJDREM5REJFREVDQkRDREVFNjQ0REZGNERCRTBGRUMyRTIKRjdEQkUz RkZEMkU5QjhFNUU5RkZDNkVBNkRFNUVCRUVFQ0VGRjJFNUYxRkNDRUYzNzBEQkYzQ0FGMkYzRjZE QwpGNzk4RjNGN0ZDRjhGN0Y1RkVGN0ZFRjlGQkY5MDJGQ0ZERjVGREZFRkZGREYwRkVGRUZDRkZG RkY2RkZGRkZGCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwPl1lbmRvYmoK MTAgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZSAxMSAwIFIKL1dpZHRoIDExODkK L0hlaWdodCAxMjMKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA0Nzc5Mj4+c3RyZWFtCnic7L2LcxpH1j5sZIaiPAjGKoJGyFYxQIyMGUVLYoYRCnr9xiQGgwKO hLKg2AYca6Xa2CiprU2tXKV//Tvn9GW6R8j2ZrO77+7va24zPT1Xpp95zrUN4/8vhmH+W9/6zN9R YvL1bz38f/gq/oYt/L27+/v+94/+k36X67b4wJSdfqh8eG9Y/sHD/be+4fX/8tuw2DUwzNi/51sc AKuKxy2Dv2ASZ6iCbjL6who5wUoMppPBJv7lxRLvf+UW9MZw3uzkjeAKWIahtIaXZVpygs9+ZDHC 1/UfP2VtK1ff/KT4HyrvCf0V5ycWPlSGS4Z6VQxDXh3j33ar/8ZvA/sI+8RZh/l/a8LiD6IksBEz Bj9sMvmvqaFv+I3Jqpi4oWJ0eOJJGTNoSYw/V+WviWuzMwGoigV3arhb8WepZYTf165xtShPtg82 CD/FlYP46PWU52i4fWhtE88dGSVcQssUN7YELclGru5ZOcBr9y+uFHV8gz9V3n8lPuJETeX4Fpww nQ27I2L8rjDFfcG/FaLFLwLdyGwK+neMZuAX3gLx2G2Hdw5tNfYvu9V/ew0dvIApS+m4/80TdKpx ccoGzZgcqQLspmfQ710TEzdhktfiN9yMwe45bpmMHFmEYUkGRuJDi9mdJyDKYmeBnyTe27xIKIrj 7fihApTMiFFztVYBtOtWNAhCqS8RsWMMT3xfu5oscMiAsPEY65cfWfTGuLMYcQtDVBvJYAf8NALY EeXDRwgPEAI/2H48qIzjJY3j98cf8YJtWwadd5weMeoEP/ok/XP8zoH/PcbvC5ojgs2hxxSd26SO zab4zC2TPd4sXs3ZFdxFfOKfcqv/Ph3EFIBsRbEHR9mT24pa/+0TBjtpmI7ir8n/viTHCcJuiQm/ b424m9i1p2/6szihYgutgErJh3iMNkOVJl9Kj8uEmUhQTZywiAl/ag+Ls3f8mm6yoE9+dNOgJPnn 31fi/NyNhWeKSHKLX8WYyeR8vOr/wDFbsfhvuVJ/R2GnI9CH3w7sBjAF347xu4w9gkz6TbIV+d3G 7jT2OKMbL8Y3lhRoJh+B/+yb/7d0EL6c+i70YDPOO7Lowf+tE+I8LSHsxbn8J54+MYntv3cNPtRY Fb8z2IKA5fP2Mfqv5B8lbjKTL7D4HZc0uQSCf6TFbloGuKwvxgi3ONCZDObobsauTFMBv8SWdCyC dDLU43IkE1a4BowzUElLLGpEL6EkM5TvuBBVrpVuDLbMMqR+MBb6XCcTBSSYztVgXIQfVVzKanGD PZzNBLGHhLnMPglxhLCPuAT5BYU4mmnwSdOQ58aWisul/C6oigfXi1+NmCH+O+RFeKYWnzfZ9eR3 AefZVtC1Bd/GrSQSSXaaBD3igEx2P9D/nRSUKWbKCYNTKnYk/4Kb/6M6iMm0GgKaCb1i/F/kLIN1 XezC2I//Wyc4XvEPq7IkeMv3P6NGPrQMiU1c3cC4lFQrBBoqfCf5XZoM2rP3LXpKMmQxpfzHICUJ HRG6ccJiKhyhAzOYkGGxWxoVOBZ/myZ/vCYJ6Sy+yziXK2LUBLW6QU/jYCW6JSwJdL+GxX+oy0gq aIppPmFymTbG1BHyrDkO80uj7lG+TTM4WjxwJDhGTCjepDjEH0cmYyOwrVuGFK1xqWkJqpI0TPUl gJ5z26TYBJ2aYTGlNcd+ojh0xbEkGAegixwzuTQcbIskNtxeki6SwTdPZ2FYXP9IYIgfIfsInI+J C0e7S9IOLYHvHBINdl2RXrHHUiKp3mcBBCSFXsoUzzZBuf4NNZpeg0sM9B+B0GPxL+quohf/907E 4wKUrUA1zRR08v+Lmf9ADf3zJtKmJMcaU1YGhMgMHooW5zwMTCz5ZBNNJDPg4CT6ENN94oKY+jAK HpGsBMI+7pQ/l8S3JbbIp+PsmtB8XNzyvAPLItGCsyoOVmoTpSSFhl88OenGE0w/xgVak18YcbNK AhELHTGVmNiveLZyNiF/ObOMBTO8kxtqA4YLbCNCUSnJkLJH4jaMm1nyEtCPySgP60+GxFtlRYNz RPHnyVPhl95gakZGCOnfZvdGjGRowhR+aSyFTJnCSqKcmaWfRcxgsh7bIq6WlH8V+ztjjKgIUsX+ JSOgVv+amph4OsobhJ6JyUB1y69bnPdiOs8oF4X+CyfwFQUKZQkyBcssdruoxIeeZVID9HcVfQ32 TIhJNYBhCnogCMUt3kvo2WwE97G8n0W/EKYNi/dNk3dSKbf+/iVqRP85G76yH/EJvoMj0F/qatH3 HV6UlmMT/ktvpehzsi7c3AiW6RtWl7JjoX2x7yubjQYnF5xG+MREG+U8YwGaUZEPAwGTf/d/RJuL c318DG5AwWbY5gKG/C+pETe5ECEU8iwkB1M8NPhXlD1J/6+wnt97gp9p3IjGxTnH6T9WhGSpMeKq IWnlpsuG6MD9ZtgTlEsOAbbhI0CojdjyWGBH4TOBRB4jgUO4uljSS8aKM27F5Ct06jFNQ/rPsHYI bdiIoZvBVEdWLE6HiTazOFNkxJmyIiYVRYr6KCb0MpamgMH5oEpdwmq5MYpUJ5qGhhZTM7YVPk8t YvThZiwrWEtuyNB+NAWXOBrDspgrWVzVDLFrR9/8eAxpXwwO0ghqxemYhiVJjql0BckNSQHFOaN6 1KyabHyBbiouOZk8NEM9BPV8tHNUL7E8fWmnNLjcbBrB/WFazJrJTiDGjCT6hlQPKv4PGGRSjHNG FZMcO8YugiVRQxC937+GX26hNOBVca5KNQJBQDCrpNqHmZVP8o44mzL+m2riki4qTAovUUge43wK LUK2XbKdvGPLsr6OX2xSTNhiNp2Gt5W2LfjGkrToN7kCU0pJsip44+K0ugjm0rh2OpiFTaYtUYtf 9OF7hM/6Ov/AXGkdj3bdKa07RSdfKK47jl1yiqX1YqlYcksl+rAvXlxtXl2i1IXXCm3JLWnbWbQR uR03tEFXW4ilyj9aqWo/bJqvVywWYaKIJwpnSzNQqsGKVXdPTFCBOV98X1uqVyYWLtXrqotbLDwj Vhe+QsHVYd+Ok1un/5vdJ2lxh8ArS3cjnPY6vHL47eTohW/HKeJkyaHNOXCN7rFNOpmMlZQ4fEs4 JKlwQZPxf1JNIE1fWcoNkrwvBppJE/tpnGmVhVqZT7N1zfh/fA0RDvofcIFyjnH53wi9JX+s4LOJ 19ilcsl1sBOUim6xVCmVy26ZJousCu4GuAXwWxQ2lS1mnSLcR1m8k2SxEcjSWQIzBjRYQ/ecwEDW bt1OZ7MEPrlcTt0CFGcd7z/bge5Z4l0SDsp1K3jje9VKtVr1qp7nNRrenu81fN/zuvRqdBuNPfrq 7T3qdvf34WcfS7cHNT2Y6O1fKd0Fdfv7R/jmX0dXZkPL1EahN34djfD1bMR+R/xXfY1G45FSjp6N nh2Nurh2b7/R9fag+PADp9rxO3giR/uj/SNqO37+kWUkP2wnuMfn4T2z8hwrn/PJ4BOso7QQmxjL denD2utn+Uz9HMGV6Tbg3ywXxWNI/LB5vNPgf6/iixXP8+FFBf533/f36IPXZqcBf3sXrk/VzduZ ZJIbP2OSvATilMKAfteauDapLI3Lemns44xBaiZpeTSubJl3W4tEIW6OJqnoP7QGfaFI9xRliB3l 2l7GsVA/xcm9GUtwORhtKkxW49gBN8S9e4V798pUimVRioVK8bpSgFIsrBcKcDvBV3G96BTg9gKE ymKx4QNz8JVOr6Q5ZiEyYRtYCI9KKyvmgwIQBTBVoHvU4XuCwyjgoVWw1OtVD94VRCl4MbACfPK6 jQ7cqPShO7a7t9/tdntdBCJWOvAOcKjHlu13j7rY65/BC98K7OBrdCTLAmjSmqoT2CvxfSTXDzak bFIrrC+LFgSGDEb35Tl0fPqlSoQ/akzYg+UVvf7eIqFROxJedxXBPriEbSs4mdA5ik+v26iWi8CF C+Kf128EeAyu48MRHlT0x1e9oDTU0vHgj4Wt7XlucX3DtshwG0ehOSZ0o1L5YQl+o2DK71VDezUD mFKWxgVMBeoxboAUJm+Gabxzq/swtd//rBpeEVhUgh8N7E1+2bipjZuK43Fpc6FiWmmCHACqSgHB qggvVpQZWFS8B43wp7hdYEsJqWRZL2SvlPQKFGuF5LigIMPPpq8Wvg7iWwHvVCfLN10sFGn3RQLR ilbqFa+OxdvBV4O92B281+n1eo0OPmk7nR68ZdfvBjPPAKFkYXDFMeKZjkMhYNpXoIQBn9iayr1w BrZLv3yW3s/EdmCR/MZqdliP4JcQCY609wggtdPp7MCnA2Aszq7R69EhMhKzkD8dPReogthwFZA4 asDe4bj3e/ATnKB24ouw9Tq85UWeprLNZ/zdbdTLxat3i37r8C/87wsF+Nfpf/cQseAhVdmp1qt1 /L897/NqpeTYwt+BaeuEejRgNNIPiUlVv2ONYYgf0f3kW7HZSb0tN++yDkmMQkqL3Gqg4FRgXDJ4 f/6PqpFOM/yX3E7E9eBXxRJ601jga4QfKQySWty0LECDe0UJOIwrFRGKBF7dq9Bdgl8AFBW6Z8qw uKDTq6KALQAYjlKIPisaQlmWleL6qUXFZqxLPGLxu5AFtlZwCsruAsKHh4Vy4Of4nEXRoMIeuMir QADc6xDB8oFKAb/ah/f+HqMmAl0QlkCEGqmi2zOGMV0FhIS4J2XCK6WnLj0ieBrhexQSJQmQnvEt POvBes+e6YInHF2Dc0CAWhRjgS0CbdhTaQSeVqexTxLg/gKkUoSwxQBF5RkeyTN+/M+eLTpLAVrP BH6xGYJWgUjqFhHzngXIJM4VpxlcA0o16pVycKMAkZJ/eXadIRTRbQsfV3RPOvSMYg+mamUHvv/A JEG3hFqFABc4m0mKHqDohpgG1xDfv1NNPM5pQVTsiWCHDO1xJtYwy1RM6YqC6QnRMEoaG4WHiD7O NfFkrxIOsWwB2QYEX/k/0sYQMU2sKsb/laTAoxh34QvWijHw5g4ohoAouQ9pdDAsu+BIpAEJLssQ oRCAAiNOlQLCAmc0BBBCRCT0AnpF80XBf4p4u7HbD5nS+roNiLWiESlLINgK15qTaIi3J9Ofr3Ox kCQCuKepiKMVeIU3riwewRQIgvBmCiuAqA58N7qohNrroRDV3b+mdBlMAUAddbv4NcJvquYIBngG lVgvqwSwNLRNLQKyAKqu2X23t7ePPKlL8isCLMEtCbOKrIMCryfRap8zKiH9jaT6ScOoq0D1DDVc Cw5GKN+6ArJ6ygLx9YxkW8IdolYBjAEuEzwjbRrtPxsJ3tnHq4dC9sEBwG9jp16FuwX/0EDcS2c1 yQ/uAyEQohZAPJ8YWLllt1TKZEg7jlbAwPCWNKX/m8V0I+j8YEU5fggc+Mdr4nzLRgpNoPEoU4Gb wuguje8WYwRKV5TenKyVZGLUzzmSMf2x8CjkGmWDu63FmJugwX2F/w+0oSPnvtRS9c2chHmAtbAY BK7AzAmPXx6F/FI101RxF1gzaVnrRWRKRXhkIUjhS/AqIdTpxEnyGSl5iWkBZPiLunZ6YBZI1+TY WSbYMQ1WOkvadsIosvWtcL076qwQydhiccMWgPwTfAr0dBjrqwTHQCi144k+TJqrDkOpPez5JEJ1 NSYleh9RKQFN8HMAPYm/8WtE+IToRfNYi82Qbh0xtVFj/1Gjt9foXY+Awd4WN2kgy4NtcGjyUedC ALUHU3giDaGWqTaqn4Pgo8CUItGFiopZgfTHOdC+LrgSxgAAi9Pk50qXZJ9/i1UQiYQIzCkSo49s U3g9GZVkNUecmyJE0QWGK7a31/AQqPAuEew7K0AKnlC6CMieUfiP3yNeD2ut20nmN0MeDdxbmHV1 QyhyLeI2DAHipiF1QL9HTVRjcEK4ZPKbpiAW3ZZDlYzbYOY9gX8CuAJ/HoOTLm4XNMzAu0I6FgnH q39DG1O40xrcnZg7NBvc8174FRiKtytdAlM4ggf+4kowRkxlnMJtg7GpYpk/2HgJFE7KpIpUDKOY cjOACT7hVdw6ESyujS8y8KLN0cbFI5LxLEU3xfXqlgpQ2KigHAXnffC1fU+Co8Ap7Mp1T1W3en4H +zra/7DXXwUqAq8RoVGXd832gSijAyJYhFxdqmFdl7odTBAFoi0AgviNfQIOttWFJdj1FftiA8S7 DnEl4kteG6kg4pPXCs6m2vgcIGqnIshUwKUC7bVAqOfsrQiBKmghWO0jCWL8jp26uADs3OE0R10B RgRTeIW6iECq1okB0zNBm0YMp6CGC9LsbHvAznD1IwQq+IFZsn4g5OATSMUkTp8Fo7LYvVAgVSX8 7yVnPW2x9DVKZA+lV4iLcCOhMxIaDrIuxbndKRr/h2qER2KUa6Wi3G2cxQuzxAZRsXdNLRUY+riB jycJYCFeZpIRCCEaSo9/Mcf7M3dmEBFOMtTqX9uGY4vFG1rBiameFiLg2hAxcWIDQg5U3c2VUDO5 FcE1TWudHk9M5iuoGIUWPOaAIOEqACmdTqFaiCsOPMALr+JxBKmwpnQrEgtykF5lJVrpKMXhydIf pGGQIsAscJAKjgP3WiEjIJUOvQCokJYgo2LcpEF6H9JSEW5Ax+sSMmH//O4gXFgnHlGT776TdUcc tGgbDUIpBKjeXoeYAleCKeAkqRyr0BAKGgKP6qjmKySDHfrgW5bPGxWAKgQpxroQFoTAx9FHaqkW qtUD9Tq1JtEOr8Goq5/2SKjJR/KLfbpMvBtJ6e+IIRlnVxKYkFshTvWOet0DEGA7BwFHBZTqoOQH tXAqePMpN4Py/zP1lHYnZIFEcYiKmUlBPpJCAyJpjckgwBTB+Dy6QSqQfnMNWtKD+H4r4FYCqJjz Kv6kAqLFWUjQIYUcSXJiTLCRIIlNTHAa6b9gyAhA1krE4rCeL/Rd/9w2CrmKKSTJlJgTZKAwZcvA mBEgtSnmYlpMnZEMdiBCgvmEte6EBToh60ldkApdiv5a4ESlzDGKIZRbr6NFBsv2dkVCSVmQKi60 FRB/0tl0ViVO6h0pBVCVxBXI4lesBExKYmW1ShY/VvwORyqAKezRjUDRg1qk3h6Djw5BB2JQt9v+ DnDouwCqSLaTAAXvNjGMI1KvEK5xEOp0mcqosQevzl6v0XmEm38ktPWswI4RivaukDk06nV8RfXU YAArIaohQKrSQMMmHD8RQ2RDI8GSAhJ1pZCnQrgEanaEIQlPHJMUPZbG1Kji2SjAIiJlBFHSCNEN BL99uKqHrYNvv4OvgzZcZ7zMcN1ahx1cGS0EeL7w38GfnNUYlYpPBF6oJcii+QWoSiBUMNWuKcQ8 oe2JCyLFI/GxjnvsCEj5bTVUTPLzl2QtLjFLTghspGXSWTHJX2jwYhp2AjGRg4bFf95i1IsCfDjg mgK0uEY5QBMe5h3jbqwS1EQKG/HFRCfW6B/Yjgj0Eb+GSPEgBDohLyotYyZXsgm4Ngy5qkEnyXdl cC8N3iipsi8zaVp2sRzGKQYnToHUVRq/kqgR2Nr8br8/Hk8nw8lkPB73+22/IkCKUGq7vM3ABL/9 fh9aDSfw7kNxuWmwQDYd/iqWFTfmilsNFF6cm3EGRw5+iAww0dhD7XklkPg6KDfB8YwnrOBkH3VA jUeAFtCP+oA2P3RBrhsddNod6EGARvQFXEItwLGwiH7cPRop3o5HhD+cCHWA3ux3+0f9ffbaV1Cq QYRJ4BOTjo5G/RG0J5jkhIyryIWs1/HaULp9uMR+v8smUHl0FAIkDaMIg1RkOqMyn53Pz+ZnZ7Oz iQpVfF28Doh6ryaT2dlrek8milpL9T/Amf3R8wlr+noG13a0L+RfLvMxRRS7dHT5no/GryeTs9eT 169fT84mz8cgUMMVg4snGFUxWwwwKs2kPwSprLQRy3zC0kmSiycMBtDoJhHFEsFigU+A5uD9d9cY IjIWZUDyG2e7sa4CFRxJSuF2MSnkkDaYi4JEtnhXNpjVjOd2MYQvtiAZt4SiyJD5XmLiIkjdvKn0 d1NeHN7h2XZ/63YE2+IJKwyFHMVMiSlmTFIh3kKub4qWzBNKhlqqFI09bPjGFDmZmRrMbEElOwsB K1yk5FVt9seTk9P5HN70mc9mk0l7r4p4Ahi1ozg4+QAakxk1Yiucwv098rFlsVIkFy0qlf5YFEK+ SUi+JHWY2+Xwc8a/+1wn1eEMpE87o73xcnoKGxv1kVH1J1pptVqdTqfd6uJXewSbm73mi16PAUIO Ab2+YxJLF6rgDE/Ynsf7nCYRtsAhnU2VzQYgtc88Thv78oBFmYqKMRxbu9sQoip7N0IHKspsNjub nZ+dwufsLIxSCn0CSDo7n//yyy9/EQWmAahehXHqOSDPczhtremfZ5PnCjwp9Aqanmgb/aHf9Llq 0GNG1rbX8lutdgs/B+MfAJyUFf7y4y+vfyARnK5fpwHCbAXvAhL+0llVNWmzUCqT38QihasZF0Z+ 3iPwdo4GedUYqRHqbwE70fhvqUFGFo+S0okpqKICl/iPcDSniSh3XGAZ37icIxLU8rU4gpryjASv 0ZhFoKYJ4pWZl7bwrheJRUS6JA1eDKE9CkiKcE36u7YjKJNQLwkiJQ/NEFaCwMVeHrT0vRAhS0n2 ZBF2vqTCziwh6cUEyAqtvGHaxe1y4V4gx6GLZ6FS1FFLeFMV+DSAShFgZ8K6v1rmp+eTMfAp3Qlz rz8+Ob2cn+tN56eTcdevBlp4BLPxJUOV81P2bivoBEKlV6179Uqf4c9PP/HvWVGqzKGTIELBBuah vdH+Rv1Gn+2A1j0/mZQ7LcQp/jWaAYKe/8Q3f+p1gWkBeh2iuNJ9Ppmfn7OF5/P5sbffDWCqP2FA /RNHxTHTH5GMSVLaPhw0HTA7aHrxM8CLeDIZ9xEnO61uC/o4vBp9ibI/yc3irrGc0hWC3YwCRqSK ea8QoRgy/IzlDbygIKicvQrc1ZEXApF6/nxy8otoyhrD3Gugi9xPSvpMAUTNgq1SU4SdpltcF5I5 I74Py375oe+3Jz8wgKIDeCOO42uPATcTxpmkW63cc2yurcxyTaVt20CjTFOoiZj8xJFK9mziOCj7 ReOc5AgqFBdxrUz9ja4EKG99fE3gL2BxLRVjSwbtkZEm7vNAnotM6RSNS8dGU/Q8omCGCCsW6uOk IZVRhmQcQRyNdMymulsKF9LSB3AYNGT2GD4lPR0E8hE+3OJtPrAdeThCwjak21NSbk0kVwoO2RRZ WALVk6RfFt/ELXHKSpadmKGMdSCfQDHKtoaunQApklDdq9wrB6okjWIRpSEnhSKIbmPoczrqBOAz 7vtVoUAH2aw/ni1uO5+fjPsILNUGw5dGYxxqMiirdjtkTBVgLaGN1SzPEzzkYDw5PV94YAwX+/sT terJRsv7n5YnXqOZtnO3RQWwA+FopK7ZzzioCUfNPEpr/Zm+z0FxvyFeXfSH73S1/V4p5/OTCUhB DCzxBZt87wpYhpuNwFVK0Zm/AoQKkEQrAFOTV4qciMgzOfsFYUQvgD6vRyPdBR2I5i9XNouI9scS VyytY3RUwXE2UKnpNsevf+EApZaXD4p01TwSmJl+CkCqwnzrhMUXQYokPSkNCBVKUu2PhvAOEGpu yoASKLSJDcX5cuFB8DE1caF4YhoqQ0hxlCIJgSZqBDjA49QCHibQQUEAhnpRRs+If0h1jiFy9wnV EacWtyQRER5XgilxIU3kTxL2siDXHje6UUpCITxJG575ge0E1MhUjI6C9xjSJmfJ1gYfxkBnUsJk yAE8MACywxT5CvFLoJl8BInV8RBsJFKF4r3yhwpRHnSuKpa745NrcICBwekEUYrrrYhkXNs3J310 FSCXRnjvj0NNj12voalsSA4KNaqlhJtU54fxtRDFD21Pw8FhTgBUHd6tvrblYclrydJpj7R9Jsvc S7zR9Rudq8f9iAAKI547ZFkcvR+k8Nhm44NusL+PAal8d6E57xVCQxh1BKa8+ctraegD/DkAGnUV ohig/fhcxhiSonz8+u1C5Pv55x9dJ/BzYlEuG27/ePFxvFxzguA8kBPr1WoFAzcDRzpSRWUpYEGM 1yZucHEXGzy1oJDwDBHTSrlAoxJrWLQrj3nl2qqPqhGaJ0PMcnQx5IYtgzsrSGgiDhbAlLC28w5r cqiL8rw6mL8vyY18/1eKGZ4WFYQrgENQrJgVS5oxplBPmvSCQl/8mxU8v2XAotitpGktU/LDWMxY ji0TmUreUgYZuRVbxhUsvkPhTWWyMXbMtE1BU5wuFQJWFSoeWvAQeqptQIIPdR/url5sjmeLGZcs Y2HuQvfkMJM6bXbIaM0K4VU3DAgAUoRgncYe0KjrARHLT017T52f5B96D/26/xC/vLbO0U5q5YBk eQ11v7NN02OxzKQ8709+0vczqzX2A/X5/keBFED2uMtRqut9FEi5/UWeBq8mr69BKF5eSxaF7Ogq ORJ49vOP5LAgHEH7r69rCcW1de9xxx/+GZovOJA3bz7ZUGOdHKZL2EiHPFMChXkyUCwziJKqWwYF ZlxY1URaEKYWQnufqkNC/ErxaHz+zbwLjKttxNOfg5GgZmzWCIRKk2OVoTAp4UUlcjQIEcgQ1M4Q wmAysZbfym+5m1v5Gk1siSl8wfQWLeNNqAKX1njrzS1sQe8aW7IlmuVZxSYUtlS23BTbrvH9BdvB FWqiBU3XNqENLMrnM3k7k5H4k0leKbZSd1s0y9h2HurXMqvWum07mPrCybDMUJl8OiNSptgZWtsU jEwoybidkXBqvSCjUIpBPEJAorTyXmok+r7FMMofn//0gbZzjlLoRdgNk6TToU8+ASK/QWcPevsV kLIYzyI12Qf29sRuqJ1/VivAk/zhQ/jy6/UwR2s6dSJZLVRla+B4nE+3OuQb3vGASI1OwvtpVqWr AXluH30MSAFid1peG20Abf/g45gUqaCElukVV5z/cj2YUPlBukIhRr2n4Y8yfhqQ+Pg9GPXzmxI5 w6E/HN1GfcCoa5q+vJPaSDuYAiPNXM7T2Ww4CB3j+aBQt5ZO2EZgyuYCCwMbZD0ySbQwvklZzFLs dRJ1jCDBAU/XZmltoly0Y8tNUWXITcWjLAZH0DipA1P2wJFIMCluPGS5/BhPSOYH05OfTnihiVP2 9RPOnbI5uYTNq3W8UlaJ2Z94M7nJU2XhiVx8ZdtiGXtNT06mU1w63K3VmrW8RKkMoVRGg6q8DlxW OlcqOcWq5+ZWk8nVzyooCO00Go+6fqUM3bUC7LmO6Xkajc/rDc8v2wBSMX7hpIgstGMGZkcQKoWQ k5LAKOFrXqlUr0hbC8psM0VMyr/CjBaUn8bCv2ZBTz5pdpg/z6g7ImeboytECphUpwPdujP+iCMb 2BVtH7UNhCfkUvAVJi8DBxY+5N7ffXW9J5kNmUOm0/CvHtPU7zJfAxZt0l2ArQtL228BIOIu2x/D pJqvGCrp+VtevX4/Rv38pos06gA+z9/HjqD8kfmd7+93+uMPtCRXXR5gUGwOrgc/AClCJcr2w4x5 KoVaR4UUhiBYlFFNaGANriRnmpAYd/qLS3rC9D2SqXBOJaQ0moubZIKT4BSMiUAzxL3kcFNxsT7L ACUD9UkdZck8p4LGcVLGs+UaqtNU4HLObINcjAJ5aa12cvmfUObT5qDZrGU4KoV/aTqvQpZlpe2y v+eXG71GxcllVldLR4eHvV7vqLffA6jq7e/DAug6mLKk8ejR416vU3HSyYTM5i/op3A4wSdS8ARb D/x8F5Gq/viDbAW6KDKpchl41Ef1zDF3YN5f0JOHrSD6DH2in19tUrOA0LS8j8Go06Zd6avzTwBs HiJOgbzn9cOaJQfoFUIY6uw1BKutFjqB28N4clWibfqKvBdWu19fZj5zp6jX27MPydTIpBbmlXr1 +gNMCrAH/ciP4Kiu5TusvPmax/WNxr8s1lzJsiWfcNmCP75Gz8VAykKnXu4QJbIo2mmRGTZLGRVR H8UphyFNRCZTjyjpmSwpPHGBzZKJ2NggACK7LQMxEP9oOspTsHNPAq7LsoxggSRkSKSY4klmgGf8 LUXwF1e3pU7LgD5u5GM6KYt7K8TMZDKR/w/BKCBSu033biapY1NGm7JUGmXZ7l7Xq5QfP94uAKPK pd1OFzDq8HC/Wq56qAvpdupAqx49ajz68ssvHwNKPWo4ZkIJyWZWQEP4lkKFTOkboFUIqwqkrLqq EYIyPT4+1p77wKTQoeCqWmU2DbWk8hNFuS6WiWZN4aLDFLgL+npto9Nod7rjkD5qOqyBKJ2vNQfK Hgd2sav187sPCYYe1ithlRSehoPqqrpPIKUuyKeE2RHDVUYLSM+gyHzdkeLBwXX2Pw6kTpp1Zsas fBSTCumkhBZdYVJvXr58uUB3/TUL8RnrcPbm5dOneus3f+xTiCNSrve3/PnlBgh8FE5QcPthHgWH 8fQprvIGQSrNfHizGkytw/PRsjEq3UI6ZbGBxCRE8Uh6ZRg7JpExmsS5TVymQRDCmlAoBTokms3l Mmt2JrMKryRLmoC0ycgk19gLFgjVVZyvZmTWLKinhYhhtLklI5dfy2TsNXjdptcaeyX5cBRCgyYt kRxLoQPG1gYMBN79ezFoQXmHr4u/spn5dLC726zlAv4kpT5ZldNkvUzScvx+o3Cv0nvsWHbJLRZy HQ8TFe17aacDlKTX63YbQJ96jR4AFaLU416jbBnLSlQQ10wZ0sMziTnrMD2BSEIucpGnWcZXJgKW /X5YZz4b5NeWDSORyIN4LSon+XQdiEmI2kwH+eSykVheqw1DHXDSZb44RwsoydBTM44sIFKnW2nU YIfozPEW3iZLRjSRMG8Hh9YEFqru/NgpE42q1FElFdaf1QpVwIyHqLTyVZo1zKzUy8w8BVRqIXAf lzTnCV1anDVRFYkIGlwzsemCh6mykEmpK+Bz4EoZZPxRqDBXBA4ogCSfUHkQBhQgSECkDkYTVYR7 8/STm58k7uhtX35NaIa6K6X66YNPbt5cfqBv9QH3xnSc5o8aj3oDzaE9FDoUEPfW0yw4Si+YXQot fNn0OqYGJr0z9+pjxnh5u0p/ZG5VYzNqusu4sPULRRXlRhBqdGNtS5Z8ho9eAX1ta2uXlW8Gu5sZ gxIq8OTdSVzlG7Zwd9POMIEwelPZklpQQyM1WMKhS/ptGTSOxH8KkQKMqjUdAUgqGNko5GXyDgJX Jp1hxSJNeQltbN6BB4+BHEaSeJ2jo97RyMs70NGBVO13gFt1gD89anR22t5jEAErecUH1RBD4UlD iWFaK7xgEih6UTKogFWlkVN1j/X+eNLM34pEIlHTXAKmm68ds+rpFkhR7VDfHeSNJWiVMqMJUzQU pd+l3L4L6MbJzD/qytfR5OwqjNXuokSi7W3avx25Gd3IlSvl4gYIDtFMjTG4gV3WnLFmuxv1Cgh1 XrnuXiV+f1xh6qpyXdebP1ldYdGC5BaxWEtXK4DQjRjHqFFbPbVpHvBzaclYShjJ0KU4djmqaSA1 zCfhIQMQvxx8LyeXV30lC52CVMSkEKFuRhOp1Y3V1J0HT3WUeuoCLz3Q6BFg1JK5kdtY3dKw52kL QQpaqhgFG05ZqegdHc9STFWQdoc69j24efNGJAo3STQKN8snnyyb7H5icVFOQKowG7VNk8kkUzdJ fx7+bKUqQwxQKsS6uNCX8yluadP04cKfnFVFFGzZXSMb4Goep4dQjuEzgLedFAY/01jdxKaDoSiD jE0gdOPGzcUoBThl0PCYhhL7wbRdDKaSxtb5b8WNfzL3eqf+zKff1Gq1PGEPQJIl6RTAU8axGTYx 9MoAYmCtlXFKuVy5vtPrtFxYmivUu50OyHpHI9d2jwij9nudfQCqBnCoxmPMQ9voNRy4yXnAo3A8 DzIywI8lUUotxK0CAdANaW2OEaJWHBZkXEyb0fyTKeuEG54/nmmNm7cj5kYFmcfjurOR18nUCcsr t4hJnT7xgmxPC9XPIO7ho15d8uS2Yf2ht4cRYmiA8wqpqP0E0eBJpuJpSqla2qtXiBZ1wiop9JRC nRRAVL2sIVEtUQApUAh8i50FBuk6JjyueG696rmVPfXUpnkLoyOzxY20adaOdXujw6RIbavDVdNK QcmkUqsW+161rNWiT8mqWOYngVZwJ7wmiLoZsXINVuc5n+ms52keTXuvVDB5+kmifHB01D0s/1GD HpdAStVdvXyQsBudluc5X79UW64x4c1t/lnHvhuRJbh/nALeQ7YVhQdVtsCSYlDSRSH6sV8i7jgS DFNImyKPkUmOiUlDqqYMJRem9CIw5JK4EPGE37kltFS4bGlrwDnT7uCbTZTskmtrkkfJRRkum61B yQOP+kYsoC9AIQCp5V2+qW/w/Y1cd3cT4SjKXaLI44fU6hL4Yh/NpN5dM7244sPb+LjWczZ5MthF kOLYJBEKmFPSAjiyVc8EiyAskwYJL5NzuyDUtcr26l3b8UYgcRweHh2U7Qp5tLC8RZ1er9HAtN+P H4PQ17NjtyyZF0GxOMhkCeYikCKgkji13tSJ1DAfiZjrBa60Qn+8lEnoM91Ke31Nw/NTcy1qVwFO MVTO73TKTV039aSL6R4XapePfTLrkSPCeBEe1DKwaHymgUAi3RBJCDBlSKNRdUwU+gZ2xdOUUoOs 54GsB3zHD6ukYDtu2cVFAFMqZszyiW2/zJVH9b1F0h6s60injTJF/KjL8ikZOlTI6iBX22CRcDpI lcqHncMOpk7A0+n2AEs6hwedw26H5YViObB4LjoAKWAv0Q1g2KMeVCK+d77WWc9nIzRCqGDy4A5i 1BE0PVI9MF9utQ46o7GqY3r6idXCa7vneT+qG32QotyGQKR0jFpKI2/KsgxSzAQo8gMxLRbZBfFd xCjzdUzMQpxJyefB3GcEahEhUvNHWWwsQiBqkRv0AWAkmxy3uTGDmwgIjhuRvMKk8mYUpLm1/AI2 lEFESSJGLRLr8tEogNR7mBQ7Qs4ESTMvcpwDKiY2T8K48E8upGr6yF0JNnUyBGGPYxTCECBThnMn IIPJzF07EwiBXHmed/KZu7lStdOAx6PjuI7fOap7o+dHR+2y6x8S+z9ESx/QqR6OSNAAaQ9e63y4 aplXSgkR4jFR16HUihgkr9TUuuMxYRRLULaeJetzIZvKPJmhTqra14jUcC2y7hGvaXc7B51u1+tr 2phjn9IiLRScmp4wkR1dxZFTxqS6mj/4MJPuHASWNfIG7VadTPO4mfG8rurVNCTigqlQuldUUiiz obz2ELBIpV/DTApIkldB/bZXDYu1vMxqBfTCEGFFrgpSk01rW1pNCzv6LlOEaqGjzJfxLPjpECod tr5tffvttwddkZmP8oyy9HI/Ao1KuZS+SWS1a3d+1EGqDSCl06M7PZG55UeNdPmdb0evtZapOnNk 7Xg/aC3RtWDdaer8LBJNM1+oNKNLLOGmSApNCCVjRHGyVLQlnJjC1sOVFHHmNRUIcNItHElLJPHp p5/e/PTmzZufsgkEKu68yfwBosJ3fGltS/pL5tdgJ8vElfKbm/hFvow0mSePh9u3b9NS8YIW1GZz DcW9fJ613sQPm6CNrEldPQ96I/8DlpwT6gLjnoIb71SQeKeDxrsrdaHG74K5y6uT76sMNn7lOKYD hHEcPywjOZSil8rcvav7R5E7Qv5uxs5sOE4ZZJB6G25MTCIJLKTT9vwOgNThPoh+RKY61Dl7X/Ya j3qPSrHAQ4pRqZiItzGpzjQXCXyqg53lauqT2ZYRCQ2wgHdhKlEbzvJWpa/iyTRv2FUe+c4ToO1N NALR7FKI/aLufvyQA05ntEgcPK2t4CINEvMsaIVnrhVQ5dn5/Krb6Wg6bJcnzKv0r3hkAsFbgSXl h/XKnq6SStfr9Yf1esVF59ZrfAUGVrEosp5mC666gemmycO1ySNN99yKUn6a4l6ISXVEFiw6lfZh +7vvWODzAQcuwn629Os7htMJ8KxLDUcqnrx84B0djP+sIsydNJkiYdstHXrK33Z0kLqzCsIxjnfR aXe1jd7FU3IHGqBFokF6KLxB7IJIYF4saqmCMCgUR1srOeQgZRnBANqxwN2AZzNXHKSY+W0pwqDp /lcvvnrx4qv7nxJO3TSXeCSfDOQzSRS8eXstKLdNI7GcXFtcYJXE8vLy7WuW3rgRuWbFtVWZzoUb rExmgORhMcnE1r9Wcf7RVO2dkPSgAJFCIzk6GFjow6kj0hXMSq4tJzOlfCbjum65VCiD6HRA3kOY 6tCrlKH3HTANxGFvn1EpiiV53Hj0iDEpEUbIHc+ZPxzLnkA1C9VSHKuslfR6TTPtNW9HUhKd0sIY mE2nzK1aJqo7OA6SZmUfU5p0+IMfYCoUzesTSC3q77MaZniE7nOwOB6ntgJCpAZSM7feXVQapdU0 8DnNxbRWbFFqlO5VlRTF9qFE59Z9TSVlFspe2XsIz4mKZvabHk+DkzrO4JgDOeYDlHaGymaneZN7 FKFypqQfT5QlbvZ1xbnXPWh1Dzr0woRy3x62vmsdHLbxdQCzrYPWt98dMp+mbqvsdZTTPmgftjrd 56rq++WDcsefaMrwBJyUWy/7GCikCncvP/Na4x9VcnSn0ECRvd3otLoq6YKNeuWir7W9uSTHLxPP MXudJL4Am2TKsGK5Uiw7tojgEhG4oag9SldgMvsdc0aKA2WK3kdg+ur7v1H5/j6DqU9v3kC/BLLs MTmLeVHdWFbKLcNMLF9bYC/XL1yO3Lj5vjUFk+JRNsHIoABSJmNSi5RM70IV78WXhRornVhdS8Gu 2/5caM1ng93aFqrCAaYyVzkTVmFIi6Fyq1LOWvH8VqtVBTGvc3R4CNyp2+q4cHNUDkZByn0U+Aij eo8eP0KXqfWYVD+Rs36MZ7mJibxUeC2tFWuxAp0sfrq0B8KeIZ6P6cJ6NsgEZKUShulrnT2f2Kiw TJOYU6BNCa/3Z5ovgH8tkzrH2BikBIuJ1GnNanUamjb8dOKyCPsrMAUUoNs4UpsOcjzrwCLv+JkL 3a5eqde7yq5n+UQZtVioraq4qtlukG8qh71ppUlUxviOlYwOUgYb2okuXkldNNuKEkY5XohJHbQA i7779rvvvkMp79tv29/SVAsQqwW0iifo6x5cOWXArENUIfU1PLmTLvsDTSUV3UBFURnjWlyt6Vq5 3NdUUqtFDNzxOj5An9ryzVbZr1aaOpFKpa8O0phW8kMHlIqCG8rFdRr10xDp1IS/gZLdUTIpkzka GEs3ze2d71/cv//V32TZuS/YFHOBQpVVlMZ2QelPAynY5q3rYShpLL0HpW7eWLpu0S3B9YIh+Czp hmBxJvXuX+Qk9e7a2fcdAGqkarW8jRzKWoRR7PtuxpKBxVYePcw3yi3SsRx1Dg8JpJ6jtrPbOnj+ 6jlOYzrqQ9Ke9xiTAir1GEAqyHgeiPnS75zdDIhQKkpZCmalbXeqKm2eJCPprFQ04Cst0+mnU2mN lwwz0TINmkDu28BcSO+qocJJrYsgtVi902TsazxbGAgITKodNs1NULqDftSCR34Lx7rieYQ7XVRw qf2/mYP+Bjh/jSMBqazqZV0lhV5S7O3WVd1bzVCxuQnXEwfatUCUNu2hptiPMl5B6r6SumiWj2I+ nHtFP6STAgkPuNMhJgr97lskUgdInqCqhUTpoMXyYHYVlJJT6E7aao1+UXnTnZW0+0cNTpb4GJ3p AixRoefBiltTQeqBWaz4Zb/iobeELhnaFR36nn4CJ2qX3Fq/2ew33VKQKwGTRnFteZApGmOpChbL eyBiI2TCRgsDSUyWhVOGrpCy6cYSA6fvv/+bVr7nMLUkQ2dknvElHU2M5aRGgaLa3BIUZT5yW10a +SCTMrjPtFDbh5gUlYvfCDb/xIJ7OpkCRm2SZvwqRin+5jmpPE/bBcCouxtO/fHjHhqtEKIOj2Ti WCrcCg2vQ1RL4aC4GBsDIHWLj5ojUl+YhgR4EcdnWgsLA6lsTVV1wxPflHk58HbbUBzV0wVXU3HX ElY5yFP1sO4/BFzw9k81sPBDTOo4UFoNWsyhUMCB7rZeWwERbj+ELieYiRPhBwe3koPaeYxfqbsB SYrqF4cZDjZalMW8r6mkVsjgV8HwSDWWZroVcZR1pxkzZYoSYlJRxKcVdnlVVd/5ECRBYhRdVdU1 cb3+QX908Fw4bOIP5WYHPnXYIowiwY8ryjWMah1QUj+NST1NpNI5HaQ4bgJGpQs6SJnOE51zcRYE oFIYayCVABam2vaeRhIFtzmYvn795z//+cfXw4FfWpd3SZZH74mIPwc2WHQsJuxZRmB85jpUU+ni Qg2OyXhvWN8jQFU2Pv30fgim/vbiK4SpO/lafjXIZIAuCBqaxI2INp9cUuaTIEsGXCoJAp5Kw24T SN3WcIsvWeZ7s4IBBkRq4zjm71Z0UhcX87kAqsWiWVgA5DXvwspuLrq9u1i4Hqu6eCd3dHERhse/ Kqv8dTpAjdTVYGIdpGAqz2fsklctra6u3i1jGAyOyMGdsHnAFuAUTjOJ75CPlNtr9DqN3qMdFPeC hJ4iE6gp4wxoAcjm70Epyw1Je5YtmVTBLugBNe6xQnoA0NLE6B0RCfiw/hCewmcqHDTdkW7dawZG +KkPXPFgItrPmppwt7WBqq6w2nvOUwb7Qe4iHhLsN1QEnbn1FubEXGyjG9pdDM/TwpprCade98sg BgKWNJUlw2TEVs0BeRN9m1J0CXMhkAoubsZVd/hkNUUh3Q1fhfCT8VjJPfwD/+m2kCO1W8CkgCoh W+p8F5b0WkBa25T9ZaQ5Bty00pry6OUdIzCA2DpzirqL4Qz++LSrCYJR26opW33zwCg1hyxF6Ju/ YL7PPw/cXDj2Cm+igr1eIJW6nSLOZEgTNB/5yRAjxQgnTR6/GzUiBiLTi+8Jjr4KcSmuQb+zBXxA KN9xdU1xnjSjS7FgDihQJLIczC/diCwt8fa3124vAUgpSnc40sStoAE2WbttGYlbphjAj4+LqeRX iDLFuWRS87ez6fTtHNXV8/nbt2/nJzDDseJXnpIVanjVO5xhISt/nWsF2749YY3/Og/A5t0lW5+t AlMXl7xmYZG4NR/ubtW2yP3AWqyPssjrwLS4kS9je77n5ldvr/rdzmOgSN2DAKNeEUgxPsWGVzt6 9gy1511AqR4wqX0Q90QsubTxKZY+kat0MUqtoBiYaqrk6EkymubewVk92QbFsLsq1ZmACCPHfilj 7y4jC/E08nJc6up+UgM/UFo9aR0dHEkEG27q/pgr0Bt7V9VZc8qlPhmPO20laZ6Haam01R3y5AzA ZqrwtKlL2hc1qGW6aXKAQulEFR1rZtRSlFKnA5N6PEbOZsq6n1RU0CggUgMVHmtmmgbq8rohlzBM bAyvt5i7mGUwHgMfbWMu8QMAKJAESYkeQqiWzI588IOuK0qndc3THTMAj1xNhx6Nc70hkFqBfxnJ sw5Sy+n1moaFuSFLfCclzb/8pVYSue2yFEuc5QNaWagtsFkmTjHgL08kGzApMVyLCAoGWc/g7Inw 6KuvvlLJ1Fef8nInk9+140EU35Ju3Vu6sRTMLicNDYdgbulmMBsCKdrkjRtKA0Iurvq3DGGdMkUG YZHOJWmSTuryYjb2O36j7vWfn80vZ/BY7fdxDI7+9OLy3bt3MxyDow91nXb/DOHj4hSnxxeXv17O J/5+vwOLO/Dutsfnb2kOi98/ZRQNdvDu8nzc99vtCe7ttImajcvLid/2+9jYb0/Oxj48ymAbow7M judcVfbuZLCFvuZJkZtFwyhtzkRfBCBSlcZOvb6dWXU7B0COgEuhPupoxFiUOmARkSlEKHI+3+9R rLFDsXsiJkZ9ywygDKWuIVNWynqidSaDnrw2V0IhNK3Q8OkMrzR2MMgYykgODsIUuTJqUDMoeQ2N sDQVq9cxUKnn0l2zltFsebUNNLsvFtcws/psMup39Ug6bcfpUGzLoKlAUq3YAcBQPSuHmRTwKMSo wnZR9cGf5SNGylGQ/NgOBonX5F/SSSH2Wyu2+0TF/uO8UazU3R3Pay/wiNDKNL+CxrjyQ7/e+l+v 5df/53/+h0MSy0AsCssv2n+tGejMkHocahh2kNtJ7Wd10U1NRwVMSrqnWCs5DaRMS8e3H3+8mg3h L3/M2eJmkU82FiyaZdmChcZc5o0SSS5FThZm2UshN4ksCVD6E6LUfW7ge/GCql+gT8L9O4BS0czm ZlKsDavpjgQqSEGXiy/dWM4HoBW5saS010FqjUDohgpyCFICkqKoQuMJeKVBMmooTOpi1vf4wLqV /vxygmNIws1VB8Y/RjI0q3s7lfJ2ZXu77E4vfoUVJhjf4U/fwfQYtSjkr+eWtwv98xkGoVbgxtwu ejNBiOD3vO/WK3Uf93fmVypj+B3X63UfNgo77o/97UrZg25Zxwdv8/yCi4lIpPJXQ/YWViCXskuN nS++ePzYKbUaj3u9LqY9kDwqGFbtFYIUw6gj1EjtszDjR40ifyoJxzIRURQzgozHLCMr6Xkt9lIx ylIFltPdiIlaX3s9vS5uNO5WxcQ9XW+eygbDYwVZqvb0PlduaNxqkOlKiee82VE0UvmcbrS3D7pd v3O6MDqF1j4/mfT7DZknva7vx8Y6BTAHjrL4iYPZnVSnryerK5xI3SsUVWlvml9KWRnFZnlec+C/ r3jVHbe+F4rdY9GRNkhDWvKGwXKqUq3jfRpmUlfKNJ9CM+A2+haVH8IbC2bvE+Mft/ibxnX4WnWK evMgkYZj10lQah115qyUdCblaoLhcnTFlrYVR0G6N2/uWI6qN7+m/NG209JmLIuVJYyS96Yp42FQ U8FVUkFKTKYEjy5VFAUUkSbUS8HUBqdSL5j+/KZhb+VNPjBf3Fhaq+VlWbNAouMh35tba2sZAK3b fD6/tcVAis9v5WEWF24xj841zNRgRIBJbYrNkXeocB81+NlISVXk5jO5x/lp3wXijMOu+WX//HKK VuN2v+17jbo/QwwDVu23jzrAe/onl78iK/rcq7veBHjWfNIF0oUKjb0mTI3nM8/bAcoEtKiNTOqd sB2e9/G298fnsL12vTJBkKrUPb9DA6eBtAFsDbaDe27CLX1xiaqqORKp5lZmESip7pwWn1t14Nh3 dnZwVLYGJl/hCqlDHaMYl0KUOqQIiR4IhT3KiOA5xi0xwkZMMCoxbKlELpYSndujzACsUohRluYD mUdHznUJULZIos+ir0qaaDhIrhTUUZJROYUwpbkpTPJFPUVvM+OdSVX90P1BglRzraj5IgCTOuge NRaGzIiCYzC0G8K5XDfW5eBQVP33VkpFLLuMSWc0L6l0nZkBMLmbsqHmqpHN2ir+DXPwv7PRnnx9 AAgbboZm80l/ONNG0TnORIuU0x0elR/KJzXNm2QdSxc2NpwNNqirtE2g54QLhM9j47aALKH7jJvw 1GzrfgXSuxR9EHT8CgmGhngmAcrkQzKjJhleV3btAOWYiZPybyBGiTG8udbcEEMcmULAIyYU5ZQq srQRFu7u7yBcIaPa+R4dET59wUAqcju/lUwIu6GWvGAtCTAURLMk1wzEIRk1s4ziXhAzk9Sik/M4 Zin5nasblDjKXbsoqEPiK0t9x5jUed+rUELu+em02zy5nAHk7E/OZ2dtb2dneA5MqupV25PT87PZ 7IQUUaddHLUbblgU5qByNqYgqtnZyfziBNbuTnC0s9lcKNLxDXsB+Coj6r1ucyYFG+nPzk9mZzi4 0mx+Num6cJdCxQnXv8+nu1u7tbzqA3UVpJhSihn2yhUEKQDZHcy8gvlBmE9UGKReSQvfs6Nn+w2E qEdo0Go4yJ5vsbzBXFMuh0QWwwIyPRViU1LBKPpBUqUZ9/JLTNYjqk5TlKoMhT/oOSU9s1xiJc0G WdeG7ytrrkDTTcfzxoq6HeAhoFqzpsSg6aZZ0ZnUCrlZd2bv5x7nk34Lx1l2q0CmlfqTfKFc9gJp DGiOIg4e3113tAyjs3yUYwF6VyvodbIZTRcLWVXQnZQqsDN0voBnpaaYn2E5pcG71NrNhIUD33Qa 1Yr/YSZlZjFDnJMmu/5G2nZseyOd3ijQYC10ucsCt9pqXs03D5Y3QKAMOT/JoaFhFc2b8+md8rXa qxUVv94Afn0USP28ZgvXFsQ6K2NZCFWU5DpIGmBRojgRtmdJFwKWLpM4SiSqaKC4x8H9Lxin2th4 wRTqXDEVy+ThtuZj4kU0kAImpYAUMKnIjeVvgsXAsyIKLOEDPoGvBHeWMKH9krpBWwQyRwWT4vmk uG2RBoMn697FGfpxTCgdwnw2eXsJXKgMhOdyPgYqhUB09nm9OpJK8HfvLiZ+tYHk6Qw1TMh4JnWv DFuAyYsz34NbkmuU2OJ3jEkBj+p41fH5xWt/pzG+QEmx3plccHEQGl2c9yuN7uxSukO8Q7X5k9oC hNKLJbLd3a3v1Le/fPzlzpc7jS97PS/vtjp+44jMeQvG0Rb2vaNeg+S9XrdBTErwTjbWe1IZqUb1 mJMQpaJUUgcp0qowZELOLkAqzVTpG47mtvQEHvk2BWlhQkZ4cZzSXIGm+bTek5/YlUZgK5vJRcM1 S2Nc6CdFfprtBfn0tALSv1en0baqKq+pmQXHDwL3hplo6STY76aVzroT1YRnOmSlxDHjfSXi+hjQ C0CqqB7EFjVEQAtnUp4vGDJiVlu2yiwA26t+BEgZLF2csF3Y9MigIeyzaUeMswlXe8NxR1qY3p1o 2WvshEHKq4usoOUQyfJ1kLJ4PDDcAXZY++5+FEi9NDPScGwJdzxMzyJCigmXYFoMiMTzdxCXsoQ7 p2UsWaq7AVeSf/U3dOz81EymvnqhuktlmpjjiWuvZcKDb3YHeXMpsiQTHGytrhk3ImsyS8JuDSBo SU2QkIwaaqGELcuUVoHnm8pHGRSZ7CjFqOKK44Twk5qPy16lfcY01RcgoU1aADNvASOm/jbqqJBJ VUB0Y2kJAHTm4+rn/f4e9A3kSiiVAc5Vxizry8TfcfsnXGF+SUIbOSPM+8DP+42KNwNUrKOoCExq m8AK0ImB2mm/6vmntMKvtLGT4RYaRWOLRl1QQYr/LgPcfvEFiHtfosa823ZXV3MbTrlzhUeFmBTG GO/19h81HnlFYznIciiycopRTA0xXjIRLFPFKAFV1hWQsjBBmZ22yNETp1eEVgqWaM7pAxNQLGtn +ePdSZPzp6M7VU+3TD2LCgpa6rzYYi1h6Sp3HHcPhy8ou+FkelcK6iipaEqpVEENQnmSTBWDxecg 3WVd5dQHCZMFU6NnT1NN+pk0Majf0eQ9q4je44DI7mIXB7XMmsvRAkFUt+NXP0InZWZ5bI3IxyRG NSBsCugO/B3HmnnupgWXwG2HQcqTKbJG+qK27oG+UXTYIC9A1ML4pamvfmYpPJ++fPmzXt6srSjO LSsW+mmkKdFdUvEt58N3y7HIDTkGHs9EHrmpuBz8SZjyvnqx8RWA1P37X714gV4IX6UYSiV38yxN FWwvsrU7wBQr9N5MLN0w5OzWbWRSeTn/zebSzdgt+B2IzxYfxtewBOQB89ra/UaWfFTkCeVKKUMh UgzWuMc5Upz6mEtlRIt81IAiZPgVH0FktuNVuziyd78/wwYnXfcP/Um/stO/QNIDctmksgMUiWBs 4qGVBxqPxtM540REtub9incwbler4/lbv1I+g/VQ3Gtj0yOgV4hpAFJ1/zzwkppP0bZnW7HrZT0V pTIZB3Ma7Xyx87iDfLyUWc1nVh92R6ODozBIqSjV2weIIuMe5g9mCaRuGWJY5WAgPx55QHLgLbyo CpdiVCqJKKVBSj5Cz0KGTDL6A+669EoqldJBqmnKnkMD04JYQr3LVZnUJG8VqyoBayaLlepVbTgQ lo2KRtRqJkV+VaDLXEl0qZfz2R5zKS22ldqBVSgqx1uLprKKqmmQyq77igkPFgvlmx4oVDMA7AAn VDXVsUyY5H5wTIppzYg6MkbYv+L4daV93iykA1QSIKUGyvF/Z90dqMIeuoHjQ0KX6VaLdRZrjSgV IlmhCL1CWUlBEwq20ebfvHzAM3KGknj+/DSlxlyhMxlIe4YQ9DjfiUmrM7ftWdJNivX1Gwkp7b0Q LlHIpL66/+IrKJxH3cmiee+Tm0liUgxVVGb0TR5dEAST+mZrDXVSAZP6Jo+un3mFSX2zuSqGo2Ps TjIpXvJieD6WdD0YIpCy4DGlFGdSODbQ5ILJZwykMGnQbNL3Xbc546jlVyrblYKLmAXS3h/8CdCp Bsp7hCgTb0cwqalP46wWofl4fvF2Nj05OTs7nV/OR+52/2wCpG1yxlARmFS9Dnjllrf9CYEUWgDd M8WVk5ykMjHrCkgtxqi7mXS+7u2gW6FbKuU20Fsq7wFGeeXRNRi1/4zG+EB5j4GUcctUmFRMZjo3 VSLF3M4WlCQ87HQmtWSiqyJwdYpLTqdMYQRMpVPw6Fa70yBhyX5TIM0V8zZ2NS3XZqqggc9g1SmX r2rDa4ZZCDGpJe7b4Kyk8x8gUxMufVWUuuPcuqKSmuQjlqpYmmTSTlM14UVS0iTlDgKV0nE+AsKu lbUcFVhrFh+cwF2YZUYpw7yCUeidqj0TTobHx8Nj+hJliIpzhoAKmyKtYJYNUs6122kNo1jylJUr Lk53KIe9Wyl7VS8Uq5fRw/7WChh0TQWe26FFezpo3YxE8PaJLulJPEHeyzLJlHkhbKRXLEsZItwU 9jxRwZhUlNvMRErziCRSL+7fkRi1DcIe4NMX2wzBvr+3jb4J6+byVoariijpHch5u/QZbCWWIre+ 4fMDNM5FIvkBJbCDquGmCfNIpRi3wjbfbMFjXAieUtyTr7xME8r15mLEQEuklREe52/bZa81If0R gtS7Xydc5vbqbheNcKikavg+xsB7yLjm48rO3vxyWt3xmEYJYKtO4h7KizN/p0Gt6/4EBMNGo+23 vfEpWvegb5114fEzbnvE0MYYHN/yEQJnpLqa9Sv1vbMLBpfvuLSXN6Q4l1xo5qNiQG0us5qBG2jH 67iOW3JdJ7O6etfpHI1G/oa/QCVFKvVnhyDvkZvUvvCTMuToxyJ0T1hRpKWUj3l8tYRA6hRBClCK OBRj7KwZEXgrrVn3htGUeLDzN+/jeqC/WSiq4NNMgqTkhqkUKsM04oPUh0RMxD0rmswP3gtTTeZV 6ipKqVk+reiWQGorFp1AKYXuSJpXeTTNA4PTtqtJe3gYgFJZTd5LCf3b+5nUcW05YpaVQOiuliRi mFkzEonlBPxNCaEKuZVg2w5SW3KM4p5rNh8Q2HYHet6oSJT+Mkv3M0jAFSTLnoNH+z5x70HB20GQ KlNa0tCidkhHVfZ8aFkp5/TUoBi1TMZEVABswE9uRVj2BLmPidHHRcgpQUIKR6bCiGET44pfCIj6 VBbArYSlR8d8v4F+CV8t53kSBUCKyO4wKLUkiGtTkRp41wYiFNk6HvByjGmAo7cHx8oa8KjIbCWj woRnYn5OnnQYv7ciBiVeZwlDZW+T7It5nBOT6sIFGjNRj9wuTygOv1KpN9oTMrLNvGqjPT6ZTM4m 6Ps5a1cae6cXJ/5Opc+zD4O4V0eQQtnQ9+r98QRaY+NxeXt72y2ikgpB6u3luFX2+55bJZBy0TkQ N4vODOiQ1a9UG2cXmrS3a8dUV3OcXFtIpzL5nJ1z3cJGuezkVjOZku+7qznYWef5qx82SjTu2gIm ddRDp3P06EQ9VqNkxCRT4qyJk1CZ3T6IOVdV5wKk0pbWzXajpKjiscc2YJXEKHTK05w5h5lUYLSm uGUGVK6SeeWnYcbMrqvgM7DS0P3CVOrJWjSddTSiVosExqZUNJLIXxnoQSnTNBsAVYHD85qlqKRq yTSQLeVcaylf8XgYJEzb4SOchKS9KMq8WUtzOp/mmGNYxXv/aDHTTNSqtr0WOjm1SeYKpQ+OKv9F 1IwmoN+k0sxP1MFRWhwVoxCmhFv3FYy6GeH/WgikUmn6Z9jj432K87Vig1jUDo71qDGppw8KIdJV 5jnePU9PSvzmQcPDdDd1t+6Vy9sVl8XsCduzYcgUnJzhs2yccUPEw1AAXuKF4mwegFQ4Oub7+5++ +NuLT+/U1ggrcP2lXUQU9hpuIUiJ+eluPk/9QRbqJZG1wfFgqL6O81E2thVjUt/IDR4PNillVJxr 92UAIhsOQoyiRUxqznRSZImjWDrUKrX7fcCg9pRUTmcgzPXn73hEHix3vb3Rq6OGX92bMbPcpOK5 P1DIy8XU90jbzpyjJk3YUr8JTAp2s91/e4GKrh3YAOzwAhiZf6ZG9p30gVoFWdfRAaHmcuK0zKEI ZuxAzrPSdpoPveAUyts7nXq5sLGyurq6trx6t+Q6D48OXX/0fLSea19lUlzew8H40Of80Ze9/T07 KZhUwlBczFnO6JjQU7EcLgA2V1FqJT3UwmKipJHiGGVn0isCpDIrdtpWHa9BYiJM4uKHVJjarka3 Vs2sKledNlfXHWddT/mCDgBmNlsKMSneN9HUCOInPMbW8oNrTH3TDEtEp1K95kogZs62zGyxoCml LFU9DrQNQznI014xCaKuKg2SeDFXcjSArqVRvKxW/Q8MaTV0PPS9qpddru/R/KSGmSzzSZZR2nwY ewlTBTZgom1nNYgCjHryZ8Xp+w1glFAHlTRqkzB5fQoTXujOnI5Ol4oswoiCIftaboXV8tGftaxV xY4nXr465vqbp9wZHuSNBmKzYwk1Kd2WPMrUlLckQy42dJ5lZ5p5HAvIfPG3P8EzWqrMmQvC/XAM HxCtjXv3P72fZ4nnSOU+nEI5hhcUZFK3+ezwZJDPR0VUCyvkDrG0dYwt2JutOGxGSTlOIDU4EYum xzXhxyUcJzjgGiJLaMCkxui195YJWL+eAwiB/DU+OxtTxmqSwqrVKgtxId36GF3RK9BoD26pOVUB rlV+YBrvmV+VBAsw6y2GT53jPDEp3Hq90XDrE9jbuFp3f/gr+Xu+I6fPU/SlOpPp7ubHAFKlkLu5 NpoVjo3OsnXadNNiFk6v4pagG6ymrNVV1+8+Luc7z5937dKIj2JLENXFOcxs/ezZ4WEPqNR+Y6/3 +FHPsy2e9sLUYop5NKdi+CWOdRWjkitpjb4Mk1aQxgWtfCtMdWUBSAEkOSpEnGyapCMhR+PAiT1X UzcIYlZ6XYt8SyKTsnXvp2EeE8Q4IZAS9IEPMAlsPmJE1zK14QI9+m6KWqrpCoaKwmiYp6RzhQAh hqo/BUibqPwnJHCa6uYnzfFwMhzjS+NAgC7oKKWNFkMjFU51FO0XuSGQ1GtFR5eF76ZZKjwHmziF dcXljCyN2cJ6oDC3A6152n3yS4hHGeJfK4UMc4LpWun1XQ2kIjk9K0LB+7zaqPKhukImwpAhsPy4 3Wl1HmPOnH09KXGn1aJAQ7/bOejuubYpEptx3XYsIPdMpSMGDTbwfwV5a2DfWDo8e/X8T8+PNJBi sXo6SlXu3MRcCMmoyWnYEmCKKCck7vH52XyATEpJtmCIua2Tk2AlWhHIFMmPUWRiyrKmHEuZO0zd 4qfFB4qJSp3UJfpJUbQcapQmp5dT4Jz9+cWsjb6W56QLZ46b5Pn07i3q1fd8199DzwSS0+aTeqM6 Opd4NRI4wxMioCAJTKrSP7m4QCDq1atI3caVSnd8KZsCSLWBW51KjDoZ7m65pbDWnA8MI9MIU0yf XcHBTCreDtdT7riVXHp1bTXj112nBaQpn/ZfseBiLKMK1PU6+yMQ9wCkAKJ8F4djeNRwLHJCEflX pW1PDmeW5M8MHnZ+lUmtaHqmWT4ImmH3tpkgKsUS5+X0lLhGmkuFCkZZJT0YMGJZmlGwuUzdTc9m h0JV1tZ4EICULQqKkWw0XBNHT7qVzF+x9z1hWuOckh/luBnkbBisWtjxK4GH1kmzr6qkTKfAhiJc d/WU7+iYycPIVXgpkS/n59poMbM80NrVpn5oTeHvzc2Buk4qFRjxSCEmjXoFzZwXKmEe9fRmxExf A1LKSBz2ruaxELFD+aWqrDTg1dVBqqIrzh84j/+39b+YQKzV6qqpp9487fCsYh1M1eo7Ka4UlUND MveYWBDAxYcRNqJb0+YgXxsfD3bdyatXf/rbn55/fT8MUqGcLai0uv/ZWozJjPF4dGkQQMopglRS zM0YkxIZrQyZyyBqbDWxwUSBqUmGUS3GpPiSkyncy8HQyeRAwfsW33CceSOixznAR7kOEhmGbvnN U9QqIRe6mLTrXzTQZocV+2cnZ+hxPgcM+wI1SdPJeG+nvndGAHMMyDA+Ryp2cebv7BxOTmYzsukF qTnn/R1kUmgbRHc4jDT+obHj92cn6Jz+FpX2l2ftesM7lSleZijt2Qo+rSWXTRxQlaFTgF4xy6nu bO9UPm9Udio7GBbz+HHLc927q3dz5ZzrIZVKl3gaBPgadVc+c93PnMZodPSsBzRqD6hXyceBYxxL jAbLjSUxJdBYDMYnnls4qZAoppRKOlqfqlG2kVSKmfUAfACkUE5lJj5bC/QbRjmUaSHLeXXsmdlW xLQ0o+AAtSTptBoMh6Y3ImXX6KRwD0Itn123LSMSiWZCivQnUTzmlKo5mincZ9c00ec0q2DjWMGz J0mLM5dC1j/+oOsTKryKNEJVKHYvYkSili6RnrvkroC+rmiwC4OUTN6F3rA6KjG/bRazuyIxKJ3e IIxSMeOTGwoUafzo5ZpckknnQ2nK7V2VBD1I84FuAKd8nUmZAFLqqp+VKeS53cIYiR+0pq0gOd9B 212JSoyKBf4wwTAxSQ4a2PVrwwhevszx5eWfmIfU8On7MYoCZu64d0QsXRzEvZMZoAm9TgbEpNjc 7O2QMymewCBuiPFogDANpqIZvGD6ZMhGyUImNacFpwhSXAwUQyizviU0VFEGUxbPJ3XSBlnJ62Ps XsE7v5y6O5URgte4AaQEKNYMUMXrtv122weG1a9so5SHPp0N5kcFclml7gZMCogZNO34fa4DJ23W eb8CDAsdpn6o1Ou43sW4Cnclhu55zTGtfNrervhnglhRlhZ3XedRaxZKeBlh0btNmql0DmBv+4vK Hyo7X3yBsXuEUx2v7vv+3dt3c9tHz0e+zwfXfvX8oOyurGZW7VXHx0TnvWdHfibvVBv7nT3PNoXD uSnsejKDRDKYFInQFSolpzJan5oYGCxjpnjOEVMyKeaHoMHINJNiST8thmmEZfau2uQY4MfK1FQm ZbBuo2rBvzFwBLd0Thf3IkwPz1FwhQQem/VioOLJJxpjeWLg4aUsVSE2DVRS+WiKXCTVRAlqUoSo xQe1dDRPzuvL0KE0MSGQMgs4iKYu8c0ch/njo2h3hUkFTgbEooTSiWwQAS6p3kdpuzb8s+7EGYkG i60QPzLSwqxhOXr+KGPlaw1fUkIpVq34P2g7SHl7Gl96UJa5GLohkAog6qDt50yuikiIAC1Op2LC SYpTEAQPdxBh4xmcnDGQ6nkhkNr4k45R36Oj1P3P7kdjcYM5Ki1Nf5Xpk34doF/UJU3/dX45yW/K UfwsQzhsxlnQ3UTL4PTrfEhjXi3duHF7ehnUPokIFsWGUGY8wGQeUmTcE0wKIGQyamACgopbrgPU TNBsd3b57tf5uFL2vRnIg27HJce0QvvsrF0p988IRaZexSV5cI5TY+Y2PmlWcbiDslcutCkLwgXz vkLFuU97O2u61fIY6n6oVqpeFbWcOfJwvzzrlyvumVSjoyenazPb3hrTnHMaJYP18NfOFcveDhzd FzuAUV/Uv/B2dgCpMHjvsO2ura6ahYPRGIfVpoQtr557Ti6PLCuzmvGOjnAsBnfD8b3Oo0c0zHpA prncJ0x9wheBuU8xByoJTvwHx2nQ2NHprgQlolLcA4GUTSUACa1tjeENEa8Ub5YPBSEDSCVrStUg QfiXUrZ0kieNipXTIHAXmFSW0n+spNFpK82GT+IcI22a2iA3TxLsIPUDDOAjQkNY2iWl8lxZHJW5 ucMjpV5TMCNVo+N1QyCF9jirqWvTx06OmNQ6yKsLmBSTZKlgAEwIkgiWtLkQRqn6KPaX6fwoGizS k9zdiaZdteVTq8y8zSpFHaRePrD0Qa7ePM1JkAoxqQdyMMWDrl+yOHsyxAghgY+UYYp0LUyZY0Rr x0zuSx6fcCb1iwpS9/92pexgdbdoREU4XSwylJgyvxxYAFJzjlqXw61NDO2r5Ws4atXWVkbKfuip DvxNhanLQTLKmZQCUgNDxhqykUxjIkGW0HXFhU6K8klhBgLf749nFxfTvt9lKqpZv9luHp/PML8B 5ipot/tnZ/1Gczwnbffbfrv5hKSzabPJyRCs3Wyz0uyfiASemKpl3PZHJP+9HXebzcnlxXzcxURV bXg3h5QV9OSHZrsv0vD9ldzNS1zcS1BCKc6hLKFLj5mZnFsqb2Ok2c5OZXsb4GmbtFKPCaUee05+ 10mV233fl6nvRgft/qhPKJXP7eyjcc933f0eZjkvWbeCERekr5TUSVlieAZ0OSenf4In8WJoldSg 4XRmrCa4F4JFfukEWqjraA6bK+uawnuWtAVKmQRTwJp2tYH5aktR4Goak0pYNj3wlTTCaxFSO+XC 1r2s0x+WgpSPUjRiyKWNyfckwTDSXmhuY95OSFAW+q4P0YkKhzSB0l2ckP1KaVa6OJiXDlIp8m1a D2n2+w7Ao4Mqr8IVkLKzaUXEs1U8Cp4Uio7QytW00c4JozRx29zUbXgrbEUzbemZppZN3Vvh5SqO KHiveA9gSpfuHmx4HV3+c4K0Vgc66WIZjg86Bwe+uyJ1oexZack50p5zKiUy7zaPI2wI9pNTDlKv fHIp50ExV0EKxT0gUrekkgiYlAY0CFJibprfNG7c3J2jfgrkupOTreUgq0s+unZy+auy7hC9paLA pE4ESL2dz5sEpszdnPyl5BjxBJJWYN1job3zs7PJ5OwC8zjB12x+IarPzy/gZ35+gW/gefBFrZAj UeJDCnuZn5MFDyOMg7Zk+SOzHdsqJdx8d0mLiIBRyzmuS/vF/KAXb4Ueaz79BqS9kq0Y84KM5hny SYhZaQetel98AYJ/o7K9AzQK0yB4GGCMGPW44+YBfgGjMg6GGY9GOPLsiNIH+wBTK1YZQerIc3Gs 48dfdqqrseWYJEwiRQtlRbA4kxLBezzTGGFTMqBSRD50S5u1aimdhKvNbffJbD4w05owdzoAwMGe JXw+zeSmBjSopUGQUldhILWyIitnTZ5pzw4pzrO205/PXAKwrL3OOnO2sM4Ih7WlHknNMFkEzzeL EKWWoD1YurdTsDiZAozyKK1Bf1GDBWXoklijJ7pJ0UC+2VLIUcLnLlj2FXFPyTyQVjVPGkip42iU mhMNoz5BHqWLgzmVH71MMC4Gr4zugXAzlQ75IBTuAUQhRlX8X9SWdwptTxuJ7+lnrQCk9GQxB5R9 vds97Po2jiDMXKGEk5TqI8X9+izhb54fJm1MJWWeXL7iIPUUI/W+x4TmYUlPgNT9zz67v0xDt9M2 IuqQd8Sk5Nx01zVu3Bgoi28md2WCg1UjszVX1gWQMolJTdUNolTHdxUP/KTMwOYnrXvMkRKAhsXh 6WNzXgSjyVAI3ru/8qwGl0pq8gveMMhrHi6/kj/7JUttfiEVVTjNtxP8CJDCcYtdZz2ZvJVcVVwP 1jiLMmLLSZuk0O3KDvveqVR2RGkAVD3ueblk5+gA8WijBTzqwCt3D9DTnIa48t183j/qAJMCabbT +fLLL3uenTCkt4kYKSYm4oxjwrOThZ7zUL5EIhHIfJQ6MeRZ2cwxe53aVeza4Pz8NBNNl3REc+wV Er8ESuV3T9WhX5q3MXxCY1JPDBLd0ivrEzI5Hx831zCJ1QImZdtU08yBjMPzx6ALOroO2UApVLls hrovKrodgC/dipgoTsFhLl4czSJIfY46xw9HDPOVXBzx/UgFqclmityts9mwWqrEY/3s9WtAaiXQ vy0sAsZKg9d6vF6ETA7C3Z9+clqc3ZrEwfJA86yKZLPayAw/P82WuddWV+dNd8peaCS+zzwcrIZG rAmNgoy6KBxPEW7ilNCUs0elxZVR/FEqnc6561E0P8jvoq6nBh2bUOpPPzxgiVle3PwqPBIDB6n7 n3n379yOxZnMEI/ePFFktido3RNE6K9DZFI3di+k9LaLuYEpshjji7eMG7Vg5bdTHEwd2icVava2 KRyiTBFiTD2OwqPNOMvkoI5gzF01efYBWa6MiP5u8Qh8IXDSR8mSWaXeqQ3e/ao3CJf5dHfXLeXs wIlTs/NhXa4EN8A2YdQO/DSARFV2mOL80aPGDvzppZXVcqucs1fv2ne9w+dddwPHKT9AEe/w8AA4 VreLYxf3vGqj0Xn8uAugJpSRSSbr0YzQA1hCW0VWCOYwBSCFol6CCX7ouZnS3BQxX6ZjkwQnLXcr ThNNXjMcaEB3+waewwU+Aql8baoRqc0IulSHdFLCgT1/G0gfvG8tRVmKtNwV616miaqjiXuXRKH0 StAZrWR+qMAhUDZOOjIL9N5MJYWpt1fsBYsnOJQLuq010CP8I0HqdFCFTrqvuiCc5NMsQPdeVh9t /vSMUApIoK0FNqJOSmNSEpFUYFKkQfcqRvHQJGCazIMhNCjMz095Cp1CuhkaoaHgOF+rLV/mKuUi noDb10U4sw6MSR/kCseDxaG4OuHxkoH548jKB91K2uRGHR60IlwPkjzVuUyMwGlIcnc6zUWjNiXD ReL0avzZp/fv4JAxG4sx6m9ffVb97NMIPGqZFBY3ljKSG9V2bTNyw5A57rYymAVhTZKn3bUbmE9K ZHLZzagLtwZbSdjijRs3N3c3gy0wQS8qDXxitBgh8GElz8z5f7K8ezvYQpDKhFw4RbHSbJTEynad qNQf/gBQVf/ii51t4lFAi3aAIGXsldzdPI4ds3oXqNTIzfhHh0cHRwedo8eIU4e9zk6n03jU8bzq Tm8HQComEkZJ8V8SahEwJRTq/HpiVq/Axkdqp0lIUzPN22xAFNSIAz2qDU8wjRsigalTqfMT18ZW hFGr+aaGUadPlikONdNU4KS5xKyHVsqIRCI34BVZ4koVu3nFw4pzsKGbYzljgPmlMGrVXMlpgiey Mb4R3Q7A8CRpcJVWNrcg2G6QtCr1anWHgtbUy9DczOc3Fc3FQNXVM3lPY1L5HA2b7Hn14li/pGOg WFmH/KQ0j/OVQjrkdvAekFqvDX9RyBCqo6LcHGijvguze2HUnAY9bz5jCe8cf6SNbLycBtb0/3X3 Pk5xJFe66IAqKypIVJQUuEGSIaDhjWQM7AzydgONsGdXjKEHjaYDxHjH2l1Pc72Mb+wbM3ZsXMXa EfzrL8+P75ysBs14I+57O/cVTf+oH1lZVZlffufLkyd3cnfxP31KQL05eD74bctT9Kfzw34y61qe 5VvEl2hS+BaR+vbnD4YJoM7Oz49O2EXKhuzlA0zhMCWaDplPEgBh+/r6ohPY6rr+Hwml/ufXy//X vZ/N7t8NULT85qONZuoRlGuKzPlBtkyXIftFxWz6g/cvUxMbKWNT7VXTsd0vqDWLL0Hj3oX4Ywap m6tRsvYAUreX5skGx8D4iGjUxx8zm9r8BY+VwjLc7CRweri0NL+0sPBw5eSrL/e63aNk6p2f01R8 r4bkGDUkO28wPNnZGya82l+E625jLrwlJuIzQR3dK7WsIJCanY0KVekjdCejX14eP1vpPEwoFZul Z73RWBwZx93Ei8LxxL6H3aVGIKo3asfGfdudZpCqe3lkzkAnZgjk08+S5hUTbVt4GHstTSrBjhmK 31309jrsicDoOffw2Rc5Hl4eFDab1B2qU4+CRSVGQX5Qd2w+WFgjZNlJGPV5bu1dPCjCbDEbkkkt r5hDz3grUd/WRDjj7dXT0z7N8JpSm5ClvtjgML6tGFZ/+MNXh198dfzF6Pj4i+PRV8fHo8Pjw/T2 dLGFUvhcObz49/ac6s3THs3OeahvvGytr678vjWerk/lbuP0t22/hdm1nZ3NQWvPP31K42J2Tn/7 by04++lK4u8np61d/+ko0aXheTL22j2ND0+H50dn56cnT+cVoyIQJJp2qrpDqX6V3LlHDkiL9dfX F88urhNGJR5FOPWLyaEw7eWbL7/5x+mORVap2ih0r8x/3gvTTQt0qInMfk0g0hQZcRM4Nm3DC5Ud ouqpcF/wuh8xSNE8MQeZbu6LrJl/urUjvnIJoT7m/82P99n5YD/h1GCQXk/nE4daWJxf6HSSube1 sbHyYOkk4VMq9l8OU4kY0mR7CZo+eTXoP93ae5kOWSxtCquYt1M2hM+mi8G2mEBKF+NTs5MhBr77 7g8Xx720HB5fvLV43YlJPUyQMjHw47vLC9qzN7q4bDll/+GyF6Y4QEznIAOp41TXiZ7NxTnMsblA nG1hbmGxN8Gk5jIp/Xp8cdh79nQlLc+2eoeJ22X7vn00ZW4TT28FT7ncLh6Ky/fq2ureXZs3B7p8 lVt7vYXlja2drT79pY8EYi0adrz1+eetKeLH3ZWETyf9PRpNPBlQdG+TQxNvtddyp8x3NKnVH+RL ers+bO7SpyYk8wQ0v//9n/+dlj/z/5/5y5//KXGp1qDfP/3+qy9OvvptC6MSPZqjiSE2W6TrT3/6 56+++OK3439rdx8u9NmF/J/be/7Lm6Ozs3/5uoV8n/109c3pyfDs/GyPjb1S59VmUVTRSQUpiSCr tp7ykxgedEdjquLfffc/vmSp/B/XfnZrZlDHqM+/+c3sfSVlLBRNT0/Z33T6TQRpSl7TpKt/gB+0 efoD+Sq/CeB0K/0zGukq7FJUqvOz1u8xkTHnnsY4//GC1PXVqNe7E6RkWSRNkjBqn4hUYlJEpgb9 XdWkSDkf8CShncWFzlJ6W1xaXk4/90g0P/2SJuul2dWJTg0+GfQ3O8/6w2TwPSlngs6+EDAzbImi YLGD62xbKShFz4DYFLtgTnpJS/357rvLyyuqQFhzRZrUXOx+PQlp17zn9UT1Hz34QAb5Ny0mReec U0BhVUz8phJQLdz2OM/XXF9fjsccUOPysj1I5bIbphCer7mtOr0lN6h1nYVq85YTwttuM0gMlV6t OeJpJr7ENjbTa4vHi2xunebHXSz2J/yktuc3t/obe+m1s7k+IUtdbXJo4v4Pu4qqnD4JUlu/b2NU WmhqTn7hL635rFibX/22hVL/8e//lgjPf7SIFIVDHyQDt02l/uPPf/43mvQzW/XZT5cZo05O24n+ nicz/XMbz2b75zRN/NnJVmy57qE0qsNewLh3jYIg3pHUtRfqZ93exWj75Bt05/3re1Hqm7RTM/0g 6pHUx5dPQny/pCmt7NfMTB0S0PicxHXamm2OCZGyCZDJp5AmYpjJEow+pXrRYBSiIG+j8n/8UYPU X8lNamt18Y6Ad7SqWdGOk82PVZISJrVrKPXJ/mDYf0r+6Ytk8CWU2trrLy2sJAZ1+uUp+aUMiUcN BzQHQ399qbszfMnTrOecCV4IjXih6EBz9u4NLlJFplGz3M+3QHE8mrl6UpbiZQJ1krlHGnk8vHPf ydo3eiSR0Sb9pHSmUomcQBhFkjg7tC/e8pN60h5H9wcZRvfdpLZN2leDESS3VadR3XiQgZ3bmzvL FN2XqmJrruUEFgnU5iku0vLa41V6red28WV3bXWrPTloQzDIoa3W1uYnZKmvn64nkrP1Q5E5KcBy WLwTpP70Nyw8fd7cP03MivcfE/j22c+LDeLug36bSn37Lc9K3EpvVuJhnff/eRL6/v3PrX0J+c7P hydvzk42Hvo40qhWHRzOtaOvlqmLIzQp5kIU4qkout2QzcTwr/fuBqlvht98M3/vPkb4NgJSjx5g efSgLKZotlD8mp2Zmb5PkxXLb5rC+B42p2UmQRb/Sv8yEShNaSW78+q0rsmCBUezUgi0FL5+5Exq zExq/i4WRYEP1nnKjk0WpGRJUMXDixmiXnyyv5+IUn93gyIlLK4sLi12nu798+HSytbe1t7RxkY/ 4dSrTz4ZJCL1YvAqManuViJS+0+q+8KhzENOWqp8DF8ZrVRof8SsW3xKP8IPxb6USsgBTZp4/PYH 96XABlPq6bDQ8pNSz/SH84twUmTnAEKrCeH88eOVO92abp3q0ZRNET7/5MktT6feAoal3Zq7VDav 9o8Yo4Zf5aJar45rj5GsDFtpj4tOZtnqb1t+EPHxvA4mppgKk7LU6uSwmPdczoT3lApU3b8JpL4l kGqabyfn7pxAsnvz+xKVZff3E3u2j/z25z95iOF4/d9PxjRvye5/+uwncfecl91lCX4wg0JYmgAl o93wQ2PVqb+29OGnXbbrqTlDpt8s7//nHTD1zZs3//mLqfs1vL3ZBCtac3lSAD3/WSeoue8zHNfl dGty0EeP7od8dlDK2sTkoHUIRWUZbcz/iwf6RYHZH3Xv3vX4oHcnkyL7r6wTkdrcJfeDzc2PP85g ijv3BoRS+y9e7O+/Ot2aX+g8XHyYQGphYet07+nS1sMHS0sPV4/O2R6hSWJevPhk2F9Z2BgmuHqi 48pLjDyQEmEdKTpqL2jvn3DvekKWYp/Nzg+jFE8jTlQqHP4gShFGhQCQavlJRfdQ1JOrp8NS25lz anGCW73/VGGehXEZfjcRq4piSa1lIDUpSqXNG/3+sH866LesPXK4SACxOi/R8HjOifYUzhfNk6d5 XyKNrnnsoDa/NYFShymNre8P187J3gIpcXP620HqYez+7ntQ6tvPftJsMkYNjvpb37cnAY8GFj0/ Pdr7gV1nN2g4zPm/fLoei2hiVDRCVaIEqhufjOBrVFFC2LtUhrvd4oN5czH/zc9+s7w8CVHffPPm m99M338gtlajMX3bMxindTnsPNruZrOwpyOn703nGx9lEJYwLNyaZv2RIFFVWIQ7uq4G3p35vHs/ zuV6/GsCqTuZVEKqp9St9/HHsPQEogbkcq7W3otBgqoXL4fDlc7i4spK4lILC4vLnYWFjZWFhYXl p0evXg45qvnw1csXg+HpxsrGyxcvBosRsQ/Q2QBTGSPNxW+K/aggUOXiuQUVDp0fmO5AQIp90EOx /f3zTF0dPpr6INhspDlIjWaCKFA2VSkrVLcY1x8OppI12PtBkLo8fjQ9Pc+aOAXnXF1fnyQrX3fj hg/w39n/+tbm/m7CKArglvOicXeaiNmiRcWkSZ0X2/be/NM2rAWO9r42zwE1m2bSLn765PHq+AeC or8XpP5mJkWea3H7/YBCUzZwd+aAsHn30++BngQ8q+fnp/J32v/01vwwrV2XT2nfr77Ymy9ckIoq kZcRJbLyyAg26g0oUzEn6T6r733wGESKA7b8LKz9Igep02/+8zfh/v06WgQCSqk9715aMbP9viVR pXR8932buzHlaOqD6dbkoIVODxhyF8QAkGUII3Pvj//dYHTXwvOCXhz0DrZWiUjdChdc1p0tcjHf /DhB1EebHwlIJYza2f3oF7/4SHTzwc5g/9WL/f5Wd2lxa+9wa2vhwcLiYndpa2VpaWHr5HT4cv/V cPDy1YB8qgZpt+Gr3cSkgo3aC6WNi5HZY6BFlUqrMyndUYq+sPNnLIrvi89LXkPdICJTOmqqM+mJ kC9vt8MHxqMS+OQuTYdBRjDPxdjuYpxgXIlJxabu3pK6Jk/Vuz9VPNY53mXZ/J/tXcgNiheenG9n UpQadeZ2d/c4BvVvc/w6rAtAk73m51sItx2fXrR69wp4LT1+Mp9ezYQsdfnkyf/7TGqaYxDGyYlc sj1+UiwTQg36w9OEzf2/e++eBDxDHYtHKLW39T6UIr/S5eH5WcKo870VJlLupoc4UmochdpUVLEC eeZi9jpX02/lWSdMTWFGdYwwdmeEb778MmHULGNUQA8hO3O2QIog5cF7YOiAolBNT99/H0Zxvm/P YGxBORWmYqlBEOgiKhbv73d/lCBFC4FUYlKtzr0H1rX3tJ9MvbQwjfro44RLH1FAqV/4qJgXsgwS l9pY3hh+OdxdJk+EBFgJo5b3Eka9fLWfLL79l+T3OewPiXi96K80JjxZAETEPlQtCsAlsdDhTRVh 783qWOP0vKfuvx+mEkRNEzkSkJqt771fxRoTjZoiLOLpYOPswzaTmo0LTMjc4kxUipwv4qQLQtq0 2Ol9j2mZcjU1NUcTouyaObezOYFCvYVlijC4u7tDbmmbm7+c3DxPAVLJBTNXnK6eUUTjW1HnWsNq LprVtnBe2H58ZDM/QTjHf5u5N3dXuLv/gibF0/z89LM7hanf/fxesTzonySEGnIMzeHO3312J0z9 jtDs6PT0zcmbk3OZ7Gb3/bvOLp+wd+f5yYr6w6gCmg/fQ99emTWXAVXfHKqKursdyukpdjT/x9uB EIhG/ee//uxe/SBDDLa4prd/vX0g/zRnVcLKBwcH2we87tfbB/53sM2nLurt0Z0Qtj0jwvl0+mpH yZRWhZ9QLy39mIMXRFVXh9c/DBf/3y80TOaPAlKL3qFXP3ggKFU2K8yjWJJSU49eIkjtkvPBvmJU svdevupvJJPu1XBjdWlhYWmrs1AvrB4NE0i9fJHIVIKp4cvh/n56ffLi1c5KDBGiubVa6OUrrRNC gt/U1scXQgYRTd3ICJkEU4/uhKnxqPuIemiDxEPhY4up+93D8a0qd/m2R/NX64zV/NdmSIecCI1J 1gxwFCqGre6EJtVQ4Kip4n734E7jkk81FR5vytDgzX7CIXrtnLR32w7rDFFph/S3szn4v9ub49pG f2szvVrj9t5yROPJZX41p3aXnYnevTC5+y1Z6gdnMM5C4eV/jx//zb17JIktP378cPbnn00CCs+Y F58OeXItfTs93Vr9+W3s+d1nP7k3u8ouUufD4cmbU8ap3e6j9+y6QrE4X5+ff7qRjL0WhcJIiBIz bCMaQgnpPASJBwXrL3YPOzFMTzX/+JvftGZj+FfSy9988w2tvjfzwPr+KwW6qV+PfNlmbNwe3bFc /LqjhlpXfuOF5REnTbPFXFxYmjKlFeV1Lqh7aroQgJaMlinr0KVByX/9y3uGz/13LbdBqkWkymZ1 QzRzeHNq3x7VqD7NzvHiYwKqwYAQaH8wPCKaNDjpby0trmxtzC+s7O0lQy9Zg4PBJ58MXr0gu/AT IlKf7CxGxIsK1mpJL99sGbWzV+NiyCgEn9CYbT3SrdXBaL5ZbOLUVHj07DAHqvHFQecRjV+ZJld1 ij33sJHpsYqphFO9TMm6fHvYe0RDEabZpHOc6nxxvybPlPT/4AENguFUaI/A8dMfsihFKEX74DUl E6XMF0URut3eRV7f06m2H81MTRXzGzu7/ec7CaD6uzRHCRGizdHCfTvh/fshfpQYFM3DurszSHvv HD66n20PBSbF3PniYMEzEAqKTq7+BFg2Hvce8WXwoY8W5g672ZnqIg9SToE2m+6j+9nJHnU7h906 zxy+5q/ZOZkPdO0JDXTRkJ2PH3/285/8LUvkubY+2thYe/jTn+bo8+3vUgr3irm94fnRGzLghucs iA+/7G8t8J7ftvacmtsSD6nz4UlCKaFdww3a9bOJXYuFPTIIE0adD5Zj4QGrjS5RERSub+QKkTl5 3uKiybrOQqJSj0JZfDDVzM0vZyj1s28+/+ZVwqjl8EF48EBEdzqqUCaVT2k13o5kQda/Hl9MLm8v OkHwsQi9t7e2v33blRSnE0jZ1rejnurlxS0mVQC0Qqob9eH/utHYBD8emKKcvPvjiDWpVu8eUKpZ B0Z9nC0c+EANvhdq8O1/sk9dd6cJgF4NTvtbG3vD/t7f7w2H/ReJSCX8ekn78D+Rr+frjfpJWaAe jYTgzubqcI7BUuJXR47AwqUaRL6cf7g4nzhVSNAzPXO/fkRj1Z51U43kEXYQwclfoMOTzhDzKtO2 oPt2U3WcSRbhB1NT9eysjLthHpXeivYABJn6SsTylEyHfzBFCzSW7wMe0Dc1FWmKggQRH609nqNp hu4v2Jnq+zMpo0WzuqmTiPeJKPX3dZql+YL9hmkJCVyXdylWa3qjkWmbu+vLxVS2hIfsHbKx9tFa k28IPNqS51DezGzJx/k+RTPf+jm/vrq2mv7XVwFUc61zpV0mft+1FOTHsOrQqN/i3Xt/kP3Twcu7 NN0UtXj9reXZ+z/9yc9lSfh1L1l6W2+Gb45ev06vtEASP+2vLKQ9f5Lv2WyQg57A1Juj4YnIUqfD o404uevCBtGoM3r9apUEKRv8UmJ6GGNUJRQJdYN0D4TGJmKpQqe7XVeRx7WE5XuqSf3sZ1tbG4lM fZSe7qMHLro7nZoeXdg8em975OHZTHV+/XYChJJhMK0nT6ZlbzSx+WLU1RyFD+6P8qNkThh5Ux/5 EsHSK+BrSFTKY7L8iJa/3lxx8OCNFULSyWXx6Q6B1Ee2qCKV7D1TpQh0Xsqyz7ZdAqRX5GL+6mV6 f8mBOwdQrmTZH2w8acrS/A3gzmtzBWFeUGhSpap9KDYEU2JoUf/a/MJCXYuYLlgjVYBGFsTOPLuH M6Q0tFeyEWuBlWmuHh9MYUCUuoqq9wPbk5KoPEtM68BMqlEPBBNynqxSIJbVx+wb/tGauL8KzVmb n0umX1FMh/Q3xdPT7Sgo3bHsKzUdEMOif2JSOtEAp0eAxc7kNp3Uh+vrH67zj02KgAcVXnPQ3+nv 0BABmfRpsNungUwf73DUHYGvj3WGchzJEEdJ6voP09/G5tpG+ttc21xPP2nNh7RJXOHpxDkibtif LxRCdnNjj94pMC1929nd6rPapnnrn/QHsOdOjzaW4/Tsvel76b+YXd7on5+fnslCQpPgDkVWOR3u LC/E2Xv0N1XEh0/7sAeJRBGbOsLup8OX3QVKNaXJiR4NaRjfm/Mvz89PVjT4twXdKPMfiM3pgySk VNDMxYpVBff+NV2OnUnFOAEVhwne2xz8XSJVNIb4/qP7JWQotRYVNS6ySV96UQhW9+IPtk5evUI9 H3h7+bY1V8zVARJO9p7OFkNvlzxbTKVzGDcu8ArOalwsGrw307347waku5e/XowOjjHAuHMLpKiY s3m3nz72d+hT9PJ9MvEGg5effPIJBYqiPxn+8mq4/+rLBE8CUi85/EF/+GrwarBPtt+rwXBn/UlT l6X38mokKUTBEykdk/AJr8pnkxGU8vB3NaHPjHW5JQaUUIvHIatwlIhWHQXIJM4LARWPD665yy/M xNnaPLDkJL4E+ByQAwJHNCAncfKRWpzHZCpCGz5c+2hda2aqfTsf7+8Q6UxAsz/oyxA7YqH5sql8 qr0k2pQO2mQStdvf2rxryea7WxOkyCBGcQreC4JPvCTIGuykfKSVg+f89/FgZ4edczMNP1/WPakN DQKaMCpbOOTe7k764663AU95vrkr17XLf4S+/SFlgqa8I11gyMN5hol1Q2AaCjs6Z88B/v75KY+r +jwt57TqiCDq6CzRo/MTQSqN9/smkaU3p+1FyNP50VHa/cSmi/9yqHHMP/+cAOrkzevz4RmFklrp ULFCR54GZvF5QS2elPufM1CIuaQhmYSTLHYPu51UvpaY0v98u3t/eureB/fuJUb9IMwY9dKgmLD3 6s6D9EdvTQepx7rThZadPg/qWmgeuE86yEPb9XrpCirzfUrbFlJi9aP019FZuXQO45YmZaSOTleE bo+NSlq+/i+/3k78fe9O+CX/txPwNfTtIN3KxZU7x+51VlZvLxhLJrWBSu361vrm+pbXjfVWVaHl qa9Y31hfX0ywYeOi2MG3RA+K2fzwoAoI3qkt2CztVpOfFCMS+wsQtszMtP0CZmkacPX5FJNvluMo BPcwaLBjy58g+mbBNxlYR2I4xytXjyLyROJZ5vRmrK8Je1HWs/t8Z/D8eQt6CKIm0Ag0ggUprc87 +/S3ubu1u7W51d+8G6LySTk5VsC6MikKUbm2MbFQS9MXiBIY0U/gFi1bhIo7iaKxkj9xpklMkqX/ /HlCuQxiNUHBXf0+kDMOE08iaDqiFuuUtKLTyUXdBRBr3IAloRSvPTrj4XXnGsdAdqe/BDbnk+ml 38KkhkdH/zCUmRdo9Tnwi9HwNRGz16/PT7aoZ0+Ep9xfj2hPLbK5+nRaDxm69VhdipUE6GVo6XSf HT579ozGrj/rLHXvJwYdptP22Vrwr1GQkTn3ikonbcGi83XyuL4idLZFKEgfdSFRF+BbRdtpvQTl SRXKuu8a2WgpBp68Csae2i7O4yqZniGtSp8Ul3ep21nqpP9H6a393+na93w7f1/qPFrqrKTP9H0l fV/q3Dp+aaH7YCltp39eR5/8fYHSlm2d9valhNyP7t9nA6iuUzOSGAujU6xnUrNS6pRQk8vdaylW EnETqs01xYej+JnxoXAZCylLU3/XUdw0YeCJ+1xprnIwAt1uN84lfuiCOBme8MDjFtRIcxijzc1g axvBH5mj5RYspdzWGPE7b1FHdLqBx/MuLhPYov72pWbvbBIuEX3YnAAjqbq3jTzq2DOU4m6+TaIz H1O33+bO3fB0C6MI9/P5g28tBJ87nAlnVLycAqYYR/rCe3aIxql1uZPnIV1Wuj6FJKJjvvRP+wpJ NERK/o6O+kNGB2bYR/SVGE0GJowTRntOQaDIu+k0X5+I1CmN/z07On+dPl6fcUQo+zs9J27lmJYB 1fCcyVQWM5jC3R0l/vT6/IyOFQPyZEsC3RmzN86OeGcZ5+eWU+WcQskUwUxl3ggJpjrdlVTZljp1 5DlEaqgImJKKmZRKWWwvRo3ZApmrcKxJZ1CoMQSqCpW7GdSmaQ9jROpdGtSaBO0Sy062lXFGuyfn 0oo5IVeE0DHAdJV/+6L/s/Sm3/PtNj5ocpk4/ta2bJmdXFG0vlDtLcU7je8i+irKUiLTlfgrec1d C7dD9F8HKHvp/74ePrnrjHXmcVTzAAKFic5K9KSIc28NzhUwflt66cRnQgCIS4BPFkOIoxBl6raj k2hL6Y/j401AbRZHk3rQaWDJ+uPV1cfkE05B2FrGFAy2NpkAi/CVt+BJAGqH/J/SP5lK0J7MRmsT GjO42gAFnLoTnIjoSd/eBriUzGeV4Gk4+Dy9/3Lg0CW5SmbgDpMqzot+UCZ3JxAuHT/85StOiTrP ElNi061/kj5Irqbp7Y72GJpOMmxiHQmvk3MlT8qkTty1SQCLXsSj3uSodEKMiv+GTKuO3mgX3sRy REwqnT/l4R8UpF7LkgxHSYEdpM635qlrXtvJgKGkPh4Cnc+w9DQUfyGalOAF5B2pVoYaEeZjY1EH 1B2AwEEXsRWZW2mSwYI/mU7PvxBcxd2zQraHTlEl54pIFsFYGrwQX1TCtOjsxuiyFKgSXVb//Zut aH3Fj2i/86+IaRaYWGB3T3UW+c8OynZQWKJIDiRjB3Pvp2HeDFwerwKO9NyU2C7J5Kpkchc2yFI2 ZvhCS4anmCDofnmfnxDvrp4mMzMz1llS+uzVIaITBXE5fYiC4JJI7bMMZIxRBCodlsYpa7WI6RlQ RXZQWNSgkSy0zzcy7ffik/lVGQPLEYB5D+ZLj9P2x4s0efhjruFa4zVgDVGcXRFddjNYatEK+/Le hUCJ8Cn9bfSTYZf4045qT5DH7+RPtw3p92CUd63JJSRDdOe5ZXZ4mnAlgYz8ZTlnO42nLCc2Zcxv IC86kiCJgOmX6fNz/nrKbwmfyIxLH8OECsmyS0iVPnT2KCVF58KezvUXWW0GSbyCO+OGLZRKy5eC UoRFR2dEhl6fvRZiRZB1xETq6PSO5WSYEjwavjnRmfZOSZ9KCHV09prVraPz87OzT482OjFGlL4s mLX22URdoQURA0yV6AigWOd+wABkf8vxKZiiJF7eTVFlgAMiVQDL2oATgTUB7lXaU+duW0qzKktK ZH1DT1h7NY4ozM0LcGoQoX4Xk3+tHzPv3WIjtWP7htzaGfv6zrfOGHTMpHirlaJRWwxC14nkOdXa 5yFgPGOjgABm/mzkvcQ3HbOpkOkGXe3mnY7l1MMiBlBFh7CSiVfUWWXIjiSU6hDI8IQvDU2cPs9k KH0DfxKEekKTx/HUlU/Yl+fJExoyt0b+hovzT9gD8ckiR8DkSo0udEACgcfzAclMzwcUc408m3Zv 41MbrNy829zNGRf94kTIRTMxpoR3Wxz/aecuCy+jbupX8IMUaoJNMdCSyUfGKBtngi6fnxIV+mXC nduoOkgkygE4GW6JJDG4DU+ZgtGsWApSaTWNUxkOyO1kuEdhiI9O+j531BHg5vyUXbvPxKYjQ+2M 4vmg6y3B04noSOTiZERKDMOEUIRPCV1apEqJ1PnR+SRAnZMmJQm+JluT1yUMfP2GT5FSohyefXGy tzofs9KXR1vCtCDme64BOZRXVe6S2bSgxvlPYwJWTmeiekjNhRbUNc6pACp6SGUIw8ACzGlabxIJ WLBNOJlmB/2IOExrZTAxRY1AE39BG3g+uRKBlLOQfz5dqnZ/2iqMGwLNgPcrEm8dBZLKa8uMoEQD I8lQ9PheEc1Ino84Y4cEM8L0GoQhmwQ+mdd88vSINqi2pkgtPW2/os6xR99mNYvGqCAXwBpk+1ln URd3KXbu5IlVqOOtoW+ESYi9vba4pjNLcTzt+ceieKs1RN0BaxpPiTsGcotOBZnnNCdLIhn7ojPv Gi25k0pBuOn3d57v9HlgCxMUkqsSvLGfOFGnhBxbu3eD013y0+bGxoS197eBFAMu0zTKH9GeAQvT hDWEPLfyv9/PLkx2OR1Ay/5clGxwMSJTbN7xq8+0JdEpV6uVFLHWnUy0M8IUGG6JSw1dIx+yWxPx IlGbeAsdSVCUuM85A5Uae0ysiEW9Tv9np5MwlQ4jay5l4/z1a2AeHySHJ6vv5M2ne1srzSyKdlSO hNKLAOc2CYMqqVKkG4x7c7oCk68xlAKSud5NxwhJqnIjUVSqQgFLnZpk0nTmS6InVaqqCzQWbZhy bDMiZR16VSwqwBJqt+w8V8ngaEXmEp9KpfTd+Yb/RuA88JLSEsENNXVG0aMMTnlCsB8zRlAx4EhH n0TJECeAB6IIVHq/m58oOqERLmOzpAdbXUY/zC/EhpRb55126ME/SmihUuuZCLtfLs2BGYn5wKro IKWUyYJsP15U2VvmIeG5L2l2Tvlm3XJcfaWDbsMH+zpC7FCHF8WrTcYP9d2z53euQJEcPhgM7nZ8 Suzp+WBzwKL6zs7HO9JPP9lht7H5vctd5t3fAlJrE8uHNKOK2qd9EqMEd1hUes/C3AkIJShy+kox 4NWpIhRxKtbJj0T+EQqV8OYUVh69sW6k0CRiUgKMI+qUE4QankAkkp4/VrVMXBLZiWy808SlWDx/ TfaarCddaYJK2ZnenPNORN9YokowSnYeyVPkebCVaBRsBmHqM1pbrFx7RbMBpiEqv/HZ9zReS1UZ QsCfySGqgp4E5aoxZbvKdPQgIaZ4HhkI4YpL2ArhXelTzr0Ak0Wj1iTYl6wjOMXl6XnkUJAHQ+gZ UJnaQpSWoEg6aIjrL8gP9tGqDroT3Fc7Oh/BJGHqPmsUxRuGUtdDIzP9J0QL4ax9G20zPBpJMlFb emVdU4IXZhBVC6hiVw9AK+FYTgkxWVMehVgZZcgz4JmfMdBllOLxLo9VWlJI4vlVZOTYItMkFZAf r/J3qr/Mlog5rd7iTIxN1MlGTgGCKn2SjJJdxijV38lgaD97H5DLZDKS9lkUJ2enfWZeuzv5svUe vcnw6P3oBHlsXdFpAqcmIGsCoz5aFyY1oaK1lP5sYdGJiRZ9YXjKGA9B1YBQ6tUvhwJTqfqTCgX7 DuSJvLnlG/fACRCdnYvz0gnTJj2COv7E4ks23NEpXBCGKi4lXHEb70zJFAGVUiNwJT3xqaw+wyHc hzc857D7omclmDva21hsIGRoRaiDlfFWuQ4Bxb32kHFNhgoc86QpgE2uPhU6ZzDsLgudoMYZIYWJ 22bFzbmJh32yrRX9jOBwcCdtDDIrn7KYAx3MZYTLrBIRvqBJWYwk5ULWSwXLF+wqOnLr/YLqo59m K2PYmxKLskVbatvXNJ2sQfAuf1qFaDmq+ucMSFbiTLWfi8FtxsOT42LqPPsxZOSptAtG9hCyR6hT ic0aNhhMK8B6lZTCrJt7M7hn8z7y/jFJ3aor8RxJq0qRWosaTrubOT71N5jtEOnZ2t2isYm7rBnx SlKgyG17k+01co6knXbc8GMwo+2brD2xy9P+Jvfm7/Tds+i/QJnwk8ay6Zr1jz78kLzLP1xLr/Xc GUp83GWvNQcxE/3X5CrpSnItPGVuV18ZN1TwSjYh+xMIh2LIctAQJpUrUkahFKPY3VI6+OmDKM3J mfgQEAUanjC65EtiOmkdkSn3edLEmAOx/H02PFOwAkKdvHmNHj94WKldR+r6G9bJmWwl/DsjDewN GYdp1a/2NpbnTe7Ie2hg0bTKNX2PVrnNbzzTvaWfjAO3gEmpv6TgBobOwUMqIz+AOuY+VVGpSmSc i/cWslXprjqJHjCGegUZmargjMzPxlwLOFjbBQZwsmC9mUZJQCw8lrdpSbDDlMDAttEj1BjTNGcM IxBAzg1FF3QmmIzRJDeyG13TqBCEUXIRUwqbuWpELPP+xvHeHxcgJIEkxjJ4I9QAqF3Yyhgh2jIW w7QXwvi4qlEzODlzL1ajuCtudUPNt40NHoe2nkVrmuQqxG82gU8EUdzbtstdbTsia+/ubO3vECjt btGKhDj7ABzeqW9ohhe7bm8SWjH1Il+n94CTZuMHTDkab7u+tsnD88TXeyPhFM/iuflhG9PsHZfY AjxGKO5VbMn3u6LW7+qgAnaSytnU4HRvqNjEglTLF4lJlpiMJ8NhC24EzM6VygwFq44YHECh3hyd HE0cw0SKSRZpViRWGStjxvVGAEw4Eu8kCtUZ9flxJ5/5WQlx4x3eCLql8yXL7+wN9eedHf1q7+8/ XFnuzM06NdIaCFAqoddaYeYupazHR1GoAEA13qOmiFSp86XpVOxZBWfzSoWnmPe9FRaFTt2QqqrQ SOiNqktQwNREBJMS5ck2G3UyizBgiGG00bFwhjAVTSiV930F19b8i2/xDoJMhXOVKraTaH1k3Yme 7MS2TO+KejkxZGfANTbZbhFHe9qtYxs9Q5RHA79W7TGJGvk9KLuOpQpbbgBCBlDeqWcovcPFtPqs Y5Cz1DyZFxOOCYaORFvXWU1RSZ/ndlaqrgmUNnZJtibnoFRFN3bFmXKXHZbYj4kdhtLmfSUbMvUK ARHtsJ+winzCM2OOfuyyL+QP+WJuStZuKeGT0LMOlNm4ZZSKVblD3I5AV3yu5EWQM9ARe/3dQX/Q v+2ttcOXkYCK0ZmyLVzRHMeP9sgNE3LU5PKK6BXj1JEqUgY46KVjcy5RKLLwmMycMFgo55oENpr4 bnjSWgvEI4p1xgglsJRIkmhR0tnHHgXDc7hWDc+FsbFByLI5u3FS4p+enJx8ure3tbz8MM6ii7sE wY82gZW0lChikF3U+1y5FZToyvrxRQcKEKCkk62AJMRIwhXAdpeoc1xf5lQmr5QOBdGUxPEA/pJ2 gKY5F4KRNe8mNO8ozpievzBrElcrFbXBlTRW2xvs1Fg1d1qGlY2+NdlmIFPmSpBvciRz3ACoREst 2DYkARRFDsRmBdTAWlVgMnBu7HRAJ98fQxy17YlGpXKyFdwgjK0t0RgarfDuPdtn1nsQocaTSkVx nmhehA0BmefMaDYEcngg2e4+GzgDrcM0pI7p06ZMKUHCEs0eLzWZdqMA7n2ZcIJH3O3zTs/7zwd8 cCJVfRrKOHj+fH+XZ4ITOrUvPpo0mA0huHg6VQq//P3WXnvhIxKZe574G8c/bVMcjH0jhsNj4NR9 Sd0E+pDEZRc64JQGTg739X1o/qb7PF6nv0/emuBPLDLxTGQMR59j+VJfX/HH6ZevdPXwS9rnlQ5W eXNK2k/6oyVRmSP64FdadZLezxlEXp+fJfggbZvjFLw5TxvolTBsSIPx2LfznIav0KY35/zFli9p emx+w4rz71lIPk8Eand3a2t1dWWl03k4mypujK1C6VINlTf4mkPDkGKIMaYixbackBodGQPsMkMK alBhJhgIlctIGf1R9yj082l1qlrUK3gnH4ApH/ei05aqbqX1VU9E4wSl9ktmzAZFBUc4ZM11u25n Xl4Bsltj66schypz0fBNzoua7LRVtkIzG4BE0Qzq0NjZLYXsMGsYmiwNy0GDtkBSyJ3TVOEyjmxN k4/VuyWZoalqYKW6yJX1IIJkaQkSh9dk+bEOvu6GlLEWXrvRHp+vbGVzY0cJ10bm8r2xqWt3QGDQ Kbdhb5LCHe6Vas/J23rOlTJZLF8xuXZjMxskt9XqTcQgmz7N5ilOlhpDYLg30N8TnIlH620yvRKM 3trMqV/rC8W4EnNwz+QrHhTMMJjgi/4SgxKXTln2fkmci7mREKG9X9Gy9yv+TL/2jv5+j1f2/2GP VhztHjHFS++7e0d9+tvdowPo8x/2/j59Sev3xGP9iNPJ2dUJ8ylxk3otq86HbfOxvVDKv+pvrK0t dhpzEszKIzyJRYMAVWqgP3inUB1dus1rgwQBRkXJoCpWWRgn7dCzuC6NEqQ5wyLsZpW/MY1L3aMi tokJWRjohUqDHNipg3h1NsahigZR1XX0fiEwqXiRhRg2hArASdmhivmWxvdrDAma7DUBEo2RIiOQ DiABJNBua2Wan63Oiart5dDkJqDgcTRwtDxV6IGw7LFpz9KRS+U1+vaIAmVTFsdWkTABDIUomIdZ 5h4me0vbJvA6zy7lsshX+cVu5eR+Pv9Qty7qtHCLkwvNeXNrSYc+1oTZU5Rj7GqCD8lH9KGcmijd vJ47/7MvD2//PVRvLtnI+97OQHtZoSkvaJHvWPDD9qNpxlrf5fWDS8fe+Aun2X1C02zIieVjsbtq Z++sLKU/fmv9pWV5aeXh0sOHy4nALD1Mq9K1pm/zS51lWpHe0t9yZz5te9iht/Ra6dD6JaSygm/6 05LOtt9xat0/vZbltE1tHjpe6LQERfQ4WdNo60NjCnom1woisGAEzUldxYMrTZVsEhSpoCMVvnsV XNaS1BgIKl2rdXPOmUzj4QtUYgeVI9pRhCy0QsP4Vyg7q7zGIrxDjki+osmACMN04MNe5ZAlv6os oxkA+c8qBzqQL3sZxuWb8n0sI7hq3ZifxDbZmKJoINgCKrnwKktddCcTmzJC5B5VaMLavSo2FkcH dHpnoLloeX+oC1Yuwf0ftLja+H/c8r6BpYW+Fz70laaeLmgYOI9T1S9BJqTm9bJXgXW0dyFiTOHj WWm7vGn68prFl4lMtFZTui5DlaDmIfgMCw0UKFXN4QuETnP0qGs/UwHE4dNxpQFeaJWGFsUrIn+o O4D5LwTnRZya1HHYc94VWBn8VLkcn6dT2N6iRXn3XwDzCn4Rgqbup56PGayaDHskGwGuEi261UCR KjJ/r4z6aE4qo5N+lgwgzUKWmza5jyO0syklZmI4TxK7xjha4/Co4CYXUfgJIgJFxQDfp9LUqJaX PNo2HsQTAnoOo7VzZe7h5X7wEUOtHKZQ4ScxK/5vxoLo/xOv0F7b/sSht8ApZsf9/2KZDcCeH8ky mzvIgJZHZ0x18OKWk3y4RilMYfCe8h+LJ+UVIa/1JlkxpbCRMFkl01W5SoU0EHZKZkkOlnIOTUGC raDuNhg2rKanWj76g0frlvC7aCp3KBUbtTIUsKoNI1R8KCrAcVUZsfEuBONSoD6ZXtfkOW4Dlh9W GZbmkMO3Ty8NKWrqOM6IUeWNhY02clCXVTo0nH7UEijKOuiM9IBuqsMG6JAyJHhmZMOOcx5mnmAl Ov/8J5T4EIJRrcwdzeem0V2ybgjfMcOI98OFBx2CGWr+s6X1GbV3wIiiCCx2dzA1huto6cTyB6AK ObYhnkEHmfMtmLnz6DuwNL/SScRk9I/hfnZzZqL7qGWDR0OWCXyl0F3SgTbLP2aDdaf5Tvnf7F3f 5VB6yae90QeFFAvR1s76sbN6Xpw7f7pSUGYxSrTGs0R3snn3gcBr8cm8BYV1VVpJrEaoKFRZTXC+ ZLWEaROjGgHJnNVzwzPQQTlS7BZGmorq35waOQhDxQjDliELW87cUAlDoyK8+TmU2qWO501YWIH/ sJt7AVjBF7coYTo2hW8Q+9TxyD1Pc4QSSzQolFeFSneVqG6VJWV8yYxJRS5zP8u/ehawqoLna5Pl wIheBTd7ezQQoTJvE6XPQTxTMLBZOJZ27MHv3Fo3od6qYQUM8jFPhmiFS+sop23jB20cViwN8Gru dsQ2ePtjTKI48Ne2F/+JMijDAGpQv9wlTPswcVogj6ttvJdew4w7tM44hMqlojNUztRoBjiMBOEf hhek3M1mozkjriIqpOshEVfTCp8B3yBcjal8cufoYqLfWx+QqY9BAVhvucLszAToYCicwVjZ3gFm 0+R63TqLNEPmLGeMmX/OaE3D472VAVsFMm5uUbjiWMJ9kwp05lwojz6YJzFOnqVpNdEqaIgeVsB6 2tjWQZUgfwXRtI2hwOtbqlEMSpSo/vKhCZwaeGTpOLwQbIWPzKlYJ86d01GfHTPEp0EuJJqEbxU+ I2jZJDhwXzAbtWghVwARy91TC9iuGVS4d4XFfjC8UVxXKlipqypYI87PNEn8MzR1tAeFUcj8Shp3 vkBS0Q7XO2IEBy2YTfrijhq1NGilM6QgnALz7qHoODQJ5VJK5hwGjaCkrU1mgNHn2r1t0m3RK0KN YwwxghXJENSrlVP3wfG1wiVaWY0TYV3XPiBThynZeAAMWLQ+T+CRXjn/a5abELLbU/qV4K20fLqr WYBbsH6ts2xHS8oehN2yEt0UtrfDcESkgOBGE2BEDppRmNZRAvYrdLsdTq/T7WrDIGPlHGBncMK6 9URQcBB6DCVJMUROPROzs8r3GeynX/1O8zXNAIebkPtCgynaQ0TZtQLNb1rY5zIwCuiyA6kquCoV WltCAxcpAFRhsjmLVZUmErmKRvhGYTEeBjAwaGt0f62D6nau2If6Ki7pzgwDWGAV4YzaWM7ETKyK CjgbTIhuCUgqVLm1q7ZpBVoJxwsbDKQwlZmH2T0xgpZfW3AcLhqnhMqeKs9wFghCvrMtjR5JMzGF WDKohwDXA4lq4H70kMEliPQkPqknVc6/fCA6Gjp0EKKFzjypYPKg6dRBkFb5QHPaBCLvYpRv2ow2 GFJpWr6MpbQaY21rcNokq607E8faRm/S/dxaIZAF0Kng7X0T7D4EuwC/QgOD7JZld9HZJHDQWS4k Ytxa3XPGnkeert3unCjVuBC5G4A1QCHfoMubEX+Obi7tdtGrO+pNNBVZQejiwWTCpLBPQEzodGt9 DPn9U4gOeBoB57RHkvUPB0BlNNnTB+9p3DuAFsgzTLPMMmoCZFzr2bdaLzWKawdbetWcMBwVf6s8 EVQnwQroW0WWXoXgUoZBMP+iuZ0XGEpYNIh4VYmfFN9Hz5bBiS6ahblsddFyTG0ycFTXeDtQ3cXa EhBMvRCyK2yRnkohFHJ5IX0MtltTZJ0EhQ4Qsp7Mxnr2DESjaWaV9lw0hZqzBmuV1KkazVLuOp5p Q1IkWlQC3XawXDLFSXabwTA+a9VyLpU1xWWQtjoEWxXb9CF4NrTFBvKE/KPRVhTChtbJctavCDCT Z8stBWCr7xDshWGcXDM4KfQpZf1KIJyUD1goyMqsRzf1ym4MyGhsaz2yqLZWmd06cD4zdpRI1jol YtBA8zmniWFxfMV/44NObeKakkV9OuMEUrT+8ObKrzqtT7+RnVYOOOcyzUBXR2LN2CCvLDLGKB0f dGwdULE2xyakaqdAWcOntnq40y29rQSJjmglSm8nVFQGVwhezyeIjlYirVERzIPTrYxqmHmV0QFt +AOG3xRKlGwPN3GKttGVu6BnXXtyDr2sRimXnVrHMiPJylcrsjoIKPAJt6rUS0KZ1AQL0nugwlfm ExWAvo1JWRZbRjKs/Qp6SruRmbOHXYZoc5omAv9VVYRxmfl0eAYqNInG+HVw8gxsDyjhaMBKY0Ye zSdk6/LKE42eZOTHRSxtadVmAnMAoygRuUpUjxLikE9go4KJyUp6z6BqaMlGA11rO5610UGJY7Rq bjBV6vlttiTnctEZwozlHCINLrGM2V0zvsJv0cEyiEdsmZlkGVOtNbYP7p3fuvSre2DUEAALWgFD 1LKntyId5BMQXdSKArPBLD468OrmkJMb3Yz9kabPg/EogCsBgeR3+qEghadrHM4asjJIeiEejC8c 9XHP0TY428YzNBkytvqg5bBsH+HTXKwzK9RJjABEZcGdqiKjRlyZpe/NXNH5CLNh4DUV3AiCXjxn lQl1E11/RaVdbZqxCt5aagTBS1wP0sT1jFFlhgxBcpHfAFKlbZOcyH6sjOx5qOIQLcS6IGXWSafw 0QAn2AhrKnNX9ZOyl6rfo8Kc4R1HgyJyNDzOotEo9GtAQaVy0cIjGzDhRjWAbu+5QrtUB/XotQIn VV55jDV3wVu1WvErgipYO5hTF+U6UDAU0HDqTBM3HiWMIqC9D9bNI+UcSAgsKgNoHySKGhkWoIR0 j0xzhVMe41mtPZWclIWs+pTRd7H6kvWRG93MOE8mMTlzCM5MnDHoHs4l5AYSyIy4jqZvDZIoVYtx vQbncj4ip0pHHR8fjg7fpnSu6lqN5CjcR86ZmBSvJSYVEYO1BFPxh18b8NLqlHCvW8fSHuuMlwq5 4MNkPtJBx+lzotPXUjEYx+3X/cBbIXD56XmfgCLnl2xoD6pSBdWaFI8C1FnozUXI3LqBLFlPeUa8 muDkprJuPzhMVajQsGvmBO9Mv6rMhkEnVmMEyPq08CwBquqfoHtXmdAcArC4CeAtsrZC+JlCjS/p b1QZHyyoqhQkJHNqfII6tXmaokqT3RG9a3obqwqmdJ6jyrmXAqdBUmF7mqVoo4/U7OOrjl61rOF0 voE2LpNOEKxTp+QoMz6CBh1SqCkzAf1O2trXgDgTGvBd62mqRVeXY6cQYj6Bo7gbg7WtIFSN0Tir 9mGSRZkTTaai5VlFwiJ2lHqs0TIQQqdsWOO00s5milDrPtJV1N3RqKuHcNYPx+8IhOw+Y29Qu8BM iH+lb2ALJj/Z/Uf2ckLCn3wUdbclokSgoTmtu92gIEFMiqOBEfMJ3YMuHl53dGgBBjRgmFHUtIZ5 FO5pzK4A5wczU20r6/QtnU8FQx9vOjOBzlqNEsqaCn2xbIJ1SKu9LSWT9laWUgVAbRYiJcDRUdkG 1usO2b4S5sCbeksLQ3fzgzNxx3c36doSrfyrDRpRZHEfC7MOIekjngyC9zliuKdRZV36+XBEY4bB 6FFTmJMGdnWYRWqy61y2iaPV2KnhkJCHilCgxHcgbCFDYbzTz4E2mAVbYARj0Dtb5zfEiIk1SKZB oNaXaOo15dI5S4AJ4VRKk5RGufSzMZAZOQehyFiaWBDGzmZgQMFHy7viaiufdq5o14S8Rk8ZVxZk 1q7s2nA4KINWCpCTMrbPVWY0x2heMH+I0O2NaKa1AN1odHXzbrwt8JV27PEV/qUbAOkyiaQwpeB8 yp5ASSBznXYQuMLDwf23a0sVt8tSdmd0YGSD6zqDlOyZzr4tN7B7Racdd+TaVZOaObwZH3N+DuUm HBOzwsWbjWtPIoGUXP/o5m3duxp/feA3v9PtdqFxyaJlLVhHqUuV9iiCygABAijugxBuK3bBe2ZL a6GUsocG4KF13+GjMYh2iGkMa0Je9YFWtgJl3yILOAjZ4TnwBD/eW7AQcbaYJZidGEwKsKGBZSqz nCQmaAOzMutTa4xRKaqoExNqfZUJZkZqLN8GES0LrDKXVUe0vKvOXcpb/C4zSrGv3Oi8V1QAyjxd 6dccMqoWa0YbwKVyMSXjVcYMhPo0eROXMRqUPzR4ZpLUVo384aJeZY0k18LUdKcqZWe2nGVpapsN AHSIQKEXnWVyWKJhlbbRM054wAKdJoFe1t2Oax2xczA6fuY+DZobUES6ss7bG2COMI6OikEjTfiQ prz9Y/pflGIaE1aMe90uOIb1ZCnVoAtPIJMoEGVEmRTdkc7ocnzVE9t5++aGDjngj/D25q22KhLd i44P6Aa7oo0hcj5oeceXU13eHPLTGZl6VfOjPiZmZYa/3EqnLpGYFP8a3Vy/E9FLC0z3kn9e0fGp uB2OL3AxNFtm8DvfovNByZQ/NdcEM389+9Ii6kEt/6ghEQyQmuCAIXzLoAhzsiu2ROzW+KHytZJv yly9FKNiOrnKsagE6yqBTciUEzrQKpc9gliIJpuzqZXFZGE7VlDMMMa9npSBVRmtiWZmumUpFK0S m9hJU2HO7ew45m5T0SiUKE8GfcF6KKUXry00uaTmmalMqC/Ev6vIhnqbeyuIJWiD2lsqwLgGEVQY nrBqjNB4y5ZRGujRaBptlWoRSN36sqx3R5kaswXXq5y91MFEjzLvX3MdgqsiooRKUbX8aS6giWsd 6Y2vbq7Gh9zYZwoTFKTRzahGDp7pvNrbBrGi4Vm5Fzy5uab9DjWF65t3o2eHf6TazJl9d3OVztV5 xxJ2zajQ03KdhSu0C2PZKCUar2+olncZwHM0YSZU39wk7EzodJM4VDplT3vv9KZ3mZtKpns37xpJ 8irxvV7KR1QmxdeYaNS4y9xrxLkSJiWZa7wJUg4TpG8vBsa8q+PDa6ZWBKEGdle8tzKyoBr+1UrW z+uFyhhw9lxjsLaz1N69/Eh0pZjLrxaQRp5+rU/Jeii0PPHFiH2o4hfqlfExFFct23Z445QQ8Bp9 FeXATlcGnxpQaou5uWnJLFuqgjN+Ax8zteAHoXUZelKlsZHNA117/8FZrO+wAhGCIgYN3fwI3KuM gzSotQbtSUxOc8pSjyt4ZwlNc9HKhmF7opYZ0aLgtwBZUAS3KmT+rsIrvQFDg6U+5dladKLYapUN Avp7vEUExdKbDuyCTBEi6EVw/+8m6CqVVyL1bNuZgtG4Gk1lvkbZVmXoF7T9wvhBZUYZBRMEQjtc X6EqdfXAgGxR5e6OGG0UZtOPv4zpgE6Ad1IAkwqNlLfuZY8w6OrmOoA4dShnjDEpeSU7cXTzTtK9 vjmWhrUGCTSCEHCnCGQOKKHYBctM6V6zEn7Fj/871rSUyKDDLYBY8lH6DNX0G4tWROafEqxDPmZE 5lmg3r4x52nkTKoMwW5PUDqJU9Wjmz92aGbZd2I2xsuba7oR3Ss9ntPJOxo76E6ABmXBbJF2CGZn R6Na8mABX5kw6H2xdQCwSeWwrtKghU3LWgDUBZXxahQgdxo0jo56ZjTORLQ2EYRJCkroVS0a/Ws5 ncSMH7pGoKChJEfl/zlTelhokyzNhdz/QPZEfx7MJmEmRcDAnSrDDLBKKOcgNgImLXzxeQgV2wr2 cgU6yoSq6nhe6AjpgBjyPrwQ3X+5Bma5gAWp3q7oxkM5gdHi1Ag0K2jNRr+V6VglZE6lZkFbGTjC hMzRCa2L8qC8s25GN83qzok38HFXxEjepYZdikt3dMCe0VaASiXVjVvxgpPWekWrqFpwRF313qSL RBwOu6Pxzc2lkchZ04TYYhmhzQ+9Y3pPHOECZiO0bQUTKZRBGQ9n+i3tHEkLuubNUlkjIUlHSZIa ypmne3Apr9SdiB9dyDfarcNwNEO/u7QrdaIlABgTTWJIQuXmLBETA1XjtJp0j0dkd3UTSNVUvJVJ pYTGnF/WkgJ9joNRFrmv5lwnTEou+1AZ05idQcnI7QWxKi/ZiY4+KUOdi2dktb5Tz4TQ9rLTmm38 XtmJcu6ZjBvbytrKacaY+eIVUzJN0kEAQoQgSB28hTOaj8feqPY+4XNnPUa1K0nRSlkwywHcCbmA TVAq9QYkZxqqVrgmuPeAkh7pQzTJxxUol4ukB7ECC8piagqKVbKygDwtcGF9nUp8EF05G2MdspPo DxkDZAaexjDwPaIkVaE/VNQq77EQLy4b7Z3jlV5ZiZa7Nn+DDNTRJsEVRUOa82bnSPZfyrMyV0a0 D64JxRLNi+GhoWKovQxxyZeHhUb3QBJL9ZvMiZvrjrgcHVyO+HjuOOI8kFTbsfNbscBpvevPMIXq EjWqVFeDsUVcINOswwB5SIpmfUE4Q3JVZoaUVtikd03NspJMr2A4k35fkj9SGYSDCGj1qHNv3LWn kZFIJZ58cOJONdJNP67lgV4lIpauhve4uEnEpUsadkYv0Lun11T3hEm55xRzoYxJjbm+jFpMKqDb ANURuaSj64D9SgXhmngf9xDPcO9ehP9VrbU7JswOzkfqAL+E2g10uEgZ5zaalAuNWYd0MMasrEQT ieDRsB7zAog2FsQIrAf3vnHkAuOnL5qckprSWkHcGsUZbclwqPd366ndnjRChYvJXK8KKE4RXkZ0 EKyxiaF5WVwEpTDqOsEcJposVaiLVECfP9Cq0UQac7XKJoEWKpYN/TPEspF6mricL3M7kM/o/vCV XJGRt6KyEM8B8R2iPkdIAfjAY452l0MmGLiIUIJpSxFu8mZQdeoAt4/amzRvU4zEtQQIRg7t6bvo pab+j4IfpUm9bEBFdY5O5x2JyQOJ+npbEePyZrR9RdpK3SEdia42EacWn1NzhbkGMbQZu0ZoWtBq Qm0r5XxwWdS5CM3hQIrdQaqE1kfPh2t1pl403nBN6NeEY7uokdHaMob83tTKhK7Tebt0AelkFzfX l+Ory6sxH6cXkoChlwBqLH6ZEdoW8zrYLunIt5GZVAZSki/WsYgRBfnkknVMzAq1vnE+oU0+JKhS /KvIDB1T4RoJgcLxwsz4jvbGelqIycbeDSPsBChNmaKgHa9aGFEcM6IjNw+kRe5D64YK5miCviWg 7AuWA5mUcPmzqC2YulVn42naEOMw/FmacgHep6SWgBoaM+g1jcJYvN8/d+gG2amq3AbTgdSsAwlz AS64Q9ZcQIjSCnGmAly+cyqm/usFfOkl3SoEH+0C6jQ3mVGFTWZ0GpNBlKk5xFbgrAsDo8OF8hXo Ei0s+EIQFcfaR7m7ynbcLKq9BcqYTwS7AiWSJ1MCZ8xTRhvO0sBQmwmjbXW2Vpoc/Q0mJUtUICEf nzFpvcR+pNeb/amk8ZaqrLWuVpLBQjdJPtfa33VD3kARrVugFWO+zAP0lEdTN6VmXArDQEtIK5l0 hPad8Xae63LNShOoRsQXYSwCb5eiTCcUvTrsdg9ZpYFlYwoNDF2+I+nCu12RkOLYMeZQTOOb42fJ AuzcvFNcBB+cCcakYnA7TBycvHSN2U/KNShhUo39Nshznk0vgbgyGuPiT8JeIU5gZvaQ3lq+7Rnn glRe4yGFGyThdlssDvPfQ1MbkJJksKQRqIoXaHj9Uep1yeamLdAGFOBQCoxUAXJqcLKtrZP2BsMi tk3Gp+Boht5mhUgofdHSiYiFRI1uq4cuNFbtG+kSy4AIdMQ5F6+P5oJuHlGiW9tgxFzVtuNUivJx yUhNcwE4Ul8E3kemWlZdPPfeJyeQSiIoIB5niK2YW4VFAwTZMkkNTUMJcEe1hBcy7iPM/ZD7TgXd nGMPr3bWUaOVAsnWr5ghTRuSEsQBxTCQJaSrexeXl5fX6oujztDU6ItTNDfS0nhzit2ve+lDNetI HVY314mKUfcXWXPy0Qng5nw+cloakTcP95IZ4XbbU5hPifahZFrSKa0vBgQFWgLfWWJsNQfqNiYV csZCX8gOLCV99pdnxZlvyUwuKXNmhUklILoUuCKpa3w4Sn/Hh6MOZ+T45vLi5hntQ5aUUwyAnD4V 6tTjiv+WtSeK+dIhny7JhzIifNJV8dg98Z7sdrsmnihJMSY1gzF/ehxJbXz6Q2Fi7HFecqcfPROS wvAQSqicpiuZ2iRJ81XMOME0bSDiJoFwoYlFgY0+bhIw4EQrOJ8OOBueJmLwcEEylYnthdLlb6NP AkbInxkh4hNo3daWj9iqFWBP/Ky9W9p8pNyHO2tVxIpr4D2VR3XRkXZtvMoSkxWVSEhFZXypsuNM nAJmVR7FwBWkIhiGNcq8TMSyjfql8VDN8JsibmXjlTyis/pqRd3f7r3dc3xVzA/aGVdnBUELhfOo DKZqYJ82IAE9QpCmyolT1X5+NEj8dFV36VxnqklQZ+jYbrTF/BrbE4wd6pCTwnDJHkFyfmFf47TG LoqhJXTlJGMd/WrKHK7gSriXaSVlLT5Qek2QR/R6GnFjOFRVXAgU3TdU50YYi1RvOsVb9uKMJFYd Q+YCWwUS1OLCqe5SQfQ5xoKZELQje4n8PSPRrT+Kq5IKu6ZJ0RVsJx7zlw5fP/mHHiS0+PX4hvo1 heGB8dRycytlQvKcD264cQABoRx2waREc8JDatjA5l4+AkPOoI7h077FYJpdLiwpiYm+0vUmKyrO 1tHtPMF+ndEa4VGOVVqKsLZKmJUiZwFx5BFkfTAgQ2V2Uy2pzOCorWSjfLWb80bLlmcfG2sUOJxQ ZR1QGNWSKthnRlQKm3gUXEYAw2zBtoOB+NIXHmWrxaQixg+rHZh7iTLpqSooSIFlLh/Ugn3ywMhz +FKo27/7sSvOyVUh7B02W9+f0yKXfaOCeSkwA0+6ABHSiFE2Uh++5zkt0gYna4GsrNV+Vm0+3OLU Ndo7RZbB1eHooKdMihtr0aZ4GJg00mJacHmquxewJPjix+pRSfkYEb2oRZqqra1LxXKcKMmVKkKi pMNiLLW3apRJRemAK/Zz0nY34BJtKBntekDuStpAa++bdcsJM6tFoyq1Wy4IZYutdgGGTK1Vmw++ Vi2nJl9xqped0aGEBXh3c/O25m4/kaRg7wRx3hpfChpfd5Re9XLhHPmaVW0JmhTyVzKcpoT50mfQ EuH4GESLql3LSo/i64PuxTX5SSndjcIJa/V8sFYLhQvZreHcUreG5Ck5UstJs9Dg4HbhUiJqVl3M B6Ciyanz0ikP0eoEpLIQAWNBG1rbJe9TNG4ZkEmT3I0p6U55GgpLxghrnDAo1MCtoKi0T8/iLRQK CxCoYu4kBS1KoUxdvgPMLQCRgpF/b1MvSRApy9oiwg+r8UlXK4+fbN5ZQSfIKYIqYBjvIuhUYQIf uL+33B2yFVAng4RRNBqRW+daJIwjQY9ozPFDuSvIsVQwVapqhQgl7vlnmQNUiGiQtErxnvAnVDVH mZQ22mBSAZpUyIR1KTusHWm7tHhzs0hdYoVcKOSkwD11oXPB+rqYmlbxSjGxDtEPwFm8unmHzIJQ ws8GOx2K7FNy6M5rHe9yoL178EM6VCTeZsW+DKwVpTORK9FIuiuFDdHO0JRYdZN8ki/nFenmANGv /0pnbUjkqiHS4CmaWvfHQ8tyYAS5ub7gFiAxvONgdDUdQ9EP6CFzFAR+VjfcoYij+fr1XkVjUkG1 rGgOaO/kYak2ReCaCBw3C1wMNOIFuA1KgyrbPnVxgOWq4x3MypaSCf8PZ/ppvxLdfZLGjBZ4gx60 kcA36zDidKtckDWCpcXJ1mYmJYhdNE4mVArXAOHW0lDqbeeQnXnfGBWDMisrGuwwH6oUxYJ0gnln IIJGVeoW3sg0e/CWQmi/VpegqtoivnPwTbXOHAYBHz5OTxUkDJwuWuNbIGppCtyrOBe0z8/SySfI yHQyJ1tOb+qcGGXe4nhqcrtrjPPFdvT5wDYq1eSPnpiTqACJJPNfKqO7/JbgwWU5Vt5Avge0A5GR yB1OMqD+0DSpa87goTgz1yx3dESAAWlpALTjZARdpWrcWHvI5eJd4lb0o8fRBcgekUW7lBvVjORa 0ttFMpcgatRSqsCktKuGeFRP60wgFLxSEvSWT9sVAynVYdFqEoqRB/t2Ar86wrWKuFClLYi6h8tN HHPl5rvdk1Eo5IXKedkW2Y0csmDrmTnROR4dH5M8x32Rwgy88Su1/dTaySWyMrat9Sw+48uyrhCp enKv+GZ0ydWiCd3jQ5GY6uPxzf/6undAWlTa9Zh7DXMCZ7hjpUPieLqqIE0mmFap9tIEJ1J+n/W+ aevHaZgWlNNe6302liV2esAAipZUlhVf52egV1rGwa2R2WDyFtRFJBuiE6doBcivQva1Z4NhdjqZ Q7siVwYvrTG+tp9F5sv8zC3GAHwDlBXpRoNBnN6pjkvt6PAzxFJWhUB+hYpTwcQpkLiGnTs9zAsc H+Qw81X1vGlDDUpg7S7ASRsQpTdOd9rbsyiZGR3yroxg9j2+A6gUHYP25jNooTeeU0jGTbeut8dw GFRZo0Zjf2jkhDuOuipWQ4ChjjkMiIgJOt51uKqbzsFlC51vHVKRrNjJzeA8sVQEiaSmLCESlt42 XCw4pPCoRtp8xpeLuqwvLOxSAqWL49E1qe98gmd6zX/poOQm+mESndRTlcs5CMI1nlbCg4Q8HSUL se4GszRANcCDbYnGTGppkOXJuhkf0URWxOGNJ6frujA9Xi2jjJIInwB1kAzZ0pHMchQEYoM8VrEj D8kVKdOVTXuwSq56aM5d6lZxigCFMs+QZBCiFr/UKoPSXZugpApFMF8BaXvdnAhgyiZRZbISnOtg WEj4+6iDpcw5yoRXZ2xOpfSFYMnkuA1Y0V78lrSkRl871IGFHG/5MFUw12Krs1AVK/VOL8BtQG+y yE6AKNbEINbbvF4SCRiULjjSNBq+pbGRhMBBH2YYcDFqyEZYo1mkqcz+tXYgZt+sRQpKqyO229G2 k6eSr4sGUb7NgcCO1x/BMIp++fCvLhO1QyUlh2xRsFJDI9V61/K7a1Qi06Q8Q9c3VzcXlg9kR08m B2UZtGvKEyETZjGE7B4cjK+uWglSF//F4WiUXmKritc6SfO6T0cZ0IHZciwWXXaQxDPNk7Jdxjvq V7PmLbS/Z7e8ym6wv4UGD8+ed7TSh6txGq7rGt230h2ub3rRXJOjnSYrQyh5ALqIPTn5wjJL3+SK /PC8nPgl6uU32RnbTwk3yS4uZgdkCbdKo9+TkO8zcSWt5PJbV9268pilEPwj5PXwVtmKIbSeF/iG HQ9lBv6cNtRN5//LAjeIK5KgypxsKTAjRPARLxUStiGAcmCF+Fi6bww2sAbgFBq3LecyyGwcnoKu bvxQWTz2ZqFOVjqTPRwR4N6uHZmFiV3mjW6jt7OyaY9dv7jkFXGAF1N94vkY8th6tJVlFKfRe5Z9 x5NawRB5q75XbCDRPtzhlP6EOTVsKV3x0BmWQ5K5d2VyB20XmQUnvWClqWmBJis4vdSc9TjMklVN 3JaUmYRsZCbxtY8SAI2OR1+Mjg803a/FtPPD3Fkr5YIVw/qtAq/mI3ZG4/F4JJRVDuyonzwyep23 McGyEwI6Z4J9x43Wp4kIZXZwjka+txXWbEPVKmx2iIqeCXyv6ywDVSv9VnQS5EjtEwMapmZI2wsQ do/txPKikbeQuruHzG4X2NYBSNhKaFZA7QbgqAzP26VSKrAXYL9y29/ObKGjzCsAnfQtILXwMbiN 2Un9DC7+CEyYz2TQSl8ZNdIpJaRawSkpV50aC2ZcoWOu8fXtiC8y0wTCugSLZOoTzFdFyJUk8cOC 5WcxFGLlc3c5McoKXqwM5+Qtd/1qxZtq7Ezmr4WHoF8rP9B+ZkUsOzuADLezskMaX9OqClk99Nqj WYkcxj+xnFHN+/TGUtPJ5YbPID4K12/5d1NoXIDrnEnZjSTJ6o923ogLWYSbw1+W8gwpawYLGskG V+Yv9QrJ+kIzJJdAIHU1puUStKPDwNtYQxmk18TurNNR/n2tp8tuze0n1ZjAWE1uwj22XOU/wbhR GbO1epJKxc3GhITKWbhdgx2dPXxgF35oQdWvWXYagSvfkBWEqp1cyNqy0N4905ErrGjyuwM49ExW KKDZzQXO5VgxubW548z5/uiosrNk19DOj5WtievJTopk9NKMrRTmTSTijiKVYFXQ5sTnUq5iyK5C u/Bo/6jgVeQZV96DsHMqXblGZVamuaAHQ5jMLFXwQQwFkCkpbVVjkRVoFSa9AJECu6ssp1X26AFl LWOx8fuux/ntrFAcHdOkGdcjKu2bELjyG5GlmveHBmObTXCqgFKW2xKyU0n+mZx83TscdQsGL1oo hNG4pwJOJc7iKBYVDdMrGpsERO9m7AgQjWsrzRkOAKSOZcPBGMuI41RUJCZn9nh7KfJGO7/P7fsg tQaVpGpo5LGX83YF0CLhqbVqW7R667qF4VFTGP3wcuINeat6WD2q4sRpGjvKa5WPEJW7VOXezVmV w5jXkJW0qnX6qn2HtFD5BVkO2hceUAVuJd9C+uxrlZUvzUe+yktclZXgqOXIs5C3AVYRjCdV2ltf TZy/dVB++fmdV6aEYJzACLOJAlqopqp8lJ43EoX1fti0qAo0KPvSDDfelaaFoWg8HQwMDtkmy6vm AjeusCBT6FHU8g1HrsbIXHYOtWblvRLPK+/cmwshv323nzpABDe2at9P3sPCMOSr8VyCX5234Dk0 MZcA2OHszqW8cKFU2vBDr/j+dPF8Cjy+2Ol2sqLIvV6WSbuQqKOSvcHNiZ8v2oubn5EM0HfoBpfy gmoBglJ4G5cVCw91LzmWq1P06f1FiVSlsbbt9tkuVYVyi5SUwxeQKX3KICvPwe9xDiAZj8pwAffH Gg84CRok6NbJWtoqCDhDlgv6MofH2FhL1+JLjWfJ3AaVzOFxWj3Lyx9uMspUK1M5JpkxA2xCgcCV ewpZydSnV03czSZPVwuKvcT4MfqQXac9nQoHieuRA2UrkEpQDiNzthiYMTOyvbOZ7QQ2imoiHqYa bxbUHS1gEXACTctCQalzVsh668xvMwgRkfZPryfq6VQob9Gjyi+naLIA61jyKa3wtMEr7CkC+PHk 8vbIS551cXqLDSd4Bzad3bmxgmXjkKgIVAYDmXO9l5RWwx59xwJQojPDRktYb6GrmXTjmKDgxhR/ ubmA071V+qbNc3Cpjd1XNIuFVQAtfPKMaJAwDqyy8gIuyccUthKXVeT3rPFCBDcX7T6pQhEzfm3P W5To2JYt2w/Jmkuza6WAtgpM5XkxSuvoo7G9s65trTTIkNdSsSYqf7P1PkjCWnvcJ5cRoIb5qb2L 226ODJbwEmd11G8ACnD0n8iH1VID7+hpZgUC9TIzleQ89qSy1QbwLjwbD8QjhitkE/xcXgz8VkLg aaBVm4VdVMDFim4c5CG/bGsEdO/sngTbV/ZxZQi3z70K7L/Bb+2i04qi1y8OV5KEC97uBFF5Qyb3 LFYVTuOXX/lwQqm9OTOQliD3qvDgDF6OvJj58ygmIQ73QlknGkr4ilV5wD9nlVJGCx/6CFLg+Qk6 0ttaBctYA65YZfvK/QwmWQIbsizSIT3pmIOYaIkYOw/gI5ZzLdQuEOqjsCup2bdJGzAZD6o3zudZ 07CJWlxC3u5KcNa23R6YJ4nXncFLyHYpGm2bK3uieAtVFtA+FlZBiwZxiPScrVKFvDXg4tIES6uA K9Wim9GPosXleO7tLER/ESzybE4atZBVyhlQpkzwyG+vpgUbRR9CxHmjlTurY16K5nSiquDsNWS8 1IBLq6jTJR1z4oNGPDsN3vXeM2/2quR98/5IlIpVAAr8ULqH3KC0obPLC58xnpDVltZEN+KEKbxH w4NrEZAa4b7irS4zb3AqdaHyOfQyLyoLdwDncaVniMJZ+Tzy4GA+uQ0gsLADNRBWgdtshb7B/qjq BbLeSAAG82BHG4YMaSEvLCxokcGZtRwBGdRbwwV3zu9Cm2ZXMvlihv3e2vilyyk0XZk9taU4BNcT G/eoKCwDVe6tprf/0gb4aXMK9zZ7WgVL/h5PrHFfEENwf+h0HxePe3bhOAhqI+YeAp6ifSmy+6FF ptDWn59+DoI4ngug1gB+OOhdrvILalpZQTmpuNTMZRcku+VSX4O20RuTxvPJU3ygTSnyRyQ1Ux6W sH67R5kHYDBtRnueNQ8xNJasnROlwvvGsnm45aFWkLe8PE8wNvB87TRHQQ5WzrIHpDSmaNUtOXxO c1MJ1YMVFYKGo4yWZ31kc/bNr8c4UlDtTvJoscNxJZXdMX7C/w87m0RzCmVuZHN0cmVhbQplbmRv YmoKMTYgMCBvYmoKWy9JbmRleGVkCi9EZXZpY2VSR0IKMjU1CjwwMDMxODQzMTM2ODgwRjNEOEIz RDNGODU0QTQ2N0ExRjRBOTM1MjRDNzU1MTRGODQ1ODUxNzQ1RDU0NkUyRjU3CjlCNjQ1QzcwNzA2 MzY4M0Y2NEEyNzg2ODYwODQ3MDU4NEY3MUFBOEE3NTU1OTU3QzREOTI3RDU4NUY3RUIyOUUKODI0 QUEyODU0NkFBOEE0MjZGOEJCQUIxOEYzRUI5OTUzOTdGOThDMUMyOUIzNThBOUZDMUM4QTAzMENF QTQyRQo5MEE1QzhBNUE4QzRENkFBMjlEQkFFMjQ5RkIxRDFCNUIzQkFFMkIzMjFFQkJBMUNBRkJF RDhDOUJFQURGNUMyCjE3QkZDQkUwRERDRUE2RkZDRTBFRTNEMUExQ0ZEOEU4RDhEQUYwRUZEQTlC RDhEQ0VFRTBFMUVCRkJFMjk1REYKRTVGMEU0RTVFNkU3RTZFN0U5RTZFOEVDRUFFM0VCRUNFREYw RUNFMEVCRUZGNkVGRjJGN0ZBRkFGQkZGRkZGRgowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MD5dZW5kb2JqCjE1IDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UgMTYgMCBSCi9X aWR0aCAxOTIKL0hlaWdodCAzNwovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDEzNTE+PnN0cmVhbQp4nO1YDY+jNhD1AlESX8wRlB4sHwpNcrs07pY2baQTS8P/ /1d9MzYkubCrqNJm96R7gG2MQx7DzPjhtv2J98buzyE0lwMrFbcbxejrytTV7Wl3qD1v7I1p7w73 znXvfr0cqYVqU8Hoa21qfXveHeowDH/h3RzzeZgk98nvlyMN/5TbXU1974t6OvE83qlA6Sfrx8f1 P5cjDX+Vpqm29QZ9Dtfvh93YO8J1/WS5ztbZ8q/LkUf/SW2trP+85zuov/SI5tH6Cdhif9H+C611 Y+sKfRL17va0e3xzXQ5Y2u7mSRbdY4uiF+3/4fz/04TdHpsbrlfYGC/wz4WDdCkrU6udNvU7BsDz 3CCcz5Onxx6v+r/QXW3zZ3p73h1quI1FmLDrMAby58dE7XeIkDYfKXc+oBqw/8dEPZvN/Jn/yfdX TH/N9H8c/rvOeybLZZJl2LkYyJ+NcoQq0dASLp+TIIIiaguSP0otWhJFm5bFUKwqXGyogV5Et1ZC BJxmUxWgVFY3xTSagknuaHDa8vCGRl+ZE56jkDHPtk9bu2+fHi7t35hQLdsKpSPEgiYvp20lyR90 HdqAApnFkOLIltTgVFua3+5xG1QVlxz/GNjGQoy4F6wbHr4QjrxWVNXT6WSC3YvI7vwGlonvfb0Y uBAjDYoBDli2wH9R8mlaYfnr1qG3csIfLcsfL65ppChafpIF3c7MHBgIcxQtLgbEX9LwhsySiuA6 /mPMXjR/havEIvPuBvSn5CypieuG7VgQRRSS+Ev+2zP7j0DD8ufOPc3TgYC3nPEviG27Qa/CDbR5 3EUxIOAH8RzaCWBFjsN4DP3Pv10M7F8ouQoTAQWRpiIm/spRJZ2e8FexKAx/bSgDB7yxEd+o55+z offMvxCjHPfgWeXKj4qahQP2KFvRtgSmQ/Y3Zu8fZMT8pVQyZf4xniPv+EviLw8O3Jj4V8b12cxO Lplwzz+lOCG/opOY3yGSQnCtKmT9CenshVmPyBvwf3J9/L8COWSdSlgTi9jwR0AoevcKEd5ycJjZ 2vpPQQFEVwnOKf+SgghBLOmEkkS+kwtOF1fx/ze0yHr/gQcN5H9KKAuy7sY0JFHAnxfMX+74SVLK JosRf5mBn2P540ECUD/s6an1iJ6m508JbCHp7dJJTjlMCpWrK+P3ucv/XnKKPy5HxsKkfdNAwgYF WGln7A8bl+Q/lWOyLPPTlj8ldEpfBZOOidqRv/lFbE7IL9uSepzrVHntT6eYgGdTP1sdMTj/NtpG 8F7rV5IzLh4uOnf6lXDEL/ZX3GMQ9edO/5zKzyH9+THxrZefbtirzx9Jf4ad/vfvt6/av0KQxaR/ SjQcCoRDMBJyw3LHKpqNXRiKFSmlVL39h0HtQz1MGd799sG6/9D6gxIjSbmuNPonZenDHy/KKAhq 2w8bpFKHJqu3XxjaeeQ65vPX9VeU/lEM5J+K5pkACcgRQdMgBx0w85dNyiqB+HcDuQXuZXqLj+P6 i1m4YkQrXn/YDq4/IE2XptamDJif1pZ/CvT8kSqdm6zL1a7nuefrP0l2nw34P7uGaqyYkSR+c3Pl 6D9H/kjklNPfnv/ULD7w+tvUm0xmUTa8/tDWpEqCqtPx4B+f8td2VrD8y170vCmeo3OE4Rf6DID/ N+cSVsucZs1Ry5MwqZaYhEw17P8n9duino5pAdod047WhAr37mvbbPLzGRwfIakE97zTPxAPTkxa wfDnvHlz/mb9v8Hx93Hxn9b/D2Vxzj9n6diQkLRrnhuHnuDU/9Xt+b+Ipv6+o5M9u37Jk9ZCf+J/ 4z9ad2mWCmVuZHN0cmVhbQplbmRvYmoKMjEgMCBvYmoKWy9JbmRleGVkCi9EZXZpY2VSR0IKMjU1 CjwwMDAwMDAwMDAwNTUwMDAwQUEwMDAwRkYyNDAwMDAyNDAwNTUyNDAwQUEyNDAwRkY0OTAwMDA0 OTAwNTU0OTAwCkFBNDkwMEZGNkQwMDAwNkQwMDU1NkQwMEFBNkQwMEZGOTIwMDAwOTIwMDU1OTIw MEFBOTIwMEZGQjYwMDAwQjYKMDA1NUI2MDBBQUI2MDBGRkRCMDAwMERCMDA1NURCMDBBQURCMDBG RkZGMDAwMEZGMDA1NUZGMDBBQUZGMDBGRgowMDI0MDAwMDI0NTUwMDI0QUEwMDI0RkYyNDI0MDAy NDI0NTUyNDI0QUEyNDI0RkY0OTI0MDA0OTI0NTU0OTI0CkFBNDkyNEZGNkQyNDAwNkQyNDU1NkQy NEFBNkQyNEZGOTIyNDAwOTIyNDU1OTIyNEFBOTIyNEZGQjYyNDAwQjYKMjQ1NUI2MjRBQUI2MjRG RkRCMjQwMERCMjQ1NURCMjRBQURCMjRGRkZGMjQwMEZGMjQ1NUZGMjRBQUZGMjRGRgowMDQ5MDAw MDQ5NTUwMDQ5QUEwMDQ5RkYyNDQ5MDAyNDQ5NTUyNDQ5QUEyNDQ5RkY0OTQ5MDA0OTQ5NTU0OTQ5 CkFBNDk0OUZGNkQ0OTAwNkQ0OTU1NkQ0OUFBNkQ0OUZGOTI0OTAwOTI0OTU1OTI0OUFBOTI0OUZG QjY0OTAwQjYKNDk1NUI2NDlBQUI2NDlGRkRCNDkwMERCNDk1NURCNDlBQURCNDlGRkZGNDkwMEZG NDk1NUZGNDlBQUZGNDlGRgowMDZEMDAwMDZENTUwMDZEQUEwMDZERkYyNDZEMDAyNDZENTUyNDZE QUEyNDZERkY0OTZEMDA0OTZENTU0OTZECkFBNDk2REZGNkQ2RDAwNkQ2RDU1NkQ2REFBNkQ2REZG OTI2RDAwOTI2RDU1OTI2REFBOTI2REZGQjY2RDAwQjYKNkQ1NUI2NkRBQUI2NkRGRkRCNkQwMERC NkQ1NURCNkRBQURCNkRGRkZGNkQwMEZGNkQ1NUZGNkRBQUZGNkRGRgowMDkyMDAwMDkyNTUwMDky QUEwMDkyRkYyNDkyMDAyNDkyNTUyNDkyQUEyNDkyRkY0OTkyMDA0OTkyNTU0OTkyCkFBNDk5MkZG NkQ5MjAwNkQ5MjU1NkQ5MkFBNkQ5MkZGOTI5MjAwOTI5MjU1OTI5MkFBOTI5MkZGQjY5MjAwQjYK OTI1NUI2OTJBQUI2OTJGRkRCOTIwMERCOTI1NURCOTJBQURCOTJGRkZGOTIwMEZGOTI1NUZGOTJB QUZGOTJGRgowMEI2MDAwMEI2NTUwMEI2QUEwMEI2RkYyNEI2MDAyNEI2NTUyNEI2QUEyNEI2RkY0 OUI2MDA0OUI2NTU0OUI2CkFBNDlCNkZGNkRCNjAwNkRCNjU1NkRCNkFBNkRCNkZGOTJCNjAwOTJC NjU1OTJCNkFBOTJCNkZGQjZCNjAwQjYKQjY1NUI2QjZBQUI2QjZGRkRCQjYwMERCQjY1NURCQjZB QURCQjZGRkZGQjYwMEZGQjY1NUZGQjZBQUZGQjZGRgowMERCMDAwMERCNTUwMERCQUEwMERCRkYy NERCMDAyNERCNTUyNERCQUEyNERCRkY0OURCMDA0OURCNTU0OURCCkFBNDlEQkZGNkREQjAwNkRE QjU1NkREQkFBNkREQkZGOTJEQjAwOTJEQjU1OTJEQkFBOTJEQkZGQjZEQjAwQjYKREI1NUI2REJB QUI2REJGRkRCREIwMERCREI1NURCREJBQURCREJGRkZGREIwMEZGREI1NUZGREJBQUZGREJGRgow MEZGMDAwMEZGNTUwMEZGQUEwMEZGRkYyNEZGMDAyNEZGNTUyNEZGQUEyNEZGRkY0OUZGMDA0OUZG NTU0OUZGCkFBNDlGRkZGNkRGRjAwNkRGRjU1NkRGRkFBNkRGRkZGOTJGRjAwOTJGRjU1OTJGRkFB OTJGRkZGQjZGRjAwQjYKRkY1NUI2RkZBQUI2RkZGRkRCRkYwMERCRkY1NURCRkZBQURCRkZGRkZG RkYwMEZGRkY1NUZGRkZBQUZGRkZGRj5dZW5kb2JqCjIwIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UK L0NvbG9yU3BhY2UgMjEgMCBSCi9XaWR0aCAxNjAKL0hlaWdodCAxNzQKL0JpdHNQZXJDb21wb25l bnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NDA0Pj5zdHJlYW0KeJztXWuK5DiXXU1/ O7HA2kcILBg3zDLcIIMDZnYRBRKkf/QuOiENZehYRsNnqJxzzpUzI6uzHln5quFrZUVH2OHH9bnv q6vo29t/xj/jn/HP+P8ypvcm4Osjb+t7k/C1ka+WJb83EV8a2+24rimvy3sT8qUxz8tVwX/KexPy +EjL2qdt7vP28b1JeWzMpcyQvnJ1neefkMVpWVKC/KWFCF69NzkPx/nfN0sGhdMEKvM6p2V7b5Ie jglaka6WCeilspS+LD+VHbxej0MBf5clnsDfso7p5vzeRN0PqEZJ81ymeZ4yEMxLAaPP703WPlbw toC385z4AnX91ZLi/N502ThvpeRUckk5lzHnKed5mnI55Zv3Jk1jW0r8sEwhL2mA7KXlGMtfxwhj PfwUOlIAGLAreL8CbGWkMOI952P+CQhcS8zL1BUKXOkHaPA0l8jNsvTxvam7vUopT+k0n2KZp1Tm dLo+9iN2ZSgLNt+XuvN6FdNS4ZpTv8wxAb2RMrjEeI3Nd6UPJjkfE+QulqtR9uWP0k9z7mmsS+5B 7LB9ejfy1kIK+lQmvIOggtexB8k9NAY6koZSgOB7EXgj9Markk5LpY4EH4HgGI3C2JfUv5MWb4Js SAv1I0GLyV3BlvMI/ejF4TwNZTu/A3kmYSONSZmoHXGGOkAzkpSlx+4YuYlv3p6+P1dDbyhHvE/i 7jSR5DROxzEV/MP2OALFYzrh+LelbxmjhK38lq6nSP5OMMfXUIdlgn0x60wbA1E8Lf/9xob6nHPf AzLRqBc/pnSijkyIFhLQxCawBZbYkdL5DQH8cxVlkLI4LJMHZK7MA3Z5+Dif5sl9mGMsOQZIJ4jF EfEtEbyhwEG4AMtob/pkHyB1BAzY9Zn4GZTweG+Wkqx9HIlPqTqaoKN9d5qj5+b1CKM31iPiMFOD e7zeDMEV1m0iLKlPBA/oDIKtlGPeVhrARAnEMSCUHymf/VTS7VsYwm2MR+onoCrH2M859ssx3Ur8 726/4ogTjpiTH6A7CVCfoEavT92nzaAbd7FjUv74oSsUhdpRX+Dx+Aa1rTEMy0iFDFTX5etJ0Aac R9+TvmmIKcVXritsG2CLfS+Jg2QBuW8FJ/lk6A0J7D7l+fyK5H26hcHj7a5l/y6+sbtu27quG8aD s5bU66QRHE79q6oI4jyCJ919IHXwxjE2Hn9N4xrn+3m9IHIlgjHmkSr1in5klcpS/qbLuyy9d86R tlYfGvynbXy8uiNxwwPFSKlAwPBq8SpC96qQ6Z68rSdJrsPLNf8y4hqhiNc9yAi9MuQv+UN+NUcC hTgxIL6oXCwCzDVBdBl4TYUQH4K/11hDEK/4OgSu8Qh3hTvcW9lZskZmNt7dE2gkcw8+e1+N3hah +kQwluk1CCRbhd657lhCC0qoE0aJcfaXppKoN0gknqByGfLXg8TYd6/gSKSB0I67SydJGEkkfs4E zojE65eKoml0nVVCKO1D6YFgf+8KX2LALsOsyLRULLYQIXOSu2AKQUqAVxPaqh6kGy9HRntOj5AH Qx8jzMwL5+1bV9HbY6QslLyrCAo4wubviAumJt5754PfeQz3E6AhPqb+y3d7+uAjJzx5tRdbkTp0 AgeffqkCx38t/ppKcxVJk8QbKQWuEaMnhS84k4gYKQYiWLcTyIsix5vY7Up7N/5lhIPprb3jn1ml UIhebIbpxVhMyhJ4m8yWISjx0ltREtxBUobN1lguir1Znp31Hg/idDoEd4wOFLbpf16Eui0NE2gD h6shS84bYmIygASpXuQCLUndBZBNNOuj/ULwWtxNXYsI+yXoE3JAcKyePUumfCSDvSlAtKDAhzuq PERQD0EVis0vBjCU5EzpgLi4ON0x5HnkgRWRZrU+7eZAGWijTjoyWhrhYsBO56ofuUewoUrX3Z5m hlfwtNKxwevq9llziedNsgeRHo+mHBsu2ylA8Q1hi0YG6Ywmam2zqwQ1XN/AMoYoCZBVufIOrigk uLrj+jxXl9MQGVam+KtxN8YWhLRQC/wn7uGAiyaTvvo5kBoifS9DBzOMMuCuEUchf/yncX4OeUvu qWpxQKLG7XVxJMVR5jz5A/nnB5IDkYQEYpc7QKuBVQBBEIAmGMGHIFr5mCsukpJzw9DE6RkELnTm +BvwpstsvK3XzeV0W4o/wAQZIjVQIpuOkun00csOUU28mRvX8DrJCbvAfz/uSJbStzGDE4gsK3dx XylC1CuA2JYAUk0jFAFC79qOcPGjNoErg9e4n0QOb7feE0Eaahd/sB3g0wpPNNGVM640+KKpwq6S QCh04QCCDzQgIOIANrbSGplGqjo4KyVqZH1A2Mpwo4kDYB/k7uIPpSSrBbvR5M/gEyhU1XCPj7Sj MVEURhTHjkcwoOl4Ak2gqyeY490an3w7JBdS/2MIrqRO2tHgJSuw8v76M310/tBESn8QlOQ37Aho E8kdEYaGuHiAeSFwfDDaJl4LTojQ/arzfP/vpxH38XYF9IS/IsidfybR56r8ecodybtDrgn2Hg/a RchIFT52+HgwjGE5ZyRwC+kLPskVB2Q0T7SDGUZe/MX53ht8wUjin0gxVjsTt07q62MbZBZjB9KC cmLaRjsyRHqaTjaPuVM0M+iBw9Nc8Vbtp69mVDsLGNnGC7jqC0SRXnehsuQxdmsz9t6MZAU1BcWq J0cvgqfvgyOP5qcACP89VO3/wHO1E/KCex6iUacbMkpwA6FyrW1Gs2weh3XeSIqNEetlH2kbafI2 GiYg5z01eIzN8fzd5J0IWxurde6NvoWiDD0ABTsdoMsrXPDy9q2rDqUqssRxoIRAUaoGDwHYSt3A fX8nf4h4v78fYMEzEfnB+XyfKpx0KQel4bdEsMVm2K/eO74IquUXJLwhPvgIQr27s9AA8XdgdfId LDTOj65ase+sbWWT2XTvxY29wovRzDqXxO/aEGhUoIjlllWrZBxuzfETYJazbC+M3MbIG9oBvSEv Vz0QH5fPSuH5Pju94HF7LzESENHLfG6C7L6xakOm2Iiv03q7X3ihLbPbwH7ue2EI3P555nUPjAM3 BAx8vDBCpskFPP63g8H1KlSTTHGG3Po4VvHD3vPlobhV031mGbbBV3e1XaCRLj4vpEQcqdoTJOfe bM26fUONF/lwiTL1KnVdHPUFbFT32bEZDxE+k+ptZ9P2vxc7Lw/6g0yZEejThdC+RJNh3s2Hb7B4 bQw9B+oC5L/lefziEy7xt3Nd/PukxhIvFPGxu9GwEPTtejevZpIaE9v1a9XBv3hu8Pspdeiqfaik LGlP04HAnoKt91WzGHchXctF/rPknWwaO+a+G+QvxUNFD5oSHHP3Rx+qPpprKnp8WXRQ7dKGDFjH ZGZsVehy8PCbG8Jqpm61hJGbeoPIsKDSusmy6OP5RAB0N+eChalS+1aW3315muljoGeth5vcxlgV YK1s25w5TsOktfdVgDepkjLvDxL9zv9Ex1vLWIs7WEAE8YOFTnB51X7KnILAxxHc6AjNVumEEMz+ 6nZXyS/z1fpxRuoBtTCTfcM7nslnRASpRmGb/11f+hYHBr8/OZ2LnfVHF0xWguAL1R05IaII7nHy 4NMZBzF3UIxE74VznG6XzY3iLi2MQWsR5WLqth2cbuK6QVWEWmjxsu9nbfCREYVX/Gp5TfEDRYoe kOZM4UR6ROnEo87UAkkqJAFw99V7iAZWT5GeefmPWsU6/yGz+4mCDmstZ8pYVfSdEUAEN9asGWQP 1RLc3niY5PPGbAaCDitvnr6pOsmb9n9n8cC5AXCBkfCBqTaPpDPylT6M7rNWkeumcvROVjt+2vET w852hFewW+kD45mX4+It3E2wckJ74b8/Dwc/bSnUWDGmPTuzMkSVqjIhjfv8oW52dGgyeviAk6qj prMB9+13Y91YlrXz1yYeZPMABkRmUARmQa+nV/+MwFQDOguLQqhW013w97eLRHWtdzJTco/foNqt 0VcNgOHXSFTsCouvPhB+2NWAbADag+IziJUy6fkSjA/6BgpiwS6NpcWNaXdXKY7V2G4FEtCqq+qm 1Z5zCxfFKheYcLoLQ+i2XJ2k26BsefdEC4Pe9Uz+OiGIGFGABIZeUUFkd+mFqJyhMrTp0h5+MpDk ubrddapKRdFEriE3tOMn7VTAnchfu7Kz3KoGCwR26Hf+aveZks6sLohPTWCOAJvuVUm8jLZ0RmNB u+oDwVt8rFRNJaZTrbhfe6eg2eQv7FCJlaztnxm4bJzqbN2dc6RV71njrFK72xfYM6Mt2BVaCzG9 2eBL8WtTTXn66OJddmisng3iSgqwY2ZXn8t83glmHBbMrrjWIxk4x5I0nwoNinmvX0P+igVYobGw mnbc0i4cdzCj/dAG5p2pvjNJr9pBoi38s0hgow1Ne0Vi2dWzk3YaX/fpOW+m9mz8DQPyhTv9tZSB aZPdg0yRhVb2CqsWPjfRQyXKalEmjm0vY2SE1UiFhv5kCY6SbCNUxYZapQjVf8DVswJk/AWSQNAu cQMOjCLaU+RMJaQoQa97o3E5epF0GBpn0b0Sxg5SU716RWW7R4/xgbuqif9d3AvvX+0LpWP3H610 Z7cvZgk3GhcWDVlLbFS8Rmik98eqlqoKsEKgimfUWVa/4K3Xe3nlpp2PYBtfnu93M+sJNb5iJuLq JMcGnqV99glnlYlRmcqC1WzA9bQmd84/XtDaxNjG6ihNlT8aT6/iTXlw0iql3hxoOD+8CO2zSAXv aG6qB3Sgbqz8dbb3j6hyKy0G03aPd2EX4nL72Nhq9k0L41VuqhMGJGzTxOpmfnu7cbNsifK7dY/j /1w3ljbYNr4xerqnb/VNqvZlY9QoIAcnk6EbWWmYM42H+MVEfSNeHicEt9dncT9vx6/lqBrJmdoA 3VzP+EO6knufjKDzmgTFgCQM/xwho31BEvzR2xzKypE7XXFTodpZxFLLI3QJ8b6J5/NcbrXatw/N QYEgxLEDDMaWPvZ9TBluirE8DXnTddTvZHm7lL5hwp36jj6AuRV7tHjnQ2szUL+FwHqW0ecPnhFg gBpbYdGxlP21StaikJElIHhAr3AxVgVBtFFG31n/Az5Hm3zDBeeeNsmrMokop4wKgci00zEOeZQo N8UsNCUmKHr5q1GgUoUewATJ1ddnDZe99s5wmxDwZTH6lQqqg76UOe415Tpa540m7tmcwMkSAq13 zZzwT5/6ZHBanHUiTSpPaxIvIMgA5/pv5+cmsM5sixKC2TREBAwMVHJ0arhBwAK9iez9OsLtUeB+ dZENk/h24pR20itV9MrRx+vkxcIQVFythUN6Lmx/e95/idYuopk1ng1iZVe3lKYYj71cQX+yZhG2 ZByHOJBCfgSSENDhxIYwHKROt2jI7aO3HoGPnBoJXjNPUGJPQQ/fMxeSrYwcmBd0CICYHsh+LHlS /0bUlByka/SX+HD2vxQ/QEqx6fIc/ZG7xzjWRsuSvRqiLaBsVFZntEyZ55TP35zu4yNFzqdQEGmb NM1cU/S4N/LhZkcZ3Njn0VqKMmc42WM1EMEEUK0hLKUMDHMaxtrQO1m9iRknJ+8ip3i8Fau/izwW AKEUdHNQSlyCZe/zGYKx4kb9eMRdp16c/TD14t+Rr14EHUVunwpCfeyiMus1GMYZb4rJGAQe2prn aAbsCf2p2WYPpCScZAkKx29vjw8QhPyDmbAgxt+xQIm5C3EUdo1shQY5/Dannl2Ap0kf5b2GOjMb Ojk3Vv6fMIskkxtqCxCnpiyxXFL6MLJleDQEwbvxN9DXi6hjivmIj1Ma2A57TEPOd/wf8SSngm81 j7xtDQ1mUNhndD5tkitputTZfEpo2hrnLUXt/qdS+2MLrDMXBIx3zcZ1c1zi/Wby47JrSLRFXSlw 8skm5BSOPnUOLqqHpYuSYlzJ7CaiaMhWHtM4/irbMR5Htcoe+Vk9s9M4Tscj39jbnvEN+2mxZ+Si i6Iodt00XdMSQDXyfGfp+WJsVg2wXgg299X+n2trx/2w41O0nOK3uY9sab8ubHivKyx+Zf97D4PC 1QNccHE998P1mRcf5Q45lYysjVncD6w1ZJaLOEEiCAKr40nHfBxyGcc89SOCBS7VIqAfMtf2AKHj yHUV6nefRsE2AcE8lVOagJ4ig9W6ExjNUzPcj5Cn9EXqaxFBTSW3THPBxW62AoWrt7h5rJuzLUiZ qsAZvlwuNWSuv6iGVFN2UmCG9/74dOI21QOtJ8gaWiqH5z7PU5xmKGnu0zINZDcUZshaW0EUY15s /RGUZpy5mHBKdcGULnGlbIOMZc0lND/a6LQ1Ud1exo3DZJO0XGxUV9+NWn/EHvtr3V2raIDgHbnc LDFfa+VeuraaCrgbQtD8u2MF5sf7sNbo2QGBCEh1hcrho24mzpX+uK/OK7y/SDrNE9eugGDi208L T+iHeTbHu6kWSeMf1bDwnEa7JQTrHIiKNiqB06QFR9MRVEwlA8xigMpl9ICrLxW9pQjXSZumBTcB lq+N1n6CB38GeSRQbiS2rdpuzpVArixKXMy42IKjk61vtM2Mb6c4c7n3rM2Mb5clWVa2egXbTa2X PXNRyHZ90IxtIzcS9lbczOW0J/wHb0RwKlxPWwhZnjN04ngsMw864hvshXm5NvK2oKtRoEP7bPJI SnAdPFBLJ9LW0gURXGw5PDHKCzeR3i09N08QuiLIuL4LpgZw/14bzjcm/epY9QqqnkveLeNV9VE5 xKoh3M1DLpmAYcwzALQ/bQMqLvc+Ejl8KtwEpnbWOVnA0Sk2fbpXe3ScmtoLS0eEQKHWhoBePyzS gVjWaTBA+xOUOmPX9arNSfjW2s2WvdpmnfXmPZW8L83MJaZ+3qs9zbu7jjiAM3/I/GWBq1koLXOB KmfgeLwidHjNeZrLXkreMqxpp55fhVfPa627JJBJTMPGKgZEd84y3/yeiuGTlvUYtTr+qs/r3M/L qB/kWK6GUktwMHyNBI/9UfC78QV/5WSwJr7OetfuMvwVlB1nGF7+bsl8Y8I4z0eiyJ9qmK+mcgfS loKr3Wzi7ovI3n5tVkh80JQLILBuMe5f7edArpcp3SxTBmRlvcKrAFBu3i8BWRmsyCQzJP3BkOWL g61XBx+RbXZsqrt8+BWkzGleyyiS5hEEH5eFFNY62YqAdLGGQUTiMFV4Pakd5zvGxhK2t0iBlbpy ef1VHJ7Kol/fuLrhT5nkB5WAxC5ACMnhAAXpfPvyP0O1xjYeVBFUdyxs16cHJJ6gIRN5DGLvftjC jvi4sux0UK2qUwVyemo72HeMjTO1nD1srYjePJgsPD+g6PIzy4Jsknbq4G2Z8b/Oj3htQeV2TvXS RnDe8ZFmhkqUAlzO/W89+Enr6ZsDK1Q490WXLlyMlVO6B6HXavWHi19fm7+eWWp1oAtDlo/ofauE 9uODwQdnT1TJ7uTjHXzb9pCp21ncBoRXluaHVpYvqGf6K/0Pzx+rSPJKCgOVpUGQ1MYJQF1KIP8h 7lN+3zXIMRCM4shWfdMvu7Lns7GwWkR3DBgbb52oziYt8rJ+XPXvJrMB0PK+g5qNO68AknXqV2Ou jTVa1ShaSx9tNeL12nZs2TxbYRubBVB1WCtV6DL8Xsp+aZouN26iImlbpdCGlh65qctVoDsHfuVr F6236hIRZpG+uw8fX3FkpSS2niKoOBuskm5d2OC8P/iaMzeaMbDWWHfXYfTKozhbIwPOtizdGQls iz0gEyVpB6bMwVknb4hdy0Mb170JeSpfBpsG4wK44OsqD9cKV9aSqd3ibOiYPXOi/K3Q40itNQE0 1GSCxZUq1mavBR+BHdpdY17D27qG8HbkMaAWS6NmIbSGgtaw6ZT6NKReM3fBlijZUoI3/c29pLq0 q4uO9iU+jS1SaHfu8gjlQ/CIP1Cj+uL4tpFSsE6fwLUWwebhGlvlJnosTgya1iCEIX/zki86Nna3 IuRvtbhWvVrBEFS5wYq2hl5U7ettyeNQYSaEXfxsDY3ciNW96fUOiOpZgHyPX23dqKBqltEKmSgu S/5MLQClOpy75ywxes5YD7uR8cIuViccbdqA1oVyeXjTn365HBtdSF2kxaYsm7CObWsNINKWR1pt 3m6s6kCR32BzipZbdrVgHeRSENq8w4832cB9/6KXY5sqNRX/lP1Q9tSdoKVb70aexuI5TcXGHq6l VmhYQyqmoDQ8f/dq5zej7szp9k6qIM3VnLuzhcvqE4j+UVP/hp74NnMSLNgfKxhBljrYOqW3jAm+ MM5FNlrdv1qvTFYHJhxesvfK+cZ3DGZD+m0V9th4Fqd2//El9N6Y5pMtM5Mqm9v1zMffKlz+5thS VJx3aLSMtgkyL19Zj/XWPN/62lfI/zbWVNG8bAHymYNrpdQrYtGfr4uqvnN8lyA8Vr3/zhL2xgJw 0Gxao3zosknu/cf51jrEwVgY6kPru1eojz53cOGWP3DRJRK2n488RVv6uQak6T8jeWwiDppn8u8T Ln97bGrIaF+7hPbjg/XV9r/em4qvjCX6zxdBvuL4Af+5PCnZ+Opaxv/g8dMqiI2f8n9f8arjP++J X2b8H5BeWt0KZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xv clNwYWNlL0RldmljZVJHQgovV2lkdGggNTkKL0hlaWdodCA1OAovQml0c1BlckNvbXBvbmVudCA4 Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1Ci9Db2x1bW5z IDU5Ci9Db2xvcnMgMz4+L0xlbmd0aCA1NzM1Pj5zdHJlYW0KeJy9WnmcVcWVrlt3f+/1TiM0omwN JpiQxOgkk4mJiiLqECUuMZOJIWJCUHEhyh5AMC2LgIpLoiIqEgExGHXiTCbmN/4S1CiowSBh74bu ppvu19tb7lZ156u6771+DSrgH3m//kH3u/dWfXXqnO9859RVQj8kChEfJfrh8g8ekt6PQmj+Vxp9 r+Quc/kjH+RqSMVAbsB0TQ1JqJKQh1xVxLOhHCEamhZGwFxh9J2WG+QkPkoYhL1wc48BLie9KKMr lIg5xD+4ph6HGFMrVAtYqKiKH/imphbgngAx7gnpScKVD7I84iJ0EeIC6sLFsGhWJUIc5m0cKkRR ImShgBByzinNIQyL1p+fuLCfpIA4PAlDK9g5OV/vvZH5jrVHdEkR3+Mv9XjEWCHnMLOEq3AeUOAN GVHUaKS+blaYgRTmCfta55MR40O40nfE4276ZMS9E9Mg4FTVgoBpmvBhAOaMUVUpWnsBHy/6/dQ+ CocZ+oz18ViLEZOcV/C+E9OCz3g+N3ThEWHOMfgnI/ssiP3Ck0rx88fbPO/iRXsaOZOAKyhHLsLz SVtbR2lpaUlcxYI1hfTdioIH0iLEx3rIpyNmRXjox2MlBf/iRVgLFzQm//Yl3H0Hmtrb24F45Igz YyYxiv2n96FiuHnEuZCgnw5a+HHu148DKhxRUxhjqqrKfxXpmoURcSlUqM4UAtD4+WBnYyrt4GbP CxKJ2OizahIaUTkRT3DpNdiI3OIp44TSoig8NcTHwuWEc8FXlEqSol7gY1odZCtHh4MqiprOOLF4 HEADQjIB2Xugvam1XdNNVdU8z9M0raLEHl3bz0YcBsTQSOCL5MI4CBVDKmF+WxlilvmGoROAoeqJ EPPjbCtYHZiFZXyfaboehMCXo+fAc2EXwzCiOEtnmWGrKY/sO9h2tDOt2/FMVgQGzAzEXjY1eECZ rZFhp5f5HokZhDECeIZJ05lANwWpKDLjCfBY1mdCXEhjufB3ghDpF9sKQy5atOSDbdte3rIR/ioY TOZB2PidDw51Z4MAsxnxrOvFLBs747qubeolMWNp3T3Dzhi0bPGdGHHnRwevv/761atXL122/IYb Jk2ceIka7agXWIZwGYH/Uzk5jzi6KZeH5L6LnEczTmBYIrBABVANj/xqw/vb33nyV8tJ/naHkd17 27EqpuhZD56p2PGSo0daEHmWacLlDEu/+WdTRg4dvHL5vBKTHG5Izpgx4+677/7RjTfi3xt+cAVm 1iXBw9LMD1Rd+zS8kitC0ptpCjJIwM0GXNdoWxdbfN/ymtOHTJl63dat+5sbG6679tsbN/2JChcn 9YcaA87NeOnOf+w959zzPtjx0eDBg8eOHbvtr2+/9eabtSPP+veJV8ycNd9NdXzxc7XzZt2qMPLS lt997etfn3jNtUuXLr3ysnNXP/I8c1I//s/rB1bH1U8HGyEOJOK84+QMzIU/0DQCRVcX1j36yONr NS22cNF9299/r/7gvmnTbpk06YZUKqWq+vTpd63/zYb6hgbiMrO6v9vePrC2dsmSJfNmz6rfvYso 2oPrNm3YuPEvm9ZDPU347pVXXXnFTyb/+Lnnnpt6y7RVDz7QmWyfP3eWl+6cNmXygtnTVHISWVp4 aZ+UixXAM6gXUsRy2icXXHL1gEHDLr7k8rEXf6uu7oFkR+vIkSM3bNgwbvz4jS9svmP6Xc88+5sB A2t6Mtm2tjZc+mD7tpun/uyh5ctuvGnSiy/9/t/GTTja1rl/799Hnjno7++/O+WmSY8//vj9998/ Zeotc+fOfX79sxec/42Yyl7dsvGNP/6+xFboJ4HOh5vwirymYYWYC4nuyYyQJWT2vIefeOixspoz 1q9fv27dutYjLZqh729oXLZy1dXX/8dPb5627vmN4y+7or29Y+fOD6+95rsPrlg+4dJLX/ntC1te 3DRz9vzymuHJjm5LV74z4dLFv5j7/euv3bJly8qVK6fdfvtNN05eu+bxIYP7txz6R7K1/kjDbksN i5iC9rprQdyGH4sYYaBoQOxJHnjz/SNb39z2zLPrh9WOqKioaDp0eOiI2tf+94+33nbnPYvv++m0 O55Y88yEK69MJpONjYcvHzf2gZXLf/C9a9Y9uOqV1/9w2/QZg4aeHYRKsq15/LgL1/z60eu+d+3a p56uq1syc+bsW2+e+uzaJ78yZtT4i/6VucnJP7w2popMn0/ctFfrRohliimOvEIGFrwWSLjpgNzx 88WllQM/2neQhappWQcaDkycOPG+BQtjVQMyXam7Zs9f8/TTF114cTab3f7uXy+7fNxTa359X93i n99+y5gvf/GDv31449Tpew8c/L//erm8uhI0MHny5LpF9y5Z/sDsWfMWzJ//6ku/LU+Y546ptah3 29Qfmho5Pvj6qjGeQ9znDim1PJ+puopsMH3W4iee3cRVe92GzX/40xuv/v6VTZuee/TRJ9ta27f+ eevUqbds3rgZ5JDq7tq7b/cll1yyYtXyTZs2PPHkY7/buKF66NDVjz61+pGHd/7tvfaW5gvHXjhh woS7Z8xZcf+qmTPnwCvOHDRw5vRpodOxbPHcn02+hkoO7eu3ecR5/o308bHaKTI5YtJjJNTI9l1J T7Fbut3mo+2oi7ZteyebyXz9vHPnzplz06RJF3zrfLhEWUm8qamppqamrSOJ1A2Oe/vddwzTru4/ 0Pd9TVc6O9oTMbuysrL+0OGK8qqenrTvOaOGD6EsO3r4wMoEiQsDc5GWjgm5okhUSBHiQhWi5hbI fY9TUzh0JiR/eb+9vrlDjZVW9+v/+uuvP7Z4EYnZxM0uXrH89EEDUl3dtm0GAYgHukjLCDGkWXZc QR2lUDiMYYgyynEypmkqUP0+E7qKKqbGB1SVfGnUwMq4yCMaNj2kfYqnfDXVC7rgFX2quhDqhFOd gi46PfKnN/c0JtNMjcslWP369fufP7wGZvj8WaO+8KUvEMZNUwc9JxIJjAGUPAiRX1TkIM/1PVZe URoGAf6GPPKFGFQp1XzOdBoyL21rvKbSOucLtQNKNQgsi0rEx1R8Sm8tV4i8vmUMECuC3TI++e83 /n6wpZOYJQ5DBU3DgCEDx+NxyAbYqTvVA32HfQJEaeMQcFBCAzecEuqiubWlK9kBWVJVVdWvulrX 9bTjCr2ja66btU1ND12W7RhcXXrRN79alRB6Wu01KS8g7m08AHEoqshIQEKWQa+FVFcxaoaTF17d Vn8kaZf078o6up2Ao+hQu0zsfqhoEJyMU1nZStNyDgEtHU0o6bfe3rpr1y43m4Ufi2VQrX///uf+ y9eGDh2VAmiqikoWlibc4K6pBmW2ftnYc06vkFIuCsHAhQiUyCEktQi0AsOIaaJs5zNCDa4KZ0g6 5LevbT94pJNrMZ8rkJF40MmmbCMM/KxGoDctVJ+Qo4gV3bJwVWhiQ0Ps+L77xl/+3Nh4yLIMwIXa 0sE7kPku102rdtTnzxo9BiSNLcJTBjB5aS30aeANHVQx/ttnn1Yusi7KLfElVfxsRrdtYWcpJ2EQ JsoKrEiUEzo0cU9AsiHZ/NqO93c1xCtPczhNpV3LshDaJXFz3EVfScSF1PTSYplCIobEcYiuEwh1 SDzTIg899uLO3XvAKppGDVwAtXu+9Gw9nXWsRNmQEbX9B57uM7HpGlWYk7EAMPAVr+uM08zrrjq/ X0xY2hBqzhUimgXCxjnE+AN+DdcIVbgFo6TLJ+s2b92xr8UsPy1QzLTrm1I3uumeeMwqidmB7ygs wBwIHWCBQ2FW2NK0xW5gxz/acwCbniit6OnpwfcgNR4w8AP0J5bhMmLGE5XV1Zyqsp0BCJ6laZaq e9kOW0lVlek//eGlZQbxUkEVqq6wj2QHYg9P+dgkXQWRtWXIxpffhnWVWCXX4inHU1AGaTpKD12k 0NB1PEPXDCGTPMIclfgqtDEJEFKZTIaqZklpheOhaNHBc0quvcKlmyMSRXkjYtMw23t6mIJST5QL WDCWpMOzUTspPny6OqH+4LvjhlcLM2s83z2S8aeE8G6qgTW7PNLhkofX/q4p6QV63A9NcJmi6oKw GXxR9KhMXReVKOHpVJdK+Ve+OPrb54/oV0E6kyJQQG6pFNm+7QDIy3FcTTUCHmqG4TkOIkUVrMdU zVB0w2F+fdOR1s5ORzTqcIuBSpaGYl0wOEg1Qd0KI7jjxon9S4klnu3NJkoIf1T0QNMzhPzq+be2 72nsyBLkZMY0RdOE+vADA0ZWAcLhPIDVRFUp6xsV9tch+rFuxFvgpLsSlnHRhec7qe6YJQwnaicm zB8zLNQXXtYRTxiWT+iu/Qd3/GOPT3RODaoY4FiVmqGgROK7PYCrOW3nnTXo1h9fbBb4TrIybOwB OfbeV8mOBrZ2wysNKIJoDFUQGIWxwLT0wHW455fEY6ioZaEfDQAeFm1JwEIcxG0dOdai/je/cd4Z AypTHS22oTDuIvS8gIPbdVAmZmEozVXViv31bx+99d4Oq6RfqOquw6gC3zMdP6AaUDu63zm4Qr/p uivOHmpZVAp2mm/Mif6xTM0YlqmkqZPc+8DTTd28yzdorAyVG+yKYjh0XUQfvMnHkLruuS481LYs +C72dPjQIePHfVVUbJT4GU9njkWD0O0RnknBmKrGY6EkZZGYwLWJsudeeLW+tYNRC4IQDAu42bRj qiA1x6BOTbk95YarR59hwMCi9wjmVguta3ASflSZBxSK4GvuIfOXrT3cFXSDBqw45uNOlnLf4syK xVOomA2DeR7SpKWpkAoYBboZ8Y7ozKY6Rtee+f2rJ4ReKq5xuFXGdwzD7E5mKsqqkLEzHiupLPtw X8uzL7ychcjSbc/3gQiWtXTEs6v6yXI7nHnnzaMG6YZUvdi7qEcaSaKcoocSgDHhrT0OoTY50Bou Wb12b2OSmhUuRguJcGQeZJx0qFrwS8SHIhObSExBALcOGAP3cT8T+tkrLxt72dgvOWmSSXUbyC62 4bkpcHMq7ZeWlUHBrnpk8/4jrUZJSWdPKhaLIQxAlyESquIOKNfmzbh1SDVBDRtTReNIdEpkHyNq Qit+CO1Owc6ClxVBjw4XZcDe5mD5w0/VN6fToC/FRNbJZlO6oYY86vKJmgWRrYnopCIPqyp0AuaG +4Lyrv7O5ZePGy0aET7p6iYlZcgyQWmp1t5Bfr3m5fd27NFiiQzzQR2Wqae7kghZjWQrEtr0KT/6 8lkVmmwJMLiioeZkkQhK0eVREFMquCJgpgY0OQfP+kK4HWojsxeubM8oWV9nupnx/FjChgiBuhBK QuwKl6pHhRBD+CHRwOpgBDCm72a+9Y2vjb3ggkEDDDtGso6g/3ff+ejFl15LdvmBYlDDEgOaMR74 qu/EzcA2srPunPLl2mpYFw7NfV8XvopEirA1hVdEiH2p3Xw/sHTROHWdDLYPS886gWoZ+5v5sofW 7DrYGuiJLFcVyF7K4bJwO9GvEJIIjCTSBGRGsqsTQgImUWF7VUn1dCZMs6qioqwk4XqZjq4kSNfx YAwzlqjwOObyIeKhBhM6t9XUPXNv+/yQMoxlyvCSVRsybVYxbdF5MWyWU0JhmMk6MdsiIWhO5COQ HfNwh+VhVJPWH/XnLH7wYGuKaaUZH1BCoc8kHyu5dhJF/oD4LC8vb21vQ5WR7umW/W4mlVzgu55u xOE2UEiqLOXgvpTY5SVl0M3E7Tm92p4z/ScjziyF4woVwgNslG4aIjlDLWF3VCOUuS+MuljC1LJ5 heuiZoAIETyOKNUCzpmmNSTZrIUrD7e5XmiwkEPaCs4LxFESPrkmKhRf4EFScrBPGBqGhohEaoEh kAKBz/V8IRhV0Ew2Hi/hTAlcz1RYVYm6eO5tnzsjLgKChfJgjeeM4XtEl1/D3KpOcoijsybK89Ue zVVNQi6J6y5TMFVjm3/3L5Y3tqUCEYVx0LBKddwrjM1D2dHi+TomWkFOjDMGIWWDWnwmVDgcHUWU bRkAp1NWFuMLZt06ZnhVzhlYVGbyYjkftdRIvi6RGUTWon3POGRzAHEuso3uEQ2EcrDFmbd4xf6m Tl+KY9jB9cC4mjiwoUL9FQ68RPUhfhFyCTdIRa/DbYQGJKzUjnckj9oGiRnBwysWDOofL1VFHOuS gWCmCFnxkRcpKqNkllaUqAfKlMLBBs+dKrEQakbVzR4vwEbvPty59KFnPtzdgGUgXyOzwomgeAQm hdJ8x0Oe7mFzFYyCx8HfnueYuqFTM9XdEze1MEgP7G/XLbr7zAExQ+pgUclEBqaEFZ1GFR9e5KwZ MifXC5UnA7m8IhiZBYGva1AwnGoal4uBpXc3e/fUrTzUdNQJkEwSAVOybgC9r0i3UorK3mgoOJ2o 1hX4AJgvFA0y7tecFpv585tGj+yvySYs90NDNP9FUzqisN5BjoErim3oYyKbXdEJbu8JjU/FyS6K OXHYIY/leI/jaZZVfySYu/DehuY2XzGpGfd8wXCSeEJ5aMpz5olOpEWZE+qCORiqsgpYmGTvmXv7 OWcPFMowQEElbnOdwLQjhGrxkTDJYyX58vnYHn3Yi1j+x0JV1oay5wCi1h2kRo3sbuheWLdyd32L apUEUHkRYjlc0Tg0wu052RiStU6zXe011WX3zr9r9IgKWNKgPGrz+z6HphA1J/M1wQm0+Iy16DDu 2L5bULQkMRkEsWlZXOY2TdVk9oFToi4KNFs73E5mLLhvT0OrF6qBWJhehFjEXOTHUKSoJEELhur1 K9dX1M0fVhOHvrGpnFBENkhJ8cDZ0shK7hDtmLP13pM1qG6h2qTBC4en4oRDbLJ8Gs4SMIGYB6IU 56JoUBzoLZ3sPezMW7SsoaWNKyABVfTJlWhD8wdgKFRVzcumYyYtS6gL590+prZfVHIq0RkgKiBT nDbJJKz7gW/IE2IJrfg4tNdHis7zTu6suNCki46z6w/33Dl7fmNbt0diCBwtVso4zWQcpGuwB/ez NgpB7iQsbdX9vxx2RsxUc6ceUaOssDo5LJXZ4GNhfDziE39CGfvRCLBFAL7WSf2R1Jx7lu49nKTx yua2biOWsMwY9AlSWkXCMFnGUtyHHlw5bLCQYdFP1NMpPu4teg+CKp8M4LMgDmS3hsrjVASlI0Hv 2Ns2v+6BfYdbzHhlRhynhXbMZA70rndaqV63YPbwYVXI1KJdCJ8WeRhlUv6gN8zTVO7vExyFnDJi jAu3NlR5ACwYQvQM4B7NHeSueffuOdgEsY2U6DsuDFlqqw/fv2jkkPJ8HgVZhrRAoRFc0qeBeVLv V5wqYvCq6JepohUp3rQhNOMLBd7UTu6aNbexqQXiEEpp8KCaexfMGTUEOZiI/hCFckJiz1jiNFdB lfoZXlU4ZcT4+MzTBOfniNsXbVaTyTNgNyRHjnq33zndyWR1XV36y18OHVoFko0ZmpBL4nzRMzQj cmAqdeU/AzEYImAeDOy5Dh7WLZAohetCXkQuvre+dd3Tz1x11VVjzh6uKZFKEUyP0kWjWtbNaoZJ FcStSo5740QKqRO9X3GqiIWGFk9B+0q9Jxp8TNNNJmmERgIKTEKJbCPlXnWRIhxXKTSn6BWJN0Xo cYgl053ovazPYGNCel9j6fP2zzE6Kx9KxQLh2Jey+iIO8mR3km+EnALi4p5+4XP8Gzv82O+PP9To XSXPvSVxIsT/D49ZJfsKZW5kc3RyZWFtCmVuZG9iagozNSAwIG9iagpbL0luZGV4ZWQKL0Rldmlj ZVJHQgoxNQo8NDU3REMxNkU5QUNGN0ZBNUQ0QUNDNUU0RUFGMEY4RkNGQ0ZFRkVGRUZGRkZGRkZG MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD5dZW5kb2Jq CjM2IDAgb2JqClsvSW5kZXhlZAovRGV2aWNlUkdCCjI1NQo8MDAwMDAwMDA2Njk5MzM2Njk5MzM5 OTk5MzM5OUNDNjY5OTk5NjY5OUNDQTZDQUYwNjZDQ0NDOTlDQ0NDQ0NDQwpDQ0Q3RDdEN0RERERE REUzRTNFM0VBRUFFQUNDRUNGRkYxRjFGMUY4RjhGOEZGRkJGMEZGRkZGRjAwMDAwMDAwCjAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA+ XWVuZG9iagozNyAwIG9iagpbL0luZGV4ZWQKL0RldmljZVJHQgoxNQo8MDAwMDAwMEE2Q0NFMTk3 MkNCMUU3N0QzMzY4NkQ3NEU5NERCN0Y5REI5NjJBMERGNzZBQ0UzOEVCQUU4QTlDQQpFRUMyRDhG NERDRDhDRkQ3RTdGN0VFRjNGN0ZGRkZGRj5dZW5kb2JqCjM4IDAgb2JqCjw8L1N1YnR5cGUvSW1h Z2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCAxMjYKL0hlaWdodCA3MgovQml0c1BlckNv bXBvbmVudCA4Ci9GaWx0ZXIvRENURGVjb2RlL0xlbmd0aCA1MzM0Pj5zdHJlYW0K/9j/7gAOQWRv YmUAZAAAAAAB/9sAQwAEAwMEAwMEBAMEBQQEBQYKBwYGBgYMCQkHCg8NDw8ODQ4OEBIXFBARFhEO DhQbFBYYGRoaGhATHB4cGR4XGRoZ/9sAQwEEBQUGBQYMBwcMGREOERkZGRkZGRkZGRkZGRkZGRkZ GRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZ/8AAEQgASAB+AwERAAIRAQMRAf/EAB8A AAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUS ITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4 ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEA AAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKB CBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A+4K9AkKACgAoAKACgDx3 xv8AHeLTvEU/g/4baFdeO/GcQ/f2tm4S10/nGbmc8Jg4yvboSprlnWtLlirsrl6s4fxnrvxm8N6B c+JPHXj3wZ4AsEUlbS009r2QkdEXzMmSQ+i56+lYylWSu3by/pFWiyp4D8ffGvXvCyeLfCd54b+I 2hvJJH9lltH0y9cocN5f8HYjk9+lKE67Tkraf15DajsetfDL42aH8Rrm60iS3uvDniyxyL3QtSTy 7mLHVl6B15HI/EDIrpp1lN2e/Yhxa9D0uugkKACgAoAKAHUANoAKACgAoAKAPIv2hPHWreFfC2n6 J4Lbb4v8WX8ek6S27H2dn/1k2ccbFxz2LA9q5q03GKjHd6FRV9ex5OfjH8IP2cdBuvA2i3Oqa3rA SRdUvtKiRp5bsghnkmdgA4bOAN2zgdqxUoQi4w1b6oqzbuz5I+M11aaleaRqOnw+Owl3DI/n+L7g TyXHKkNCwAyvPPXqKxhZt2/P/gDke7/Af9pSw+D3wj03Ttb8I+Iby0F3Oy6lBAgtZGZydquxAJGC CPrWkKrg3FK99d/+AK10juPFHj7wR+0Rpza18Krq50P4p+GUOoaV9qhW3u7lEGZIcqxWVSufl3HH +6Wy6jjUTaVmtfu/y/4YI3XofRfwp8f23xP+H+h+KbRViN/bj7RCp/1M6krKnU8B1bBPbB71105c 8U+pDVmdlWogoAKACgB1ADaACgAoAKACgD5d/aJur23+M3gKSzY/abfw5r8+ljdgC9FnIUI9Gyse COcgelcFZ2qavRL/ADNIrT5nyL+zJZ6JrHx18KReMBHcWktzIyJccpLciNzCGz1Jk2kepwO9KKV0 nt/Vha6ntH/BQP8A5GjwT/14XH/oxaqr/F+X6sS+H5nq/wCyxp+j6p+y9JaeK0hfQ5XvxfefjYsI Zi7HPTABOe2M9qqkk4ST2u/yQ3e6sfBfw+ubyy+InhyXw68hu11aBbYj5WfMgADY7EHBHoTXPJXh qNb6H6JfsjDZ4F8VRw4+xx+L9RW0/wCuX7vH65rpw3wv+uiFPc9/rrICgAoAKAHUANoAKAK9/qFp pdpNeandQWVpAu6WeeRY4419WZsACpbUVduwJXKjeJNFW7WzbV9PF2wjKwfakEjb/uYXOfm/h9e1 Z+1hdK/4js+w2DxRodybgW+tadMbdJJJ9l3G3lLGcSM2DwFPBJxjvTVSEtncLNdDx34/6TN4s8N6 R4x+HF1bat4k8D6gmp20VrKs3nxEAyxfJn7yhWx3C471z1mpx5ovbXQuKadmtzzCb9mT4e/Hmxtv H3wu8QXPhV9SYzXNvBCLiK1ucgunl7kaJ1bOQGxyCoCkZFTVRXTt3Jbsz57/AGmbDUdC8SaPoWs/ Eh/iPc2Fm26Z7ZUey3N/q2cSOXYhQx3NkZHrWWl9HfTcp7djuvgR8MdT+NPwxk8O2nxdl0Cxt7qR bjw3HYB8gneHYiZDIrcnkEAr/s04RUm1fW/9dQd0jvNU+DnhH9mfTBd6RcXPjH4o6yGsfDdvJEB5 csg2GVIVJxtDH52J6gDGSaKkVBWbu3sv+AEdT6Z+DXw/Hwv+G2g+GWZJLq1hL3kqD/W3DsXkOe+G YgH0UdMcddKPJBJ7kN3Z3dbCCgAoAKAHUAcZ4w+I+l+EtS03RVgutZ8S6oHaw0ixVWnmVersWIWO Md5HIHB64NYzqKFkldlJX9Cpf+JPHtpp5vYPA2n3m1Sxs4vEOLrjsAbcRk/9tO4qHOry83L8r/8A AC0b7laLWLj4wfB3Up9EsTpl5rum3lklrqLmM20uZbdhIVViNrKcgL2/ITdWk2lvcPhl6FqXwzrU nxCfxCVtTYPY2Nt5C6lIm5onuWkZ4/JIcL9pBT5h80YJ254lwm6ik9tOv/A+7YaaUbGVpvgjxJa2 viGGd7JzqT6p5K/2nK8US3MkksYEZhG07mXcwJ78HIrH2FS7be6fV9fl+JXNHTysdF4A0DVPDekx 2OsmKRo7eBFlW9e4bcse1lBaNNsY2gqvPLP61tQpyppqX5/8DYiTUtjzfxj+z7dW+tal4l+DeuL4 R1rUkddS0+aIyaXqm7hvMjHMZOW+dQevABOaUqGrcHb+v6/4A+bueQL8KrjQE8nxN+zTp2syA/8A H3oXiJvKf6RO5dfqT/KsuVxXvQ/Flb7Mu6N8L/FU+r2mofDn4JaD8Ob61kDQ6vrOtPdyQN3dIUbq AejKRU8spNOMbW73DRbs9GtfgDq+gWl54ji8Q3XiX4l3ZRZtbuiEeGEgq8VshO2Mc+oyMgFc1U6E +W8XeXqCkr67HtHhGDV7bw3p0XiiZbjVki/0h1IOTk4GQBkhcAnuQevU9dJSUEpbmcmm9DarYQUA FABQA6gD5b/Z1u5PEHx1+N2q+IJGbW7W+jsbdJOsVoJZgAgPO391Fx9PWuGh70nKW/8AwS5aKx9R V3EHkHxO8R3Vv428A/Dzw5cnRv8AhKbu7udQurU+VLHbwoZpVjYD5XlYsC4+YfMeCc1x1NZKnF2v v3KWiu9Td8RfCTR73R508L+d4c12OEix1WxuZI54pRko0jgkyrnhg+7IJFN4eCXuqzWz1Gpvrqjx DUdZ1344/BHwTrFhmx8eNqktss0B8sSXFtFcSleCAUk+zqSvQZOBxzzT/ewUrXknb8P6/QtaPyPb vD/xZ0/XfhdaeNIIGaWeERnTlOJjfbvL+yAckOZsIM/3geBzXWqy9nzPft5mbj71jh/2ctKnvLL4 h3HiuVtS11vFN9Y3k7O+NmyFmjjUn5E3O2FHTPtWNCCknKS1d0/wKk2mrHC6Hp+l2HgL4s3SX2pW XiHT/FOs2nh6Wzvrj7aHi2C3ghVWLSKGYArgjDHdxk1jy04qUr2aulr2KvJtLc6b40Qapd/Cr4ca h4siNp4ol1bR7fU3gkMTbpSBcRkpjgnOV6A9M4q66vTjJrX/AIDFF+80tj2Px5odjc/DzW9PaBUt rfS5fs6oSphKRHYUYcqVwMEc101YR9k1bRLT7iIt83qc94b+Gfh7WfDfgy71S3luTYaQoiiM7Khk mSJpZXwQzudg5YnjPHNZQoU5Qi2tLbetvmU5NNnB/CPwVoviPXfirZa1ayXdtYeKJrS0VrqUG3h8 qM7EIYFRyeh4zWVKjTnKSa0T8+7KlJpJrqRfGXQdO8K3/wAF7FzezWlvqcOk3BiE0kt3bRwMAjpF kvyAcAHkmitTScE9dl9wotu53fgfS/COq+JvEM3ha21O0jtbUaZqFtcpcQRzGTEmRFLhlKrkbgBn cf7oq6UKTm+VWVrPfr6+gScklc8B8L3HhwfC3xZB/bNxF4/GvalaeHY7TVJBqTXCyEWqIofcybto O7K4zmuaEafs238XS2/Qpt83kfXnhYaqPDOijxS0ba6LCD+0WQLsNz5a+bjHGN+7GOPSvVjzcqvu YPfQ8s8XfCDV7D4in4j/AAovrPT/ABBPB5GraZehxZ6ug6FmXlJOEGQpHyg+u7nnTkpc9PR/1/X4 lpq1mdPL4u8dmzdbf4cv/aBX5PM1y1+zBu2XB34z/sVTqVukPxQWj3/A5HVfhJ4q8SeH/Cus6rr1 vF8StA1GfU7e5+eSyQzN89pjhhD5YRMjn5Se9ZujUcE2/eWo7xT20Ozn1Xx9qWlPZ2nh6y0TV5I9 n2+fUFuLW3Yj/WIirvkxyQrKueMmr5q7VuWz73/4cXuLqczafD7VfAVn8NvD/gnS11PQvC91LdXd xcXqxTTPJb3UTYUg5Je5aQ9uwqGqlPlUVdL+v1Gmne7tcfoPwiuNB+KOu65BOD4QuJV1az0iM/Km qtG0U0uDwPlG4c43SZ428NUbVG7e7vbzDm93zJPhJ4e8V+FLzx6/iDRreGHW9dutbshDfLI2ZFjU QvwMH92OenJop+1jzXjvd7r7glyu2pL8F/DfibwrN4xj8U6VBZx614ivdat5IL1ZtqzshWJgADuG Dz0qqPPFtNWWrvcUrWVmbnxd8AS/EnwVc6PY3qadqUU8N5p9y6bkjuYXDx7x1KkjBx6k84xWlWn7 SNuoouzMy6m8feLdBuNB1bw1Y+H5NQt2tb7UV1VbiOFHXbI8MYUMzYLbQ20AkE5xg5N1px5XHfrf 9P8AgjSine56GkC6bpwh0633LbQ7IIA+MhVwq5P0Aya6PhjaK2J3ep5d8H/C3ibwz4i8e3PibS4L O28Q61Jqls8N6sxjDKiiNwAOcAnI4rmoxnGTbVky52aVnsR/F3wx4r8SeKPAl94V0e3vLbw3qy6j cPc3ywecNjIY0GGOcHqaVaNSU04q6XmCaSd3udLFfeMZtahmj8MWOl2SxyS30jX6Sz3jLGywwptU BfnYHex4C471SdVy5uS3fVaiajbe55p4R+CGo6x8NfEnhH4gWkelT3WuXGsaXf2V2JntJ5HLxyJg KQ8Z6+oJGRnjOnRbg4zVuq18rFOSumj1j4ev4vj0RbH4h21n/atkqxfb7KffFqAGR5mwgNG2ApZS MZPBxwN6fPblmrW/EhqLe51tdJIUAeZ/Gjx7deANK0C6WZtO0q+1mCz1XVliWQ6bbsGJkCsGHLKq 7mUhdx4yRXNWnKCVtF1ZUUncsXHiF/A3h7xJ4x1rxS3ibwpBp8d3ZHy4PMVlEnmKjwIqur5iC5zg 7ucYpczgnJu6+X+QWu0rWZJ4TtvFHizwxp+t674hutEvNUt47pbLSoLYxWcbqGWPdPDIzuARubIG c4AAohGc4qTl91v1QNpOyRzPhr4t3mga3448LfE2aGXUPCVh/ao1O1h8pNQ08ru3mPOElXhSAcE9 KmNVwbjN6rqNq9mja8AXfij4g+HbTxTqusXHh211eMXOnabYQQMYLZuYzLJNG5eRlKsdu1RnGD1p w9pUXM3ZfL/IT5VokXRpvi3R9H8XJqfiea+jWI3Gj34tbZLm3UISySKIhGxDL97ZyrdiM0n7WMZt vzW3+Q1ytrQ5PwP4l8Ta9+zuni3UPEd0fEFxo8+oC5W1tQIpEWQqqp5W3b8ozkE9eRQnJ0XO+tn2 /wAgaXNaxF4L1jxF4p8AeCdVHxClg8S63DbTG0mtbIwXDbDNLFtWDegMaSYbPGPpWUZSnFcs/efT T/IqyT1Wh2fiDRPENq/irXIvF+oWdqLfzdPsLaC2aKARwDJYyxOxLSBjhSBjHfNbzUlzSv8AL5eh Ks7KxyPw5Txj8Qvhh4Q8RS+N9Qt9RvxbXV9ELWzWGWESgzRrtgDoWjDAEN1I96hRqVaafM9fTv6D bSexPZ+LNc8EfGCfw94+8QS33hzW9Oa68P3VzDbQRwyRZa4hldI1y4TDKc425yCeQ1OVOpab0foK ykro6r4dy6/rKX/iLW9UupNL1Sd5NH0yW2hj+y2hP7tnKxhy7AbsMeFYA5YE1dJyknJvR7IUrLRH dV0kjqAG0AFAHJ+MNbj0+807TtY0G61nQNUiuIrySDT5L1YHHlmNZYkVj5bgyjO0gFVzgHIwm9Um rp3voUl23PHNA+DY1bSPix4V0NL/AETwDrkMC6JbXsEsX2a82s0zxRSgOkPmeVwV+bB2nABOEaba ko3S87/1+BTdrX3O/wDhx4s1PRvCumaF4/0LWNP1/SbWO1uHtdMuLy1ugihVlimgV1IZQCQ2GBJG OK0pzcYqMk00uwmru6Zy8fwon+JPiP4geJvFNrNott4j0T+wNLt5o/8ASYbcDJuZFyNjGTBWMnOF +brgZRpurJzkrJ6L8Cm+VJLU3vhbrmr+DfC2n+EfiBo+qQ6noUCWMN9ZabPeWmowRjbHKkkKNtJQ LuWTa2fWtKc3Bcs09PJ/5ENX1RuXPi6513QfF0y6DrFtplrbm3s3m06dbm/kZGDmO32ebsBZACVG fnPRc0pTlOM9LLpo/PoNJJrU4D4fC80r9mCLRtQ0fWrfWLfQrmxexbSLnzzMySBVCbMsDkfMMryM mpi7UXG2tn0fn5Da965mfC6fwl4X+HHg281DwhqcfjHQbAHyrfwzdC7luRA8LR+YsOG3hyOW28gk 8VjTqUlFP7S8vXyKabfke1eKr6aPwNqMt5Y3QvLjTpENpZwSXciytEfkAjUlgG4zjH512VG3Temr RCXvHK/s8Q3Wn/B/wtpWqWF/pmo6dZrBdW97ZS27o4LdPMUbu3K5FTQfuJNPTy8wluc3+1BpZ1vw v4etbXRNQ1m7t9fs7krZ6dNceXAGKzZZFIGUJBXOTuHBrPE6pJLX5/1uENz260ukvbaK4hEqxyLu USwvE4+qOAy/QgV2J3V0Q1YmqgHUAf/ZCmVuZHN0cmVhbQplbmRvYmoKMzkgMCBvYmoKPDwvUjM3 CjM3IDAgUi9SMzYKMzYgMCBSL1IzNQozNSAwIFIvUjIxCjIxIDAgUi9SMTYKMTYgMCBSL1IxMQox MSAwIFI+PgplbmRvYmoKNDAgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNDEgMCBvYmoKPDwv UjM4CjM4IDAgUi9SMjIKMjIgMCBSL1IyMAoyMCAwIFIvUjE1CjE1IDAgUi9SMTAKMTAgMCBSPj4K ZW5kb2JqCjQyIDAgb2JqCjw8L1IzNAozNCAwIFIvUjE0CjE0IDAgUi9SMjUKMjUgMCBSL1IyOAoy OCAwIFIvUjE5CjE5IDAgUi9SMzEKMzEgMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvRmlsdGVyL0Zs YXRlRGVjb2RlCi9GdW5jdGlvblR5cGUgMAovRG9tYWluWzAKMV0KL1JhbmdlWy0xCjFdCi9CaXRz UGVyU2FtcGxlIDgKL1NpemVbMjU2XS9MZW5ndGggMTI+PnN0cmVhbQp4nGtoGNkAAETAgAEKZW5k c3RyZWFtCmVuZG9iago3IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovRnVuY3Rpb25UeXBl IDAKL0RvbWFpblswCjFdCi9SYW5nZVswCjFdCi9CaXRzUGVyU2FtcGxlIDgKL1NpemVbMjU2XS9M ZW5ndGggMTI+PnN0cmVhbQp4nGNgGNkAAAEAAAEKZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1JDQVJNQytTeW1ib2wvRm9udEJCb3hbLTE4 MCAtMjkzIDEwOTAgMTAxMF0vRmxhZ3MgNAovQXNjZW50IDEwMTAKL0NhcEhlaWdodCAxMDEwCi9E ZXNjZW50IC0yOTMKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDE2MwovTWlzc2luZ1dpZHRoIDI1MAov Q2hhclNldCgvc3BhY2UvYnVsbGV0KQovRm9udEZpbGUzIDMyIDAgUj4+CmVuZG9iagozMiAwIG9i ago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQzIDAgUj4+c3Ry ZWFtCnicjZFNa1NBFIZnkurCj/gBrmzxCBa1hoALkbarEjEKaQ0JRdw5uffcZGAyM8ycYK/gtpuK m+4qWtz4F0r/RVfdpP8hdNWx3Tg3QePS3cx5znnf88HZXIlxzivt+lp7vf6kkw+6RhWRpXCXh/lS mC9fvLo4PD8+3760wJrfv14PC9fYbji6HX7eCj9uhG83WbmQ+Mg/88PN9lvomIw+CIdVqBubO9nr EzxdXn4O3Rwir0EHEaiPkEmFUH/Tevd6owGPGhub0ECNTihoDbtKJtCUCWqPjyEzDtT0A4nRqSRp tK/BmgcB3mIiYxFuJWgLUAWLbiC9j2+QHnpOaMIUyIDUiRqmhX2MZ0YTWGciH0QSpVrGk0+ctATR sfXi5bRH6gsqfL2MGEwWM1OTDAcY6/8wElJ7INyiwqeLkEpvlcijb5SyTk5aGHqpezP3KjjsCZcq 9BPdYiuz+eCfqYW1Kp/UmknWX39JHlVW65DQaVSC6QE9NGfL/4+jMMZKB8AYMc7KnM/df3D2pRLe h+19fvYp7N1ZXFl9uDhaGY9Ho9Px6snSvUrkv57tX965snOVsd9c/M4zCmVuZHN0cmVhbQplbmRv YmoKNDMgMCBvYmoKNDM3CmVuZG9iagozMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0pKQlNNQytUaW1lcy1JdGFsaWMvRm9udEJCb3hbLTE2OSAtMjcwIDEwMTAgOTI0XS9G bGFncyA5OAovQXNjZW50IDkyNAovQ2FwSGVpZ2h0IDY2OAovRGVzY2VudCAtMjcwCi9JdGFsaWNB bmdsZSAtMTcKL1N0ZW1WIDExMQovTWlzc2luZ1dpZHRoIDI1MAovWEhlaWdodCA0NDIKL0NoYXJT ZXQoL3NwYWNlL3BhcmVubGVmdC9wYXJlbnJpZ2h0L2NvbW1hL2h5cGhlbi9wZXJpb2Qvc2xhc2gv dHdvL2NvbG9uL0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9ML00vTi9PL1AvUS9SL1MvVC9VL1YvVy9h L2IvYy9kL2UvZi9nL2gvaS9qL2svbC9tL24vby9wL3Evci9zL3QvdS92L3cveC95L3opCi9Gb250 RmlsZTMgMjkgMCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggNDQgMCBSPj5zdHJlYW0KeJydeHl8U9W+7y61yUYFlBibiCZxYh71 iIATMzK3hUIZO6ZtaNqmGZqxmeeVpJnapk3bpPNIB2YKZSrIIFhBEVCPKI5HvVeOT8/adfWc91aK 5+q773P/eZ/0jzR77TX9vus7rDjioXFEXFzcE+vWLd+yccWsrYJCvmTOWmmmUJAd+30WNSWOenoc 9Uw8egM1/mb9bX7CM8SGuvETKM6jRO3TnKcmj9Q/PjJjEvUfjz3oyR3XE3dmHDE9NWX7jFmzZq8o FinFgrx8KW/B4sWLeVlK3u9PeCv5EkFeEW8q/lLKFxaLCvlF0rm8LXw+T5rP5+UKhHzeis1JO9Zu WsObvmZTKm8Nv4gvzhTykmRZeG68DYJsfpGEP4OXWyzmCR/8w8suLsoRSAXFRZK5vGUSXiZPIuJn C/BLfEU2XxR7MJsn4osLBRIJ/s4TSHh54swiKT+HJy3mCYqyhbKc2PD499ziIilPJC7GzwvxE9xV UrFEKskWC0RSHh4xaeXqB3OU5mdKY+NKBPgxrzgXt8wpzpbFVvNfz6SZgiIJT8pXSGPjZPF5OQKJ SJipxOPirkRiwdgUZBJBUd4fo8/mifl5meIcIV8y1m9sV/5YH+9Pq84UiYTKsXeLx1r91/gCqYQv zJ27SVCYJZPwUooLM4t4m4oX8zbwUvh5MmGmmPeg0P9vgz/K9v9XSIIglmxYpizK3rhcVZyzaYWI v3llSW7SKnFe8mpJfsoaqWDL27J9W9eWFqSukwszt61XFGZtnz6DN3vO3CXzXiKIOcRzxE5iM7GS mEs8T+wikohVxDziBSKZWE3MJ14kUog1xAJiKrGFeJt4iZhGbCXWEi8T04lUYh3xF2IGsY1YT7xC zCS2ExuIhcQsIo3YSCwnXiVmEzuITcQKYhExnniYiCMmEBOJScQU4jGCQbyG4Us8hIc9Gbc17t64 18edjy+Iv/vQwoc+SliR0EFLoR2is+kV5BNk7fjnx596mPPw/UcaH532aO+EZRPenZg9cXjS2knf PiZ7nHzc9PjtyU9PBoxJjBCDeqKbSWNGmPefdCS+mvgvlob1T/ZbbAPbzN7PPsf+9KkpT73yVCX0 TKTOgF7qb5E4atrIs0zUoqZdttSYQBEos0nNYjRpdBNLmWy2bDGQaspHvwDXyH35K0QF6TJ2virL 8hdAviUOtPi9Td56LpxEba451VJ/sZw9kYIgArN6qSdxx5fCzBSvJaD9cA51hVVCQ0dG7a8jtkGf bWKr4eYwPc1r8oJmUO8J1u4/DxNYUESLoESX0WUEJjbglxnXW0g1dNJH2bCGCWfC0FEUSphIJVGL cedzD8bXUC8wQx6/qxKcBzXi42hp7bomNB6ogNqi1iiFWfISva5UpjNpgQWYPfqApkrv1QNSplLJ xA2K9ndhIu50JyS4w3BS2wfgJNkhbi6UqjUyTUAf0XLq9X4jKAPZuW8sRM/KIcnSfLkFLtYA0kZz Om3ABozOPMs2g9WptZc5yImU3TgAfzk1GbZ85Pw0kfE5lQHHM0tLinKV6jLANpkCAT8A1UPc8zAr gfG+N1reUP1Ur6g5Z/2GzegvL3Deg0V2d6q+1PYXNVtNP+UMWYAcWJwWp3UW+pn1EW0AvhRsODp8 8dtTg32ArAnqlTrLPpOQm44WJzA+16bZywxP8avV3cdaot++z8G7pO+luNE48AU0fBAPf/6VuTUp R7YTkCmCIzc+7/lq6B1ue8fBugOAbKwx6awOq83INWsdZmAkJTVlTa3RSMvxvT2b0UzEQ1PR/Nln t35381znrYuciSM3QYQaicSN/DOGm9do6KtRw1bKkIDWqmmD9iY9kAKTTWNROmx2vU3jtDttTtuz oyRL+LxGvj1W0J248uXyKtAGKspbvLXwYWoV69LokYRaGjWBuoCYo/vU2+SadWYMkpYwfY3P6AOd oNYdCnbGgMaqu+j1vhMkY0jroL7umAwgB56FxPb7iYz7pidhDw0ugMRf4cN9uh5ZA1feKK/a3nCj tr2qq41kfNfWVLP/4FPfrzyNmBxUiTFvxZgvBhqb2Cz5M+YZ70MnHGZeBYdtEdMhVXM6SCURsWwt mpgpq2mtqjrR+AkndMzXGDpFMi59BGuZvoYqH97MT/oEy1Ik6RkSrkC+y7wA4Gmyl0QHIuYIvH9x MrxyLpFx+1N4mRkdDAUHAAmn0tCVUTJoDIdC3lrAbgLd2oGiQeF+bRsgB4/2HoyW1ZRyGcfkZVql 0WPw6bkei9sC7KRRb1GLdYHD+zjp5xWh5BA8An9kVaI+uhDR8RGx66PUXFz8u7Dlbjy8Q21k4kJO R/PQgleGUr+59m7H+Qvca1cPfg4+Ij9LPr+QoytlHmnLTVm+b1r6Om7uNr44A5C7hb3nbrZ/efIG 98DQ4Y4jsaXYtRHlCeqJyGRwD268lchQUNkwnpm6UW9UAdJgClZWd8GJ3XAct/Xb6Cen4G6rl7VN n2fBx1hFP+fw20Ep0DotZWnpaBHLdFgZzgEkehItRElo5sqDGVeHj3b9NMzVpzk0QEoyQqJaZfPh 04c+PM1hpKFF8Dqzw1GjAHkkmv08WjpPIGk98NkgJK9d57S199W34RM4Mk8TGSExMgtiyNylpp23 hgwgD+gcOrM8BkTgfHH0MRbKoWwJ6BU1bcAW1dbloEdGX2Hx0RMmXYrp3+hUVGJ0hjwRXxTSqCUs qBodSKijwRco0AeZ5b4r1Ww8mPIY9VNvHIAPxY/wKD6zD+5KKKWZ1AaLHJiAzl3q3VuZ7SvASxSg VLQHidEcSCACzvn5k6O/fM1VVS94OblwMWCj+PW3IBM+cgJOuPMp98TJK23XwLfgVGoFImJbrq+n FkQUeMthJnR/jeEzRE1nNtIAcAOXK+RrUQANMOah5/IRSzRNMttcpN+j1WU48Uoya+i7VcFode2d yE1us7bO1hgDHJwLX4cv30kfWLluV8GSZG77T54gAE6X0812uBIYi1xOADiM2w4nmitLgGEMDEd9 CUgGa4teydiYmbRLuB2QxfKahv29MLH9Jrd1+MLJQTsZ45tj1BONcRgZimvx8DcYx1yRJFRjHKXk 9p6tcdcEurht5XBm9Ndb4Av24cKWHegFtAAtRjOXnN1y58btQ++9w0FFcB5z/1c3b58CZLRaLRUq 8oSF3Nx8vvKVUlzdXGU39a/uOPALteyXeKpoZC7zVbAg+7XlU+cmoYkAjScR75vpkAFz4F6YC0sr OX747Ix/oKcAadzH/HgweQ4idqOp6+Zwt76+MWcVIF/dcwkSfxuEMy7e4w59eqn/QxAbZIxUcFU5 VDqMj4dPjjzOHBNGESYJyX8TRuijw/HgH523h368cR6OA5Ak4SJE+wWt5qBOGlyfhGmhxn8Qy9Og tktyMq91A3gdICITPbRmTdLmJYXPA3KPorIl5G2ovcjFtUb8Ovj2GWpCA6btA9AST01BW5gqWi4o rXDVA4+r3FUOF1E3Wctpmt3q4/JwFkYPC72CNqDZKw/svXLjeB9kfMV9CR3XZqtN66yYQC30VSMk s7tFJFi0Bj23JoVbIhPpJIAUyDoGbp6G8VevcTs7u+va8dJhJ8qOUh93QQUe/j1qzfvxPRSP+TXt 5dFFMt6+rZmArTP5gx6Xx+Pllvtc5cBHRpW1paVqpVTQIzr61fX/hBsOcT6AHybAOJqvKwERtHa4 oO/GECBDQavZ7nTYrVyb0WEFZiwx6obG+rqGvty2nTtzZLvzOIU58j2Fs8h5tAcOor8P7u+Io5w/ x8OpuALnzdVGUIKtSal2L3p49A2WcrPZMnZcHWH6hqDVA/aDKndFRe8ZmMpqtrQ4DoG/gvdqj3QO 9rWfA++QPyw9g57mIBcNrkxm+qJV/jZwAPQbImUtyspCsBusk+5JLxGqckwbsXswuUTlY/LSTd3t jiEhfmQiJpRRy+8WSQT0lnyrcgwJqhSTecwildMvw4XqwO71JSUZcnauao1hKSC3SCqaKisHmr/k ho4Guyv6exydzipwwNVmqTR4rW4jHkzl0FplEStrGGqU5fyFRst8G1sHCpz5zmuwjOVrqCzH+wcX 9Gg3a50ap4obdWB6Z2MFfjESByc8eRq+WXvk+K3uobbOWuADXpvXEFAFrBFAttfWdXYqosVSkUZU ws3KzE5SZ5flsc7AQrt7udboWK5jq+hNXg/wA7IhZFCWAaBew12CjsXkA2U1wC+jcNuB6obJ4Fz3 HTjr4r6PExn/ooTUDOYmmh1Y3SafqG5fBR/TW/yCN+dsbyg8X8JNylbKgQRoA7r6sunr8Pc95Opr e+/DyXffuXdl19HZzZz0ypIwqCFrGltCbjdwejgBR7UzCEjG37/526d3wvaIJcIdpDF+Q7fRN0wX cDvdTo+zwh62/rqvrxh3l5qc/eZru/vfbfLVhus5odrD3QH88q9wOjWF2Vcv2Z2vS1cIuDivyQSA 5MvaBr49/8lVLj7WaP3wiL47zjVGHrBLzbzt7a8Y6oTTP7sPFwL4EgmnzPoPxH5tQdaK1zhT5ySh CZhRwOKONWczW0obDEcN818zmt5MrdCw+qP9FQdABLRbjuouqc4a+sA5cL3l1MGmulB1S6+mkrUl OUuxAqO1tPytuu2h3UELdkAOAAAppkHzyDbmJyeTZz+7G01bP2+MiZYDcsnuS798fxLOuPQHEcVO AfVjd9wIOwY9q5p21VJlwe78T07l30fAG6Yne5SVoAMEPDW+hstQwupzNDgbMMT9zqCtxuTXYiup dugswlor6xbUKr17F9id6HUHG2PMF6n2HQJs+HqvdqMFYDPLdVqA06mLOlgYaFjwo9TsRqw/3314 HCu+qxdOZcrRywlhWiDs81aASlBni1hJhtDcUGsPT7l78eyt/tKjuy9w+QPqTtBKdkejPac7ct+o 4IRpjKcjkJtQRjOVmWxlwAwMboUXvxkQa9zqKct3ZbxdEM04nMo9kFabD4rIvYUF6VuFh75Xc/5t reNgw8eeO/EUHxvr1DU6vRozuzkYrAhfqT3Nbf++/iZoIg+KWnPWrVyLXpzLgY9SW63eZG2OebOZ rWmhuwD+uKp9TSrs6susYmOR02kvs8jQlNEgNtgH4dzQ/oOXTn88fLkHG+yQTmuza21q7laUrd1p FgIdu6RW3Xqqp/UeNsFj5fkJM5QZS9G7YWa6R16rOD0XOli3a7ure7u627G1PkZ+t+wUegrzjpp2 2OJ1VpgDVp8O6IHOKjGLHhQxCSuJERfRHqZvCpi9oBtUeELBniHIZ121wknodgKcTkNV1LeYtkL+ LkB+doi/bPr6NPS4Wu8ql8SgreyjRvZjnhoHB2B9/EjayEymplwlURlKANsAdB6Zf0c4I5CFT2oe 2op2I9Ga9lUDu7in0j4U3QNfgg/qbx85CTezwkPhqqvlZBjVq+lVzpCjHHTbwwagBDJLsWyZbIXd pNPJZHzdXtwRc/lNHJ4mnYSMj+9yjw1cbr0GroJzoo494RJ/qTe9zs7CcqI/CX/rioMnqaXM12ht P7vcMcvC9ts9VovdabJwctI27igwik1mC94SJ3C47ORN2grU5jA67XYj21hoygcmUhZVtx7vbvvu Ckfr37lBrVYDttESqIqV0sP9En6RcJcWG2uAYkZgaiQOfBQPxZDGlBSYTQa9SqUxGAGJw5e/wlPj r+cCj8fvDpBuusv9JfzI7p6qkNtz7DhwncEsg0+Jya62yHehVSx1skUI5GRuWN5xvK/j7nlOKXWC KZJLCwvqS9tbGhvb2qUtophmK3uo0W58PiDtS/j4vUTGIiqfymcexGZQSisrNVplAFfcIw2QjNtB WYFXOOX5ZatnpNYUXVzPDRpDZbWKOkW1xm8a2BkqARnk0i3JyxdtuPF9wBVw+TlytwBJsPH0N1ZW RPBRq7G1GI+rWi2dWBLo9+7BhKvSAwu+4S74xliN0+uVwweG+zq1kiinQRwQuNeOuZkIfOcwrMOe OBDzxEBNu2CuiiWesZS/B/tw1E87C7f/Ht/DqEVN/x/vAaAzTN8c0PtBO/C7Am7/NWhnwX7aOqRX b/8jsK33lQVi2c7lcwcgi5Kxai8EfOcrxrzsmbQBioG97G345p1ERhqViU/y9nWaMnySzTZfpQ+A +g+4H8PTCctoKWieWb1nOck4NnvzzrSCKTpjRU05cOOifwP/t92dos0zp5jZZfR+LBJBq8/hNWJG MeFTLchFz7GUK80CoCTz6hQ9N86chamQziniqVeDUpKRVlin7BhojPw4zBnzPI3U3x8gZzgeOqn1 TLv7JfUOk9DJVrfS8TJdEYvXxi63eYzAAAxWkT5jBTrGEqBnpOnZgNRZyv3lLne5l+sLuL0ggC1R WCpVKSX53SXH7128BV8+yLk7QsPIkQn/G3LOYAb5viduZEKM4NtpmWhune0MJLpq4RwHG70w2qze JlGvjZm4I2G6yqXBuS/bowtimg95qoL7IZeyss7RPugSb8HOwKHi1mJnAL94kM1xDraHaSl+vQ9X ot5dFex6EJ0v+GOVCGMc0P+Mgz9XGTt5ZYR6FbuLf5yKj1LTmJWuAIbeAVChqp5XsboKzQLJZLHb 7G/+7lf43N85PYMtV0Ef2VXSWijTaEvVPl2dmhPSeU14u/asRfErlwkLWGb4rOW09qb87wCbHmwA nSa70rrVwLeMBYfTcdRLOC9oSpRCnV4D2KWgtDvnB2tI06s6AKfBxM7IgAdPer06TG+uNuvlO3bO Xckt0+sMKh3m+D0sqzdJyzcnYfzRT7jqzS6FQ2UWaffYyux6h8lhZCHGqDzhI9oJ+PbhrnB6y6a6 PHbXhjpFOzgIWpqP3R2LFoeof2AIfB0/4vs9O3bZKxxVpgqLvwxogbrkxV3oDZvWprIqlOs02TJB zsZUIc4Qi1JOXN/fCSe8B9Vct9/td3mj18PVw35y7CS9Z6mMabbOrraptqGtrEJEaNeDbHLWt6vh ZJj42Q048yjnM9jfD58s917GoRLvfecIgSfyHZwJ/fGULjYZv5p2xVId851lNpmpGCWO8ln6nDIN tvESfajVC8pdPm6Q3ixtEIsUsoLtA3nXTx2L9HVyWrsix6K3fqborLqLuPCBWELGtV0Yi5PUpycS GX1hnCUjNBfwAK+rzV1h8POrUqqe9bxe/jLLneM2BXHha5t73/dWRno6znwF57Pa0QdukdvuB+wA qKho7Xa5yr3lXvg0fPUWnAzeJTtkDYUSDAOt1xTWcMIaHxYgkCFIRYno1QL4C4uRVOnwWKx2h8nK wWJ03n5d/4v+Opsx/7LeEdBNwUqANVdvk9j2WW3A4NA5YrlEjzfkdjxUwElMox5/dAWZCo0SkAar v9LvqfJGuC6Py+tyw1nUrf8LDBGz2u602I1c9MxoMwaDAVjZebXyrtM97T9cjdkK/cldEWoeJqS7 MO3DRMYxKgeOY2o0FqvZVCjUjkmHxeePHIZvDcClXE+Fy+0Omj2sTWa7Xb/L1FcUzRhLYHPRevTS qv6sd68f6YaPfcmVv2HXAgmmmqIqXdvB5vpvbnIYIfQa/IC539EgAfng1R3o4dXLJCKBqgiQ+dL2 42f7fz5ymXvwwkDXwViYhsrIyCOYtFfG6r9JTTtmrTMABVAoMvaloCxEsdZSm5248MDHBvurK67E 8GZR04fMbnsUPf75aC2rnkaNp1Bta7iq0RW7rPj9zi431qFYTatyVmKBb3JUxLRXsjX1pY1o9rM4 HGyrGWyNvPM/CsFmqzUp5lZcOHX5x+7lKtxBX8QXZV3G5ZmAcpqyqvOBgg00ZaYCuxXonVoHbt6G m/ssnuIBtBwOseAZWNoWbaxsil0XJ+kvwG+G4qipMJ5pMlotRp20UGfQxy41QuY2R8Dpc3rE9/XH Qc3R271H63DGCdgrrFVmvyMQuySoiUZVYUk6P4+3mqs/Vzasj4gAWwYExk1yvY1VrukPBt1BwG4G PmP15nY0ibUYjZcXypV6wLYAg8fg0/r1HhMgFRqNvCSi7uisCl4a5LZ2RVsPX+hAj7JCaSF1F+gH LU0Xvo7xBPah/+t0HPz+Nlz4cfzIKixfBp3JYLcV55WqNBgtVl+Ftzzsa+IOQxzW3Xi+7F5xq0Ah N2sknJ0FWbtWo3HNt2rOg3qyR9os2LQKO9V5nAuQb3dv0ZXaFmnY6mZ6S8is0Uvn5yEGV7rYbtCm kTHyermmb//poc8vDu3HgdpvVBsL0IQNSMuNOdf5kcFTN04ODx7FQb4yaNBbHTqrkpuMVMZcmwIY 2IXV6paBo903z3C8/rHrwUbqsZNxVNzn8XDcSCLzHYfPDmTAaNdZZA6zw+y0Osws9PSoI8FGl94u HIKz4BK4Ai64vnPw7VXbs9C4lZzTMMXfegy+ZfWydhjzLG+bSJiDoswjrfu2rU3jJW3k5vIzSjMA KdRUNl7s+PHwTe7R28f6T8SuWG4+APdvnBgWN6ppZ62VZqxEapNYW4I2jz7EyqamOqvBoerQWS8G ohFrlaPC7N8ZXM1CS9H9dGomhr4fuNngAK5WDPp6Nb3bFrQHjVX6ckXVvMuj1Rj/UEztTPDSBkd3 JkRocIj6pPVURbC/io1FcuQZzCjvx8OX0Qpm3n3dFfADgI+2wxeOw/iuj7sGrg5ra1joSfRw2trM 50s26DeCt8CbVUsbVldn1Ah7sa960APMeD++Hb3NhI9B4tS7x2Bc27WqK+AmOG96t+yialjTu/cT hZW1f0nNEjANIIYALdzBK1pXmLlpPe7Bg/+8iMm8O3B8CAyRB8Wd+4pkcpHKp69XcWrKxuRTJBVt z4+NBrdeiYM9MMBExbSyDQlQhC2vB7PiX39iFopLhEXN4raulqaOzpKWQi5urofxUAXjJwMYj78m Mj7/9Sem8EG79q5m3E6M2zHe/0/4N6ZQIi4obJJ0xH7uEjcL8euduDwsvLprI3OZoxP/uTThQxo1 cWRpDDbgFtX0ITYGX8RTL0AuU7KjVJuK00CKlwa34s94OL5rEFxj/7Dy5vx8vkFdyEkrFgmKVkTN rL6rR9ovAvLG2e2rSu0Ki5YrSd27Ye0qlIukLBWE9EHISpgoj1ArI3BPhNb48J1HGoOPPkoQ/wdd p7zKCmVuZHN0cmVhbQplbmRvYmoKNDQgMCBvYmoKNjgxMAplbmRvYmoKMjcgMCBvYmoKPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9TS0pSTUMrVGltZXMtUm9tYW4vRm9udEJCb3hbLTE2 OCAtMjgxIDEwMDAgOTI0XS9GbGFncyAzNAovQXNjZW50IDkyNAovQ2FwSGVpZ2h0IDY3NgovRGVz Y2VudCAtMjgxCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMTEKL01pc3NpbmdXaWR0aCAyNTAKL1hI ZWlnaHQgNDYxCi9DaGFyU2V0KC9zcGFjZS9wYXJlbmxlZnQvcGFyZW5yaWdodC9jb21tYS9oeXBo ZW4vcGVyaW9kL2NvbG9uL2F0L0EvQi9DL0QvRS9GL0kvSy9ML00vTi9PL1AvUi9TL1QvVS9XL1kv YS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveS96KQovRm9u dEZpbGUzIDI2IDAgUj4+CmVuZG9iagoyNiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDQ1IDAgUj4+c3RyZWFtCnicnVh5VJPXtv9iIN9Xq9gSo6TYJLVa rVOttRbaOuNUUREBGURkCBAMSSABkpAREqZDAgQCSYBEQOYZRMSJatViayfb2toJe9vejq8tvfeu 89HDe+udwOvtXevev95a+SPJOWefc35779/+7cMgfOYRDAaDfezgK+GHdq+NEGUK5evDpZmJEu/f a+lABr1sHv04E72Men/X/L7R93EitJG5kOYtIM4se2y5/3Txo9PLFtHfPDJnyMJoZ4wxpldHhh9/ eu3adbulMlW2KC1dIXg2ODhYkKQS/N+IIEQoF6VJBE/hL7lCsVSWKZQoNgiOCYUCRbpQkCoSCwW7 j4TFHDi8T7B63+FIwT6hRJidKBaE5SSJRcmCUFGyUCIXPi1IlWYLxHM/BMlSSYpIIZJK5BsEO+WC RIFcJkwW4UVCZbJQ5h1YJ5AJszNFcjn+LhDJBWnZiRKFMEWgkApEkmRxTop3e/x/qlSiEMiypXg8 E49gU2FSuUKenC2SKQR4x7CQvXNnVKQnKrz7ykV4WCBNxTNTpMk53tv8c0yRKJLIBQqhUuHdJ0ko SBHJZeJEFd4Xm5Jli2aPkCMXSdL+3H2dIFuYlpidIhbKZ+16UfnzfoJ/uXWiTCZWza6Vzs765/4i hVwoTt1wWJSZlCMXzPpUcFgaLAgVhAvTcsSJ2f8+8qe//n8eJAji+dCdKknyoV1qaUrM4d0y4ZGQ rNSwPdlpe+Xp4QrRsZyMiAO5pyPzxIkHlZlJx1c/vUOwbv2GFwliPbGciCWOECHEBuJJIo4II/YQ LxLPECuIo8ReYiOxkggn9hHPEk8Rx4j9xCoigjhAPEdEEq8Qm4ko4iDxPLGGOE6EEluIaOIQsYtY R8QQh4ndRBDxEDGfeIJgEAsJP2IREUhswYFK+ODhi4wXGT3zfObJmGxmFLPZ5wkfuy/TV+WLWLGs e2QYOUGtpBofWv1Q8fyT8+88nPzw/QXJC24tXLHwpt8Wv24/etGmRdWPrHnE9ejGRzP9F/k3slex P1r83OKrHCZn/xLukmVL4pZIl5QtGYdWPxoCt3KI/tXt/5eppWwZ/R7cxVELtQqNOj0lQhUEqP2s XbqqPj6dSYK7TucnlZQb9SnJD80OLdhDzYSR7EqwR6vZVUSxw5R0H3kJ7vL1m04FHhh9jn7Cw5iO cnNOWo329A+Rhb4TkMdCKTP6g+gpfX5cKVcJY91kXJ6jvc7qrHTwx+BDvtDFOre2TmbLAlouyFYX RpVRSlhNzuignQNJ2A4p1O7rR5cgySQ94WHQUjqKgwI1rO76gvziMnOJib8GdSASVpmdxQ5QywWN Ltt5C+VCSVqytbjBUK2GLFQWYC10ZbbH1KcBDRdoFKHqTG1WjlILzKDAYqxU2tQVakAp8vLkGd3Z I29feg2uuMaHG+h1ju5ae4uVi/cHLvqx64w3J2HIJLOeXs6pstrLawHVXqOJ5aNyEoQbtNHFlAam u8joCk0d6KdgL3npQlNdD6Aut4gP8JGQBKE6dYx3UoqLjK3U14HLFFSR3ye8tjNerD64j/cJabLE qkSGiHy8Y5jxfdq3gwE+ZtLL4UZO3J40eTigNh78FJK/Xb/7Wb/DkGrnV+VUSxtVZwC3tcnd/Nqe iy/ERuelJfFjEqT7wMsUWvLJBsi8MFzf1c9ra3G3dd6i/H5fCNzTPm7GT6N04xRzegv9HmcmhgRB et3LRRj5Hje5q1LrBHcpOgwHgMPxYRUOgDgSZc1YUD5t8UWxStbnRQ492EXNrCHBCq0yyIzX6d3k tgp1M/iVoleRsGLmoq+T5Tf9DI61AfrBgNLt/+MULJp6EZJL2Wsaptdw2C4lOVlUZwA7vTEFdup0 QSUUO0MJ/0LeB3fPDPT2d3sugEtgVDUs7shsk9W9Uj/uOGNvOUOxxWebXAPnHoM+m26inbxg9DXn JzBW1K/By2/I25JDHwORuSnJitOqpMIDgIrV1nTz4TkfDPQZW42LN8piiyE5Ebdpa1TCej6GGXTS j3Uy6C0wkKOqMMaY83VqrlYtKogGFOKxYBP9tK8L/UKWoPm+jayaD1yu1wEFeSzknnnaV0MvJHFs GNvpTe0M8A10fsOEVvoUBy3ZuBbxUOB3T0F/6P/jPyAPLn3mB7SYr5NyJm+tRY8j35P7dqSktgzn 8qXj+e9huH+4ePsuz2trHNTT87G1L2HeJBP+ZOTAVeO+9aSqrBSUACqtsHaMT79JFlni1OnGg2pu PlldXgWqATVQY0zio42ksFtWm4zPTm5Avmg5WnxvM5z32qDnYi//IAkZPsBk0hsNqrxsowRQQRGf wkXQ9/KHH716+UQU35vH7mmmhwHHcGgcw25CUiVrvKyhEMiBsUhfoEFPotwAtBpmG+rNDbPZ5qzp tlQAO6gtx3HSoyQvlTq1v6An4FIUEYB2kWCz0bixGAfILTe5yaKtAx9RMIqEq2HuxFetTVcruHhP g6fAG5L+OCSfG13KvkDTBg7dTILX7QNuh9PurBiswLb1SnKwxFnsKvBoa9LAIQp9Q85waKUv2q5k nQfOwuET1Mwhkh39n0JyGcl20IdxUOKQ1I7Svw0zAKSY0wTmkgKY65vLMufm6/NAAdBYNVWx9THV J0AwCBIfithzSLgBoHlgQ+fzV8Nff+Vb4c8A+oKfxyY+o1SNO0MOZAYBbig45jk1GHFZ/A2ATAoe +A4+BFfeGM9NHuZ1n3ZJ3a9QXvrKbFA3qmCmsZv2e93/vUmY8+VSdlEN/TinptwGagDVazOe4M+k k+C4wRBmpthPqWERyT7ZSO4o19WCNyj4LNmX0WIcwcE3/1voA1fCR/Z8veZYQnZkAv9j0myJzE3X Rai5cM0OTudr/WMfXt6OKMSM3bH7RHh/J89LJ+9CSTck+xn0OhjEidt+SnIQhINTHZIbqkFTT+kE BSdYhXeMHdndmf3xZ46DGHBCJRSdSJKFgGCcCe8/D8kf7t2CxAgP3YfrOLX3ewcmwARokTo2U9iJ 2n76f/oxrCx6G2Qx4X9PB3HQMbQMrUDx67s3XjvKvxn6dcpX+PQxcBkUwPifJQ8iXueHvvtC/1oc 1T5jYEzVf/pabNd6gB4GYbq9eccLstXZCkV6+klVFIgHJxvTu46PZfyKMQZT7T+NXKSGzl9uug6o 2aD9g2W+mqJZkLGUXf43yOCA3XrddlynxEo4QEIK/L3n9mt3bg18DX4C32Tej7i+713E6EeP41xp ZrGXKclPTDUFmI/Y4qkeTldt9bkv7+SLLvHuR557HiACoPlJL7x4IlpyVL8ZUMl6zCqzbnVqG2D4 BO3f7o8zNn9yKVsDZ+itnPi2zJoUbPnRtcgHY+D/1qbvb15vvTTKR5jtjqk0Ifhcl9XQ4CQj6gqr wQhF/2Agd6EvOEBerDMW5igz9GIgBjJ7nud0R+4d8BZ2+6sfPrjdlbGf5we/xNVoVTdMbGd8gTni trckLoIU66a7a/CM0yhp5NVn1RkbANXsbmzuT2g9cihKFp/Fz0ooTCt7iQo+/Tl6mwV2GfS7vbXI 4SKDrYZacI+Cb0M/TGevAjdsGoZXvHhOTsF8L55ieBKOclpLG8pawX1wzX6+5fXu/gnwFhjRDso6 kkc3t6/Hl21gsRuwVCi0G8FuamYPCV4oNG43zVWVl60aJ/gAg0vn+rTZbG0w8PaJFWvCYhCZpy23 KHhzwmQAnj8HawaVc+pEQX8Pt3KkrBhEnJKjJwElY8WCxEqTrchaWgsaKAjgBvJz4NI5gqhmqFGw TEnFGoNWp5YWnsDH2QCzWe1VVW08GMjCWdukaXiWOssqgU/6zrSz2OX/Kmr+kDQhSnqAnMN3q4dx d5Jpox/jOK015XWAOluTn8BHVhLEmEwH9Rg5k4vcZ1W7wA0K5pDd56+0VdUUGWt59dpaswNQLa6G 9p5cjwjL+pBY/reYsaNy0nRhSu6smLkBn/PApWdhxlAl5vr3YP7Hbe1MOoMO4AxtI/MwD+XZcqoD ZHZZZRagNuzcvTG0TfhWBl+pUqnNRRkSXR7IA7l1+nN5IcdlGSCVirqf8MO9+60j47zBroZuMAhu nxjZaUWcqoAoS3YNqAeenr626poyW5kVuEsdZVVgAAy7utp62l194AroKGrWdlPINPMYp8f0qfky oP7ao0s7uj0F+T53tGO02eYYucKvhN9xbrX3jXW1qjPreY3pdfEghTomSY8/knjnR95c4Ez8i/vS aTnM52C/kPqXVJqXsEdWej1S6fXIsv/gkY//9AiOnSCDN3lnY2dbBVYk71NQAleSn4EGTd2LmFK5 xia9h97g0TX5g9sw+L2l7HXwHfg2pxgu8zWwSksLTGVlxYBrBkaLoZJiN1Tn5FRkBb4cHr37WHfy gzj+zYy+vAY5EHMTTkujRWJHk5KXe7agWXeDykcbHSybvcKCnc4OrQHO0mZMyA3m9rbixsCP37z5 3hV5z5F+PiLelNZrzoI27nBX+9iNTtGmZt6cUAy85hWKh3FqPgt/5IyMdTYMAerK2bQ9fBRLgn1G 3VHznFKMtJurwbsUjCP/nnjtxbBE+ZF4HrxBFllF+uzCY/lcWaFvPllRbgWVgDpfXXiKP3Mah6q5 4GghXi92kUerjHV4/azQon/zJuyDKajzJuzH06vcHKE1zy7pRUmwKuBtR2ddT1t3q3sEXATndQNZ HcJzQa3epO1gsS8oyXuFdgMImQPeqN/hrZ+dGPhKncMLfAz5mgUWoAlf+DyLHT0TR3/Jaa+tHoaP 3jy1PiY3MU3Ji89KN68tpfxgl3GcXtDtD2AROoTZ8AGsxuzEfvcpTE/2MquZZyowF5iMwohTcfnF FPuBwWQ2FT0GSspLraUU+91X0TXWC52nbl0ebBnv4elqc7PVxhzATdW0vcGHQyT7wa8svAWG+GFX nwcunPK/PbUF7/J3uNurup6J8NVgOVRncZTXAG7LbL5qSLDbaNjrZTqjizxQWWj3XgiSbDoa5nJk CoVU2qRo72hu6mhXNEswp7+q7c/x0OicyOPf8SXU/rqUvYw+hqtZLqtYYTCogRHgZqGaYvc4U1Or TweeAgnqDEm6WJUIjoOXRo9Bn7D3heNJZ4U1uspcIKf2x8Tv2hR6HfrF8BSsTpTu28Rih7rL65yu QExhxW4TtqQZHC4cDoTk15/89nnEHRRwl7/8ZuIouEZdHxm8fWFEmdbH6zrtzKoPw8nilYg3wz30 iw1ap//tSbh30ntA+RVOESvegLUh/BFtItk9avJ2SZ0RxFBITwJpkVZrkOWI9ZmASjndO8JnN8BP 0FNa8lKJUwPiKVRJvnwp+oOBofq2Nt75875BJDu0ovSKp7/2qpOL8UaS3mmfWbjhllm8v4ORdDyn yBqmEOrCVFiDVpa7LK5yO+A216hxlC4iwfaSbEOe2agt1AINMNrUZ1TN2pp83GSp1DmnhxXX4Lxb H8HlfPav0dPb/5MbcDWg/2uEAY1TTGibJjgzJSTYYjAEeSnhgpsMrtA6cDmhq6+RkAWaVM1oHtXC MsNtvjMTLDPa5tvCaoGMZjf0wQoB8/lcz4NtkV5hsEOnf6EEG7qCDVnzvXXJ2+184HRMepXmFSX5 YK41wWBrPfTLuO3M8tZYPm47S1xGoATGUmOxcTWqC1gJa8zOEieowVK41tZnxY1ntIYcLLUZx1bA BWg4wGK2mqyFVaqqwipQBWwO1wBcDD8M6HinytZppeb4IsjFuIdLzTSTgwMXo0j12HVx/JlcLAZL SnZ7S43OReaVJ1twCe3jwlASCtARa7GlxFJiLeFWG61mUEQVFJj1PKUGSlysBKvYnXgVrYdRAR1t d9+6PdZRzXVVOC1YEVS70Ckta6isthhoQWGBVqvHzYhfAB1EFluEeknh0XxuZqG3occyedrN+GYK /vcok4Z0HQdM1dV/bsfwaJTkfXN9DliFdRNmM5MwP1MWd1C8A4SA2BbZRVW3acCrVz8gwfu1tZ/a 8Ip+rK3MtQbcMqI7JNr5WTDcBhn3+t4Z4rWM1IyBj2f14xzO72CcNWSvyW4CaqAxyw2yZ1F2wAtQ oR4DADi4oKnWdtGGUU7QkAPFdQZPpE1pU1apNqK4gNXQWWwvtQM7F5ypq+6twLP2a8jm0mpjUzQM RD8E1GVWa6swl1Y76lqxhDYF/BUZnKkV5irAtYHKmvph3Kf9HNA4Yq304C3IWaZhfDLJxD0Rp4pV W15XjvusbrsWC/UsEkRqdaFF2DcGFxlaobeD6xT9PUbxuFpo3KuebeBvhN+kA1r83V/A1Z95+5rD b3HUWn2RBmeByTnKh8dJMF7UoWnJ6T/lDgPU+p2xoQpPXnPLGU9TRVllmY1fWlNWDWxUW3fT8OU2 SSTvMIk2HFIXnhLm5GlFIINiR4eOJkyMnjszPsFjO45XNuaeC+zFl+8bxEPoGawmxUUFuXq5VlqQ C6h0ae95fgUJbp3rhwtH54SzNy2+mWLSz04v5dSV2UEF6CytK8TiIkeRGRGN9qDnA2AiTo3a2s+8 DwEDXt/X6f6oFIa5R4M+N7nV+5zxAQWPkK1n/rH8ox3XQoCcC7Rak7SsCBiA3vuqc9NNHi/X2jf+ hLTQGgDDYdg7d+qr36nkupHL20YDD/2ciwG7lsB4F0sM8urFo2gxjA74Ai5wt3XWd5dzXWiThuws tZtx8Or1OdniIrNepcvTegKkI6pe4ABOh62zHPs9WVNDdoJ6XdeJ79GKAMRCwZlJRlNGCVcDV7pI qb7SUWVzOTz8T+CivyJBhdliBmYuUJmKM3ANm3bjnHx8nIG7tFDvh+mml3Mc1mrve09rTX4cH1V5 va85Voa9n+0ioyyaWjBEwT4SWKrtNtvZ5vMNfYAabUrHBT8Ty32DIdxbfxQuMrxc0wBuU7CS7Dzf 0zgGqBuNsiA+SiNBeGHhUROeJHWRWZZMi64RDHFhEgnnp7y+7Wh01tFInuqGqC0SJACpNiiUukea LNFKkSFC49WTuKt8+A3GW5Mw7ysmXD+9lVNkSdTICk/ouBKvgqgqrwA2QA3XFCTyZ+pJ8YOMT2HA FJwHn4SLtn+/6vDRtNg8XpTP0MX+8ftXtiI/xIw7GHz8ZPNZnt/vIQbP9EIP4/cg72tArJJ1tajR AGQg15xllKJH0bcBKAB+X1pZ0FRm5RacMbtBLWhptl/zvgZ4lOSNMntB70s9wQEC1IdW0AtMjcWz zwZNTttVK55SqiSvFrlUA+th5ExvgIsFN9Avwc0zL/m6WA+g094OGfCie7y25lW7l8WnV3gY4Esm vITL8c64zKzU+JDN6asAeggg9sDTX608F9eaM366rj7gpTekfbJ78rcNH4FfwN8dn7fdbr/d2f/+ zT+MwG1fMgfRHs6HlzpbB8bu/qXvFwAfAnBx6k/PTSVdymo63q3PD/g0tC29fUfL/trtYBV4Uhck OywNzUzbfZTy+329dgjO7zl9Hlo88GiXP5iEC+/SC4eXsienQz7gbE2P1u3Hymob8oOPwF3f9X9/ 4xb/8uW32z7A7e+zcAlahJ5eFbrmQJbO1WUrryyv4t+BNt+9LKMw55ymNh1wT4H0fJEoKkq8HVMm e1XoUOzl0YttF3p57HcSqgYklwJ/fgCZkAOD0ZNwMTqEEtAW9Aw6jiLgZrQaJr93xTH6E5+9Cm2l gzntpS55aUppnDos64QyTZIjA1Sqomf8WuOV3kF+e3efp8Wr2qz4Y/bk/83/l6Gl7FNfoCc4b/dc mACvU1fSh06myxUiHvvM6WZlf5WtvLyKxz5lsQFQHlhdZS48LU2NTOVjXGHUG7j9L2MOQTsnFJa9 genTasBQP/oLJzM7Syw5m93R1Xq2oyurNRNP7zLgG5RDJgMuoxP+fQJCPv++KM9DR3lghIfVOf/B w53VCxY8aFywkCD+F5jlaT0KZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iago1OTExCmVuZG9iagoy NCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0lHTlNNQytDb3VyaWVyLUJv bGRPYmxpcXVlL0ZvbnRCQm94Wy02MSAtMjc4IDg0MCA4NzFdL0ZsYWdzIDk4Ci9Bc2NlbnQgODcx Ci9DYXBIZWlnaHQgNTk3Ci9EZXNjZW50IC0yNzgKL0l0YWxpY0FuZ2xlIC0xMgovU3RlbVYgMTUz Ci9NaXNzaW5nV2lkdGggNjAwCi9YSGVpZ2h0IDQ1MQovQ2hhclNldCgvc3BhY2UvcGVyaW9kL3Ns YXNoL2NvbG9uL2EvYy9lL2cvaC9tL28vcC9yL3MvdC93KQovRm9udEZpbGUzIDIzIDAgUj4+CmVu ZG9iagoyMyAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDQ2IDAgUj4+c3RyZWFtCnicnVVrVBNnGp4QMoxd11o1LRGdzK619YpVj6er7rb1cmqjiKCiIlVP SAYYCZmQTLgkkJCQcPvCTULuEAMqgoIsAmq1rev2srXupVsv266ntYet2l1PqXa333DGPbsziaLU fz1nfsx87/s97/s+z/N9I0Li4xCRSJSk2JC6bfO6hetoo54i9YvX0hr1lmwNVWgkhfACNknEzopj Z4tTuZ6x62OcZDaS0jbj5yw+GWmf9VTqtLGZz7BjT7O3psbw6kVdokHRv+dlbN05f+HCRetoXame ys1jiKUrV64kskuJBxFiPWmgcrXEC/xLEamhdQWklkkmtpEkweSRRA6lIYl1W9IyFakbiHkbUjOI DaSW1Cs1RJqRb05FpFAqUmsg5xM5tJ7QxD4IFa1VUwxFaw3JxBoDoSQMOlJF8ZvIEhWpEwKLCB2p L6AMBv6doAxErl6pZUg1wdAEpVVpjGqhPL+eQ2sZQqen+XgBH+Gh0mgDY1DpKR1D8BXT1r8e65HJ UzJCXQPFhwk6h89U0yqjMM14jFFSWgPBkCWMUCebJNSUQadRlvJ1eSidnoq2YDRQ2txH1RcRejJX qVdrSEMUV2Dl0XzEY1MrdTpNaXQvHc0ar08xBlKTk5xKFWQbDcRmWksTKYSgL/FA4AmRR1L9NPEQ BJmqonl6cw15TDFPW/KqJQiyHklD0pHXkW3IG8h2RIFkILuQtUgqIkKeRpKQqcgzvGmQeMSLfCWq Ff0zrjDuf+KheL1EKulCtybMTJidsDqBSehg70xh75hHYfuoCNwVj8WxM6QNQVcTOIB1lvsNRRZ7 kQ3PC+9p3QaSwWpqy8bMDM0a8AbYGckaKOijL5RfBqPgStv5/sNtgQgIY52mEGO1VVdW4FlUrm01 wJ7P7LnYFxjo7Jb3n36742NwCvTaO8wee6MNmECRy9nsOFDpd3pBEIRavN7W1kZP8yHssZbglbti dg67Q/oSWKJK3/TmLt0msBXj0BuvwhnwZTgfPgfnwvgVn3FTceZF6bULe1NeXr7mhVe2n754Y+Ty XTmPxClHYcIodIyK2D98J4Zpf5QOqwdN7wEMroAyOAn+Esb95q/clM17zMp0eetpCYehGmCrKbeW W+0mYMa0gYpBPIQuvp8qMf8oEqw4icO1aDfwNPi9fq87BEIgaA9YGisbKl2lAEtHYR2bJb16jtyS Te/N1skLSnJt2UAJNK3G9pI261HXocbPr314B8QmHhn5mm/yS/iatGWgIVgfBEEZxH51lXuWW8W9 yCVy8zn0y/Vw1t8hdrBjGD/o8baBCBYpCzJ2S22NBV/EaKv2geUgq6viQywyIu26cKnvCvgUvJPb lCEUAKOw4dv88LTpB9kEViHlklA9MFdbKh5MQwvT9KGZnF2Sxs9pry23TJjzHbQL+Br9nuicfG/2 oDCnw1UMME6O9sB5kumvXf3h7JGepABwV3ktXou7yg+wnp6e7r5tAzt255SlLnigx81R2MaLe0/M VrJzpfnH94Z28CDJHM7JuAUc8tkaiL57JtD7O7l1e8XOffu3AhknirZUZimvsJfGWhrEoRiFceDb zyP/uQbHEoOP68DbKaaDM9rfJJRbukL6p7f2paxa+cpyxZunLl7/4m9fycd9dhlK4DoYL2ZpeEna YvTaD4IAb0gfb8gGd/ORlv7EBr/LzR+KSJnfaLY7iy14XpuqJYuHnjln/dKNb+fDKRb5eefB6oAj 5Gi1AiumTzduyFD5DjN4TbfFXwjyQHGRbY9jf2JNWZ0DODEmVNbpa2lw+/ETJWdt7/N2fB6KL9/u Lz2mCcsLgzmeta2b3U6XtcnSZBcqt7/bfmGox17cgQtShuEXvFU23hPD62Px0oeWFaQsjVl2CA+i S+//WuIUeKspm2jZePQo8AlUedxtgpS2gLXJHqPKiQ7ATX/+fafnLJCdOVqirayrqLHKc7lXo0i2 CUiDMSTvI9IF8zcJpBcJSCdhCk+bH/hk19LPLd+5uzh7Nx6jvHkUzgyLhr8XwwH4tRQqJqJEpXvQ D6dA20ca24ELtMgipiBjNlVarbjNVm2rKixZnpiH5oPK2mhT47boQ/dw+bW2ukpglYF8P91hPlp8 ynoKfAL+1XGhu9PnCfHHptMcZCoctfZSPJPZVcHbb1ehJ9Lscte75VF+2V+ERfA2VEiPcwrJLRQu gTc76j2NPr/M42kOAN9Df0X9v+ThvRA1JzC7y3zVLTUtde0AO4Cu5Rbr4DLJMjSZW+aEi7uBu8Hv kfm8Meofc+mSCRYH+oClu87H3Uz8Bo2RFn/rI/7QQBE89r2YTXwWToqq6PvRxROFMqHDcG+D19XK c//JpuE52+ebzBRebLcUAyPGBM0Rj7++MYSf8Qw1HwPYe0esOicAddXyKkZ9oKAhH8jmghV5O1IK NeX5QIspLmX944OP/IfO44dgvDSFSjNtBxipDbR7W7xBv/zY4UH/OdALTlT/1oE9NOf+8DS2/95z 0/uhhb9rkh8QVBbzji5k6cUzOZtEWaDPEzSTjwiXy7gDsCMmH4UPQ6Vk+l96+yOerqS2Vkd5TV1l rUOu4D6WfPNE9n4he+hEyH0EyNqA2+GyACdw1jr47MQnsyn8LUjXe1wHeHo+2DeYosoro9S48XhB UA0KgNGeTQtz8E8Zb4L3y6RDJwcGu42RfLkJVarUKk3EeEwejbIvxRKGB55MuAE/jW7sGV/Pfrhx bCr7gzTY2egGPizC/zEN5TaKwe+T/11lNlZZgUVmbDN1dPpbe/nDXhxmFWE4LRwOo989de9nt1sm T0aQ/wNha8kRCmVuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoKMjEwMgplbmRvYmoKMTggMCBvYmoK PDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9KS0NTTUMrVGltZXMtQm9sZC9Gb250QkJv eFstMTY4IC0zNDEgMTAwMCA5NjBdL0ZsYWdzIDM0Ci9Bc2NlbnQgOTYwCi9DYXBIZWlnaHQgNjky Ci9EZXNjZW50IC0zNDEKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDE2OQovTWlzc2luZ1dpZHRoIDI1 MAovWEhlaWdodCA0NzMKL0NoYXJTZXQoL3NwYWNlL2h5cGhlbi9zbGFzaC9jb2xvbi9BL0MvRC9F L0YvRy9JL0wvTS9OL1AvUy9UL1cvYS9iL2MvZC9lL2YvZy9oL2kvay9sL20vbi9vL3Avci9zL3Qv dS93L3gveSkKL0ZvbnRGaWxlMyAxNyAwIFI+PgplbmRvYmoKMTcgMCBvYmoKPDwvU3VidHlwZS9U eXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NyAwIFI+PnN0cmVhbQp4nJ1XeVRT17o/ Eck5CkVLmidUTdJBxafV9rXW4TrVoTggolJxIGogCQRCEs4JJEAmAmFwM4UZggSSIJZJkFEccOy9 DtfaOlxXx6veWlu7Onnv24du7lpvH7DtXeu99d5a77/k7O+cvb/f9/v9vm/ziMmTCB6PF7xl6/pd 29YviFalKJjX1mnVcu7pAnYmj501iZ3th1aib34x/RLtP5uIOOL/HCsKJDyzBGuDRw88P/rcNPbh 9InvFPOO8oZ4bNh7O2PmL1iwcL1Wl0GrEhL1kjeWL18uicuQPFuRbFAwqgSNZC7+ka5Qa3UpCo1+ kWSXQiHRJyokSpVaIVm/PWrv5shwSVh45HuScIVGQcvUkqi0OLUqXhKhildoGMV8iVJLS9QTfyTx Wo1cpVdpNcwiyTuMRCZhdIp4FX5JYYxX6LiFhRKdgk5RMQz+LVExkgRaptEr5BK9VqLSxKvT5Nz2 +LlSq9FLdLQWr6fgFfypKC2jZ+JplU4vwTtGbXh34oz6RJme25dR4WWJVokj5dr4NC6b39b0MpWG kegVRj23T5xCIlcxOrUsA++LP6WjVeNHSGNUmoTfd18ooRUJMlquVjDj3+VQ+T0/yb9kLdPp1Bnj 72rHo37bX6VnFGrlokhVSlwaI9mpTZFpJJHa5ZIIyTaFXJWW8t8Xfi/X/6+ABEGERbyToYnfppVH rtcpNiijNtIJ7zKJ4XrVrrTozckGtcyYEhcjeW3FYoJ4jXiZ2EdsJzYQi4goYiOxmHiV2EG8S8wh wok3iLnELmITMY+IJjYTYcR7xBbiLWI3sYT4dyKC2ENsI9YRe4lIYj2xjOARQcRMYjoxHxOQmIyD zvIieOcnTZ9knnTJb5Vf/eSgyZWT/+Ef7/8BfwW/l5xG/plaSg1OmT+lfcq3U1dNvRuwLMAecDpw eeDZwJ+eywt6Jej2tMXTTk47Pe329CnTJbAkaHQx8NFto4Qv+D58e4ZANxoMDUINP2mVQZ2YHKfc lbEaUJHG2gExqybB3braB6WUD/1Ekx/mH8kCe6gxIykoA3sstnV2ShBFs3fJoFEl8MG1JyDjhrvc vNGNPmE+Xw6ymvbCqYhhPSFaPqLHhhSLrKb99lAaHvSRUaX6atACait8TefrT4TANH7nqpoEkAbS LdmJhXnActhcSNHwHjlWAG3Cb2D+jyjfP4gtQLJL7H03D8AAP1bPyoRoAcMfKKzJBQywFdrtdDiK DlkPtxnOAgAqQkFdTaWv2FUU4kUlDOkpcBY47SVgaH6DDAaiUyEZuzP3pibrQag9p6KyCBQXlYiL yorKQCl1jHGrlLpUhbQ36VLnsZqmJlGTx93b9Q2cz74U0tBfVdVWQgWx54CXDb6R4A0+B8VQBMUz BEMwkTvULoY/mFuZDWQUGiaBLMd+wE4x0OEllWXWetBNQTcJSsurqiopwT1Ps7fGM7OrQbdLjPJI oLRkqfJxsNVLykuya0A/BUvJ+7svLN8u1UYpRUFslPkGG9qGEXjJj30d8oRKWao5DlBvRT+As35u vzriqs+xOcVldgyArGjfEX03oPpbvCeubDr1Jpo17yX0KhJ9FQan37vYdueyOOiXDcA3yvfxHvWz rXCx3+gK9h/CMScJdpmta3NxAf7qI1dVZVeDjyk2kgS36utvl2EylJEodkyNYlm1P3LS/NsOlwXE UGNaEmy3WFfl4PcsPnK509gI7lBsEgnLxh75H+Xj8pnb2FXc2efBN+A8P1jKpgiRIOxlNAu98u2r cAYUPnmKoZQseIqE4iK18HJjNFqGFhlidkQZzsK5cMORkStijLv5YpqHnXoRhnuDAQyDSznoTfBr i/Bkra/sSvmVihAPKS2x1GL02FsomSFv5FXmAimFtpKHTqa4pIBCk5ZL0ByxoAPN+kvY3891uM4M iwr+KASO7EyrxaBPt6UBajf9RyiAwqMfXO5oYxR1YkzzDHchB1fww0F2/eAMgRFmji4TogSa7wYN plM7qTENCXaazFgZNDT4yNWVGY0cdHNJwRC7a6zPv5W9zweXamuvV2EUk2nyTm5jOthAocuchoyn Rqd0YHA2+o3OgQuFUduSmX1GjTXJoQWbQUSXZkRzznwL/EDB+GtwEgwcHshQDIgG5J6krjWUD1p0 fHOizWYEdmAqTauK8u6v3o/z3I/mo0XoEIqD89BcGP/xBw3dF8Ttzc3uoTMcg5GsKd3LQJnlAjv1 EmbyRQz/2zBshiD8X5hcxTF5rJAEcTn2/TmU4BUGtpACVxMZWZLpBjco+BJ5KrbFMggoOPnTp7gg 4rXfIr+oBP0OtVgws1gqBOWVrppad7OnphlQI97taAaaro3amaTx9JjEHKVvwe3d8K02HjsXPi+M 36fOOATkQHMkvSujPacj/yYFy/iOL03DyT1JJ6TuaJzW80vD0Fw09/MFcPpnp9sfXxejerhGWAID j/SeBq2gMatCXWYs1hbvoUwT9kR3sU87aV/wFzi9KrhuhqDou0dCcJA27CikBGoa3iShGr6KVRwP 45AEPo+yxOgyXzCLJq85Gk2YOwI1fNsj9LhrTtw6m/Rup+jo7rp1YClYaFiSfEAl3a/fAqgDltoh cRC8j21h9iDc38a7BMV+H7NLhOg+CQ7ZrNI8LOw2L7mx2FoDrlPwxoPBt2AQeaG+uetIda41vyDX kS2ym/JtIJtStzCd3T5f9wdRfUs3xTAHdaK0xNw4sITaeRALCQIfO9aF0/kSp7MCrp0h2APr4UUh nFnUWTJ45LO2wT+BexSkFv4Z/UGE7vIFQzT5kaMuC2ykxrCOt1kMsY4CkF1o40z2gY9cWWWvBLcp wR7WPNnTUNPxRcdBRERYFal6EWNIyt0AqGddg4UciA+5vhHGfoXJP3aHL6ilyZv5jc96A4gx297B JEmk2c/JXij31/LVmwzaBI1UGZ21BlBbuc4C80jIA33yGkRRLfBRKt+E+PIERBRR0ET21FaOwKWn VSjUJ/LhZKMwnm94c9zB5zmd34Qajpg7sO87qi0gftxi47JtB3MwuI1eMrLUWguuUHAHOdI60FFR mZtVLWrU1dtbANXd0npCLHh9SNURu1eh2xQr4hpKXDsMgoEPjkL1OXtbMHi4Es6GIXCm8pMZgmCC TWdfFp5D/0YKviVcB7XO+JkoYOnmharaJI9W3Mw0WoYNK3XxChAD4o5kXNNTgu9sEfYkOu7FHXdV MBiueDjy/b1tJ+eItvD/YChvfb+1uVc8dHgY+Jyd7lDBR8RQi6fv3Iug1/q+tpVaPbZbKLhtO9+S mSSNTg17U+oZbCqvbvWIBQuIv7F24XCjYtEiY0Ls/ozjj79p7B4WT9Dgn78VJIr9lCvINb6ge7wg Js6TfysIDcd85OLSjBpwgYJm8qfCbmUdRt8HH9H8DMRPTJwHOPAFUd21VWe//iAzsU3UTFfr6iIo L65BqLmTXdbBK/4Bip74wcfwEyGck0Y6TI48K3CA7OKssqRqfSk2zdc3b1u6uU/64yHxhymtNEim 5CmpBzZKhx6ki7RouY9f3eQsrwRloKKwKv+o9ZytFVCPrl756mP5QFi/OPyY1gc6qY5WX0/LUVt6 s6jJUJ1Rf/C3VosNn/es1/pBOWe90Qz/pL08B8RRY+X/a6dt9uA2C6j/qc8mlFjquT5bNN5ndysN O2JEQaONxo7RkHE7hiPwdb/RfNgrRE9o/v28eht4j3qZ3KNJ2xQhaxxIEh28mH4fwEAKKq5CP/jc SWzMg6IBhUf1fxtzHDbmuehVqPwZ8rw918RQgLtsdc3dCgr7iPVj+Msgb4RL9jLm/GtwFc2PXBJ/ YEs0pRtB98gtA/E3b/S+/3mfiK42KLLM6SBUa2voFcPz35BBsG1cNnfh4uBBuBh7P9bOYyjntINB G7RX2jFo49rJzZHaMBI5XjKxzFoHeijBjxvZ/xQeSkyUHehIGhzs7BgcUHUd4hovxuTFNqM7uBLy oAMGzBAsY42sVghTUsjc1JycTJyjrSStAo81rthkp2ImmrVsNQp+cyQCBuwU30h+KPOmgpjQd/cd WL1jr++0QqTrNndkfkRpEDjGd/oqKl2gAlQXNOeeyezOHcB8DPvhrzD4rvTu1nYxmnd7RW+aD5wK vdLf8+FQv1F5XNSZ6NK4t3D0MF9Xe1iRN/j0r5OYET6xCAfqvaXXy6+U43HgYDG2hQEKjiEpQ57J r7GCQxQ6jvtyUlK6TTszzuQ+K4ZfoyiG7MupsHOTWxn55pmYL0a6XGcui8bdbzTAzYM0fNsPOuEU IXjHZlvCjUijPvItp60K/IVivSSclj8ibUAB1DF+IZT6j33HL0BS/2P8BhgwchJOL8VnDZ2YuB5z H/J/IgR7M8zjo9bPPnJNmbEOjFAsFu1Ik+tOCR4SfqbJW3lNJuyt4yIYpby8U5gQbBVXyCQ9v7qw 6nDJYW9BdS6wAHt2hs2GXkAvhLDr0XaG7CyoywSKcWnITRlJBRNVji3Pc4JhCvJJj/db9GIDXW4F OaHAanZoD+MIi5e0gbwSew3aDZtCfvh7y5GrmI2jSrObDcfDfQy38UyG351fnQP0wGpRqlea5Dnp VlV2X0FN+h3DzdxWUAlcVWU9JZQXWRjyRH7R4cbNTmNIOFrDXLM35Tbm1YVqP7K1g1ocVtFaisNo hmzJK3Uc3QzDxqaGePnweXj1J3TV38OHi9k5ru6Kipay0HFOcwic5SQRx+l/J8PvKnBlAOV4kspM g+pZkklFWY2gl+JmTnzudjwnzsU+L0Kz4WzcQ9iUa8Ls7IKCgsN5INScW+kSwzryyzXnUBDyX7Nn bZyX7utt9XbWOWqtLpG9qsAJnFRTq6tLJHh8uUUXKV5HooCEfQYlfSglXYWZFDl84Nqlk+4zF0TV e5qNp8EAaHP19GEhoZhLQp3aYGUAlZJ+tPdyf/+nTVhIBcDNLnfzWKNXmFWWW5pbjcKgMeRHGNzo cVe3lYV60UqGrDxccbgEeA5XOIAJmLIztckOh8loSneU5zsLSpP7UwcwgDV1zo4iavx+05LvzHOn wBfQ3hCNUpdkN+96x5CpLMR4rMImV2wuB/WgvqW/52RxSXlFeWWjpoF22j1JVUZg5Yqv5iIdeFq6 8+u15sKEmCYEdRrG/zoQOqqtv3qHbaLv5nLeYeO8gzNcp6uxtooSfOZqaihvmHmiXr993HLjbBZl wQTBEkuxO08El3HBzQ04ElA99UzUeKjMZlVwoXZ8Cyq21XDCnbgF7VTot8aIUq4meiNABJDqFNvH 1d/OzjnPNQfuxEu5m0UCR47dXHPAPhdPjT2tIT+5eDLueNYZEApDHz+F86Fo9RPkt1+ZKVeKd05u GHC7OgB1pW0Tnk1FKVu2ynRtp/D1yGRys5vdcLeb94uK++QWmn++oD4bqIGl0JRnRpPRkxBEwL9l t+fXg8pQ4K2vHCwpxv3NWYTFe50m+wrd9mqma0EImor+hAJZIs9VWMFFHqupHOEu1sM02e+osjfs g4lj34e08mEkmwrXjKXiCxOMZb+v7fU0dZRg6pfghgDXQAp3pHw/2Mt1o3xEwXw+fm6Bq/CVahUP j4KvC6UK+YH9x5XDp3q6Tw4rTsSK4c3JUoXiwL7jylPDPT34WU8snlKxjY/+Bza0C6Phwjf4yPbP ff5f8YMMblbmhjFufsdUKAno6AgMhBJP4HME8V9Ssx2JCmVuZHN0cmVhbQplbmRvYmoKNDcgMCBv YmoKNDI2MQplbmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9X SFhSTUMrVGltZXMtQm9sZEl0YWxpYy9Gb250QkJveFstMjAwIC0zMjQgOTk2IDk2NF0vRmxhZ3Mg OTgKL0FzY2VudCA5NjQKL0NhcEhlaWdodCA2ODUKL0Rlc2NlbnQgLTMyNAovSXRhbGljQW5nbGUg LTE3Ci9TdGVtViAxNDgKL01pc3NpbmdXaWR0aCAyNTAKL1hIZWlnaHQgNDYyCi9DaGFyU2V0KC9z cGFjZS9jb21tYS96ZXJvL3R3by9maXZlL3NpeC9NL1MvYS9iL2UvbS9wL3IvdC95KQovRm9udEZp bGUzIDEyIDAgUj4+CmVuZG9iagoxMiAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDQ4IDAgUj4+c3RyZWFtCnicnVR5UBRXGu9mnKE9wANHGI3Tve4aNShR V+ORwyQaEQREBUUEcY4GGmamh+kemOGY4Rgd2CcKAwgM4oByn8qIpahoolEjaIzlkXhsrdm4Mdna 1dJNvcZn1W6jWzFV+99WV1e97t973+/7/b7vezg2xgfDcTxo67q4TZGrg2MYPc0t+JTVacN4lY7R jGLBwgxceMtHmClBCejbF5YXcdKZWET9eD9BOQGrf2tszZSR308e8ZkoPJ30Olop3o2fxf89N3bT 1nnBwfNXs0ariUlJ5alFK1asoNRW6r8ItYbmmBQD9ba4yKR1rFFPG/gQajNNU3wqTSUzOppavSF6 W1hUKDU3NCqWCqUNtEmlo6LNajE3KoLR0AaOnkclsyZK9/qD0rAGLcMzrIELoT7hKBXFGWkNIx6i LRraOArMp4y0Sc9wnLimGI5KMakMPK2leJZiDBqdWTtKL/5PZg08ZTSxIq4XETFUNMvxnMbEGHlK ZIxes/Z1jnyqih/l5RgRpthkcaeW1ZhH1fyK8SrGwFE8beFHedQ0pWU4o05lFXnFUEYT8yoFM8cY Ut6wz6dMdIrKpNXR3Ku4o6680Uf9RrXKaNRZX51lX+36lZ/hOVqXHBLF6NVmjtrE6lUGKopdQUVQ kbSWMeup13X+X/xN1f6/OmIYNskaKTrNb1bp1Uvfo+YvXIxh8VgIthFbi23GYrEl2KdYFLYam4YF Yjjmh03GArDJYv9gY7BifCxe7yPx2e5zUrJBcndMl3SW1C59Jv1FRsqcsr/Cvf5CNFJ5Rnw9uLBy SFIrvCuvB2V/cjkPFNSp3Wu60JID7wAd4As5qymTNWZmAwewuIpc2dWmSisgMrgMQ1qLseeLYe/V L0g4Df4RjocF4CnRbWhP04tWci77YauyPq+8CNiA3qpaixT220FmOC4DjrEObLen7ArfRfi/8LN7 RuQe/MW8kUVylCpDV17ysQIvRRkm2ZXiSidggc2Z5TAh/OXYIA2a5siPtRMmqGnyXV+RUw2Ogbry 1ppTTwVp0LWX56WtMmG88A2a/FKbE2vJC3cqTHC4yXfj3rwK0AmqSmvLG/aUBe0pgxOFWPdZd+1g ucJfKEaqFriiR1juwQ8JwfITJSKpBRQWamzxc14GBeVE2W1qQOwywtIWWfyenApwGFRXdNV/vbdq 7/5S196aoB5rtbMBEHAGnAXD4Ce3VANhm5LSl0eTR6Hv7Bztrq27FLB6p7y5xM2XpDvD0+ekhOti 09g0QJiz6zx1Fe0tfyMPP6hqrTvc1NfV1FxCiIWxDQn+XTgQbV31owR+A2fJE9ayZhUgdppbP68r rdnnIZ97TjeeOdnTefAo6CEGk3qj0B/EZxlasWwo4vs7n/f985ISxf8g74XKk9+eAsTBSrt51fbw jwykoyR3d75TZFEAj7DSg7e8UW1i0NRQZCWgn8x9svb4PnfnU/fRtlPNJxqbasA+UOZ0Fbqza4rq ANHd1NHv5ZuZOHUcWvwBeRXSG3ItxcivQOEPOwo9AtU/BUD/lXBfYMB12C3EylfL+uBsaaosduU2 9Qd6InXQNxQVSgP+khdXsCN7urY1o/+St+vZVaW5ltmSYcwBiqKiCld9/c1e6E+WHdjvPXCZCLj+ Z5m/cM7aPeLfgz+BfnAS9JOUWuXtsuo2V/lBUAVqig8Vnc7udnjFclA/3IWTHiZeQ/6PyciB3EZw ghjyHhu61xePxtYoW5xemCjVywqteUWZoBBk7zO5dtYay1hAINmSZcjHWGauyCYbVceSzid9t6En ASQCs4Ozm3ltqiUebAWJTaZ+S0dRu/OSoTRI7KI8j+WGMNUjqp4odoI0MMAirIUBcnVMbm4OIBy7 yyubqvoP3ydvwHwkcVijCwfNDTuBAk1E76AYtHDV8bjhyyeP/HyBzNcW54E8IqAmud1wZGCg7/sL yoA4tBFeljeWuK3ACKIZJKVDjdvFIRPH0HKo42zXk2O3yPZzXR0tYvOMHBTt9785BT6H47xwQjr0 Cwx43C3WuELWWVskymWM88l1ovdikc/BTUcfnr/W2NTWUAOIqsoCW65dlTabzN5qU6UiKQEnyC7C mPL63iv9t7z97YCo3l+Qv6s432kjd6BAacB1c0ReJDtdfdh8/Ctv1z++VJprdhftdpQUK/iUTLMN EIUOl2s/AA3XyBNQIQ147D5ecbR5ujetIyk0UYOClikPnnE1g1ai39SsYvX5PKtMZvV0+JwhuD1o fW5mMfItFBu12NYljPsaH7U2GU6W3BmZJj9d6+Btti0ZC8kF6F5hen4S2K1gb6YPw2VwEfwYht5M HAyLS+HWxSkfwfuf2eIdiwsUcDtqlbe5+cRoY0hKJMls0Op2AsJqq3ZX1j+o6CT39x264u5pvtDZ 3gVesXqFdojj8Ma/JHCbcEEOXbJeiEtRrwwFojNXizsdR7MUX+l6N4L1xHvrP/os017ZnankvNk1 ekAwJi4t4Wz6XbgcToW+cO53zHCkl2QOGSvfPTgaPLdTwL2wwCOqGgMj4CSJAEbel6PpGetNK6PR lAUfIxKg3xEocPgDiMOZ4jsOzv1l03BIlr24QK+8DP0e3IIzBgm0HzXLBxoyEyNT0fS0CNLG8bkm QCRbm86da3jU9YBsOFdZ2SnqES98uDcBhcuh7+Cdh+A+cZHpi1PrdSpjVU57lvJQrqsA5IEUjfZD 1Wh+eW0jAW04eCaB90ZWyWNATMaOxJDgSLQUoLkEUgwt+Xu/t7atT/nk9l0YBuAiAr4d/fNCZYlB 3lFv3GFxphclk9lL41EMvy4t2ECLV6g+q9k7dB7aB+A08sjzVu+RVyYDKBEyH+HwRzhdIiyDm+Um GR3G530ozuE8GYyD7/9078wDcFvx0+pbIVsSsjRJSkNGDsfGNtqDvBePtZwFxJc96rULoxaiaLSB 1Ov0er2B4ASJr3+WR4j1wASPrGUcnDC+pXzCBAz7D7q3XTsKZW5kc3RyZWFtCmVuZG9iago0OCAw IG9iagoyMjI3CmVuZG9iagozNCAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1JDQVJN QytTeW1ib2wvVHlwZS9Gb250L05hbWUvUjM0L0ZvbnREZXNjcmlwdG9yIDMzIDAgUi9GaXJzdENo YXIgMzIvTGFzdENoYXIgMjU0L1dpZHRoc1sKMjUwIDMzMyA3MTMgNTAwIDU0OSA4MzMgNzc4IDQz OSAzMzMgMzMzIDUwMCA1NDkgMjUwIDU0OSAyNTAgMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU0OSA1NDkgNTQ5IDQ0NAo1NDkgNzIyIDY2NyA3MjIg NjEyIDYxMSA3NjMgNjAzIDcyMiAzMzMgNjMxIDcyMiA2ODYgODg5IDcyMiA3MjIKNzY4IDc0MSA1 NTYgNTkyIDYxMSA2OTAgNDM5IDc2OCA2NDUgNzk1IDYxMSAzMzMgODYzIDMzMyA2NTggNTAwCjUw MCA2MzEgNTQ5IDU0OSA0OTQgNDM5IDUyMSA0MTEgNjAzIDMyOSA2MDMgNTQ5IDU0OSA1NzYgNTIx IDU0OQo1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3MTMgNjg2IDQ5MyA2ODYgNDk0IDQ4MCAyMDAg NDgwIDU0OSAyNTAKMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwCjI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MAo3NjIgNjIwIDI0NyA1NDkgMTY3IDcxMyA1MDAgNzUz IDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyA5ODcgNjAzCjQwMCA1NDkgNDExIDU0OSA1NDkgNzEz IDQ5NCA0NjAgNTQ5IDU0OSA1NDkgNTQ5IDEwMDAgNjAzIDEwMDAgNjU4CjgyMyA2ODYgNzk1IDk4 NyA3NjggNzY4IDgyMyA3NjggNzY4IDcxMyA3MTMgNzEzIDcxMyA3MTMgNzEzIDcxMwo3NjggNzEz IDc5MCA3OTAgODkwIDgyMyA1NDkgMjUwIDcxMyA2MDMgNjAzIDEwNDIgOTg3IDYwMyA5ODcgNjAz CjQ5NCAzMjkgNzkwIDc5MCA3ODYgNzEzIDM4NCAzODQgMzg0IDM4NCAzODQgMzg0IDQ5NCA0OTQg NDk0IDQ5NAoyNTAgMzI5IDI3NCA2ODYgNjg2IDY4NiAzODQgMzg0IDM4NCAzODQgMzg0IDM4NCA0 OTQgNDk0IDQ5NF0KPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQv V0hYUk1DK1RpbWVzLUJvbGRJdGFsaWMvVHlwZS9Gb250L05hbWUvUjE0L0ZvbnREZXNjcmlwdG9y IDEzIDAgUi9GaXJzdENoYXIgMS9MYXN0Q2hhciAyNTUvV2lkdGhzWyAzMzMgMzMzIDMzMyAyNzgg NTU2IDU1NiAxNjcgMzMzIDYxMSAyNzggNjA2IDMzMyAzMzMgNjExIDM4OQoyNTAgMjUwIDI1MCAy NTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAKMjUwIDM4 OSA1NTUgNTAwIDUwMCA4MzMgNzc4IDI3OCAzMzMgMzMzIDUwMCA1NzAgMjUwIDMzMyAyNTAgMjc4 CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAg NTcwIDUwMAo4MzIgNjY3IDY2NyA2NjcgNzIyIDY2NyA2NjcgNzIyIDc3OCAzODkgNTAwIDY2NyA2 MTEgODg5IDcyMiA3MjIKNjExIDcyMiA2NjcgNTU2IDYxMSA3MjIgNjY3IDg4OSA2NjcgNjExIDYx MSAzMzMgMjc4IDMzMyA1NzAgNTAwCjMzMyA1MDAgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTU2 IDI3OCAyNzggNTAwIDI3OCA3NzggNTU2IDUwMAo1MDAgNTAwIDM4OSAzODkgMjc4IDU1NiA0NDQg NjY3IDUwMCA0NDQgMzg5IDM0OCAyMjAgMzQ4IDU3MCAyNTAKNTAwIDI1MCAzMzMgNTAwIDUwMCAx MDAwIDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyA5NDQgMjUwIDI1MCAyNTAKMjUwIDMzMyAzMzMg NTAwIDUwMCAzNTAgNTAwIDEwMDAgMzMzIDEwMDAgMzg5IDMzMyA3MjIgMjUwIDI1MCA2MTEKMjUw IDM4OSA1MDAgNTAwIDUwMCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDI2NiA1MDAgNjA2IDI1MCA3NDcg MzMzCjQwMCA1NzAgMzAwIDMwMCAzMzMgNTc2IDUwMCAyNTAgMzMzIDMwMCAzMDAgNTAwIDc1MCA3 NTAgNzUwIDUwMAo2NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyA5NDQgNjY3IDY2NyA2NjcgNjY3IDY2 NyAzODkgMzg5IDM4OSAzODkKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU3MCA3MjIgNzIy IDcyMiA3MjIgNzIyIDYxMSA2MTEgNTAwCjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDcyMiA0NDQg NDQ0IDQ0NCA0NDQgNDQ0IDI3OCAyNzggMjc4IDI3OAo1MDAgNTU2IDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTcwIDUwMCA1NTYgNTU2IDU1NiA1NTYgNDQ0IDUwMCA0NDRdCj4+CmVuZG9iagoyNSAwIG9i ago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L0lHTlNNQytDb3VyaWVyLUJvbGRPYmxpcXVlL1R5 cGUvRm9udC9OYW1lL1IyNS9Gb250RGVzY3JpcHRvciAyNCAwIFIvRmlyc3RDaGFyIDEvTGFzdENo YXIgMjU1L1dpZHRoc1sgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDBdCj4+CmVuZG9iagoyOCAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1NL SlJNQytUaW1lcy1Sb21hbi9UeXBlL0ZvbnQvTmFtZS9SMjgvRm9udERlc2NyaXB0b3IgMjcgMCBS L0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDI1NS9XaWR0aHNbIDMzMyAzMzMgMzMzIDI3OCA1NTYgNTU2 IDE2NyAzMzMgNjExIDI3OCA1NjQgMzMzIDMzMyA2MTEgNDQ0CjI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MAoyNTAgMzMzIDQwOCA1 MDAgNTAwIDgzMyA3NzggMTgwIDMzMyAzMzMgNTAwIDU2NCAyNTAgMzMzIDI1MCAyNzgKNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0 CjkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkg NzIyIDcyMgo1NTYgNzIyIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3MjIgNjExIDMzMyAy NzggMzMzIDQ2OSA1MDAKMzMzIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3 OCA1MDAgMjc4IDc3OCA1MDAgNTAwCjUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAw IDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDI1MAo1MDAgMjUwIDMzMyA1MDAgNDQ0IDEwMDAgNTAw IDUwMCAzMzMgMTAwMCA1NTYgMzMzIDg4OSAyNTAgMjUwIDI1MAoyNTAgMzMzIDMzMyA0NDQgNDQ0 IDM1MCA1MDAgMTAwMCAzMzMgOTgwIDM4OSAzMzMgNzIyIDI1MCAyNTAgNzIyCjI1MCAzMzMgNTAw IDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2MCAyNzYgNTAwIDU2NCAyNTAgNzYwIDMzMwo0MDAg NTY0IDMwMCAzMDAgMzMzIDUwMCA0NTMgMjUwIDMzMyAzMDAgMzEwIDUwMCA3NTAgNzUwIDc1MCA0 NDQKNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgODg5IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMz MyAzMzMgMzMzCjcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NjQgNzIyIDcyMiA3MjIgNzIy IDcyMiA3MjIgNTU2IDUwMAo0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA2NjcgNDQ0IDQ0NCA0NDQg NDQ0IDQ0NCAyNzggMjc4IDI3OCAyNzgKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU2NCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwXQo+PgplbmRvYmoKMTkgMCBvYmoKPDwvU3Vi dHlwZS9UeXBlMS9CYXNlRm9udC9KS0NTTUMrVGltZXMtQm9sZC9UeXBlL0ZvbnQvTmFtZS9SMTkv Rm9udERlc2NyaXB0b3IgMTggMCBSL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDI1NS9XaWR0aHNbIDMz MyAzMzMgMzMzIDI3OCA1NTYgNTU2IDE2NyAzMzMgNjY3IDI3OCA1NzAgMzMzIDMzMyA2NjcgNDQ0 CjI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MAoyNTAgMzMzIDU1NSA1MDAgNTAwIDEwMDAgODMzIDI3OCAzMzMgMzMzIDUwMCA1NzAg MjUwIDMzMyAyNTAgMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAz MzMgMzMzIDU3MCA1NzAgNTcwIDUwMAo5MzAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDc3 OCAzODkgNTAwIDc3OCA2NjcgOTQ0IDcyMiA3NzgKNjExIDc3OCA3MjIgNTU2IDY2NyA3MjIgNzIy IDEwMDAgNzIyIDcyMiA2NjcgMzMzIDI3OCAzMzMgNTgxIDUwMAozMzMgNTAwIDU1NiA0NDQgNTU2 IDQ0NCAzMzMgNTAwIDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAKNTU2IDU1NiA0NDQg Mzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NCAzOTQgMjIwIDM5NCA1MjAgMjUwCjUwMCAy NTAgMzMzIDUwMCA1MDAgMTAwMCA1MDAgNTAwIDMzMyAxMDAwIDU1NiAzMzMgMTAwMCAyNTAgMjUw IDI1MAoyNTAgMzMzIDMzMyA1MDAgNTAwIDM1MCA1MDAgMTAwMCAzMzMgMTAwMCAzODkgMzMzIDcy MiAyNTAgMjUwIDcyMgoyNTAgMzMzIDUwMCA1MDAgNTAwIDUwMCAyMjAgNTAwIDMzMyA3NDcgMzAw IDUwMCA1NzAgMjUwIDc0NyAzMzMKNDAwIDU3MCAzMDAgMzAwIDMzMyA1NTYgNTQwIDI1MCAzMzMg MzAwIDMzMCA1MDAgNzUwIDc1MCA3NTAgNTAwCjcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAg NzIyIDY2NyA2NjcgNjY3IDY2NyAzODkgMzg5IDM4OSAzODkKNzIyIDcyMiA3NzggNzc4IDc3OCA3 NzggNzc4IDU3MCA3NzggNzIyIDcyMiA3MjIgNzIyIDcyMiA2MTEgNTU2CjUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDcyMiA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDI3OCAyNzggMjc4IDI3OAo1MDAgNTU2 IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTcwIDUwMCA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDBd Cj4+CmVuZG9iagozMSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L0pKQlNNQytUaW1l cy1JdGFsaWMvVHlwZS9Gb250L05hbWUvUjMxL0ZvbnREZXNjcmlwdG9yIDMwIDAgUi9GaXJzdENo YXIgMS9MYXN0Q2hhciAyNTUvV2lkdGhzWyAzMzMgMzMzIDMzMyAyNzggNTAwIDUwMCAxNjcgMzMz IDU1NiAyNzggNjc1IDMzMyAzMzMgNTU2IDM4OQoyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAKMjUwIDMzMyA0MjAgNTAwIDUwMCA4 MzMgNzc4IDIxNCAzMzMgMzMzIDUwMCA2NzUgMjUwIDMzMyAyNTAgMjc4CjUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDY3NSA2NzUgNjc1IDUwMAo5MjAgNjEx IDYxMSA2NjcgNzIyIDYxMSA2MTEgNzIyIDcyMiAzMzMgNDQ0IDY2NyA1NTYgODMzIDY2NyA3MjIK NjExIDcyMiA2MTEgNTAwIDU1NiA3MjIgNjExIDgzMyA2MTEgNTU2IDU1NiAzODkgMjc4IDM4OSA0 MjIgNTAwCjMzMyA1MDAgNTAwIDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzggNDQ0IDI3 OCA3MjIgNTAwIDUwMAo1MDAgNTAwIDM4OSAzODkgMjc4IDUwMCA0NDQgNjY3IDQ0NCA0NDQgMzg5 IDQwMCAyNzUgNDAwIDU0MSAyNTAKNTAwIDI1MCAzMzMgNTAwIDU1NiA4ODkgNTAwIDUwMCAzMzMg MTAwMCA1MDAgMzMzIDk0NCAyNTAgMjUwIDI1MAoyNTAgMzMzIDMzMyA1NTYgNTU2IDM1MCA1MDAg ODg5IDMzMyA5ODAgMzg5IDMzMyA2NjcgMjUwIDI1MCA1NTYKMjUwIDM4OSA1MDAgNTAwIDUwMCA1 MDAgMjc1IDUwMCAzMzMgNzYwIDI3NiA1MDAgNjc1IDI1MCA3NjAgMzMzCjQwMCA2NzUgMzAwIDMw MCAzMzMgNTAwIDUyMyAyNTAgMzMzIDMwMCAzMTAgNTAwIDc1MCA3NTAgNzUwIDUwMAo2MTEgNjEx IDYxMSA2MTEgNjExIDYxMSA4ODkgNjY3IDYxMSA2MTEgNjExIDYxMSAzMzMgMzMzIDMzMyAzMzMK NzIyIDY2NyA3MjIgNzIyIDcyMiA3MjIgNzIyIDY3NSA3MjIgNzIyIDcyMiA3MjIgNzIyIDU1NiA2 MTEgNTAwCjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDY2NyA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDI3 OCAyNzggMjc4IDI3OAo1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNjc1IDUwMCA1MDAgNTAw IDUwMCA1MDAgNDQ0IDUwMCA0NDRdCj4+CmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdOVSBH aG9zdHNjcmlwdCA3LjA2KQovVGl0bGUoTWljcm9zb2Z0IFdvcmQgLSBDT01TV0FSRSAyMDA2IC0g Q0ZQLmRvYykKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yKQovQ3JlYXRpb25EYXRl KDQvNS8yMDA1IDE4OjQ2OjI4KQovQXV0aG9yKHRoeWFnYSk+PmVuZG9iagp4cmVmCjAgNDkKMDAw MDAwMDAwMCA2NTUzNSBmIAowMDAwMDExOTk4IDAwMDAwIG4gCjAwMDAxMTc5NjUgMDAwMDAgbiAK MDAwMDAxMTkzMCAwMDAwMCBuIAowMDAwMDExNzE5IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAg biAKMDAwMDAxMTY5OCAwMDAwMCBuIAowMDAwMDg2NjU0IDAwMDAwIG4gCjAwMDAwODY1MDYgMDAw MDAgbiAKMDAwMDAxMjA0NiAwMDAwMCBuIAowMDAwMDEzNzM3IDAwMDAwIG4gCjAwMDAwMTIxMzQg MDAwMDAgbiAKMDAwMDEwODc3NiAwMDAwMCBuIAowMDAwMTA4NDg2IDAwMDAwIG4gCjAwMDAxMTIx NDEgMDAwMDAgbiAKMDAwMDA2MzI4MCAwMDAwMCBuIAowMDAwMDYxNjc3IDAwMDAwIG4gCjAwMDAx MDQxMTggMDAwMDAgbiAKMDAwMDEwMzc4OCAwMDAwMCBuIAowMDAwMTE1NjM4IDAwMDAwIG4gCjAw MDAwNjYzNzkgMDAwMDAgbiAKMDAwMDA2NDc3NiAwMDAwMCBuIAowMDAwMDcyOTI5IDAwMDAwIG4g CjAwMDAxMDE1NzkgMDAwMDAgbiAKMDAwMDEwMTI4OCAwMDAwMCBuIAowMDAwMTEzMzA5IDAwMDAw IG4gCjAwMDAwOTUyNzAgMDAwMDAgbiAKMDAwMDA5NDg5MCAwMDAwMCBuIAowMDAwMTE0NDc2IDAw MDAwIG4gCjAwMDAwODc5NzMgMDAwMDAgbiAKMDAwMDA4NzU3NSAwMDAwMCBuIAowMDAwMTE2ODA0 IDAwMDAwIG4gCjAwMDAwODcwMzIgMDAwMDAgbiAKMDAwMDA4NjgwMSAwMDAwMCBuIAowMDAwMTEx MTEwIDAwMDAwIG4gCjAwMDAwNzg4NjMgMDAwMDAgbiAKMDAwMDA3OTAwMyAwMDAwMCBuIAowMDAw MDgwNjA2IDAwMDAwIG4gCjAwMDAwODA3NDYgMDAwMDAgbiAKMDAwMDA4NjIyNiAwMDAwMCBuIAow MDAwMDg2MzEzIDAwMDAwIG4gCjAwMDAwODYzNDMgMDAwMDAgbiAKMDAwMDA4NjQxOSAwMDAwMCBu IAowMDAwMDg3NTU1IDAwMDAwIG4gCjAwMDAwOTQ4NjkgMDAwMDAgbiAKMDAwMDEwMTI2NyAwMDAw MCBuIAowMDAwMTAzNzY3IDAwMDAwIG4gCjAwMDAxMDg0NjUgMDAwMDAgbiAKMDAwMDExMTA4OSAw MDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDQ5IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCj4+CnN0 YXJ0eHJlZgoxMTgxNDgKJSVFT0YK ------=_NextPart_000_000F_01C53A24.B3DF80D0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------=_NextPart_000_000F_01C53A24.B3DF80D0-- From mip6-bounces@ietf.org Wed Apr 6 08:23:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05521 for ; Wed, 6 Apr 2005 08:23:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9hj-0005Wv-D7 for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:32:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9Y9-0003hk-Hq; Wed, 06 Apr 2005 08:22:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9Y7-0003hW-EM for mip6@megatron.ietf.org; Wed, 06 Apr 2005 08:22:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05418 for ; Wed, 6 Apr 2005 08:22:22 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9gS-0005Us-D6 for mip6@ietf.org; Wed, 06 Apr 2005 08:31:01 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j36CJUJ16846; Wed, 6 Apr 2005 15:19:31 +0300 Date: Wed, 6 Apr 2005 15:19:30 +0300 (EEST) From: Pekka Savola To: Alexandru Petrescu Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] In-Reply-To: <4253D039.8020004@motorola.com> Message-ID: References: <4253D039.8020004@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: H.Soliman@flarion.com, mip6@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Wed, 6 Apr 2005, Alexandru Petrescu wrote: > Vijay.Devarapalli@nokia.com wrote: >> draft-wakikawa specifies one mechanism to detect NATs based on IKEv2. > > Vijay, I'm not sure NATs need to be detected. I'm not sure it's necessary to > impose the use of IKEv2 in order to detect being behind a NAT. > > Being behind a NAT or not can be detected very simply by the GW by checking > the src address and some address that MN puts in the payload. That assumes that you have a separate signalling plane (e.g., MIPv6 binding updates) apart from the data plane. You also lose at least 1 RTT for signalling. However, if the client knows in advance which encapsulation type to use, it can just send in a request, piggybacking the data, and if the tunnel is set up, the tunnel server can immediate forward the data and set up the tunnel, otherwise reject setting up the tunnel and discard the data. One 1.5 RTT's vs 0.5 RTT to forward user's packets and some amount of protocol complexity may not be an issue, of course. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 08:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07226 for ; Wed, 6 Apr 2005 08:43:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJA0v-0006MK-Vg for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 08:52:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9nm-0000rv-GM; Wed, 06 Apr 2005 08:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9nk-0000rp-Eq for mip6@megatron.ietf.org; Wed, 06 Apr 2005 08:38:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06735 for ; Wed, 6 Apr 2005 08:38:30 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9w5-00067V-8L for mip6@ietf.org; Wed, 06 Apr 2005 08:47:10 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36Cel24012636; Wed, 6 Apr 2005 05:40:47 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j36CeWJ8009575; Wed, 6 Apr 2005 07:40:32 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D0E35865980; Wed, 6 Apr 2005 14:38:23 +0200 (CEST) Message-ID: <4253D83F.9030805@motorola.com> Date: Wed, 06 Apr 2005 14:38:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] References: <4253D039.8020004@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, mip6@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> Being behind a NAT or not can be detected very simply by the GW by >> checking the src address and some address that MN puts in the >> payload. > > That assumes that you have a separate signalling plane (e.g., MIPv6 > binding updates) apart from the data plane. Yes, a separate signalling plane. > You also lose at least 1 RTT for signalling. Yes, but it's impossible to just send an enhanced BU to HA without first setting up some state on GW and MN about the v4/NAT traversal. The state on MN, NAT and GW must be synchronized somehow and doing it with only one message MN->NAT->GW is impossible, I mean some acknowledgement is necessary. > However, if the client knows in advance which encapsulation type to > use, it can just send in a request, piggybacking the data, and if the > tunnel is set up, the tunnel server can immediate forward the data > and set up the tunnel, otherwise reject setting up the tunnel and > discard the data. To this scenario I object with the security aspects. If the tunnel server puts up a tunnel whenever a Client requests it, and if they don't share a secret, DoS attacks are obviously possible. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 09:23:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10209 for ; Wed, 6 Apr 2005 09:23:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAdV-0007O0-Ol for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 09:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAMO-0006YU-CN; Wed, 06 Apr 2005 09:14:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAML-0006YO-Vw for mip6@megatron.ietf.org; Wed, 06 Apr 2005 09:14:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09496 for ; Wed, 6 Apr 2005 09:14:16 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAUg-00078p-SH for mip6@ietf.org; Wed, 06 Apr 2005 09:22:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j36DE3718321; Wed, 6 Apr 2005 16:14:03 +0300 Date: Wed, 6 Apr 2005 16:14:03 +0300 (EEST) From: Pekka Savola To: Alexandru Petrescu Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] In-Reply-To: <4253D83F.9030805@motorola.com> Message-ID: References: <4253D039.8020004@motorola.com> <4253D83F.9030805@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: H.Soliman@flarion.com, mip6@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On Wed, 6 Apr 2005, Alexandru Petrescu wrote: >> You also lose at least 1 RTT for signalling. > > Yes, but it's impossible to just send an enhanced BU to HA without first > setting up some state on GW and MN about the v4/NAT traversal. The state on > MN, NAT and GW must be synchronized somehow and doing it with only one > message MN->NAT->GW is impossible, I mean some acknowledgement is necessary. I'm not sure what you mean. MN can send a message directly to the HA (or tunnel server, if applicable), going through the NAT; this also (implicitly) punches a hole in the NAT. The HA (or tunnel server) naturally acknowledges the set up of the tunnel, but if the acknowledgement comes from the same UDP port (etc.), it will use the already established NAT state. >> However, if the client knows in advance which encapsulation type to >> use, it can just send in a request, piggybacking the data, and if the >> tunnel is set up, the tunnel server can immediate forward the data >> and set up the tunnel, otherwise reject setting up the tunnel and >> discard the data. > > To this scenario I object with the security aspects. If the tunnel server > puts up a tunnel whenever a Client requests it, and if they don't share a > secret, DoS attacks are obviously possible. Obviously the client can include whichever secret it wants. Too bad 0.5 RTT doesn't allow a challenge-response negotiation, so it's effectively a shared, plain-text secret. There are other options, though. See draft-parent-v6tc-protocol-exploration-00 section 2.1.2 for an example how SEND could be used in this context securely without any extra roundtrips. But this discussion is probably going to too much detail at this point, so I guess we should take the followups off-list(s). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 10:03:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13698 for ; Wed, 6 Apr 2005 10:03:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBG3-0008Oj-Ee for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 10:11:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJB5N-0005ZD-2K; Wed, 06 Apr 2005 10:00:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJB5L-0005Z7-0n for mip6@megatron.ietf.org; Wed, 06 Apr 2005 10:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13514 for ; Wed, 6 Apr 2005 10:00:44 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBDh-0008LB-FZ for mip6@ietf.org; Wed, 06 Apr 2005 10:09:25 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36E3624021643; Wed, 6 Apr 2005 07:03:06 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j36E2cZM002048; Wed, 6 Apr 2005 09:02:38 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D8887865980; Wed, 6 Apr 2005 16:00:42 +0200 (CEST) Message-ID: <4253EB8A.8080901@motorola.com> Date: Wed, 06 Apr 2005 16:00:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] References: <4253D039.8020004@motorola.com> <4253D83F.9030805@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, mip6@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> Yes, but it's impossible to just send an enhanced BU to HA without >> first setting up some state on GW and MN about the v4/NAT traversal. >> The state on MN, NAT and GW must be synchronized somehow and doing it >> with only one message MN->NAT->GW is impossible, I mean some >> acknowledgement is necessary. > > I'm not sure what you mean. MN can send a message directly to the HA > (or tunnel server, if applicable), going through the NAT; this also > (implicitly) punches a hole in the NAT. The HA (or tunnel server) > naturally acknowledges the set up of the tunnel, but if the > acknowledgement comes from the same UDP port (etc.), it will use the > already established NAT state. YEs... somehow... "Punching" a hole in the NAT boxes may not be immediately successful, several probes may be necessary, in which case the successful probe's characteristics should be acknowledged back to the MN in order for it to know what to use starting then. >>> However, if the client knows in advance which encapsulation type to >>> use, it can just send in a request, piggybacking the data, and if the >>> tunnel is set up, the tunnel server can immediate forward the data >>> and set up the tunnel, otherwise reject setting up the tunnel and >>> discard the data. >> >> >> To this scenario I object with the security aspects. If the tunnel >> server puts up a tunnel whenever a Client requests it, and if they >> don't share a secret, DoS attacks are obviously possible. > > > Obviously the client can include whichever secret it wants. Too bad 0.5 > RTT doesn't allow a challenge-response negotiation, so it's effectively > a shared, plain-text secret. > > There are other options, though. See > draft-parent-v6tc-protocol-exploration-00 section 2.1.2 for an example > how SEND could be used in this context securely without any extra > roundtrips. > > But this discussion is probably going to too much detail at this point, > so I guess we should take the followups off-list(s). Ok, let me stop here, thanks for the reply. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 13:28:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08291 for ; Wed, 6 Apr 2005 13:28:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJESS-0007EI-DJ for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 13:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEIe-00041j-FG; Wed, 06 Apr 2005 13:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEIc-0003zR-SW for mip6@megatron.ietf.org; Wed, 06 Apr 2005 13:26:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08072 for ; Wed, 6 Apr 2005 13:26:39 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJER1-0007AF-37 for mip6@ietf.org; Wed, 06 Apr 2005 13:35:23 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HQcP09423; Wed, 6 Apr 2005 20:26:38 +0300 (EET DST) X-Scanned: Wed, 6 Apr 2005 20:26:07 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j36HQ7HS018424; Wed, 6 Apr 2005 20:26:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00SDMyzg; Wed, 06 Apr 2005 20:26:05 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HQ3M22056; Wed, 6 Apr 2005 20:26:03 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 12:25:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-soliman and draft-wakikawa Date: Wed, 6 Apr 2005 10:25:05 -0700 Message-ID: Thread-Topic: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU6oFOmVp+/rVUyToKSf0a4Ve/rmQALDkMQ To: X-OriginalArrivalTime: 06 Apr 2005 17:25:06.0839 (UTC) FILETIME=[93910A70:01C53ACD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Alex, there are multiple ways of doing this. thats why I havent mentioned how we will fix this. infact, the WG can decide on this. we will get to that later. infact, if UDP encapsulation of IPsec packets is used as described in RFC 3948, (see section 9 of draft-wakikawa), we *don't* need to specifiy anything. RFC 3948 already specifies a NAT keepalive mechanism somebody mentioned dummy ICMP messages. others mentioned sending binding updates now and then. both should work. Vijay > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of > ext Alexandru Petrescu > Sent: Wednesday, April 06, 2005 4:41 AM > To: Vijay Devarapalli > Cc: Soliman, Hesham; mip6@ietf.org > Subject: Re: [Mip6] draft-soliman and draft-wakikawa >=20 >=20 > Vijay Devarapalli wrote: > >> Anything that talks about NAT traveral without keepalives is not > >> useful. > >=20 > > that was an oversight. will fix this. >=20 > Yes, but how? When you say "will fix this" and give no detail or=20 > potential idea about how this could be done, it sounds like=20 > you already=20 > know how to do it and not care very much about the scoping or=20 > requirements (that don't yet exist anyways). I may be wrong with my=20 > interpretation of "will fix this" - sorry - but that's what=20 > it sounds to=20 > me at this second affirmation. >=20 > Alex >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 13:35:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08960 for ; Wed, 6 Apr 2005 13:35:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEZX-0007R2-DS for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 13:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEPe-0008MX-9B; Wed, 06 Apr 2005 13:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEPb-0008MP-9B; Wed, 06 Apr 2005 13:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08855; Wed, 6 Apr 2005 13:33:51 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEXy-0007PC-2H; Wed, 06 Apr 2005 13:42:35 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HXbP20492; Wed, 6 Apr 2005 20:33:39 +0300 (EET DST) X-Scanned: Wed, 6 Apr 2005 20:33:27 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j36HXReP005888; Wed, 6 Apr 2005 20:33:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00DBoiyV; Wed, 06 Apr 2005 20:33:25 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HXNM28271; Wed, 6 Apr 2005 20:33:23 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 12:33:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa Date: Wed, 6 Apr 2005 10:33:07 -0700 Message-ID: Thread-Topic: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa Thread-Index: AcU6oIiWNKEiJSblQFOaXKyk94q8lQALdtUQ To: , X-OriginalArrivalTime: 06 Apr 2005 17:33:08.0946 (UTC) FILETIME=[B2ECBB20:01C53ACE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Alex, I think you misunderstood what Ryuji sent. we do plan to use UDP encapsulation if a NAT is present. nobody is throwing that out.=20 Ryuji was talking about the scenario where a mobile binds a IPv6 CoA to a IPv4 HoA. he saying he is not interested in this scenario. Vijay > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org]On Behalf Of > ext Alexandru Petrescu > Sent: Wednesday, April 06, 2005 4:55 AM > To: Ryuji Wakikawa > Cc: H.Soliman@flarion.com; nemo@ietf.org; vijayd@iprg.nokia.com; > mip6@ietf.org > Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa >=20 >=20 > Ryuji Wakikawa wrote: > > We will design an extension using mobility option to solve=20 > NAT issue=20 > > and throw away MIPv4 support which is not our goal in the draft. >=20 > Ryuji, how are you going to design this extension with a mobility > option? I know of a NAT that blocks all IP-in-IP and as long as the > mobility option is deep below IP it's going to be of no use. >=20 > MIP4 has a nice feature for NAT traversal, that I know implemented.=20 > That feature could be re-used. I don't understand why you=20 > would throw=20 > it away and design a new option in the mobility header? >=20 > Alex >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 13:55:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10529 for ; Wed, 6 Apr 2005 13:55:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEtM-0007vF-JL for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 14:04:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEYu-00039v-5w; Wed, 06 Apr 2005 13:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEYs-00039q-I3 for mip6@megatron.ietf.org; Wed, 06 Apr 2005 13:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09629 for ; Wed, 6 Apr 2005 13:43:27 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEhF-0007bN-2E for mip6@ietf.org; Wed, 06 Apr 2005 13:52:11 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HhGJ04378; Wed, 6 Apr 2005 20:43:17 +0300 (EET DST) X-Scanned: Wed, 6 Apr 2005 20:42:56 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j36Hguhp026776; Wed, 6 Apr 2005 20:42:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00S2jji2; Wed, 06 Apr 2005 20:42:54 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j36HgrM05543; Wed, 6 Apr 2005 20:42:53 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 12:42:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Date: Wed, 6 Apr 2005 10:42:19 -0700 Message-ID: Thread-Topic: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU6oadwGGCGvjSYRwCEIEcHqSdyWgALejJA To: X-OriginalArrivalTime: 06 Apr 2005 17:42:20.0463 (UTC) FILETIME=[FBA78BF0:01C53ACF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > > and in the slides we presented at the IETF, we had a=20 > question for the > > WG, if we need to come up with another NAT detection mechanisn based > > on MIPv6 (similar to what MIPv4 does), but we didnt get any=20 > response. > > if the WG thinks we need one based on MIPv6, I have an idea=20 > on how to > > do it. >=20 > How? let the WG first decide on whether IKEv2 is sufficient for=20 detecting NATs when the MN and the HA run IKEv2 between=20 them. if the WG things we need another MIP specific mechanism we will get to this later. this discussio will only be a distraction now. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 14:00:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10896 for ; Wed, 6 Apr 2005 14:00:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEy5-00082a-9a for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 14:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEol-0000DP-E4; Wed, 06 Apr 2005 13:59:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEok-0000DJ-OF for mip6@megatron.ietf.org; Wed, 06 Apr 2005 13:59:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10814 for ; Wed, 6 Apr 2005 13:59:53 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEx8-00080u-Hy for mip6@ietf.org; Wed, 06 Apr 2005 14:08:35 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36I2E24008687; Wed, 6 Apr 2005 11:02:14 -0700 (MST) Received: from [10.182.142.7] (mvp-10-182-142-7.ea.mot.com [10.182.142.7]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j36I1kr5025021; Wed, 6 Apr 2005 13:01:47 -0500 (CDT) Message-ID: <42542395.5030409@motorola.com> Date: Wed, 06 Apr 2005 19:59:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay.Devarapalli@nokia.com Subject: Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa] References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Vijay.Devarapalli@nokia.com wrote: >>> and in the slides we presented at the IETF, we had a >> >> question for the >> >>> WG, if we need to come up with another NAT detection mechanisn >>> based on MIPv6 (similar to what MIPv4 does), but we didnt get any >>> >> >> response. >> >>> if the WG thinks we need one based on MIPv6, I have an idea >> >> on how to >> >>> do it. >> >> How? > > > let the WG first decide on whether IKEv2 is sufficient for detecting > NATs when the MN and the HA run IKEv2 between them. Right, it's just my oppinion. > if the WG things we need another MIP specific mechanism we will get > to this later. this discussio will only be a distraction now. Ok... Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 14:06:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11363 for ; Wed, 6 Apr 2005 14:06:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJF3Z-0008Bz-5n for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 14:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEqk-0000Yn-Di; Wed, 06 Apr 2005 14:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEqi-0000Ya-M5; Wed, 06 Apr 2005 14:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11011; Wed, 6 Apr 2005 14:01:55 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEz6-00084e-Cb; Wed, 06 Apr 2005 14:10:37 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j36IAVUl004236; Wed, 6 Apr 2005 11:10:31 -0700 (MST) Received: from [10.182.142.7] (mvp-10-182-142-7.ea.mot.com [10.182.142.7]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j36I38ei018204; Wed, 6 Apr 2005 13:03:10 -0500 (CDT) Message-ID: <42542405.4060207@motorola.com> Date: Wed, 06 Apr 2005 20:01:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay.Devarapalli@nokia.com Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, nemo@ietf.org, ryuji@sfc.wide.ad.jp, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Vijay.Devarapalli@nokia.com wrote: > Alex, > > I think you misunderstood what Ryuji sent. we do plan to > use UDP encapsulation if a NAT is present. nobody is > throwing that out. > > Ryuji was talking about the scenario where a mobile binds > a IPv6 CoA to a IPv4 HoA. he saying he is not interested > in this scenario. I agree with that. The scenario me too I'm interested in is traversing the v4. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 14:20:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12693 for ; Wed, 6 Apr 2005 14:20:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFGv-00007A-QG for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 14:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJF0G-0004IV-3Y; Wed, 06 Apr 2005 14:11:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJF0C-0004EG-OF; Wed, 06 Apr 2005 14:11:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11954; Wed, 6 Apr 2005 14:11:43 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJF8b-0008LY-K9; Wed, 06 Apr 2005 14:20:25 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j36IE424014119; Wed, 6 Apr 2005 11:14:04 -0700 (MST) Received: from [10.182.142.7] (mvp-10-182-142-7.ea.mot.com [10.182.142.7]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j36IDYQG026170; Wed, 6 Apr 2005 13:13:35 -0500 (CDT) Message-ID: <4254265A.90802@motorola.com> Date: Wed, 06 Apr 2005 20:11:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay.Devarapalli@nokia.com Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: H.Soliman@flarion.com, nemo@ietf.org, ryuji@sfc.wide.ad.jp, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Vijay.Devarapalli@nokia.com wrote: > Alex, > > I think you misunderstood what Ryuji sent. we do plan to use UDP > encapsulation if a NAT is present. nobody is throwing that out. Sorry to misunderstanding Ryuji. I think v6-in-UDPv4 should be used independently of NAT being used or not used. Whether I misunderstand anybody with this - it's your call. All I want to say is that this aspect (use IPv6-in-UDPv4 independently of NAT/no NAT) should be considered. > Ryuji was talking about the scenario where a mobile binds a IPv6 CoA > to a IPv4 HoA. he saying he is not interested in this scenario. Me too I'm not interested in this particular scenario here and today. But I am interested in MIP4 using UDP for NAT traversal and MIP6 using the same UDP tunnel. And I'll take the remark from Pekka into account here - maybe it's too early to discuss these solution technicalities. In this case let's see about scoping and requirements. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 15:25:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19543 for ; Wed, 6 Apr 2005 15:25:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGHg-000209-Hd for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 15:33:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJG8d-00064O-9C; Wed, 06 Apr 2005 15:24:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJG8c-00062e-8i; Wed, 06 Apr 2005 15:24:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19469; Wed, 6 Apr 2005 15:24:28 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGH0-0001yL-In; Wed, 06 Apr 2005 15:33:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j36Iskw16325; Wed, 6 Apr 2005 11:54:46 -0700 X-mProtect: <200504061854> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdmrPrui; Wed, 06 Apr 2005 11:54:45 PDT Message-ID: <42542942.1000705@iprg.nokia.com> Date: Wed, 06 Apr 2005 11:24:02 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa References: <4254265A.90802@motorola.com> In-Reply-To: <4254265A.90802@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Sorry to misunderstanding Ryuji. I think v6-in-UDPv4 should be used > independently of NAT being used or not used. Whether I misunderstand > anybody with this - it's your call. All I want to say is that this > aspect (use IPv6-in-UDPv4 independently of NAT/no NAT) should be > considered. okay. infact, using UDP all the time is quite popular (even my corporate VPN access uses UDP tunneling all the time). but we shouldnt specify that UDP tunneling should be on all the time in an IETF standard. if a NAT is not there (being optimistic), we dont want the additional per-packet overhead. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 17:40:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07290 for ; Wed, 6 Apr 2005 17:40:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIOW-0007uE-D0 for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 17:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIBr-00078E-La; Wed, 06 Apr 2005 17:35:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIBq-000785-1K for mip6@megatron.ietf.org; Wed, 06 Apr 2005 17:35:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06903 for ; Wed, 6 Apr 2005 17:35:54 -0400 (EDT) Received: from av2-2-sn3.vrr.skanova.net ([81.228.9.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIKE-0007nb-4f for mip6@ietf.org; Wed, 06 Apr 2005 17:44:40 -0400 Received: by av2-2-sn3.vrr.skanova.net (Postfix, from userid 502) id E609037E54; Wed, 6 Apr 2005 23:35:44 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D069337E42 for ; Wed, 6 Apr 2005 23:35:44 +0200 (CEST) Received: from shiraz.levkowetz.com (h70n2fls310o871.telia.com [213.64.173.70]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BF81838007 for ; Wed, 6 Apr 2005 23:35:44 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h70n2fls310o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DJIBb-0005qk-T7 for mip6@ietf.org; Wed, 06 Apr 2005 23:35:44 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Wed, 06 Apr 2005 21:35:39 +0000 MIME-Version: 1.0 Message-Id: <1112823339.8.0.0845662530052.issue19@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h70n2fls310o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue19] MH type selector should not be mandated X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable New submission from Vijay Devarapalli : Francis wrote: I still believe the document goes to the wrong direction, for instance requiring support for MH type selectors when it is expected than the common policy will be to protect all the packets on the MN-HA tunnel (better for privacy, simpler, and easy to implement by BITW). ----------------- the default mode should be the same than in 3776, i.e., MH protocol as the selector. But the two others (all traffic and only the critical MH types) have to be allowed. ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 66 nosy: vijay priority: Must fix status: Pending title: MH type selector should not be mandated _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 18:15:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11275 for ; Wed, 6 Apr 2005 18:15:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIwH-0000J1-4G for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 18:23:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIlx-0006Cb-Pz; Wed, 06 Apr 2005 18:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIlv-0006CV-2N for mip6@megatron.ietf.org; Wed, 06 Apr 2005 18:13:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11016 for ; Wed, 6 Apr 2005 18:13:12 -0400 (EDT) Received: from av7-2-sn1.fre.skanova.net ([81.228.11.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIuL-0000H2-QT for mip6@ietf.org; Wed, 06 Apr 2005 18:21:58 -0400 Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id E0FBE38058; Thu, 7 Apr 2005 00:13:04 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id D107437E4E for ; Thu, 7 Apr 2005 00:13:04 +0200 (CEST) Received: from shiraz.levkowetz.com (h70n2fls310o871.telia.com [213.64.173.70]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id BF82937E43 for ; Thu, 7 Apr 2005 00:13:04 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h70n2fls310o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DJIlj-0001bF-Ez for mip6@ietf.org; Thu, 07 Apr 2005 00:13:04 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Wed, 06 Apr 2005 22:13:02 +0000 MIME-Version: 1.0 Message-Id: <1112825582.21.0.919190476106.issue20@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h70n2fls310o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue20] Add reference to pki4ipsec X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable New submission from Vijay Devarapalli : Francis wrote: Another issue is the total lack of implicit or explicit references to the pki4ipsec work... =3D> IMHO the most of the text is relevant, for instance 3.1.1 o the administrator intends the implementation to verify that the peer source address matches the IP address in the ID received, and that in the iPAddress field in the peer certificate's SubjectAltName extension. .=2E. In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header. If ID is one of the IP address types, then implementations MUST perform this verification by default. If this default is enabled, then a mismatch MUST be treated as an error and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e. local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as today implementations vary greatly in how they behave on the topic of verification of source IP. So in your draft section 5.2 the first option should not be recommended (i.e., it should be used only when the two (and far better) others are not available). ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 68 nosy: vijay priority: Must fix status: Text proposed title: Add reference to pki4ipsec _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 6 18:18:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11683 for ; Wed, 6 Apr 2005 18:18:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIzY-0000Nx-Eg for mip6-web-archive@ietf.org; Wed, 06 Apr 2005 18:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIp0-0006MA-Sz; Wed, 06 Apr 2005 18:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIoz-0006M5-98 for mip6@megatron.ietf.org; Wed, 06 Apr 2005 18:16:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11402 for ; Wed, 6 Apr 2005 18:16:22 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIxQ-0000KX-0R for mip6@ietf.org; Wed, 06 Apr 2005 18:25:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j36LkXS23233; Wed, 6 Apr 2005 14:46:33 -0700 X-mProtect: <200504062146> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdG7VkJS; Wed, 06 Apr 2005 14:46:31 PDT Message-ID: <42545184.2050505@iprg.nokia.com> Date: Wed, 06 Apr 2005 14:15:48 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <200504061026.j36AQb3N099177@givry.rennes.enst-bretagne.fr> In-Reply-To: <200504061026.j36AQb3N099177@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > > Some more detailed comments: > > > > - section 3.2, bullet 3: maybe I am missing something here, but how this > > is different from IKEv1 and rfc 3776? > > > > => there is a wrong lower case should in place of the MUST for using > > the care-of address as the source address of packets. > > the MN cant use anything other than CoA as source address of IKE > exchange. so why is there a need for a MUST? thats the only way > to do it. > > => so we agree the draft should be fixed. hmm... if there is only one way to do it, do we need a 'MUST' to talk about it. if there are multiple ways of doing it and we want interoperability, then we should be using a MUST. anyway, this is what we have currently. o The mobile node should use its Care-of Address as source address in protocol exchanges, when using dynamic keying. However, the security associations MUST be created for the home address of the mobile node. you want it changed to the following? o The mobile node MUST use its Care-of Address as source address in protocol exchanges, when using dynamic keying. However, the security associations MUST be created for the home address of the mobile node. > > > PS: I still believe the document goes to the wrong direction, for instance > > requiring support for MH type selectors when it is expected than the > > common policy will be to protect all the packets on the MN-HA tunnel > > (better for privacy, simpler, and easy to implement by BITW). > > the MN can always negotiate SAs so that all traffic is sent through > the MN-HA tunnel. but I find it wierd not to take advantage of > the additional selectors provided by 2401bis. > > => I am not against to take advantage, only to make this mandatory. okay. > > it is better for privacy > but that shouldnt be the default mode, IMHO. > > => I agree, okay. atleast we agree that the tunnel mode shouldnt be the default. you want it explicitly mentioned in the draft? > the default mode should be the same than in 3776, i.e., > MH protocol as the selector. But the two others (all traffic and only > the critical MH types) have to be allowed. anybody else has an opinion on this? > > Another issue is the total lack of implicit or explicit references to > > the pki4ipsec work... > > what should we be in specific referring to? to > draft-ietf-pki4ipsec-ikecert-profile or to some section in it? > > => IMHO the most of the text is relevant, for instance 3.1.1 > o the administrator intends the implementation to verify that the > peer source address matches the IP address in the ID received, and > that in the iPAddress field in the peer certificate's > SubjectAltName extension. > ... > In addition, implementations MUST be capable of verifying that the > address contained in the ID is the same as the peer source address, > contained in the outer most IP header. If ID is one of the IP > address types, then implementations MUST perform this verification by > default. If this default is enabled, then a mismatch MUST be treated > as an error and security association setup MUST be aborted. This > event SHOULD be auditable. Implementations MAY provide a > configuration option to (i.e. local policy configuration can enable) > skip that verification step, but that option MUST be off by default. > We include the "option-to-skip-validation" in order to permit better > interoperability, as today implementations vary greatly in how they > behave on the topic of verification of source IP. I agree. infact the entire section 3.1 is relevant because many times the identification presented in the IDi payload might be NAI or FQDN. I propose adding the following to section 5.2 When PKI based authentication is used between the mobile and the Home Agent, the identity presented by the mobile node in the IDi payload must correspond to the identity in the certificate obtained by the Home Agent. The Home Agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the Home Agent MUST verify that the home address matches the address in the iPAddress field in the SubjectAltName extension [9]. [9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Internet-Draft draft-ietf-pki4ipsec-ikecert-profile-03, October 2004. if you are not happy with this, please propose some text. > > So in your draft section 5.2 the first option should not be recommended > (i.e., it should be used only when the two (and far better) others are > not available). Francis, I dont think we can mandate that somebody use PKI instead of shared secrets through IETF specs. deployment considerations determine this. not us. I do agree that if PKI is available it should be used. maybe we can emphasize that PKI be used if available. would that be enough? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 03:24:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21951 for ; Thu, 7 Apr 2005 03:24:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRVa-0006Bw-3Y for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 03:32:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRKJ-0002Ip-AW; Thu, 07 Apr 2005 03:21:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRKH-0002Ii-5X for mip6@megatron.ietf.org; Thu, 07 Apr 2005 03:21:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21763 for ; Thu, 7 Apr 2005 03:21:15 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRSm-000651-Rj for mip6@ietf.org; Thu, 07 Apr 2005 03:30:05 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2005 09:21:08 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j377L2t7018844; Thu, 7 Apr 2005 09:21:04 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Apr 2005 09:21:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Date: Thu, 7 Apr 2005 09:20:58 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCB14115@xmb-ams-337.emea.cisco.com> Thread-Topic: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU6oadwGGCGvjSYRwCEIEcHqSdyWgALejJAABx3/QA= From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 07 Apr 2005 07:21:02.0433 (UTC) FILETIME=[5AA15510:01C53B42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable | -----Original Message----- | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of | Vijay.Devarapalli@nokia.com | Sent: Wednesday, April 06, 2005 7:42 PM | To: Alexandru.Petrescu@motorola.com | Cc: mip6@ietf.org | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- | solimananddraft-wakikawa] |=20 | > > and in the slides we presented at the IETF, we had a | > question for the | > > WG, if we need to come up with another NAT detection mechanisn based | > > on MIPv6 (similar to what MIPv4 does), but we didnt get any | > response. | > > if the WG thinks we need one based on MIPv6, I have an idea | > on how to | > > do it. | > | > How? |=20 | let the WG first decide on whether IKEv2 is sufficient for | detecting NATs when the MN and the HA run IKEv2 between | them. if the WG things we need another MIP specific mechanism | we will get to this later. this discussio will only be a | distraction now. |=20 Hi Vijay: I would not approve a solution that makes a dependency to IKEv2 for traversing NATs, unless IKEv2 becomes universal for MRHA. At the moment, the relation between the key negotiation and IPv4 traversal mechanisms seems pretty loose so I would not forcefully tie them, even if it actually works. I'd rather have a modular approach in the solutions that we put in place for the problems that we want to solve. But maybe I missed what you really mean here. Could you clarify? Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 03:34:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22778 for ; Thu, 7 Apr 2005 03:34:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRfQ-0006YV-1R for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 03:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRVq-0005fZ-60; Thu, 07 Apr 2005 03:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRVm-0005b6-IZ for mip6@megatron.ietf.org; Thu, 07 Apr 2005 03:33:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22752 for ; Thu, 7 Apr 2005 03:33:08 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJReH-0006Ur-ER for mip6@ietf.org; Thu, 07 Apr 2005 03:41:58 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2005 09:33:01 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j377WStP021520; Thu, 7 Apr 2005 09:32:54 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 09:32:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2005 09:32:44 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCB14121@xmb-ams-337.emea.cisco.com> Thread-Topic: Requirement for NAT traversal (was: v4 CoA and route optimization) Thread-Index: AcU6pOcPjZVEw63ESXi88iRjCxnGZAAnawjA From: "Pascal Thubert \(pthubert\)" To: "Pekka Savola" , "Alexandru Petrescu" X-OriginalArrivalTime: 07 Apr 2005 07:32:50.0184 (UTC) FILETIME=[007B9080:01C53B44] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: H.Soliman@flarion.com, mip6@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com Subject: [Mip6] Requirement for NAT traversal (was: v4 CoA and route optimization) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Hi Vijay: | Being behind a NAT or not can be detected very simply by the GW by | checking the src address and some address that MN puts in the payload. |=20 This seems to omit reverse NATs where the HA is actually within an IPv4 private network, which is a case that we face in small/medium corporations which can not afford a DMZ. That's also the simplest way for me to set it up at home so I can keep my DSL connection the way it stands. So maybe it's time to discuss what the NAT traversal requirement is. The way I see it, we need to go through NAT, PAT and reverse NAT. In other words, MR encapsulates an IPv6 packet into IPv4 UDP. Any of (IPv4 source, IPv4 destination, UDP source port) might be changed. IPv4 destination port should be standardized to avoid confusions. Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 07:43:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11887 for ; Thu, 7 Apr 2005 07:43:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVYR-0006Yz-2T for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 07:52:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVLQ-0002ue-A8; Thu, 07 Apr 2005 07:38:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVLM-0002uZ-JU for mip6@megatron.ietf.org; Thu, 07 Apr 2005 07:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11370 for ; Thu, 7 Apr 2005 07:38:39 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVTt-0006Ls-L6 for mip6@ietf.org; Thu, 07 Apr 2005 07:47:30 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j37Ben24003735; Thu, 7 Apr 2005 04:40:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j37BdI43029098; Thu, 7 Apr 2005 06:39:19 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 39270865980; Thu, 7 Apr 2005 13:38:24 +0200 (CEST) Message-ID: <42551BB0.8070408@motorola.com> Date: Thu, 07 Apr 2005 13:38:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FCB14121@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCB14121@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Pekka Savola , H.Soliman@flarion.com, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, henrik@levkowetz.com Subject: [Mip6] Re: Requirement for NAT traversal (was: v4 CoA and route optimization) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Hi Vijay: > > | Being behind a NAT or not can be detected very simply by the GW by > | checking the src address and some address that MN puts in the > payload. | > > This seems to omit reverse NATs where the HA is actually within an > IPv4 private network, which is a case that we face in small/medium > corporations which can not afford a DMZ. That's also the simplest way > for me to set it up at home so I can keep my DSL connection the way > it stands. I think both cases are valid but only the direct (non-reverse) NAT can be done with my implementation. Traversing a pair of NAT and reverse NAT induces a need for a box outside both domains that would need to be standardized. At this point I think it would be an unncessary burden. I think. > So maybe it's time to discuss what the NAT traversal requirement is. > The way I see it, we need to go through NAT, PAT and reverse NAT. In > other words, MR encapsulates an IPv6 packet into IPv4 UDP. Any of > (IPv4 source, IPv4 destination, UDP source port) might be changed. Only the source address and the src/dst ports may change, but not the dst address. I would agree with this requirement. > IPv4 destination port should be standardized to avoid confusions. Ok but standardizing an IPv4 destination port does not mean that a firewall filter will not block it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 10:33:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28592 for ; Thu, 7 Apr 2005 10:33:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJY1w-0004NI-U5 for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 10:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXli-0008RF-9T; Thu, 07 Apr 2005 10:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXlg-0008R1-59 for mip6@megatron.ietf.org; Thu, 07 Apr 2005 10:14:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26974 for ; Thu, 7 Apr 2005 10:13:57 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXuE-00046D-3M for mip6@ietf.org; Thu, 07 Apr 2005 10:22:51 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j37EDNo17332; Thu, 7 Apr 2005 16:13:23 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j37EDLYP005783; Thu, 7 Apr 2005 16:13:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200504071413.j37EDLYP005783@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 In-reply-to: Your message of Wed, 06 Apr 2005 14:15:48 PDT. <42545184.2050505@iprg.nokia.com> Date: Thu, 07 Apr 2005 16:13:21 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c In your previous mail you wrote: you want it changed to the following? o The mobile node MUST use its Care-of Address as source address in protocol exchanges, when using dynamic keying. However, the security associations MUST be created for the home address of the mobile node. => OK for me. okay. atleast we agree that the tunnel mode shouldnt be the default. you want it explicitly mentioned in the draft? => I don't believe the word default is necessary: IMHO we should just present things in the right order and explain there are two alternatives to the selector = MH protocol. > the default mode should be the same than in 3776, i.e., > MH protocol as the selector. But the two others (all traffic and only > the critical MH types) have to be allowed. => in fact any selector set which provides the right protection should be allowed... The two alternatives need to be detailed because they have some advantages so should become common. Of course both sides should agree before. > So in your draft section 5.2 the first option should not be recommended > (i.e., it should be used only when the two (and far better) others are > not available). Francis, I dont think we can mandate that somebody use PKI instead => I agree we may not put a "MUST" but this is a good place to play with SHOULD and MAY with a good explaination. of shared secrets through IETF specs. deployment considerations determine this. not us. I do agree that if PKI is available it should be used. maybe we can emphasize that PKI be used if available. would that be enough? => we agree about the target. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 13:03:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14783 for ; Thu, 7 Apr 2005 13:03:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaYQ-0002cO-IB for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 13:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaPf-0005Y4-6h; Thu, 07 Apr 2005 13:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaPd-0005Xy-KZ for mip6@megatron.ietf.org; Thu, 07 Apr 2005 13:03:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14757 for ; Thu, 7 Apr 2005 13:03:22 -0400 (EDT) From: Vijay.Devarapalli@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaYE-0002ZF-8t for mip6@ietf.org; Thu, 07 Apr 2005 13:12:18 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j37H3EF17022; Thu, 7 Apr 2005 20:03:14 +0300 (EET DST) X-Scanned: Thu, 7 Apr 2005 20:02:47 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j37H2ltc012522; Thu, 7 Apr 2005 20:02:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00EXKjbL; Thu, 07 Apr 2005 20:02:41 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j37H2eU27743; Thu, 7 Apr 2005 20:02:40 +0300 (EET DST) Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Apr 2005 12:02:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Date: Thu, 7 Apr 2005 10:02:16 -0700 Message-ID: Thread-Topic: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU6oadwGGCGvjSYRwCEIEcHqSdyWgALejJAABx3/QAAFE5GwA== To: , X-OriginalArrivalTime: 07 Apr 2005 17:02:17.0016 (UTC) FILETIME=[8D806380:01C53B93] X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Pascal, RFC 3775, 3776 and 3963 all use IPsec by default for setting up security associations between the MN/MR and=20 the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I=20 believe IKEv2 will become the default mechanism for=20 setting up security associations between the MN/MR and=20 the HA. so what are you objecting to? the use of IKEv2 or the use of IKEv2 for detecting NATs?=20 IKEv2 has a NAT detection mechanism. and if MN/MR and=20 the HA use IKEv2 to set up security associations, then it is natural to use IKEv2 to detect NATs also. if the WG feels we need another MIP specific mechanism for detecting NATs, we can work on it. we had that=20 question on the slides presented at the last IETF meeting. there wasnt any feedback at that time. Vijay > -----Original Message----- > From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, April 07, 2005 12:21 AM > To: Devarapalli Vijay (Nokia-NRC/MtView); > Alexandru.Petrescu@motorola.com > Cc: mip6@ietf.org > Subject: RE: v4 CoA and route optimization [Re:[Mip6] > draft-solimananddraft-wakikawa] >=20 >=20 >=20 >=20 > | -----Original Message----- > | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf > Of > | Vijay.Devarapalli@nokia.com > | Sent: Wednesday, April 06, 2005 7:42 PM > | To: Alexandru.Petrescu@motorola.com > | Cc: mip6@ietf.org > | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- > | solimananddraft-wakikawa] > |=20 > | > > and in the slides we presented at the IETF, we had a > | > question for the > | > > WG, if we need to come up with another NAT detection mechanisn > based > | > > on MIPv6 (similar to what MIPv4 does), but we didnt get any > | > response. > | > > if the WG thinks we need one based on MIPv6, I have an idea > | > on how to > | > > do it. > | > > | > How? > |=20 > | let the WG first decide on whether IKEv2 is sufficient for > | detecting NATs when the MN and the HA run IKEv2 between > | them. if the WG things we need another MIP specific mechanism > | we will get to this later. this discussio will only be a > | distraction now. > |=20 > Hi Vijay: >=20 > I would not approve a solution that makes a dependency to IKEv2 for > traversing NATs, unless IKEv2 becomes universal for MRHA. At=20 > the moment, > the relation between the key negotiation and IPv4 traversal mechanisms > seems pretty loose so I would not forcefully tie them, even if it > actually works. >=20 > I'd rather have a modular approach in the solutions that we=20 > put in place > for the problems that we want to solve. >=20 > But maybe I missed what you really mean here. Could you clarify? >=20 > Pascal >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 15:13:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28729 for ; Thu, 7 Apr 2005 15:13:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcZm-0007Fg-Rw for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 15:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcQV-0004TB-OA; Thu, 07 Apr 2005 15:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcQT-0004T6-PH for mip6@megatron.ietf.org; Thu, 07 Apr 2005 15:12:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28637 for ; Thu, 7 Apr 2005 15:12:23 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcZ5-0007By-Lb for mip6@ietf.org; Thu, 07 Apr 2005 15:21:19 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j37JET24027107; Thu, 7 Apr 2005 12:14:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j37JEJsn020524; Thu, 7 Apr 2005 14:14:20 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6E19B865980; Thu, 7 Apr 2005 21:12:06 +0200 (CEST) Message-ID: <42558606.7030503@motorola.com> Date: Thu, 07 Apr 2005 21:12:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay.Devarapalli@nokia.com Subject: Re: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, pthubert@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Vijay.Devarapalli@nokia.com wrote: > Pascal, > > RFC 3775, 3776 and 3963 all use IPsec by default for setting up > security associations between the MN/MR and the HA. once > draft-ietf-mip6-ikev2-ipsec is approved, I believe IKEv2 will become > the default mechanism for setting up security associations between > the MN/MR and the HA. > > so what are you objecting to? the use of IKEv2 or the use of IKEv2 > for detecting NATs? > > IKEv2 has a NAT detection mechanism. and if MN/MR and the HA use > IKEv2 to set up security associations, then it is natural to use > IKEv2 to detect NATs also. > > if the WG feels we need another MIP specific mechanism for detecting > NATs, we can work on it. we had that question on the slides presented > at the last IETF meeting. there wasnt any feedback at that time. Vijay, excuse me interfering in your discussion with Pascal. Thanks for posting this, it is important to remind that all Mobile IPv6 RFCs rely on IKE to set up the MN-HA SAs. I must also say that I am not very familiar with IKE, and even less with IKE's NAT detection features and nothing about IPv6 IKEv2. ALso, please let me point out that if IKEv2 for v4 is capable of going through all sorts of NATs, and if using IKEv2 for v4 does not involve exchanging too many messages every time MN changes its v4 Address, then I think I support it, instead of MIP4's NAT traversal scheme. However, may I also say that the ISAKMP (that I use with my corporate VPN, probably similar to yours) (1) uses a 10-message initial exchange and (2) uses a fixed outgoing port number for UDP which seems to be 500. Shortening the 10-message exchange is probably seen by you to be done with RFC3776 or with draft-ietf-mip6-ikev2 (I'm not sure); but both these drafts are v6-related; or, the NAT traversal should be v4-related, and I am not aware of a requirement to use IKE between MN and HA for MIP4, neither am I aware of a way to shorten the 10-message v4 IKE exchange. Enlightenment on this issue would be beneficial. For the second issue (UDP port 500) I am not sure that all wireless telecom operators let through this particular port number (and if they do, do they without translating the port number?), hence the potential need to scan for open ports. When connecting to a particular wireless telecom operator with my corporate VPN, it won't get through even if I set the flag "NAT present", even the flag "use port 80". Can IKEv2 for v4 help with this issue? Does IKEv2 for v4 has any reputation of going through all sorts of NAT/NAPTs? If an implementation of IKEv2 for v4 is able to do this, then I'm fully supportive of it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 15:50:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01883 for ; Thu, 7 Apr 2005 15:50:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd9n-0008R9-5m for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 15:59:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcyX-0004DI-OJ; Thu, 07 Apr 2005 15:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcyW-0004Ap-Jy for mip6@megatron.ietf.org; Thu, 07 Apr 2005 15:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01578 for ; Thu, 7 Apr 2005 15:47:34 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd79-0008Js-2P for mip6@ietf.org; Thu, 07 Apr 2005 15:56:31 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Apr 2005 15:47:28 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v4 CoA and route optimization[Re:[Mip6] draft-solimananddraft-wakikawa] Date: Thu, 7 Apr 2005 15:47:27 -0400 Message-ID: Thread-Topic: v4 CoA and route optimization[Re:[Mip6] draft-solimananddraft-wakikawa] Thread-Index: AcU7pr7VHs5VshD/R5mWAavD/qIlXAAA8GNQ From: "Soliman, Hesham" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 07 Apr 2005 19:47:28.0092 (UTC) FILETIME=[A0F691C0:01C53BAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, pthubert@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable > Vijay, excuse me interfering in your discussion with Pascal. >=20 > Thanks for posting this, it is important to remind that all=20 > Mobile IPv6=20 > RFCs rely on IKE to set up the MN-HA SAs.=20 =3D> That's incorrect. Manual configuration is also possible. Hesham I must also say=20 > that I am not=20 > very familiar with IKE, and even less with IKE's NAT=20 > detection features=20 > and nothing about IPv6 IKEv2. >=20 > ALso, please let me point out that if IKEv2 for v4 is=20 > capable of going=20 > through all sorts of NATs, and if using IKEv2 for v4 does=20 > not involve=20 > exchanging too many messages every time MN changes its v4=20 > Address, then=20 > I think I support it, instead of MIP4's NAT traversal scheme. >=20 > However, may I also say that the ISAKMP (that I use with my=20 > corporate=20 > VPN, probably similar to yours) (1) uses a 10-message=20 > initial exchange=20 > and (2) uses a fixed outgoing port number for UDP which=20 > seems to be 500. >=20 > Shortening the 10-message exchange is probably seen by you=20 > to be done=20 > with RFC3776 or with draft-ietf-mip6-ikev2 (I'm not sure); but both=20 > these drafts are v6-related; or, the NAT traversal should be=20 > v4-related,=20 > and I am not aware of a requirement to use IKE between MN and HA for=20 > MIP4, neither am I aware of a way to shorten the 10-message v4 IKE=20 > exchange. Enlightenment on this issue would be beneficial. >=20 > For the second issue (UDP port 500) I am not sure that all wireless=20 > telecom operators let through this particular port number=20 > (and if they=20 > do, do they without translating the port number?), hence the=20 > potential=20 > need to scan for open ports. When connecting to a=20 > particular wireless=20 > telecom operator with my corporate VPN, it won't get through=20 > even if I=20 > set the flag "NAT present", even the flag "use port 80". >=20 > Can IKEv2 for v4 help with this issue? Does IKEv2 for v4 has any=20 > reputation of going through all sorts of NAT/NAPTs? >=20 > If an implementation of IKEv2 for v4 is able to do this,=20 > then I'm fully=20 > supportive of it. >=20 > Alex >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 16:01:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02769 for ; Thu, 7 Apr 2005 16:01:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdKW-0000Wy-Ib for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 16:10:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdB6-0007Yj-US; Thu, 07 Apr 2005 16:00:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdB5-0007XI-Bu for mip6@megatron.ietf.org; Thu, 07 Apr 2005 16:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02731 for ; Thu, 7 Apr 2005 16:00:32 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdJh-0000Vr-8d for mip6@ietf.org; Thu, 07 Apr 2005 16:09:29 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j37K2t24017925 for ; Thu, 7 Apr 2005 13:02:55 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j37K2iZu014335 for ; Thu, 7 Apr 2005 15:02:44 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 15:00:33 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A6E90@il02exm13> From: Narayanan Vidya-CVN065 To: "'Vijay.Devarapalli@nokia.com'" , pthubert@cisco.com, Petrescu Alexandru-AAP021 Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraf t-wakikawa] Date: Thu, 7 Apr 2005 15:00:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Vijay, If other mechanisms such as the AUTH option are standardized, and if IKEv2 is not used to set up the SA between MN/MR and HA, a solution for NAT traversal that has a dependency on IKEv2 will have a problem. Given that this is a possibility, do we really want to make this the solution? In my mind, it is fine to use IKEv2 to detect NATs when it is used - but, it doesn't seem to me that we can assume it will always be used? I somehow didn't raise it at IETF, but nevertheless, seems important to discuss :) Vidya -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Vijay.Devarapalli@nokia.com Sent: Thursday, April 07, 2005 12:02 PM To: pthubert@cisco.com; Petrescu Alexandru-AAP021 Cc: mip6@ietf.org Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Pascal, RFC 3775, 3776 and 3963 all use IPsec by default for setting up security associations between the MN/MR and the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I believe IKEv2 will become the default mechanism for setting up security associations between the MN/MR and the HA. so what are you objecting to? the use of IKEv2 or the use of IKEv2 for detecting NATs? IKEv2 has a NAT detection mechanism. and if MN/MR and the HA use IKEv2 to set up security associations, then it is natural to use IKEv2 to detect NATs also. if the WG feels we need another MIP specific mechanism for detecting NATs, we can work on it. we had that question on the slides presented at the last IETF meeting. there wasnt any feedback at that time. Vijay > -----Original Message----- > From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Thursday, April 07, 2005 12:21 AM > To: Devarapalli Vijay (Nokia-NRC/MtView); > Alexandru.Petrescu@motorola.com > Cc: mip6@ietf.org > Subject: RE: v4 CoA and route optimization [Re:[Mip6] > draft-solimananddraft-wakikawa] > > > > > | -----Original Message----- > | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf > Of > | Vijay.Devarapalli@nokia.com > | Sent: Wednesday, April 06, 2005 7:42 PM > | To: Alexandru.Petrescu@motorola.com > | Cc: mip6@ietf.org > | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- > | solimananddraft-wakikawa] > | > | > > and in the slides we presented at the IETF, we had a > | > question for the > | > > WG, if we need to come up with another NAT detection mechanisn > based > | > > on MIPv6 (similar to what MIPv4 does), but we didnt get any > | > response. > | > > if the WG thinks we need one based on MIPv6, I have an idea > | > on how to > | > > do it. > | > > | > How? > | > | let the WG first decide on whether IKEv2 is sufficient for detecting > | NATs when the MN and the HA run IKEv2 between them. if the WG things > | we need another MIP specific mechanism we will get to this later. > | this discussio will only be a distraction now. > | > Hi Vijay: > > I would not approve a solution that makes a dependency to IKEv2 for > traversing NATs, unless IKEv2 becomes universal for MRHA. At the > moment, the relation between the key negotiation and IPv4 traversal > mechanisms seems pretty loose so I would not forcefully tie them, even > if it actually works. > > I'd rather have a modular approach in the solutions that we > put in place > for the problems that we want to solve. > > But maybe I missed what you really mean here. Could you clarify? > > Pascal > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 16:43:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06220 for ; Thu, 7 Apr 2005 16:43:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdzb-0001ul-Ll for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 16:52:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdpW-00080x-Em; Thu, 07 Apr 2005 16:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdpU-0007zf-2F for mip6@megatron.ietf.org; Thu, 07 Apr 2005 16:42:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06085 for ; Thu, 7 Apr 2005 16:42:17 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdy6-0001py-8m for mip6@ietf.org; Thu, 07 Apr 2005 16:51:14 -0400 Message-ID: <096901c53bb2$6b9e2170$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Narayanan Vidya-CVN065" , , , "Petrescu Alexandru-AAP021" References: <1B631E11D496D711BB2800065BFCB6A11B7A6E90@il02exm13> Subject: Re: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Date: Thu, 7 Apr 2005 13:43:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Vidya, The AUTH option isn't standardized, it is an Informational draft. jak ----- Original Message ----- From: "Narayanan Vidya-CVN065" To: ; ; "Petrescu Alexandru-AAP021" Cc: Sent: Thursday, April 07, 2005 1:00 PM Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] > Vijay, > If other mechanisms such as the AUTH option are standardized, and if IKEv2 is not used to set up the SA between MN/MR and HA, a solution for NAT traversal that has a dependency on IKEv2 will have a problem. Given that this is a possibility, do we really want to make this the solution? > > In my mind, it is fine to use IKEv2 to detect NATs when it is used - but, it doesn't seem to me that we can assume it will always be used? > > I somehow didn't raise it at IETF, but nevertheless, seems important to discuss :) > > Vidya > > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Vijay.Devarapalli@nokia.com > Sent: Thursday, April 07, 2005 12:02 PM > To: pthubert@cisco.com; Petrescu Alexandru-AAP021 > Cc: mip6@ietf.org > Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] > > > Pascal, > > RFC 3775, 3776 and 3963 all use IPsec by default for > setting up security associations between the MN/MR and > the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I > believe IKEv2 will become the default mechanism for > setting up security associations between the MN/MR and > the HA. > > so what are you objecting to? the use of IKEv2 or the use > of IKEv2 for detecting NATs? > > IKEv2 has a NAT detection mechanism. and if MN/MR and > the HA use IKEv2 to set up security associations, then it > is natural to use IKEv2 to detect NATs also. > > if the WG feels we need another MIP specific mechanism > for detecting NATs, we can work on it. we had that > question on the slides presented at the last IETF meeting. there wasnt any feedback at that time. > > Vijay > > > > -----Original Message----- > > From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Thursday, April 07, 2005 12:21 AM > > To: Devarapalli Vijay (Nokia-NRC/MtView); > > Alexandru.Petrescu@motorola.com > > Cc: mip6@ietf.org > > Subject: RE: v4 CoA and route optimization [Re:[Mip6] > > draft-solimananddraft-wakikawa] > > > > > > > > > > | -----Original Message----- > > | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf > > Of > > | Vijay.Devarapalli@nokia.com > > | Sent: Wednesday, April 06, 2005 7:42 PM > > | To: Alexandru.Petrescu@motorola.com > > | Cc: mip6@ietf.org > > | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- > > | solimananddraft-wakikawa] > > | > > | > > and in the slides we presented at the IETF, we had a > > | > question for the > > | > > WG, if we need to come up with another NAT detection mechanisn > > based > > | > > on MIPv6 (similar to what MIPv4 does), but we didnt get any > > | > response. > > | > > if the WG thinks we need one based on MIPv6, I have an idea > > | > on how to > > | > > do it. > > | > > > | > How? > > | > > | let the WG first decide on whether IKEv2 is sufficient for detecting > > | NATs when the MN and the HA run IKEv2 between them. if the WG things > > | we need another MIP specific mechanism we will get to this later. > > | this discussio will only be a distraction now. > > | > > Hi Vijay: > > > > I would not approve a solution that makes a dependency to IKEv2 for > > traversing NATs, unless IKEv2 becomes universal for MRHA. At the > > moment, the relation between the key negotiation and IPv4 traversal > > mechanisms seems pretty loose so I would not forcefully tie them, even > > if it actually works. > > > > I'd rather have a modular approach in the solutions that we > > put in place > > for the problems that we want to solve. > > > > But maybe I missed what you really mean here. Could you clarify? > > > > Pascal > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 16:44:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06304 for ; Thu, 7 Apr 2005 16:44:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe0K-0001w1-S0 for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 16:53:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdp7-0007tR-9n; Thu, 07 Apr 2005 16:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdp5-0007tM-4t for mip6@megatron.ietf.org; Thu, 07 Apr 2005 16:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06058 for ; Thu, 7 Apr 2005 16:41:52 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdxh-0001pQ-Ry for mip6@ietf.org; Thu, 07 Apr 2005 16:50:50 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j37KC9h29557; Thu, 7 Apr 2005 13:12:09 -0700 X-mProtect: <200504072012> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd518Npg; Thu, 07 Apr 2005 13:12:07 PDT Message-ID: <42559AF8.4080706@iprg.nokia.com> Date: Thu, 07 Apr 2005 13:41:28 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Narayanan Vidya-CVN065 Subject: Re: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraf t-wakikawa] References: <1B631E11D496D711BB2800065BFCB6A11B7A6E90@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A6E90@il02exm13> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, "'Vijay.Devarapalli@nokia.com'" , pthubert@cisco.com, Petrescu Alexandru-AAP021 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Narayanan Vidya-CVN065 wrote: > Vijay, > If other mechanisms such as the AUTH option are standardized, and if IKEv2 is not used to set up the SA between MN/MR and HA, a solution for NAT traversal that has a dependency on IKEv2 will have a problem. Given that this is a possibility, do we really want to make this the solution? yes. this is a valid issue. I am fine with developing a MIP specific mechanism for NAT detection in addition to IKEv2. Vijay > > In my mind, it is fine to use IKEv2 to detect NATs when it is used - but, it doesn't seem to me that we can assume it will always be used? > > I somehow didn't raise it at IETF, but nevertheless, seems important to discuss :) > > Vidya > > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Vijay.Devarapalli@nokia.com > Sent: Thursday, April 07, 2005 12:02 PM > To: pthubert@cisco.com; Petrescu Alexandru-AAP021 > Cc: mip6@ietf.org > Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] > > > Pascal, > > RFC 3775, 3776 and 3963 all use IPsec by default for > setting up security associations between the MN/MR and > the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I > believe IKEv2 will become the default mechanism for > setting up security associations between the MN/MR and > the HA. > > so what are you objecting to? the use of IKEv2 or the use > of IKEv2 for detecting NATs? > > IKEv2 has a NAT detection mechanism. and if MN/MR and > the HA use IKEv2 to set up security associations, then it > is natural to use IKEv2 to detect NATs also. > > if the WG feels we need another MIP specific mechanism > for detecting NATs, we can work on it. we had that > question on the slides presented at the last IETF meeting. there wasnt any feedback at that time. > > Vijay > > > >>-----Original Message----- >>From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>Sent: Thursday, April 07, 2005 12:21 AM >>To: Devarapalli Vijay (Nokia-NRC/MtView); >>Alexandru.Petrescu@motorola.com >>Cc: mip6@ietf.org >>Subject: RE: v4 CoA and route optimization [Re:[Mip6] >>draft-solimananddraft-wakikawa] >> >> >> >> >>| -----Original Message----- >>| From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf >>Of >>| Vijay.Devarapalli@nokia.com >>| Sent: Wednesday, April 06, 2005 7:42 PM >>| To: Alexandru.Petrescu@motorola.com >>| Cc: mip6@ietf.org >>| Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- >>| solimananddraft-wakikawa] >>| >>| > > and in the slides we presented at the IETF, we had a >>| > question for the >>| > > WG, if we need to come up with another NAT detection mechanisn >>based >>| > > on MIPv6 (similar to what MIPv4 does), but we didnt get any >>| > response. >>| > > if the WG thinks we need one based on MIPv6, I have an idea >>| > on how to >>| > > do it. >>| > >>| > How? >>| >>| let the WG first decide on whether IKEv2 is sufficient for detecting >>| NATs when the MN and the HA run IKEv2 between them. if the WG things >>| we need another MIP specific mechanism we will get to this later. >>| this discussio will only be a distraction now. >>| >>Hi Vijay: >> >>I would not approve a solution that makes a dependency to IKEv2 for >>traversing NATs, unless IKEv2 becomes universal for MRHA. At the >>moment, the relation between the key negotiation and IPv4 traversal >>mechanisms seems pretty loose so I would not forcefully tie them, even >>if it actually works. >> >>I'd rather have a modular approach in the solutions that we >>put in place >>for the problems that we want to solve. >> >>But maybe I missed what you really mean here. Could you clarify? >> >>Pascal >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 16:49:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06632 for ; Thu, 7 Apr 2005 16:49:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe5N-00027S-3L for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 16:58:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdvq-0001M3-KO; Thu, 07 Apr 2005 16:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdvn-0001Lp-D5 for mip6@megatron.ietf.org; Thu, 07 Apr 2005 16:48:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06549 for ; Thu, 7 Apr 2005 16:48:48 -0400 (EDT) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe4Q-00026K-78 for mip6@ietf.org; Thu, 07 Apr 2005 16:57:46 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate.mot.com (Motorola/Motgate) with ESMTP id j37KmnQ0025375 for ; Thu, 7 Apr 2005 13:48:49 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j37KojbM006674 for ; Thu, 7 Apr 2005 15:50:45 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 15:48:49 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A6E91@il02exm13> From: Narayanan Vidya-CVN065 To: "'James Kempf'" , Vijay.Devarapalli@nokia.com, pthubert@cisco.com, Petrescu Alexandru-AAP021 Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraf t-wakikawa] Date: Thu, 7 Apr 2005 15:48:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb James, Yes, my question was if it were to be standardized... Also, there are many mechanisms being discussed for the MN-HA SA creation, some of which are not based on IKEv2. Vidya -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, April 07, 2005 3:43 PM To: Narayanan Vidya-CVN065; Vijay.Devarapalli@nokia.com; pthubert@cisco.com; Petrescu Alexandru-AAP021 Cc: mip6@ietf.org Subject: Re: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] Vidya, The AUTH option isn't standardized, it is an Informational draft. jak ----- Original Message ----- From: "Narayanan Vidya-CVN065" To: ; ; "Petrescu Alexandru-AAP021" Cc: Sent: Thursday, April 07, 2005 1:00 PM Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] > Vijay, > If other mechanisms such as the AUTH option are standardized, and if > IKEv2 is not used to set up the SA between MN/MR and HA, a solution for NAT traversal that has a dependency on IKEv2 will have a problem. Given that this is a possibility, do we really want to make this the solution? > > In my mind, it is fine to use IKEv2 to detect NATs when it is used - > but, it doesn't seem to me that we can assume it will always be used? > > I somehow didn't raise it at IETF, but nevertheless, seems important > to discuss :) > > Vidya > > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf > Of Vijay.Devarapalli@nokia.com > Sent: Thursday, April 07, 2005 12:02 PM > To: pthubert@cisco.com; Petrescu Alexandru-AAP021 > Cc: mip6@ietf.org > Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] > > > Pascal, > > RFC 3775, 3776 and 3963 all use IPsec by default for > setting up security associations between the MN/MR and > the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I believe IKEv2 > will become the default mechanism for setting up security associations > between the MN/MR and the HA. > > so what are you objecting to? the use of IKEv2 or the use > of IKEv2 for detecting NATs? > > IKEv2 has a NAT detection mechanism. and if MN/MR and > the HA use IKEv2 to set up security associations, then it > is natural to use IKEv2 to detect NATs also. > > if the WG feels we need another MIP specific mechanism > for detecting NATs, we can work on it. we had that > question on the slides presented at the last IETF meeting. there wasnt > any feedback at that time. > > Vijay > > > > -----Original Message----- > > From: ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Thursday, April 07, 2005 12:21 AM > > To: Devarapalli Vijay (Nokia-NRC/MtView); > > Alexandru.Petrescu@motorola.com > > Cc: mip6@ietf.org > > Subject: RE: v4 CoA and route optimization [Re:[Mip6] > > draft-solimananddraft-wakikawa] > > > > > > > > > > | -----Original Message----- > > | From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > > | Behalf > > Of > > | Vijay.Devarapalli@nokia.com > > | Sent: Wednesday, April 06, 2005 7:42 PM > > | To: Alexandru.Petrescu@motorola.com > > | Cc: mip6@ietf.org > > | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft- > > | solimananddraft-wakikawa] > > | > > | > > and in the slides we presented at the IETF, we had a > > | > question for the > > | > > WG, if we need to come up with another NAT detection mechanisn > > based > > | > > on MIPv6 (similar to what MIPv4 does), but we didnt get any > > | > response. > > | > > if the WG thinks we need one based on MIPv6, I have an idea > > | > on how to > > | > > do it. > > | > > > | > How? > > | > > | let the WG first decide on whether IKEv2 is sufficient for > > | detecting NATs when the MN and the HA run IKEv2 between them. if > > | the WG things we need another MIP specific mechanism we will get > > | to this later. this discussio will only be a distraction now. > > | > > Hi Vijay: > > > > I would not approve a solution that makes a dependency to IKEv2 for > > traversing NATs, unless IKEv2 becomes universal for MRHA. At the > > moment, the relation between the key negotiation and IPv4 traversal > > mechanisms seems pretty loose so I would not forcefully tie them, > > even if it actually works. > > > > I'd rather have a modular approach in the solutions that we put in > > place for the problems that we want to solve. > > > > But maybe I missed what you really mean here. Could you clarify? > > > > Pascal > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 7 17:16:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09232 for ; Thu, 7 Apr 2005 17:16:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeVW-00038V-SH for mip6-web-archive@ietf.org; Thu, 07 Apr 2005 17:25:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeKb-0005Tl-R0; Thu, 07 Apr 2005 17:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeKa-0005Td-1M for mip6@megatron.ietf.org; Thu, 07 Apr 2005 17:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08883 for ; Thu, 7 Apr 2005 17:14:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeTD-00030M-3O for mip6@ietf.org; Thu, 07 Apr 2005 17:23:23 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j37Kigd21059; Thu, 7 Apr 2005 13:44:42 -0700 X-mProtect: <200504072044> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14160.americas.nokia.com (172.18.141.60, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdVY7bPS; Thu, 07 Apr 2005 13:44:41 PDT Message-ID: <4255A29C.7070306@iprg.nokia.com> Date: Thu, 07 Apr 2005 14:14:04 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: v4 CoA and route optimization [Re:[Mip6] draft-solimananddraft-wakikawa] References: <42558606.7030503@motorola.com> In-Reply-To: <42558606.7030503@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Vijay.Devarapalli@nokia.com, pthubert@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay.Devarapalli@nokia.com wrote: > >> Pascal, >> >> RFC 3775, 3776 and 3963 all use IPsec by default for setting up >> security associations between the MN/MR and the HA. once >> draft-ietf-mip6-ikev2-ipsec is approved, I believe IKEv2 will become >> the default mechanism for setting up security associations between >> the MN/MR and the HA. >> >> so what are you objecting to? the use of IKEv2 or the use of IKEv2 >> for detecting NATs? >> >> IKEv2 has a NAT detection mechanism. and if MN/MR and the HA use >> IKEv2 to set up security associations, then it is natural to use >> IKEv2 to detect NATs also. >> >> if the WG feels we need another MIP specific mechanism for detecting >> NATs, we can work on it. we had that question on the slides presented >> at the last IETF meeting. there wasnt any feedback at that time. > > > Vijay, excuse me interfering in your discussion with Pascal. > > Thanks for posting this, it is important to remind that all Mobile IPv6 > RFCs rely on IKE to set up the MN-HA SAs. I must also say that I am not > very familiar with IKE, and even less with IKE's NAT detection features > and nothing about IPv6 IKEv2. IKEv2 is version neutral. I believe the same mechanisms work for both v4 and v6. > ALso, please let me point out that if IKEv2 for v4 is capable of going > through all sorts of NATs, yes. > and if using IKEv2 for v4 does not involve > exchanging too many messages every time MN changes its v4 Address, then > I think I support it, instead of MIP4's NAT traversal scheme. for what I understand, the same two round trips that IKEv2 takes always. somebody correct me if I am wrong. > Can IKEv2 for v4 help with this issue? Does IKEv2 for v4 has any > reputation of going through all sorts of NAT/NAPTs? atleast IKEv1 seems to work with most NATs. IKEv2 should work too. but in general, this is a very difficult question to answer. I believe not all NATs behave in the same way. we have a WG in the IETF, BEHAVE, which is trying to figure what is a standard behavior for NATs. :) http://www.ietf.org/html.charters/behave-charter.html > If an implementation of IKEv2 for v4 is able to do this, then I'm fully > supportive of it. draft-wakikawa explains running IKEv2 between MN/MR and HA when the MN/MR are on a v4 only access network. the MN uses its v4CoA as the source address in the IKE negotiation. the negotiation is done with the v4 address of the HA. the final security associations are created between v6 HoA and v6 address of the HA. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 8 05:13:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21027 for ; Fri, 8 Apr 2005 05:13:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJphO-0000AK-1e for mip6-web-archive@ietf.org; Fri, 08 Apr 2005 05:22:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJpS6-0005LH-Pj; Fri, 08 Apr 2005 05:06:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJpQI-0005Cr-7H for mip6@megatron.ietf.org; Fri, 08 Apr 2005 05:05:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20434 for ; Fri, 8 Apr 2005 05:05:03 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpZ0-0008KX-CT for mip6@ietf.org; Fri, 08 Apr 2005 05:14:07 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IEM00G50E0M45@dns2.cselt.it> for mip6@ietf.org; Fri, 08 Apr 2005 10:53:10 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 08 Apr 2005 11:04:06 +0200 Date: Fri, 08 Apr 2005 11:04:53 +0200 From: Gerardo Giaretta To: Tschofenig Hannes Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: a few comments on Thread-Index: AcUy2c6ytAi7aNLSQkW//eM8gzbFVAJPvQ6g Content-class: urn:content-classes:message X-OriginalArrivalTime: 08 Apr 2005 09:04:06.0421 (UTC) FILETIME=[EAFCC450:01C53C19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] RE: a few comments on X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: quoted-printable Hi Hannes, thanks for your comments and sorry for the delay of my response. Please see my comments below...(ccing also mip6 ML) >=20 > hi gerardo,=20 >=20 > i have finally read your draft=20 > .=20 >=20 > here are a few comments:=20 >=20 > - avoid the usage of trust. this is just a very difficult=20 > term with many > different meanings. use security association instead.=20 >=20 > The basic security model behind this draft assumes that the mobile=20 > node shares credentials with the AAA server=20 > of the MSP (AAAH), as stated in [2]. Furthermore the HA is=20 > expected=20 > to have a security association with the AAAH server (see=20 > Figure 1).=20 > =20 > =20 > MN AAAH HA=20 > ^ ^ ^ ^=20 > | | | |=20 > +----------------+ +---------------+=20 > Security Association Security Association=20 > [or Credential] >=20 > Figure 1 - Basic Model=20 > =20 > i know that the mip6 bootstrapping problem statement document=20 > also uses the > term extensively. i also dislike it there.=20 I tried to use the same terminology adopted in the problem statement draft in order to keep them coherent. This is the definition of trust relationship in the last version of PS draft: Trust relationship In the context of this draft, trust relationship means that two parties in question, typically the user of the mobile host and the mobility or access service provider, have some sort of prior contact in which the mobile host was provisioned with credentials. These credentials allow the mobile host to authenticate itself to the mobility or access service authorizer and to prove its authorization to obtain service. Which are your concerns with the usage of this terminology in these drafts with regards to this particular definition?=20 > i am not sure whether people are willing to revise the=20 > bootstrapping ps > document. i re-read it and came across a few things i would=20 > like to see > modified.=20 >=20 I guess there is still space to change the mip6 bootstrapping problem statement document. Alpesh is still working on it. It seems that this issue is mainly related to mip6 bootstrapping PS draft. My idea for draft-giaretta-mip6-aaa-ha-goals is to keep the terminology of the PS draft. So, no problem for me to change the terminology here but only if it is changed also in the PS draft. > - Scenario 4 is not quite clear to me. it does not seem to=20 > help with most of > the bootstrapping actions.=20 > authorization based on the location (whatever location means=20 > here) seems to > be difficult. actually i do not know whether you use the term=20 > location as > discussed in or as i=20 > moved to a new > location and got a new ip address. just two different things.=20 >=20 Scenario 4 is not related to dynamic bootstrapping. The point is: suppose the MN is statically provisioned with the HA address and the HoA and has a manually configured SA with its HA. In this scenario, how do you perform the authorization procedure? The location of the MN (in the sense that it has moved to a new location and got a new IP address) was just an example; another could be the time of the day or whatever else can be in the user profile. Do you think that this scenario is not to be considered?=20 > - regarding: > " > G2.1 The AAA-HA interface should allow the use of Network Access=20 > Identifier (NAI) to identify the mobile node.=20 > " >=20 > typically the nai is used to identify the entity that can be=20 > associated with > a legal person.=20 > in fact it would be good to describe this aspect in more=20 > detail. i haven't > found a good discussion of this topic somewhere in the=20 > literature. maybe > someone else can point me to some literature.=20 >=20 The assumption in the draft is that there is a one-to-one matching between the user and the MN. Do you see a possible issue in identifying the user/MN with the NAI in the communication between the AAAH and the HA? > - regarding: >=20 > " > G2.3 The AAAH server should be able to enforce explicit=20 > operational=20 > limitations and authorization restrictions on the HA (e.g.=20 > packet filters, QoS parameters).=20 > " >=20 > could you elaborate a little bit more what you would like to=20 > accomplish with > this requirement? >=20 The HA is an anchor point, at least for bidirectional tunneling. For this reason an operator might want to install policies on MN's traffic exploiting that all bidirectional data is tunneled through the HA. > - regarding: >=20 > " > G2.2 The HA should be able to query the AAAH server to verify=20 > Mobile IPv6 service authorization for the mobile node.=20 > " >=20 > what is the idea? query without triggering any actions?=20 >=20 This is mainly related to scenarios 3 and 4. The HA, after receiving a BU or during the IKE exchange, could get in touch with the AAAH in order to authorize the user. Based on the response from the AAAH, the HA can grant Mobile IPv6 service to the MN. This might also be relevant for scenario 1. However, in this case the AAA-HA communication is used also to authenticate the user. > - regarding: >=20 > " > G2.2 The HA should be able to query the AAAH server to verify=20 > Mobile IPv6 service authorization for the mobile node.=20 > " > what state would you like to retrieve? what should the aaah=20 > do with the > state?=20 >=20 I think you are referring to goal G2.7. " G2.7 The AAAH server should be able to retreive the Mobile IPv6 state associated to a specific MN from the correspondent HA. This may be useful to periodically verify the Mobile IPv6 service status. " Suppose that the AAA architecture of the MSA/MSP is stateless and the AAA server that handles MN re-authentications changes over time. If bootstrapping is performed during network access, how the AAA server knows that the MN is already registered with that HA? A possible approach could be: the MN tells the AAA infrastructure that it is using a particular HA and the AAA server verifies the MN's state on that HA. See draft-giaretta-mip6-authorization-eap-02, section 5.2 for details. > - regarding: >=20 > " > G5.1 The AAAH server should be able to poll the designated HA for=20 > the allocation of a Home Address to the MN. Optionally, the=20 > AAAH server can provide a set of hints for the=20 > construction of=20 > the Home Address (e.g. a preferred Home Address or a=20 > preferred=20 > Interface Identifier).=20 > " >=20 > how would the message flow for this interaction look like? > i only see two options here:=20 > * the ha selects one (and then it might not be necessary to=20 > communicate it > to the aaa server) > * the aaah selects one.=20 > why do you see the need for polling? =20 > =20 this goal is related to scenario 2. The MIPv6 bootstrapping is performed during network access authentication communicating with the AAAH. In this case the MN does not communicate directly with the HA. For this reason, it is the AAAH that has to send the HoA to the MN. As you mention one possibility is that the AAAH selects one HoA by its own. However, my idea is that it is better that the HA allocates the HoA since it has the most updated vision on the addresses allocated in its link (e.g. it could have a list of HoAs already taken). > this question also relates to the next requirement, regarding: > " =20 > G5.2 The HA should be able to communicate to the AAAH server the=20 > Home Address allocated to the MN.=20 > " >=20 > what would the aaah do with the home address?=20 >=20 As mentioned above, the AAAH sends the HoA to the MN in scenario 2, but the HoA is selected by the HA. > - regarding=20 >=20 > " > G5.3 The AAAH server should be able to send to the HA the security=20 > data needed to setup the IPsec SA between the MN and the HA.=20 > Possible security data are the authentication method and the=20 > cryptographic material to be used for IKE bootstrapping.=20 > " >=20 > i think this section should talk only about the ikev2=20 > pre-shared secret > (maybe ikev1). maybe you want to provide a solution for the mip6-auth > protocol (but i am not sure).=20 >=20 This refers to: - PSK for IKEv2 - PSK and peer authentication method for IKEv1 Phase 1 Moreover, we'd like to keep the requirements a bit general in order to address also mip6-auth if it will be necessary. > for ikev2 there are not further parameters that need to be=20 > provided since > there are no further options that can be specified.=20 >=20 agree. Different for IKEv1, though. > one thing to discuss would be the issue of the identity used for > authentication. you might for user identity confidentiality=20 > reasons want to > use one identity during the bootstrapping procedure and=20 > another one for mip6 > usage.=20 >=20 could you please elaborate this point? don't you think this is more related to the bootstrapping solution discussion? Ciao, --Gerardo > ciao > hannes >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 10 14:08:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07199 for ; Sun, 10 Apr 2005 14:08:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKh0M-00086K-T4 for mip6-web-archive@ietf.org; Sun, 10 Apr 2005 14:17:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgpj-0000Hl-LU; Sun, 10 Apr 2005 14:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK5qG-0008O9-3D; Fri, 08 Apr 2005 22:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21706; Fri, 8 Apr 2005 22:36:57 -0400 (EDT) Received: from gator9.hostgator.com ([67.18.141.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5z7-0003yV-OV; Fri, 08 Apr 2005 22:46:10 -0400 Received: from pool-71-96-155-36.dfw.dsl-w.verizon.net ([71.96.155.36]:1550 helo=cow) by gator9.hostgator.com with esmtpa (Exim 4.44) id 1DK5pm-0007Fx-GD; Fri, 08 Apr 2005 21:36:30 -0500 From: "Dawn " To: "ICST Newsletter" , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Fri, 8 Apr 2005 21:40:01 -0500 Message-ID: <002001c53cad$6e273840$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator9.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-Mailman-Approved-At: Sun, 10 Apr 2005 14:06:54 -0400 Subject: [Mip6] Call For Proposals - Comsware 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1243976304==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e This is a multi-part message in MIME format. --===============1243976304== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C53C83.85513040" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C53C83.85513040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ****************** Call For Proposals: Workshops in Comsware 2006 Proposals for focused workshops sought as part of COMSWARE 2006. COMmunication System softWAre and MiddlewaRE (COMSWARE) is an international conference co-sponsored jointly by IEEE and ACM Sigmobile dedicated to the challenges of Software in Communications. The first COMSWARE conference will be held in the picturesque capital of India - New Delhi, from Jan 8-12, 2006, and promises to host a premier flurry of innovations in software and communications research. Additional details on COMSWARE 2006 may be found at the conference website: http://www.comsware.org/ Original proposals for workshops are solicited from potential workshop organizers. Proposals can be tailored on any particular aspect of the convergence of software and communications. The proposal should include the following: Half-to-one page write up on the scope of the workshop. 8-10 critical areas in the scope of the workshop topic Potential names of co-chair from industry and academia Sponsorship and Exhibit opportunities within the workshop Tentative one-day workshop schedule plan by the organizer Please send your proposals by May 2nd to Prof. Gaurav Sharma (gaurav.sharma@rochester.edu) or Dr. Ashwin Gumaste (ashwing@ieee.org) ******************* ------=_NextPart_000_0021_01C53C83.85513040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

******************

 

Call For Proposals: Workshops in Comsware = 2006

 

Proposals for focused workshops sought as part of = COMSWARE 2006.   COMmunication System softWAre and MiddlewaRE = (COMSWARE) is an

international conference co-sponsored jointly by = IEEE and ACM Sigmobile dedicated to the challenges of Software in Communications. = The first

COMSWARE conference will be held in the picturesque capital of India - New = Delhi, from = Jan 8-12, 2006, and promises to host a premier flurry =

of innovations in software and communications = research. Additional details on COMSWARE 2006 may be found at the conference = website:

 

http://www.comsware.org/

 

Original proposals for workshops are solicited from potential workshop organizers. Proposals can be tailored on any = particular aspect of the

convergence of software and communications. The = proposal should include the following:

 

Half-to-one page write up on the scope of the = workshop.

8-10 critical areas in the scope of the workshop = topic

Potential names of co-chair from industry and = academia

Sponsorship and Exhibit opportunities within the = workshop

Tentative one-day workshop schedule plan by the = organizer

 

Please send your proposals by May 2nd to = Prof. Gaurav Sharma = (gaurav.sharma@rochester.edu) or Dr. Ashwin Gumaste (ashwing@ieee.org)

 

*******************

------=_NextPart_000_0021_01C53C83.85513040-- --===============1243976304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1243976304==-- From mip6-bounces@ietf.org Sun Apr 10 14:10:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07338 for ; Sun, 10 Apr 2005 14:10:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKh1x-0008As-6P for mip6-web-archive@ietf.org; Sun, 10 Apr 2005 14:19:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgpj-0000Hg-9M; Sun, 10 Apr 2005 14:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJt6y-00055e-Gr for mip6@megatron.ietf.org; Fri, 08 Apr 2005 09:01:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14811 for ; Fri, 8 Apr 2005 09:01:23 -0400 (EDT) From: Geoffrey.James@tip.CSIRO.AU Received: from act-ironport-ext-out3.csiro.au ([150.229.7.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtFi-00046l-Q5 for mip6@ietf.org; Fri, 08 Apr 2005 09:10:28 -0400 Received: from crux.tip.csiro.au (130.155.194.32) by act-ironport-ext-out3.csiro.au with SMTP; 08 Apr 2005 23:01:12 +1000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.92,87,1112536800"; d="scan'208"; a="39442553:sNHT18726348" Received: (from daemon@localhost) by crux.tip.CSIRO.AU (8.9.3/8.9.3/CIPAT-2.1a) id XAA17563 for ; Fri, 8 Apr 2005 23:00:56 +1000 (EST) Received: from minerva.tip.CSIRO.AU(130.155.194.95) via SMTP by crux.tip.CSIRO.AU, id smtpdAAAa05084; Fri Apr 8 22:31:33 2005 Received: (from jam122@localhost) by minerva.tip.CSIRO.AU (8.7.5/8.7.3) id WAA23817 for mip6@ietf.org; Fri, 8 Apr 2005 22:21:48 +1000 (EST) Date: Fri, 8 Apr 2005 22:21:48 +1000 (EST) Message-Id: <200504081221.WAA23817@minerva.tip.CSIRO.AU> To: mip6@ietf.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Sun, 10 Apr 2005 14:06:54 -0400 Subject: [Mip6] IEEE EmNetS-II workshop Call for Participation X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 ======================================================================= Apologies if you receive multiple copies of this Call for Participation ======================================================================= A D V A N C E T E C H N I C A L P R O G R A M and K E Y N O T E EmNetS-II 2005 May, 30-31, 2005 The Second IEEE Workshop on Embedded Networked Sensors (EmNetS-II) Carlton Crest Hotel, 169-179 Thomas Street, Sydney, NSW 2000, Australia The Second IEEE Workshop on Embedded Networked Sensors (EmNetS-II) will bring together researchers working in the broad area of embedded, networked sensors. The goal of the workshop is to promote community-wide discussion of ideas that will influence and foster continued research in the field. The workshop will provide a venue for researchers to present new ideas that have the potential to significantly impact the community in the long term, especially those exploring how practical considerations or novel application scenarios and requirements shape the design of these embedded and sensor networks. This is a very focussed single-track workshop. The workshop program consists of 17 full papers and 7 posters with many innovative ideas from leading research groups across the globe. The highlight of this year's workshop will be a keynote address by Dr Guru Parulkar, National Science Foundation (NSF) Program Director (Computer and Network Systems Division). Please check the conference and workshop URLs for timing information and further details on the program, accommodation and registration. http://www.cse.unsw.edu.au/~emnet Please note that early (discounted) registration ends April 30th, 2005. On behalf of the IEEE Emnets-II team, Geoff James, CSIRO Australia _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 10 15:39:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14433 for ; Sun, 10 Apr 2005 15:39:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiQL-0002UI-Fn for mip6-web-archive@ietf.org; Sun, 10 Apr 2005 15:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDT-0001j1-Bg; Sun, 10 Apr 2005 15:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDS-0001it-9Y; Sun, 10 Apr 2005 15:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14095; Sun, 10 Apr 2005 15:35:28 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiMf-0002KS-0G; Sun, 10 Apr 2005 15:45:02 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j3AJZ0Fj020846; Mon, 11 Apr 2005 04:35:01 +0900 Date: Mon, 11 Apr 2005 04:34:55 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa In-Reply-To: <4253CE2F.1030109@motorola.com> References: <4253CE2F.1030109@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: H.Soliman@flarion.com, nemo@ietf.org, ryuji@sfc.wide.ad.jp, vijayd@iprg.nokia.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Alex and Hesham At Wed, 06 Apr 2005 13:55:27 +0200, Alexandru Petrescu wrote: > > Ryuji Wakikawa wrote: > > We will design an extension using mobility option to solve NAT issue > > and throw away MIPv4 support which is not our goal in the draft. > > Ryuji, how are you going to design this extension with a mobility > option? I know of a NAT that blocks all IP-in-IP and as long as the > mobility option is deep below IP it's going to be of no use. > > MIP4 has a nice feature for NAT traversal, that I know implemented. > That feature could be re-used. I don't understand why you would throw > it away and design a new option in the mobility header? I was not so clear on my last sentence. I mean we don't have any intention to use v4 HoA for v4 mobility on MIPv6 in our draft. Not talking about MIPv4's NAT traversal mechanism. Since MIP6 has different signaling way, we cannot simply re-use the MIPv4 mechanism to MIPv6. However, there are serveral points which we can re-use. ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 10 15:48:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14896 for ; Sun, 10 Apr 2005 15:48:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiZJ-0002m5-B1 for mip6-web-archive@ietf.org; Sun, 10 Apr 2005 15:58:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiLv-0002n2-Re; Sun, 10 Apr 2005 15:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiLu-0002j5-3k; Sun, 10 Apr 2005 15:44:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14713; Sun, 10 Apr 2005 15:44:12 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiV8-0002cJ-6Q; Sun, 10 Apr 2005 15:53:46 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j3AJhxFj020918; Mon, 11 Apr 2005 04:43:59 +0900 Date: Mon, 11 Apr 2005 04:43:54 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa In-Reply-To: <4254265A.90802@motorola.com> References: <4254265A.90802@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: H.Soliman@flarion.com, nemo@ietf.org, Vijay.Devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Alex excuse my late reply. At Wed, 06 Apr 2005 20:11:38 +0200, Alexandru Petrescu wrote: > > Vijay.Devarapalli@nokia.com wrote: > > > Alex, > > > > I think you misunderstood what Ryuji sent. we do plan to use UDP > > encapsulation if a NAT is present. nobody is throwing that out. > > Sorry to misunderstanding Ryuji. I think v6-in-UDPv4 should be used > independently of NAT being used or not used. Whether I misunderstand > anybody with this - it's your call. All I want to say is that this > aspect (use IPv6-in-UDPv4 independently of NAT/no NAT) should be considered. There are many options which tunnel we will use on MIPv6 for NAT or no NAT network. However, we need to think about signaling between MN-HA to deal with IPv4 network. In our draft, we provide many tunnel methods support,but I don't have strong intention for this. I mean we can discuss this later. > > Ryuji was talking about the scenario where a mobile binds a IPv6 CoA > > to a IPv4 HoA. he saying he is not interested in this scenario. > > Me too I'm not interested in this particular scenario here and today. > But I am interested in MIP4 using UDP for NAT traversal and MIP6 using > the same UDP tunnel. That's one possibility if it's worth to consider. Maybe yes in terms of filitering/blocks. > And I'll take the remark from Pekka into account here - maybe it's too > early to discuss these solution technicalities. In this case let's see > about scoping and requirements. let's discuss these once WG takes action:-) ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Apr 10 16:05:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16124 for ; Sun, 10 Apr 2005 16:05:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiq4-0003RZ-Dx for mip6-web-archive@ietf.org; Sun, 10 Apr 2005 16:15:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKie4-0004j7-A8; Sun, 10 Apr 2005 16:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKie2-0004iz-UT; Sun, 10 Apr 2005 16:02:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15972; Sun, 10 Apr 2005 16:02:56 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKinH-0003M4-AA; Sun, 10 Apr 2005 16:12:31 -0400 Received: from samurai.local.sfc.wide.ad.jp (p2097-ipbf703marunouchi.tokyo.ocn.ne.jp [222.145.165.97]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j3AK2hFj021013; Mon, 11 Apr 2005 05:02:46 +0900 Date: Mon, 11 Apr 2005 05:02:35 +0900 Message-ID: From: Ryuji Wakikawa To: pekkas@netcore.fi Subject: Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document In-Reply-To: References: <456943D540CFC14A8D7138E64843F8535BAD25@daebe101.NOE.Nokia.com> <424B32A4.9040408@iprg.nokia.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, mip6@ietf.org, ryuji@sfc.wide.ad.jp, sgundave@cisco.com, vijayd@iprg.nokia.com, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hello Pekka I believe seamless connectivity is KEY to make mobility services deploy. MN can keep communication by v6 HoA regardless of v4/nat/v6 network. It will be similar invention, but it makes sense to work on this. This is because MIP6/NEMO are also protocols creating tunnel between MN and HA. Simply extend MIP6/NEMO tunnel to support v4/NAT traversal. ryuji At Mon, 4 Apr 2005 08:22:31 +0300 (EEST), Pekka Savola wrote: > > On Mon, 4 Apr 2005, Ryuji Wakikawa wrote: > > If there are exiting transition mechanisms and MN gets v6 address, MN > > can operate without changes. This is fine if we forget redundant > > tunnel overheads. > > > > However, what happen when a mobile node roams to just v4 networks. > > Can we expect that all wireless networks will deploy with v6 or some > > transition mechanism? It makes sense that MIP6 has some way to handle > > v4 address by itself (no infrastructure supports). > > I expect that those nodes might end up running in a network without > MIPv6 Home Agent support (e.g., a WLAN interface at home). > > I assume it would be "really important" for those nodes to obtain IPv6 > connectivity (even without Mobile IPv6) in those cases as well. (This > is because the node has IPv6 applications which it will continue need > to support.) > > So, I expect the vendors would implement IPv4-IPv6 > tunneling/transition mechanisms on the nodes as well (and this has > already happened, e.g., look at the Symbian stack). > > I do not expect that all such wireless networks deploy a transition > mechanism, but if a node ends up in one which doesn't, it can always > use Teredo, 6to4, a tunnel broker, IPsec tunneling or some other > alternative to obtain IPv6 access. > > However, your scenario does not really differ from here at all. > Instead of assuming that the Home Agent is reachable from anywhere at > all using v4 (+NAT traversal), we're assuming that a tunnel server is > available from anywhere at all using v4 (+NAT traversal) _or_ that the > host implements/is able to use 6to4, Teredo, or a number of other > mechanisms. > > Hence, if we don't need to restrict the solution space based on the > encapsulation overhead, decoupling the tunneling configuration from > Mobile IP protocols seems to make a lot of sense -- because re-using > transition mechanisms gives you the superset of functionality. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Apr 13 19:46:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20963 for ; Wed, 13 Apr 2005 19:46:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrik-0000Au-30 for mip6-web-archive@ietf.org; Wed, 13 Apr 2005 19:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrQk-0000Vg-7a; Wed, 13 Apr 2005 19:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrQi-0000TM-OE; Wed, 13 Apr 2005 19:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20371; Wed, 13 Apr 2005 19:37:37 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLraJ-0008Oj-OF; Wed, 13 Apr 2005 19:47:53 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IEW00F01SAG79@mailout1.samsung.com>; Thu, 14 Apr 2005 08:37:28 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IEW00I4VSAFXO@mailout1.samsung.com>; Thu, 14 Apr 2005 08:37:27 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IEW00CRWSAFDL@mmp2.samsung.com>; Thu, 14 Apr 2005 08:37:27 +0900 (KST) Date: Thu, 14 Apr 2005 08:37:08 +0900 From: Soohong Daniel Park To: mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org Message-id: <007a01c54081$b5155480$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Mip6] [New Draft] Link Characteristic Information for Mobile IP X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Not sure which working group would be fit for this proposal, so I am posting it to multiple mailing list (MIP4,MIP6 and MIPSHOP) All comments are highly welcome. ====================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Characteristic Information for Mobile IP Author(s) : S. Park, M. Lee Filename : draft-daniel-mip-link-characteristic-00.txt Pages : 8 Date : 2005-4-13 This document introduces a new model for link characteristic information that is sent by the mobile node to let the correspondent node know which link is being used for communication between them. This utility allows the correspondent node to forward its ongoing traffics within the bandwidth of the mobile node while the mobile node changes its link. This model can be applicable for Mobile IPv4 as well as Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-00. txt Regards. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA) Content-type: Message/External-body; name=ATT00054.dat Content-disposition: attachment; filename=ATT00054.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-4-13162031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-mip-link-characteristic-00.txt --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA) Content-type: Message/External-body; name=draft-daniel-mip-link-characteristic-00.txt Content-disposition: attachment; filename=draft-daniel-mip-link-characteristic-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-4-13162031.I-D@ietf.org> --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA) Content-type: text/plain; name=ATT00057.txt Content-disposition: attachment; filename=ATT00057.txt Content-Transfer-Encoding: 7BIT _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_iqwV9fcPTeQOkWq5hLZvjA)-- From mip6-bounces@ietf.org Thu Apr 14 18:02:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05014 for ; Thu, 14 Apr 2005 18:02:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCaH-000690-Sc for mip6-web-archive@ietf.org; Thu, 14 Apr 2005 18:13:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCLg-0007qc-Lp; Thu, 14 Apr 2005 17:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCLd-0007jb-3y for mip6@megatron.ietf.org; Thu, 14 Apr 2005 17:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04518 for ; Thu, 14 Apr 2005 17:57:59 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCVe-0005ta-5n for mip6@ietf.org; Thu, 14 Apr 2005 18:08:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3ELRuS16576; Thu, 14 Apr 2005 14:27:56 -0700 X-mProtect: <200504142127> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdx1dXLl; Thu, 14 Apr 2005 14:27:55 PDT Message-ID: <425EE74E.3010400@iprg.nokia.com> Date: Thu, 14 Apr 2005 14:57:34 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Re: Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <200504061035.j36AZbmY099217@givry.rennes.enst-bretagne.fr> In-Reply-To: <200504061035.j36AZbmY099217@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Julien Bournelle , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit thanks Francis. here is the new text. The Home Agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The Home Address presented by the mobile node during the IKE negotiation is stored as the Remote IP address in the resultant IPsec security associations. The home agent MAY also have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. is this okay with everyone? Vijay Francis Dupont wrote: > In your previous mail you wrote: > > > I'm not sure to well understand this part. > > Do you mean that the home agent creates the SPD entries for the mobile > > node after receiving the first IKE packet ? > > yes. in the case of a dynamically assigned/auto-configured home > address an SPD entry for a specific home address is created only > when the HA gets to know about the home address of the MN. the > HA itself could be allocating the home address during the IKE > exchange. > > => IMHO the verb "create" is too strong because an SPD entry can exist > without addresses (addresses are only a form of selectors), quoting > 2401bis draft: > > - Name: This is not a selector like the others above. It is not > acquired from a packet. A name may be used as a symbolic > identifier for an IPsec Local or Remote address. Named SPD > entries are used in two ways: > > 1. A named SPD entry is used by a responder (not an initiator) > in support of access control when an IP address would not be > appropriate for the Remote IP address selector, e.g., for > "road warriors." The name used to match this field is > communicated during the IKE negotiation in the ID payload. > In this context, the initiator's Source IP address (inner IP > header in tunnel mode) is bound to the Remote IP address in > the SAD entry created by the IKE negotiation. This address > overrides the Remote IP address value in the SPD, when the > SPD entry is selected in this fashion. All IPsec > implementations MUST support this use of names. > > I believe we are in this case (and note its support is mandatory) even > in the real world one can't see the difference with your proposal. > > Regards > > Francis.Dupont@enst-bretagne.fr > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Apr 14 18:45:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09008 for ; Thu, 14 Apr 2005 18:45:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMDFc-0007mF-Fy for mip6-web-archive@ietf.org; Thu, 14 Apr 2005 18:55:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCfU-0003Tp-DI; Thu, 14 Apr 2005 18:18:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCfP-0003Sb-4s for mip6@megatron.ietf.org; Thu, 14 Apr 2005 18:18:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07175 for ; Thu, 14 Apr 2005 18:18:20 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCpK-0006kI-Jz for mip6@ietf.org; Thu, 14 Apr 2005 18:28:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3ELmJO02061; Thu, 14 Apr 2005 14:48:19 -0700 X-mProtect: <200504142148> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdzuhJrf; Thu, 14 Apr 2005 14:48:17 PDT Message-ID: <425EEC15.2000103@iprg.nokia.com> Date: Thu, 14 Apr 2005 15:17:57 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Comments on draft-ietf-mip6-ikev2-ipsec-01 References: <200504071413.j37EDLYP005783@givry.rennes.enst-bretagne.fr> In-Reply-To: <200504071413.j37EDLYP005783@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > you want it changed to the following? > > o The mobile node MUST use its Care-of Address as source address > in protocol exchanges, when using dynamic keying. However, the > security associations MUST be created for the home address of the > mobile node. > > => OK for me. okay, changed it. > > okay. atleast we agree that the tunnel mode shouldnt be the default. > you want it explicitly mentioned in the draft? > > => I don't believe the word default is necessary: IMHO we should just > present things in the right order and explain there are two alternatives > to the selector = MH protocol. > > > the default mode should be the same than in 3776, i.e., > > MH protocol as the selector. But the two others (all traffic and only > > the critical MH types) have to be allowed. > > => in fact any selector set which provides the right protection should be > allowed... The two alternatives need to be detailed because they have > some advantages so should become common. Of course both sides should > agree before. so you want the default mode be the same as in RFC 3776, but present the "tunnel everything" mode and the "MH type as a selector" as two options? I disagree with this. IMHO, the "MH type as a selector" should be supported atleast by the Home Agent, so that some mobiles can take advantage of this. the "tunnel everything mode" can be specified as part of privacy solution documents. > > So in your draft section 5.2 the first option should not be recommended > > (i.e., it should be used only when the two (and far better) others are > > not available). > > Francis, I dont think we can mandate that somebody use PKI instead > > => I agree we may not put a "MUST" but this is a good place to play > with SHOULD and MAY with a good explaination. > > of shared secrets through IETF specs. deployment considerations > determine this. not us. I do agree that if PKI is available it > should be used. maybe we can emphasize that PKI be used if available. > would that be enough? > > => we agree about the target. okay, I added the following to sectino 5.2 If public key based mechanism is available, it should be the preferred mechanism for mutual authentication. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From kkwpc@yahoo.com Fri Apr 15 05:50:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12593; Fri, 15 Apr 2005 05:50:39 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMNdP-0006PF-2l; Fri, 15 Apr 2005 06:01:12 -0400 Received: from s010600105a86e14d.wp.shawcable.net ([24.78.190.50]) by mx2.foretec.com with smtp (Exim 4.24) id 1DMMjo-0002q2-17; Fri, 15 Apr 2005 05:03:44 -0400 Received: from .anu..au ([46.82.168.198] helo=anu..au) by smtp9..co with esmtp id 1A5Ys6-951121-48 Message-ID: Sender: freeradius-devel-kkwpc@yahoo.com X-Mailman-Version: 2.0.1 Date: Fri, 15 Apr 2005 03:45:27 -0700 From: "Vera Petty" To: midcom@ietf.org Cc: midcom-admin@ietf.org, midcom-request@ietf.org, minutes@ietf.org, mip4@ietf.org, mip6@ietf.org, mip6-admin@ietf.org, mip6-request@ietf.org, mip6-web-archive@ietf.org Subject: You Need This Midcom X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Look at this of-fers: V-codin - 225.00 (90 pi lls) Hydrocodonee - 297.00 (90 pi lls) Valliuum - 153.00 (90 pi lls) Vi graa - 270.00 (90 pi lls) Cai llis - 348.00 (90 pi lls) Codeinne - 126.00 (90 pi lls) X|a naax - 171.00 (90 pi lls) All orderrs are delivered by Fedex with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ultrameds4u.com to get rid of maiiling list: http://www.ultrameds4u.com/aldfhsdlfh.asp From mip6-bounces@ietf.org Mon Apr 18 10:38:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNXO0-0004Jg-Lb; Mon, 18 Apr 2005 10:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMNKm-00052J-UH for mip6@megatron.ietf.org; Fri, 15 Apr 2005 05:41:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11991 for ; Fri, 15 Apr 2005 05:41:54 -0400 (EDT) Received: from smtp9.poczta.onet.pl ([213.180.130.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMNUv-00064B-Sl for mip6@ietf.org; Fri, 15 Apr 2005 05:52:27 -0400 Received: from pliniu.ds.pg.gda.pl ([153.19.211.215]:45324 "EHLO [127.0.0.1]") by ps9.test.onet.pl with ESMTP id ; Fri, 15 Apr 2005 11:41:30 +0200 Date: Fri, 15 Apr 2005 11:41:37 +0200 From: =?Windows-1250?B?UGF3ZbMgU3ou?= X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <1458274661.20050415114137@poczta.onet.pl> To: mip6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1250 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 18 Apr 2005 10:38:03 -0400 Subject: [Mip6] Mobile IPv6 in Windows ?? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?Windows-1250?B?UGF3ZbMgU3ou?= List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi!! I`m novice.I have a question. Is there support for Mobile IP in Windows?? If there is , how it use? Please. help me. PS. Please, forgive me my English mistakes. -- Regards Pliniu _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 19 15:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyqW-0003gC-S2; Tue, 19 Apr 2005 15:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyqV-0003fn-Ls for mip6@megatron.ietf.org; Tue, 19 Apr 2005 15:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16538 for ; Tue, 19 Apr 2005 15:57:17 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNz1Z-0004XA-Hu for mip6@ietf.org; Tue, 19 Apr 2005 16:08:46 -0400 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel12.hp.com (Postfix) with ESMTP id 2038B4033F9 for ; Tue, 19 Apr 2005 12:57:16 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 3013F7C7 for ; Tue, 19 Apr 2005 12:57:15 -0700 (PDT) Received: from [127.0.0.1] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j3JJvFl0002496791; Tue, 19 Apr 2005 15:57:15 -0400 (EDT) Message-ID: <42656293.1080101@hp.com> Date: Tue, 19 Apr 2005 15:57:07 -0400 From: Brian Haley Organization: HP Linux and Open Source Lab User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------010201040804060300030100" X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [Mip6] [Fwd: I-D ACTION:draft-haley-mip6-ha-switch-00.txt] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------010201040804060300030100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is a draft we submitted recently to create a new Mobility Header message for a Home Agent to signal a Mobile Node that it should acquire a new home agent. It's a combination of a number of different drafts with similar designs from various authors. Comments are appreciated. Thanks, -Brian --------------010201040804060300030100 Content-Type: message/rfc822; name="I-D ACTION:draft-haley-mip6-ha-switch-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-haley-mip6-ha-switch-00.txt" Received: from oflume.zk3.dec.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j38EV8f0001918775; Fri, 8 Apr 2005 10:31:08 -0400 (EDT) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id KAA08483; Fri, 8 Apr 2005 10:31:07 -0400 (EDT) Received: from mailrelay01.cac.cpqcorp.net by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id KAA11844; Fri, 8 Apr 2005 10:31:07 -0400 (EDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.nz-cce.cpqcorp.net [161.114.8.206]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id D063C786 for ; Fri, 8 Apr 2005 07:31:06 -0700 (PDT) Received: from palrelrim03.pa.itc.hp.com (palrelrim03.pa.itc.hp.com [192.151.81.51]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id A9131F984 for ; Fri, 8 Apr 2005 09:31:03 -0500 (CDT) Received: from palrelrim03.pa.itc.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 6555E32E94; Fri, 8 Apr 2005 07:29:08 -0700 (PDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by palrelrim03.pa.itc.hp.com (Postfix) with ESMTP id 2CCF032E95; Fri, 8 Apr 2005 07:28:55 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuQr-0001ZR-2x; Fri, 08 Apr 2005 10:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJuQn-0001ZM-Ji for i-d-announce@megatron.ietf.org; Fri, 08 Apr 2005 10:25:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25250 for ; Fri, 8 Apr 2005 10:25:55 -0400 (EDT) Message-Id: <200504081425.KAA25250@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 10:25:55 -0400 Subject: I-D ACTION:draft-haley-mip6-ha-switch-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 5.0.0.131485, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.4.8.5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Header Home Agent Switch Message Author(s) : B. Haley, et al. Filename : draft-haley-mip6-ha-switch-00.txt Pages : 11 Date : 2005-4-7 This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haley-mip6-ha-switch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haley-mip6-ha-switch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-haley-mip6-ha-switch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-8105817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haley-mip6-ha-switch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haley-mip6-ha-switch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8105817.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------010201040804060300030100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------010201040804060300030100-- From mip6-bounces@ietf.org Thu Apr 21 17:37:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjMT-00055U-Fo; Thu, 21 Apr 2005 17:37:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOjMR-00055O-Ez for mip6@megatron.ietf.org; Thu, 21 Apr 2005 17:37:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17674 for ; Thu, 21 Apr 2005 17:37:21 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOjXv-0005sN-VJ for mip6@ietf.org; Thu, 21 Apr 2005 17:49:16 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id j3LLbKjX010146; Thu, 21 Apr 2005 23:37:20 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j3LLbJB0024468; Thu, 21 Apr 2005 23:37:19 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <2SQ53FKR>; Thu, 21 Apr 2005 23:37:19 +0200 Message-ID: From: Tschofenig Hannes To: "'Gerardo Giaretta'" Date: Thu, 21 Apr 2005 23:34:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] AW: a few comments on X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org hi gerardo,=20 thanks for your comments.=20 please see my reponse below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Gerardo Giaretta [mailto:Gerardo.Giaretta@TILAB.COM]=20 > Gesendet: Freitag, 8. April 2005 11:05 > An: Tschofenig Hannes > Cc: mip6@ietf.org > Betreff: RE: a few comments on=20 > >=20 >=20 > Hi Hannes, >=20 > thanks for your comments and sorry for the delay of my response. > Please see my comments below...(ccing also mip6 ML) >=20 > >=20 > > hi gerardo,=20 > >=20 > > i have finally read your draft=20 > > .=20 > >=20 > > here are a few comments:=20 > >=20 > > - avoid the usage of trust. this is just a very difficult=20 > > term with many > > different meanings. use security association instead.=20 > >=20 > > The basic security model behind this draft assumes that=20 > the mobile=20 > > node shares credentials with the AAA server=20 > > of the MSP (AAAH), as stated in [2]. Furthermore the HA is=20 > > expected=20 > > to have a security association with the AAAH server (see=20 > > Figure 1).=20 > > =20 > > =20 > > MN AAAH HA=20 > > ^ ^ ^ ^=20 > > | | | |=20 > > +----------------+ +---------------+=20 > > Security Association Security Association=20 > > [or Credential] > >=20 > > Figure 1 - Basic Model=20 > > =20 > > i know that the mip6 bootstrapping problem statement document=20 > > also uses the > > term extensively. i also dislike it there.=20 >=20 > I tried to use the same terminology adopted in the problem statement > draft in order to keep them coherent. This is the definition of trust > relationship in the last version of PS draft: >=20 > Trust relationship > In the context of this draft, trust relationship means that two > parties in question, typically the user of the mobile=20 > host and the > mobility or access service provider, have some sort of prior > contact in which the mobile host was provisioned with=20 > credentials. > These credentials allow the mobile host to authenticate=20 > itself to > the mobility or access service authorizer and to prove its > authorization to obtain service. >=20 > Which are your concerns with the usage of this terminology in these > drafts with regards to this particular definition?=20 my impression is that use misuse the term trust relationship to define something else.=20 in fact it is not really a definition but rather an example. btw, i = disliked this definition already in the problem statement draft.=20 i use the following definition for trust relationship:=20 a trust relationship denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future. >=20 > > i am not sure whether people are willing to revise the=20 > > bootstrapping ps > > document. i re-read it and came across a few things i would=20 > > like to see > > modified.=20 > >=20 >=20 > I guess there is still space to change the mip6 bootstrapping problem > statement document. Alpesh is still working on it. > It seems that this issue is mainly related to mip6 bootstrapping PS > draft. My idea for draft-giaretta-mip6-aaa-ha-goals is to keep the > terminology of the PS draft. So, no problem for me to change the > terminology here but only if it is changed also in the PS draft. ok. then i will just submit my comments for the bootstrapping document = as well.=20 >=20 > > - Scenario 4 is not quite clear to me. it does not seem to=20 > > help with most of > > the bootstrapping actions.=20 > > authorization based on the location (whatever location means=20 > > here) seems to > > be difficult. actually i do not know whether you use the term=20 > > location as > > discussed in or as i=20 > > moved to a new > > location and got a new ip address. just two different things.=20 > >=20 >=20 > Scenario 4 is not related to dynamic bootstrapping. The point is: > suppose the MN is statically provisioned with the HA address=20 > and the HoA > and has a manually configured SA with its HA. In this scenario, how = do > you perform the authorization procedure? The location of the=20 > MN (in the > sense that it has moved to a new location and got a new IP=20 > address) was > just an example; another could be the time of the day or whatever = else > can be in the user profile. >=20 > Do you think that this scenario is not to be considered?=20 i got confused by the fact that you have everything pre-configured and = then you have a problem with authorization since you do not perform the authorization based on the pre-established credentials and the = configuration parameters but on something else that demands interaction with the aaa infrastructure.=20 >=20 > > - regarding: > > " > > G2.1 The AAA-HA interface should allow the use of Network Access=20 > > Identifier (NAI) to identify the mobile node.=20 > > " > >=20 > > typically the nai is used to identify the entity that can be=20 > > associated with > > a legal person.=20 > > in fact it would be good to describe this aspect in more=20 > > detail. i haven't > > found a good discussion of this topic somewhere in the=20 > > literature. maybe > > someone else can point me to some literature.=20 > >=20 >=20 > The assumption in the draft is that there is a one-to-one matching > between the user and the MN. Do you see a possible issue in=20 > identifying > the user/MN with the NAI in the communication between the AAAH and = the > HA? wouldn't it be better to just say that the nai is used to associate a = user.=20 (which is even not fully correct if you consider pre-paid cards but = that's problably a difficult issue to get the text truely right.) >=20 >=20 > > - regarding: > >=20 > > " > > G2.3 The AAAH server should be able to enforce explicit=20 > > operational=20 > > limitations and authorization restrictions on the HA (e.g.=20 > > packet filters, QoS parameters).=20 > > " > >=20 > > could you elaborate a little bit more what you would like to=20 > > accomplish with > > this requirement? > >=20 >=20 > The HA is an anchor point, at least for bidirectional tunneling. For > this reason an operator might want to install policies on MN's = traffic > exploiting that all bidirectional data is tunneled through the HA. hmm. this is not what i read from the requirement. you explanation = seems to say that the aaah should dictate the usage of bi-directional tunneling. = i got the impression that you would like to install packet filters and = to perform a qos reservation. this would be interesting for our work with = the diameter qos application.=20 >=20 > > - regarding: > >=20 > > " > > G2.2 The HA should be able to query the AAAH server to verify=20 > > Mobile IPv6 service authorization for the mobile node.=20 > > " > >=20 > > what is the idea? query without triggering any actions?=20 > >=20 >=20 > This is mainly related to scenarios 3 and 4. The HA, after receiving = a > BU or during the IKE exchange, could get in touch with the=20 > AAAH in order > to authorize the user. Based on the response from the AAAH, the HA = can > grant Mobile IPv6 service to the MN. >=20 > This might also be relevant for scenario 1. However, in this case the > AAA-HA communication is used also to authenticate the user. the aaa server is asked to perform authorization by relying on the authentication provided to the home agent.=20 >=20 >=20 > > - regarding: > >=20 > > " > > G2.2 The HA should be able to query the AAAH server to verify=20 > > Mobile IPv6 service authorization for the mobile node.=20 > > " > > what state would you like to retrieve? what should the aaah=20 > > do with the > > state?=20 > >=20 >=20 > I think you are referring to goal G2.7. >=20 true - copy-and-paste problem=20 > " > G2.7 The AAAH server should be able to retreive the Mobile IPv6 state > associated to a specific MN from the correspondent HA. This may be > useful to periodically verify the Mobile IPv6 service status. > " >=20 > Suppose that the AAA architecture of the MSA/MSP is stateless and the > AAA server that handles MN re-authentications changes over time. If > bootstrapping is performed during network access, how the AAA server > knows that the MN is already registered with that HA? A possible > approach could be: the MN tells the AAA infrastructure that=20 > it is using > a particular HA and the AAA server verifies the MN's state on that = HA. > See draft-giaretta-mip6-authorization-eap-02, section 5.2 for = details. i will re-visit draft-giaretta-mip6-authorization-eap-02 with regard to = this issue but i have the impression that this is a somewhat fancy feature = and i am not sure whether it is really needed.=20 let me come back to this issue.=20 >=20 >=20 > > - regarding: > >=20 > > " > > G5.1 The AAAH server should be able to poll the=20 > designated HA for=20 > > the allocation of a Home Address to the MN. Optionally, the = > > AAAH server can provide a set of hints for the=20 > > construction of=20 > > the Home Address (e.g. a preferred Home Address or a=20 > > preferred=20 > > Interface Identifier).=20 > > " > >=20 > > how would the message flow for this interaction look like? > > i only see two options here:=20 > > * the ha selects one (and then it might not be necessary to=20 > > communicate it > > to the aaa server) > > * the aaah selects one.=20 > > why do you see the need for polling? =20 > > =20 >=20 > this goal is related to scenario 2. The MIPv6 bootstrapping=20 > is performed > during network access authentication communicating with the AAAH. In > this case the MN does not communicate directly with the HA. For this > reason, it is the AAAH that has to send the HoA to the MN. As you > mention one possibility is that the AAAH selects one HoA by its own. > However, my idea is that it is better that the HA allocates the HoA > since it has the most updated vision on the addresses allocated in = its > link (e.g. it could have a list of HoAs already taken). i see.=20 >=20 > > this question also relates to the next requirement, regarding: > > " =20 > > G5.2 The HA should be able to communicate to the AAAH server the = > > Home Address allocated to the MN.=20 > > " > >=20 > > what would the aaah do with the home address?=20 > >=20 >=20 > As mentioned above, the AAAH sends the HoA to the MN in=20 > scenario 2, but > the HoA is selected by the HA. same as above.=20 >=20 > > - regarding=20 > >=20 > > " > > G5.3 The AAAH server should be able to send to the HA=20 > the security=20 > > data needed to setup the IPsec SA between the MN=20 > and the HA.=20 > > Possible security data are the authentication=20 > method and the=20 > > cryptographic material to be used for IKE bootstrapping.=20 > > " > >=20 > > i think this section should talk only about the ikev2=20 > > pre-shared secret > > (maybe ikev1). maybe you want to provide a solution for the=20 > mip6-auth > > protocol (but i am not sure).=20 > >=20 >=20 > This refers to: > - PSK for IKEv2 > - PSK and peer authentication method for IKEv1 Phase 1 >=20 > Moreover, we'd like to keep the requirements a bit general in order = to > address also mip6-auth if it will be necessary. it might be sufficient to have this information implicit in the = exchange. i do not think that the home agent will implement all three protocols and = is suddenly configured to use one protocol for user a and another one for = user b.=20 >=20 > > for ikev2 there are not further parameters that need to be=20 > > provided since > > there are no further options that can be specified. > >=20 >=20 > agree. Different for IKEv1, though. true, if it is important at all. i remember the discussions about considering ikev1 as well but i wasn't = sure whether there is large interest.=20 =20 >=20 > > one thing to discuss would be the issue of the identity used for > > authentication. you might for user identity confidentiality=20 > > reasons want to > > use one identity during the bootstrapping procedure and=20 > > another one for mip6 > > usage.=20 > >=20 >=20 > could you please elaborate this point? don't you think this is more > related to the bootstrapping solution discussion? for some of the scenarios i had the impression that it is not necessary = to use the same identity for bootstrapping and for subsequent mip6 usage.=20 in the bootstrapping you might want to use a nai (particularly in the context of an eap protocol run). as a result of the bootstrapping you create, for example, a shared secret for ikev2. subsequently, you use = ikev2 to create the ipsec sa to protect mipv6 signaling. what identity do you = use to identify the pre-shared secret? do you use the nai again or = something else?=20 ciao hannes >=20 >=20 > Ciao, > --Gerardo >=20 > > ciao > > hannes > >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 22 05:11:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOuC9-00049B-1W; Fri, 22 Apr 2005 05:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOuC6-00047R-Gy for mip6@megatron.ietf.org; Fri, 22 Apr 2005 05:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27243 for ; Fri, 22 Apr 2005 05:11:24 -0400 (EDT) Received: from web31415.mail.mud.yahoo.com ([68.142.198.127]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOuNh-0004ow-7X for mip6@ietf.org; Fri, 22 Apr 2005 05:23:25 -0400 Received: (qmail 64383 invoked by uid 60001); 22 Apr 2005 09:11:16 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=VN8AVxSG/TJshhmLFY7NqWpWnZs51NhPmQSrw5YdOJboicXnJsW90pppbjJMwvRWz5MmiMN63jaqg911Viz/AmTcONMbxLNksvVDhQ5dzV7zYrcWZOXL/Lt1+1fdB5Riwtm/70fL5H2nW2qcxqfiFKb8Li+D2FQl6K0TGiJArr8= ; Message-ID: <20050422091116.64381.qmail@web31415.mail.mud.yahoo.com> Received: from [202.20.191.158] by web31415.mail.mud.yahoo.com via HTTP; Fri, 22 Apr 2005 02:11:16 PDT Date: Fri, 22 Apr 2005 02:11:16 -0700 (PDT) From: JinHyeock Choi To: mip6@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: jinchoe@samsung.com Subject: [Mip6] [New I-D] DNA with unmodified routers (CPL) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1423081609==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============1423081609== Content-Type: multipart/alternative; boundary="0-690984052-1114161076=:60712" --0-690984052-1114161076=:60712 Content-Type: text/plain; charset=us-ascii Dear MIP6 Group A new WG I-D is announced in DNA WG. DNA with unmodified routers: Prefix list based approach draft-ietf-dna-cpl-00.txt The current MD (Movement Detection) scheme for MIPv6 is less than optimal. When a host moves to an another subnet, if it uses NUD, it would take roughly 3 secs to detect a change. Moreover, link-local scope of router addresses may cause the host to make a wrong decision. This draft describes a fast & robust DNA/MD scheme without a standard change, which can be adopted to existing MIPv6 code right now. Upon establishing a new link-layer connection, a host checks for link change, i.e. determines whether it still remains at the same link or not. Currently there is one thing which can represent the identify of a link, 'The set of all the global and valid prefixes assigned to a link.' We propose that, at each attached link, the host generates the Complete Prefix List, that is, the prefix list contains all the prefixes on the link, and when it receives a hint of a a possible link change, (usually link UP notification from link-layer), it detects the identity of the currently attached link by consulting the existing prefix list. We describe how to generate the Complete Prefix List and to robustly check for link change even in the presence of packet losses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-cpl-00.txt We are looking forward to your feedback, especially from the people who actually implement MIPv6 stack. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi and Erik Nordmark (Authors) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-690984052-1114161076=:60712 Content-Type: text/html; charset=us-ascii
Dear MIP6 Group
 
A new WG I-D is announced in DNA WG.
 
DNA with unmodified routers: Prefix list based approach
draft-ietf-dna-cpl-00.txt
 
The current MD (Movement Detection) scheme for MIPv6 is less than
optimal. When a host moves to an another subnet, if it uses NUD, it
would take roughly 3 secs to detect a change. Moreover, link-local scope
of router addresses may cause the host to make a wrong decision.  
 
This draft describes a fast & robust DNA/MD scheme without a standard
change, which can be adopted to existing MIPv6 code right now.
 
Upon establishing a new link-layer connection, a host checks for link change,
i.e. determines whether it still remains at the same link or not.
 
Currently there is one thing which can represent the identify of a link,
 
   'The set of all the global and valid prefixes assigned to a link.'
 
We propose that, at each attached link, the host generates the Complete
Prefix List, that is, the prefix list contains all the prefixes on the link,
and when it receives a hint of a a possible link change, (usually link UP
notification from link-layer), it detects the identity of the currently attached
link by consulting the existing prefix list. 
 
We describe how to generate the Complete Prefix List and to robustly check
for link change even in the presence of packet losses.
 
A URL for this Internet-Draft is:
 
 
We are looking forward to your feedback, especially from the people who
actually implement MIPv6 stack.
 
Thanks in advance for your kind consideration.
 
Best Regards
 
JinHyeock Choi and Erik Nordmark
(Authors)

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-690984052-1114161076=:60712-- --===============1423081609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1423081609==-- From mip6-bounces@ietf.org Fri Apr 22 09:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOySv-0006OB-GE; Fri, 22 Apr 2005 09:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOoML-0002IK-I9 for mip6@megatron.ietf.org; Thu, 21 Apr 2005 22:57:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13195 for ; Thu, 21 Apr 2005 22:57:35 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOoXs-0005Ho-2C for mip6@ietf.org; Thu, 21 Apr 2005 23:09:33 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IFB00H0MUVPXL@mailout2.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 11:57:25 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFB007IJUVE44@mailout2.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 11:57:14 +0900 (KST) Received: from jinchoe ([75.2.43.231]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IFB00FSHUVE1M@mmp2.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 11:57:14 +0900 (KST) Date: Fri, 22 Apr 2005 11:57:14 +0900 From: JinHyeock Choi To: Erik Nordmark Message-id: <018101c546e6$fca325a0$e72b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <424DEA3C.20205@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Fri, 22 Apr 2005 09:45:04 -0400 Cc: mip6@ietf.org Subject: [Mip6] [New I-D] DNA with unmodified routers(CPL) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Dear MIP6 Group A new WG I-D is announced in DNA WG. DNA with unmodified routers: Prefix list based approach draft-ietf-dna-cpl-00.txt The current MD (Movement Detection) scheme for MIPv6 is less than optimal. When a host moves to an another subnet, if it uses NUD, it would take roughly 3 secs to detect a change. Moreover, link-local scope of router addresses may cause the host to make a wrong decision. This draft describes a fast & robust DNA/MD scheme without a standard change, which can be adopted to existing MIPv6 code right now. Upon establishing a new link-layer connection, a host checks for link change, i.e. determines whether it still remains at the same link or not. Currently there is one thing which can represent the identify of a link, 'The set of all the global and valid prefixes assigned to a link.' We propose that, at each attached link, the host generates the Complete Prefix List, that is, the prefix list contains all the prefixes on the link, and when it receives a hint of a a possible link change, (usually link UP notification from link-layer), it detects the identity of the currently attached link by consulting the existing prefix list. We describe how to generate the Complete Prefix List and to robustly check for link change even in the presence of packet losses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-cpl-00.txt We are looking forward to your feedback, especially from the people who actually implement MIPv6 stack. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi and Erik Nordmark (Authors) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Apr 22 09:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOySv-0006Oa-Us; Fri, 22 Apr 2005 09:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOsBo-0001d3-42 for mip6@megatron.ietf.org; Fri, 22 Apr 2005 03:03:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18479 for ; Fri, 22 Apr 2005 03:02:58 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOsNN-0001n0-1C for mip6@ietf.org; Fri, 22 Apr 2005 03:14:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IFC00501667J1@mailout2.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 16:01:19 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFC007EX667GZ@mailout2.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 16:01:19 +0900 (KST) Received: from jinchoe ([75.2.47.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IFC00JHC666XP@mmp1.samsung.com> for mip6@ietf.org; Fri, 22 Apr 2005 16:01:19 +0900 (KST) Date: Fri, 22 Apr 2005 16:01:18 +0900 From: JinHyeock Choi Cc: mip6@ietf.org Message-id: <019301c54709$153f39b0$e72b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Fri, 22 Apr 2005 09:45:04 -0400 Subject: [Mip6] Test X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Test. Please, ignore. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Apr 25 09:38:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ3n7-0001ax-Jf; Mon, 25 Apr 2005 09:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPo4G-0002a4-4T; Sun, 24 Apr 2005 16:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21348; Sun, 24 Apr 2005 16:50:58 -0400 (EDT) Received: from gator9.hostgator.com ([67.18.141.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPoGI-0006Xw-T3; Sun, 24 Apr 2005 17:03:31 -0400 Received: from pool-71-96-150-116.dfw.dsl-w.verizon.net ([71.96.150.116]:2545 helo=cow) by gator9.hostgator.com with esmtpa (Exim 4.44) id 1DPo33-0002Iu-NW; Sun, 24 Apr 2005 15:49:53 -0500 From: "Dawn " To: Date: Sun, 24 Apr 2005 15:49:51 -0500 Message-ID: <000e01c5490f$2aecdb70$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator9.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed X-Mailman-Approved-At: Mon, 25 Apr 2005 09:38:24 -0400 Cc: Subject: [Mip6] Call for Papers - GridNets 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1822247802==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1822247802== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C548E5.4216D370" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C548E5.4216D370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our apologies if you receive multiple copies of this document =20 ***************** =20 Call for Papers =20 2nd International Workshop on Grid Network Research =20 GridNets 2005 www.gridnets.org, Oct 6-7 at Boston, MA, USA =20 Co-located with BroadNets 2005 www.broadnets.org (Same week as GGF15 = in Boston!) =20 =20 Scope =20 The GridNets 2005 workshop will focus on research issues and challenges = as well as lessons learned from experience. Topics of interest include and = are not limited to: =20 * New concepts and requirements to shape the design of e-Science and Research Networks =20 * Integration of advanced optical networking technologies and architectures (OPS, OBS) for the Grid environment =20 * Coordination of network resources with other Grid resources (CPU, Storage) =20 * Layer interactions: optical layer with higher layer protocols =20 * Grid advanced resource reservation =20 * Self-healing Grid networks =20 * Traffic characteristics and performance analysis =20 * New architectures and technologies that address grid requirements =20 * Experience on production-level optical network infrastructures =20 * Middleware design and grid layer integration issues for accessing and managing network resources =20 * Routing and scheduling for dynamic bandwidth control =20 * Monitoring, provisioning, brokering of network resources =20 * New multi-service frameworks and models =20 * End-to-end application level control of network resource =20 * Novel data transport protocols designed for new application services =20 * Data replication and multicasting strategies and protocols =20 * Fault-tolerance, protection, security, and scalability issues related to connecting large number of sites =20 * Network cost, performance, and incentive issues =20 IMPORTANT DATES: =20 Paper Submission Deadline: June 15, 2005=20 Paper Acceptance Notification: August 1, 2005 Final paper submission: = August 13, 2005=20 For submission instructions, refer to www.gridnets.org=20 =20 =20 Workshop Co-chairs Gigi Karmous-Edwards (MCNC Grid Computing & Network Services)=20 Harvey Newman (Caltech) =20 Steering Committee=20 Imrich Chlamtac (Chair) (Create-Net) Franco Travostino (Nortel Networks) Samrat Ganguly (NEC Labs) =20 Program Committee Co-chairs Joel Mambretti (Northwestern University) Cees De Laat (University of Amsterdam) =20 =20 ------=_NextPart_000_000F_01C548E5.4216D370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our apologies if you receive multiple copies of = this document

 

*****************

 

Call for = Papers

 

2nd = International Workshop on Grid Network Research

 

GridNets = 2005 www.gridnets.org,

Oct 6-7 at = Boston, = MA, USA

 

 Co-located with = BroadNets 2005 www.broadnets.org   (Same = week as GGF15 in Boston!)

 

 

Scope

 

 The GridNets 2005 = workshop will focus on research issues and challenges as well as lessons learned = from experience. Topics of interest include and are not limited to:

 

·  New = concepts and requirements to shape the design of e-Science

  = and Research Networks

 

·  Integration of advanced optical networking technologies and

  = architectures (OPS, OBS) for the Grid environment

 

·  Coordination of network resources with other Grid resources (CPU,  = Storage)

 

·  Layer = interactions: optical layer with higher layer protocols

 

·  Grid = advanced resource reservation

 

·  Self-healing Grid networks

 

·  Traffic characteristics and performance analysis

 

·  New = architectures and technologies that address grid requirements

 

·  Experience on production-level optical network infrastructures

 

·  Middleware design and grid layer integration issues for accessing

  = and managing  network resources

 

·  Routing = and scheduling for dynamic bandwidth control

 

·  Monitoring, provisioning, brokering of network resources

 

·  New = multi-service frameworks and models

 

·  End-to-end application level control of network resource

 

·  Novel = data transport protocols designed for new application = services

 

·  Data = replication and multicasting strategies and protocols

 

·  Fault-tolerance, protection, security, and scalability issues

   related to connecting large number of sites

 

·  Network = cost, performance, and incentive issues

 

IMPORTANT = DATES:

 

Paper = Submission Deadline: June 15, = 2005

Paper = Acceptance Notification: August 1, = 2005 Final paper submission: August 13, 2005 =

For = submission instructions, refer to www.gridnets.org

    &nbs= p;

 

Workshop = Co-chairs

Gigi = Karmous-Edwards (MCNC Grid Computing & Network Services)

Harvey = Newman = (Caltech)

 

Steering = Committee

Imrich = Chlamtac (Chair) (Create-Net)

Franco = Travostino (Nortel Networks)

Samrat = Ganguly (NEC = Labs)

 

Program = Committee Co-chairs

Joel = Mambretti (Northwestern University) Cees De Laat = (University of Amsterdam)

 

 

------=_NextPart_000_000F_01C548E5.4216D370-- --===============1822247802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1822247802==-- From mip6-bounces@ietf.org Tue Apr 26 00:09:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQHNt-0005xr-KU; Tue, 26 Apr 2005 00:09:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQHNr-0005xO-IL for mip6@megatron.ietf.org; Tue, 26 Apr 2005 00:09:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01365 for ; Tue, 26 Apr 2005 00:09:11 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQHaD-0008Ng-G2 for mip6@ietf.org; Tue, 26 Apr 2005 00:22:02 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IFJ00J01CV092@mailout1.samsung.com> for mip6@ietf.org; Tue, 26 Apr 2005 13:09:00 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IFJ00604CV0GL@mailout1.samsung.com> for mip6@ietf.org; Tue, 26 Apr 2005 13:09:00 +0900 (KST) Received: from LocalHost ([75.2.43.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IFJ00FF5CUZB2@mmp1.samsung.com> for mip6@ietf.org; Tue, 26 Apr 2005 13:09:00 +0900 (KST) Date: Tue, 26 Apr 2005 13:08:59 +0900 From: Heejin Jang Subject: [MIP6] DHCP Option for Home Agent Discovery in MIPv6 To: mip6@ietf.org Message-id: <002a01c54a15$ac79f6d0$e92b024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <014c01c51add$32621330$ec2b024b@LocalHost> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7BIT Cc: Alper Yegin X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello all, We posted an I-D that describes HA discovery with the help of DHCP6. We would appreciate to hear your comments. -------------------------------------------------------------------- Document title : DHCP Option for Home Agent Discovery in MIPv6 Authors : HeeJin Jang, Alper Yegin, JinHyeock Choi Filename : draft-jang-dhc-haopt-01.txt Date : 2005-4-25 Pages : 13 Abstract : This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Apr 26 07:25:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQOBY-000132-HC; Tue, 26 Apr 2005 07:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQOBX-00012s-AW for mip6@megatron.ietf.org; Tue, 26 Apr 2005 07:24:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27630 for ; Tue, 26 Apr 2005 07:24:58 -0400 (EDT) Received: from smtp2.poczta.onet.pl ([213.180.130.30]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQONx-0000nX-C9 for mip6@ietf.org; Tue, 26 Apr 2005 07:37:50 -0400 Received: from pliniu.ds.pg.gda.pl ([153.19.211.215]:22277 "EHLO [127.0.0.1]") by ps2.test.onet.pl with ESMTP id ; Tue, 26 Apr 2005 13:24:46 +0200 Date: Tue, 26 Apr 2005 13:24:44 +0200 From: =?Windows-1250?B?UGF3ZbMgU3ou?= X-Mailer: The Bat! (v3.0) Professional X-Priority: 3 (Normal) Message-ID: <433364604.20050426132444@poczta.onet.pl> To: "mip6-request@ietf.org" In-Reply-To: <20050425160852Z1352543-1741+87614@ps8.test.onet.pl> References: <20050425160852Z1352543-1741+87614@ps8.test.onet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1250 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Subject: [Mip6] MIPv6 Support in Microsoft Windows X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?Windows-1250?B?UGF3ZbMgU3ou?= List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello! According to http://www.microsoft.com/technet/community/columns/cableguy/cg0904.mspx#EBAA there is correspondent node support in Windows XP SP1, XP SP2 and Server 2003 based on an obsolete version of the draft. I need full support (MN, HA, CN). I sent an email request for an application to mipv6-fb@microsoft.com , but I haven`t got the response. Has anybody tried to get above application?? Or, is there any support (free) for MIPv6 (or MIPv4) in Windows systems? Please , help. -- PS. Please, forgive me my English mistakes. Regards Pliniu _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6