From nemo-bounces@ietf.org Fri Apr 1 02:14:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13020 for ; Fri, 1 Apr 2005 02:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGIX-0007jA-O5; Fri, 01 Apr 2005 02:10:29 -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: Content-Type: multipart/alternative; boundary="------------000603010906030403050704" 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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-- From nemo-bounces@ietf.org Fri Apr 1 04:04:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04269 for ; Fri, 1 Apr 2005 04:04:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHzb-0001zx-7B; Fri, 01 Apr 2005 03:59:03 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 04:18:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05161 for ; Fri, 1 Apr 2005 04:18:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIFA-0004jy-K1; Fri, 01 Apr 2005 04:15:08 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 04:52:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07188 for ; Fri, 1 Apr 2005 04:52:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIlK-00011Y-Jg; Fri, 01 Apr 2005 04:48:22 -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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 08:33:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24659 for ; Fri, 1 Apr 2005 08:33:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMG1-0003U1-W0; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 09:00:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27299 for ; Fri, 1 Apr 2005 09:00:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMfQ-00075t-P4; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 09:03:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27567 for ; Fri, 1 Apr 2005 09:03:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMeD-0006y1-4T; Fri, 01 Apr 2005 08:57:17 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 09:16:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28734 for ; Fri, 1 Apr 2005 09:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMvE-00013D-4M; Fri, 01 Apr 2005 09:14:52 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 10:03:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02131 for ; Fri, 1 Apr 2005 10:03:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHNbo-00060E-9a; Fri, 01 Apr 2005 09:58:52 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 | > From nemo-bounces@ietf.org Fri Apr 1 10:42:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05961 for ; Fri, 1 Apr 2005 10:42:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOGp-0002i0-IM; 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, Narayanan Vidya-CVN065 , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 10:50:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06546 for ; Fri, 1 Apr 2005 10:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOHv-0002lO-83; 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 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 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 11:12:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09082 for ; Fri, 1 Apr 2005 11:12:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOja-00074R-Oj; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 11:20:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09821 for ; Fri, 1 Apr 2005 11:20:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOqz-00083s-Ar; Fri, 01 Apr 2005 11:18:37 -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, Narayanan Vidya-CVN065 , Henrik Levkowetz , Basavaraj.Patil@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 11:27:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10802 for ; Fri, 1 Apr 2005 11:27:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOvE-0000zv-Fa; Fri, 01 Apr 2005 11:23:00 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 11:30:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11725 for ; Fri, 1 Apr 2005 11:30:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHP04-00023e-Cu; Fri, 01 Apr 2005 11:28:00 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 11:50:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14194 for ; Fri, 1 Apr 2005 11:50:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPIn-0007ih-Ng; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > From nemo-bounces@ietf.org Fri Apr 1 12:26:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18818 for ; Fri, 1 Apr 2005 12:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPtB-0007ID-JT; Fri, 01 Apr 2005 12:24:57 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 12:50:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20643 for ; Fri, 1 Apr 2005 12:50:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQCf-0002ut-2P; 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 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 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > From nemo-bounces@ietf.org Fri Apr 1 13:07:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22683 for ; Fri, 1 Apr 2005 13:07:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQVc-00075q-RQ; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 14:54:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00332 for ; Fri, 1 Apr 2005 14:54:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSA5-00066h-2n; Fri, 01 Apr 2005 14:50:33 -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: , , 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-Mailman-Approved-At: Fri, 01 Apr 2005 14:50:31 -0500 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > From nemo-bounces@ietf.org Fri Apr 1 14:55:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00408 for ; Fri, 1 Apr 2005 14:55:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSA5-00066m-EM; Fri, 01 Apr 2005 14:50:33 -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: , , 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-Mailman-Approved-At: Fri, 01 Apr 2005 14:50:31 -0500 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > From nemo-bounces@ietf.org Fri Apr 1 15:58:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16366 for ; Fri, 1 Apr 2005 15:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT2F-0002NG-SC; Fri, 01 Apr 2005 15:46:31 -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: [nemo] transition issues X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 16:04:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18069 for ; Fri, 1 Apr 2005 16:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTD9-0007Yx-IG; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Fri Apr 1 16:07:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19022 for ; Fri, 1 Apr 2005 16:07:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHTFm-0000Yo-Nq; Fri, 01 Apr 2005 16:00:30 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sat Apr 2 02:06:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11060 for ; Sat, 2 Apr 2005 02:06:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcf8-0004Gk-A7; Sat, 02 Apr 2005 02:03:18 -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 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 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sat Apr 2 03:37:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05324 for ; Sat, 2 Apr 2005 03:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe2c-0002BL-1y; Sat, 02 Apr 2005 03:31:38 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sun Apr 3 05:14:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06780 for ; Sun, 3 Apr 2005 05:14:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI14a-0004OT-KS; 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 , Narayanan Vidya-CVN065 , Basavaraj.Patil@nokia.com, Henrik Levkowetz , "Sri Gundavelli \(sgundave\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > | > From nemo-bounces@ietf.org Sun Apr 3 09:54:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25109 for ; Sun, 3 Apr 2005 09:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5Qi-0002vv-77; Sun, 03 Apr 2005 09:46:20 -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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:46:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27029 for ; Mon, 4 Apr 2005 00:46:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJKX-0002ZL-QP; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:47:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27186 for ; Mon, 4 Apr 2005 00:47:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIi-0002Wc-Oe; 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, vidya@motorola.com, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:48:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27289 for ; Mon, 4 Apr 2005 00:48:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIH-0002VJ-8J; Mon, 04 Apr 2005 00:34:33 -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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:48:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27418 for ; Mon, 4 Apr 2005 00:48:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIY-0002WA-H8; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:49:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27492 for ; Mon, 4 Apr 2005 00:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIP-0002Vs-Jy; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 00:50:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27642 for ; Mon, 4 Apr 2005 00:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIJIm-0002XV-GU; Mon, 04 Apr 2005 00:35:04 -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 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 Subject: [nemo] Re: [Mip6] draft-soliman and draft-wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 01:27:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01229 for ; Mon, 4 Apr 2005 01:27:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK2z-0008CK-Pj; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 01:31:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01579 for ; Mon, 4 Apr 2005 01:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIK5B-0008Lu-SP; 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 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 Subject: [nemo] Re: [Mip6] Typo in draft-ietf-mip6-mipext-advapi-03.txt (fwd) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org (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 From nemo-bounces@ietf.org Mon Apr 4 02:04:11 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07739 for ; Mon, 4 Apr 2005 02:04:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKau-0003IE-EE; Mon, 04 Apr 2005 01:57:52 -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 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 Subject: [nemo] RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnela MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 04:14:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04216 for ; Mon, 4 Apr 2005 04:14:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIMfZ-00008F-6B; Mon, 04 Apr 2005 04:10:49 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 05:08:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08850 for ; Mon, 4 Apr 2005 05:08:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINUt-0004WU-Iz; Mon, 04 Apr 2005 05:03:51 -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, vidya@motorola.com, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 05:19:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09660 for ; Mon, 4 Apr 2005 05:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DINZq-0004yp-R1; Mon, 04 Apr 2005 05:08:58 -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 Subject: RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > > > From nemo-bounces@ietf.org Mon Apr 4 06:03:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13115 for ; Mon, 4 Apr 2005 06:03:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIOK0-0000PJ-6V; 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, henrik@levkowetz.com, Basavaraj.Patil@nokia.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 06:05:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13317 for ; Mon, 4 Apr 2005 06:05:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIORD-00017N-ML; Mon, 04 Apr 2005 06:04:07 -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 Subject: Re: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 >> >> >> From nemo-bounces@ietf.org Mon Apr 4 13:36:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03059 for ; Mon, 4 Apr 2005 13:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVSz-0005Bz-0F; Mon, 04 Apr 2005 13:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVSx-0005AS-JS; Mon, 04 Apr 2005 13:34: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 NAA02755; Mon, 4 Apr 2005 13:34:20 -0400 (EDT) From: Claude.Castelluccia@inrialpes.fr Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIVat-0001QF-A7; Mon, 04 Apr 2005 13:42:38 -0400 Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.0/8.13.0) with ESMTP id j34HXulC000558; Mon, 4 Apr 2005 19:33:56 +0200 (MEST) Received: (from nobody@localhost) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) id j34HXvu17255; Mon, 4 Apr 2005 19:33:57 +0200 (MEST) X-Authentication-Warning: imap-serv.inrialpes.fr: nobody set sender to ccastel@inrialpes.fr using -f Received: from 68.5.64.231 ( [68.5.64.231]) as user ccastel@imap-serv.inrialpes.fr by imap-serv.inrialpes.fr with HTTP; Mon, 4 Apr 2005 19:33:57 +0200 Message-ID: <1112636037.42517a853abc1@imap-serv.inrialpes.fr> Date: Mon, 4 Apr 2005 19:33:57 +0200 To: nemo@ietf.org, manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (mx-serv.inrialpes.fr [194.199.18.100]); Mon, 04 Apr 2005 19:33:56 +0200 (MEST) X-SMAUG-MailScanner: Found to be clean Envelope-From: ccastel@inrialpes.fr X-Spam-Score: 0.4 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 8bit Subject: [nemo] -ESAS05 workshop- X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 8bit Dear all, FYI the submission deadline for ESAS05( 2nd European Workshop on Security and Privacy in Ad hoc and Sensor Networks) has been extended until April 18th. ESAS will be co-located with IEEE WICON (Wireless Internet Conference) in Budapest.... This is a great opportunity to present your work and to travel in a beautiful place ;-)... Don't miss it ! Cheers, Claude. From nemo-bounces@ietf.org Mon Apr 4 13:46:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04081 for ; Mon, 4 Apr 2005 13:46:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVbH-0006lD-4j; Mon, 04 Apr 2005 13:42:59 -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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > From nemo-bounces@ietf.org Mon Apr 4 15:39:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15801 for ; Mon, 4 Apr 2005 15:39:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXHj-0003Ix-NA; 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 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 Subject: [nemo] RE: [Mip6] draft-soliman and draft-wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 15:45:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17342 for ; Mon, 4 Apr 2005 15:45:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXV5-0005hJ-W2; Mon, 04 Apr 2005 15:44:43 -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 Subject: RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn elaMIP6/NEMO WGs document 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Mon Apr 4 22:51:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09617 for ; Mon, 4 Apr 2005 22:51:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIe2E-0001t7-IO; 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'" Subject: RE: [nemo] Consensus call on making ID draft-wakikawa-nemo-v4tunn el aMIP6/NEMO WGs document 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 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 > >> > >> > >> > > From nemo-bounces@ietf.org Tue Apr 5 04:02:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20127 for ; Tue, 5 Apr 2005 04:02:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiyb-0007pl-Iz; Tue, 05 Apr 2005 03:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiyZ-0007pg-I4 for nemo@megatron.ietf.org; Tue, 05 Apr 2005 03:59: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 DAA19934 for ; Tue, 5 Apr 2005 03:59:53 -0400 (EDT) Received: from massilia.int-evry.fr ([157.159.10.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIj6e-0005sq-Nr for nemo@ietf.org; Tue, 05 Apr 2005 04:08:18 -0400 Received: from massilia.int-evry.fr (localhost.localdomain [127.0.0.1]) by massilia.int-evry.fr (8.12.11/8.12.11) with ESMTP id j357xg50010997 for ; Tue, 5 Apr 2005 09:59:42 +0200 Received: (from apache@localhost) by massilia.int-evry.fr (8.12.11/8.12.11/Submit) id j357xfAW010996 for nemo@ietf.org; Tue, 5 Apr 2005 09:59:41 +0200 X-Authentication-Warning: massilia.int-evry.fr: apache set sender to Othmane.Rezine@int-evry.fr using -f Received: from 157.159.103.55 ([157.159.103.55]) by imp.int-evry.fr (IMP) with HTTP for ; Tue, 5 Apr 2005 09:59:41 +0200 Message-ID: <1112687981.4252456dcafdc@imp.int-evry.fr> Date: Tue, 5 Apr 2005 09:59:41 +0200 From: Othmane REZINE To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 157.159.103.55 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 8bit Subject: [nemo] Documentation references request X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi everybody ! I would like to know the main bibliographical references to understand the paradigms of the Nemo concepts. Is there a big difference between mobile ip, nemo and mobile ipv6 ? ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nemo-bounces@ietf.org Tue Apr 5 05:08:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25972 for ; Tue, 5 Apr 2005 05:08:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIk11-0003uI-KL; Tue, 05 Apr 2005 05:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIk0l-0003tc-Fv for nemo@megatron.ietf.org; Tue, 05 Apr 2005 05:06: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 FAA25858 for ; Tue, 5 Apr 2005 05:06:12 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIk8r-0008Ld-78 for nemo@ietf.org; Tue, 05 Apr 2005 05:14:38 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j3596BlN028525; Tue, 5 Apr 2005 02:06:12 -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 j35979m2026878; Tue, 5 Apr 2005 04:07:10 -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 D1DBA865980; Tue, 5 Apr 2005 11:06:09 +0200 (CEST) Message-ID: <42525501.2050606@motorola.com> Date: Tue, 05 Apr 2005 11:06: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: Othmane REZINE Subject: Re: [nemo] Documentation references request References: <1112687981.4252456dcafdc@imp.int-evry.fr> In-Reply-To: <1112687981.4252456dcafdc@imp.int-evry.fr> 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: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Othmane REZINE wrote: > Hi everybody ! > I would like to know the main bibliographical references to understand the > paradigms of the Nemo concepts. Start by checking all the drafts at www.mobilenetworks.org/nemo... > Is there a big difference between mobile ip, nemo and mobile ipv6 ? Differences between mobile ip and mobile ipv6: check Section 2 of RFC3775. Differences between nemo and mobile ipv6: check the R bit and the prefix in BU (nemo does, mobile ipv6 doesn't) and updating routes at HA (nemo does, mobile ipv6 doesn't). Alex From nemo-bounces@ietf.org Wed Apr 6 07:39:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00253 for ; Wed, 6 Apr 2005 07:39:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ8nw-0004L9-Ke; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 07:55:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02098 for ; Wed, 6 Apr 2005 07:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ95g-0007g2-1Q; Wed, 06 Apr 2005 07:53:00 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 07:57:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02352 for ; Wed, 6 Apr 2005 07:57:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ988-0001MA-P1; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 08:09:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03785 for ; Wed, 6 Apr 2005 08:09:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9JC-0005ub-Go; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 13:35:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09017 for ; Wed, 6 Apr 2005 13:35:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEPe-0008Mc-Nz; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 14:08:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11467 for ; Wed, 6 Apr 2005 14:08:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEqk-0000Yi-2H; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 14:12:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12035 for ; Wed, 6 Apr 2005 14:12:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJF0E-0004Hm-Kq; Wed, 06 Apr 2005 14:11:46 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Wed Apr 6 15:27:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19745 for ; Wed, 6 Apr 2005 15:27:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJG8d-00065S-PD; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sun Apr 10 15:39:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14410 for ; Sun, 10 Apr 2005 15:39:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDT-0001j6-N9; 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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sun Apr 10 15:48:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14915 for ; Sun, 10 Apr 2005 15:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiLw-0002n7-6n; Sun, 10 Apr 2005 15:44:16 -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: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Sun Apr 10 16:06:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16183 for ; Sun, 10 Apr 2005 16:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKie4-0004jC-Lz; 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 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 Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org 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 From nemo-bounces@ietf.org Thu Apr 14 08:22:31 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05905 for ; Thu, 14 Apr 2005 08:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3Hi-00056O-VF; Thu, 14 Apr 2005 08:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAdB-0003rl-QF for nemo@megatron.ietf.org; Wed, 06 Apr 2005 09:31:41 -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 JAA10783 for ; Wed, 6 Apr 2005 09:31:39 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAlX-0007aD-S2 for nemo@ietf.org; Wed, 06 Apr 2005 09:40:20 -0400 Received: by wproxy.gmail.com with SMTP id 71so373554wra for ; Wed, 06 Apr 2005 06:31:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=Tudibu7bYQ/Q4qh2sz5RGACcnDhpctyjklsz/Ue1h0b82hYVARnZL5Mc8ztO5xxWraP9cg3TxnDeeOuoPnhJnsL1Ykkb852D9bjBT9EFBL+Z4SYGGejeAsGYEuVLb/zbqh48R5A1Og6t+fBzaHM01jIliZKdzzYZGrw51NEQMV4= Received: by 10.54.32.28 with SMTP id f28mr561372wrf; Wed, 06 Apr 2005 06:31:30 -0700 (PDT) Received: by 10.54.26.9 with HTTP; Wed, 6 Apr 2005 06:31:30 -0700 (PDT) Message-ID: <29ed16a4050406063152628e54@mail.gmail.com> Date: Wed, 6 Apr 2005 15:31:30 +0200 From: Ana Minaburo To: nemo@ietf.org, rohc@ietf.org In-Reply-To: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3248_24001933.1112794290551" References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Thu, 14 Apr 2005 08:17:24 -0400 Subject: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anacarolina.minaburo@enst-bretagne.fr List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ------=_Part_3248_24001933.1112794290551 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded message ---------- From: Eun Kyoung PAIK Date: Apr 3, 2005 3:44 PM Subject: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, March 16, 2005 12:09 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ROHC (Robust Header Compression) in NEMO network Author(s) : A. Minaburo, et al. Filename : draft-minaburo-rohc-nemo-00.txt Pages : 0 Date : 2005-3-9 This document defines the use of ROHC header compression mechanisms for the NEMO Basic Support protocol [9]. The idea is to use both NEMO and ROHC as they have been defined without any change. The tunneling in the NEMO Basic Support protocol will be done over different supports (Wireless LAN, 3G or PPP) links, where ROHC compression can work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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. ENCODING mime FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt ------=_Part_3248_24001933.1112794290551 Content-Type: text/plain; name=ATT00500.txt; charset=us-ascii Content-Disposition: attachment; filename="ATT00500.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_Part_3248_24001933.1112794290551-- From nemo-bounces@ietf.org Thu Apr 14 14:55:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11987 for ; Thu, 14 Apr 2005 14:55:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9UA-0007F0-Tw; Thu, 14 Apr 2005 14:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9U9-0007DH-R0; Thu, 14 Apr 2005 14:54: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 OAA11911; Thu, 14 Apr 2005 14:54:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9e4-0004YU-GP; Thu, 14 Apr 2005 15:04:57 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j3EIOUL32416; Thu, 14 Apr 2005 11:24:30 -0700 X-mProtect: <200504141824> 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 smtpd8hWsdO; Thu, 14 Apr 2005 11:24:29 PDT Message-ID: <425EBC50.2070005@iprg.nokia.com> Date: Thu, 14 Apr 2005 11:54:08 -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: anacarolina.minaburo@enst-bretagne.fr Subject: Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> In-Reply-To: <29ed16a4050406063152628e54@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, rohc@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit In general, I like the the idea of using ROHC in the tunnel between the mobile router and the home agent, to reduce the tunnel overhead. I would like to see this draft standardized. one quick comment. > As the addresses are classified as static, each time the MR changes > its attachment point the ROHC context will be initialized. wonder why? the MR could just send a binding update to the HA from the new CoA. binding updates are sent reliably. when the HA processes the binding update, its updates the ROHC context with the new CoA. once the MR receives a binding acknowledgement which shows success status, it also updates the local ROHC context with the new CoA. Vijay Ana Minaburo wrote: > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, March 16, 2005 12:09 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ROHC (Robust Header Compression) in NEMO network > Author(s) : A. Minaburo, et al. > Filename : draft-minaburo-rohc-nemo-00.txt > Pages : 0 > Date : 2005-3-9 > > This document defines the use of ROHC header compression mechanisms > for the NEMO Basic Support protocol [9]. The idea is to use both > NEMO and ROHC as they have been defined without any change. The > tunneling in the NEMO Basic Support protocol will be done over > different supports (Wireless LAN, 3G or PPP) links, where ROHC > compression can work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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. > > > ENCODING mime > FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From nemo-bounces@ietf.org Thu Apr 14 21:00:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17318 for ; Thu, 14 Apr 2005 21:00:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFBF-00049s-9J; Thu, 14 Apr 2005 20:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMFBD-00047R-5C; Thu, 14 Apr 2005 20:59: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 UAA17235; Thu, 14 Apr 2005 20:59:29 -0400 (EDT) Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMFLI-0004KW-9C; Thu, 14 Apr 2005 21:09:57 -0400 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LN4CNC0C5U93FRVG@vaxc.its.monash.edu.au>; Fri, 15 Apr 2005 10:59:16 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7CC0480002; Fri, 15 Apr 2005 10:59:15 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 544D13C008; Fri, 15 Apr 2005 10:59:15 +1000 (EST) Date: Fri, 15 Apr 2005 10:59:09 +1000 From: Greg Daley Subject: Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt In-reply-to: <425EBC50.2070005@iprg.nokia.com> To: Vijay Devarapalli Message-id: <425F11DD.6090901@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> <425EBC50.2070005@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7BIT Cc: nemo@ietf.org, rohc@ietf.org, anacarolina.minaburo@enst-bretagne.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Vijay, I think there may be some value in this, if more than just the next IPv6 header can be compressed. If it doesn't mitigate the NEMO MTU issue, people may not care for it. Regarding the draft itself: Section 2 has all of the details about ROHC compression. For the 7 paragraphs after paragraph 2, there is not a single explicit reference to the ROHC documents for NEMO people to investigate. This section, while brimming with details, seems to leave me feeling I don't have enough ROHC context myself. It would be good to have diagrams illustrating which headers will be subject to compression, and some considerations about the NEMOs themselves (apart from the 10 lines in the first, second and last paragraph of the section). After all, it is called: "The use of ROHC in NEMO" Apart from that, it seems like a good idea in general, not just for NEMO. It seems like a MIPv6 HA/MAP/FMIPv6AR issue too, although the addresses in the upper layer tunnel have more constrained destinations in the non-router case. I didn't see any text about packet reordering in the document. I'd guess that the Internet is about the most likely point-to-point medium to re-order packets. Vijay Devarapalli wrote: > In general, I like the the idea of using ROHC in the tunnel between > the mobile router and the home agent, to reduce the tunnel overhead. > I would like to see this draft standardized. > > one quick comment. > >> As the addresses are classified as static, each time the MR changes >> its attachment point the ROHC context will be initialized. > > > wonder why? the MR could just send a binding update to the HA from > the new CoA. binding updates are sent reliably. when the HA processes > the binding update, its updates the ROHC context with the new CoA. > once the MR receives a binding acknowledgement which shows success > status, it also updates the local ROHC context with the new CoA. Actually, I'm not sure that the draft text itself was accurate. If addresses INSIDE the tunnel changed, then there would have to be changes to the binding or to the context. Why would there need to be changes to the context if the transporting tunnel endpoint addresses - the outer addresses (which aren't subject to compression) change? The data transferred on the tunnel doesn't change because of the CoA change. I'd like to see this document develop maybe as informational if no NEMO-specific protocol issues arise. Greg From nemo-bounces@ietf.org Fri Apr 15 03:25:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01410 for ; Fri, 15 Apr 2005 03:25:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DML7H-0007zc-2d; Fri, 15 Apr 2005 03:19:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DML7E-0007ys-Jj; Fri, 15 Apr 2005 03:19: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 DAA01084; Fri, 15 Apr 2005 03:19:39 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLHD-0000c4-SJ; Fri, 15 Apr 2005 03:30:10 -0400 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j3F7Ik98011072; Fri, 15 Apr 2005 09:18:47 +0200 (MEST) In-Reply-To: <425F11DD.6090901@eng.monash.edu.au> References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> <425EBC50.2070005@iprg.nokia.com> <425F11DD.6090901@eng.monash.edu.au> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3355b6f47b3836070b9015aca6515b30@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt Date: Fri, 15 Apr 2005 09:18:46 +0200 To: greg.daley@eng.monash.edu.au X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Vijay Devarapalli , Carsten Bormann , "'rohc@ietf.org'" , Henrik Levkowetz X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit I'm not sure the present draft is really doing much more than pointing out a potential use for ROHC. To get interoperability, one would need to -- specify how the use of ROHC is negotiated or otherwise initiated between the parties -- specify the encapsulation -- specify how to deal with reordering (see also draft-ietf-rohc-over-reordering-02.txt, which just went to WGLC) -- possibly select a subset of the now no longer trivial gamut of ROHC profiles to choose from. A standards-track document should nail down these (and anything I might have forgotten). We can do without a rehash of ROHC fundamentals. (A couple of diagrams/examples pointing out how the result of the whole thing will look like would be nice, though.) RFC 3241 is one example for the kind of "ROHC-over-X" document needed. Clearly, the two working groups will need to collaborate on this. I don't have a strong feeling which working group should be the "home" WG. Given that similar considerations apply in other uses of ROHC in a mobile IP environment, I'd like to spend some time hallway-discussing this with the usual suspects in Paris. Gruesse, Carsten From nemo-bounces@ietf.org Sun Apr 17 22:45:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNMGQ-0004kW-Au; Sun, 17 Apr 2005 22:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNMGP-0004kP-1O for nemo@megatron.ietf.org; Sun, 17 Apr 2005 22:45:29 -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 WAA13722 for ; Sun, 17 Apr 2005 22:45:25 -0400 (EDT) Received: from [163.152.33.121] (helo=dsys.korea.ac.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNMR1-0000xW-MC for nemo@ietf.org; Sun, 17 Apr 2005 22:56:33 -0400 Received: from shkim ([163.152.21.125]) by dsys.korea.ac.kr (8.12.11/8.12.11) with ESMTP id j3I2gCbC029859 for ; Mon, 18 Apr 2005 11:42:15 +0900 (KST) Message-Id: <200504180242.j3I2gCbC029859@dsys.korea.ac.kr> From: =?ks_c_5601-1987?B?sei8usij?= To: Date: Mon, 18 Apr 2005 11:44:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcVB1O1M8skN1f+PSeWAUOKyS9KA3wB64Wcg In-Reply-To: <200504151605.j3FG5Ll3012766@dsys.korea.ac.kr> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: 7bit Subject: [nemo] RE: Nemo Digest, Vol 12, Issue 15 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org I don't want to receive this mail from today... Thanks.. -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of nemo-request@ietf.org Sent: Saturday, April 16, 2005 1:05 AM To: nemo@ietf.org Subject: Nemo Digest, Vol 12, Issue 15 Send Nemo mailing list submissions to nemo@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/nemo or, via email, send a message with subject or body 'help' to nemo-request@ietf.org You can reach the person managing the list at nemo-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Nemo digest..." Today's Topics: 1. Re: Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt (Vijay Devarapalli) 2. Re: Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt (Greg Daley) 3. Re: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt (Carsten Bormann) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Apr 2005 11:54:08 -0700 From: Vijay Devarapalli Subject: Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt To: anacarolina.minaburo@enst-bretagne.fr Cc: nemo@ietf.org, rohc@ietf.org Message-ID: <425EBC50.2070005@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed In general, I like the the idea of using ROHC in the tunnel between the mobile router and the home agent, to reduce the tunnel overhead. I would like to see this draft standardized. one quick comment. > As the addresses are classified as static, each time the MR changes > its attachment point the ROHC context will be initialized. wonder why? the MR could just send a binding update to the HA from the new CoA. binding updates are sent reliably. when the HA processes the binding update, its updates the ROHC context with the new CoA. once the MR receives a binding acknowledgement which shows success status, it also updates the local ROHC context with the new CoA. Vijay Ana Minaburo wrote: > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, March 16, 2005 12:09 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ROHC (Robust Header Compression) in NEMO network > Author(s) : A. Minaburo, et al. > Filename : draft-minaburo-rohc-nemo-00.txt > Pages : 0 > Date : 2005-3-9 > > This document defines the use of ROHC header compression mechanisms > for the NEMO Basic Support protocol [9]. The idea is to use both NEMO > and ROHC as they have been defined without any change. The tunneling > in the NEMO Basic Support protocol will be done over different > supports (Wireless LAN, 3G or PPP) links, where ROHC compression can > work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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-minaburo-rohc-nemo-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. > > > ENCODING mime > FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > ------------------------------ Message: 2 Date: Fri, 15 Apr 2005 10:59:09 +1000 From: Greg Daley Subject: Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt To: Vijay Devarapalli Cc: nemo@ietf.org, rohc@ietf.org, anacarolina.minaburo@enst-bretagne.fr Message-ID: <425F11DD.6090901@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Hi Vijay, I think there may be some value in this, if more than just the next IPv6 header can be compressed. If it doesn't mitigate the NEMO MTU issue, people may not care for it. Regarding the draft itself: Section 2 has all of the details about ROHC compression. For the 7 paragraphs after paragraph 2, there is not a single explicit reference to the ROHC documents for NEMO people to investigate. This section, while brimming with details, seems to leave me feeling I don't have enough ROHC context myself. It would be good to have diagrams illustrating which headers will be subject to compression, and some considerations about the NEMOs themselves (apart from the 10 lines in the first, second and last paragraph of the section). After all, it is called: "The use of ROHC in NEMO" Apart from that, it seems like a good idea in general, not just for NEMO. It seems like a MIPv6 HA/MAP/FMIPv6AR issue too, although the addresses in the upper layer tunnel have more constrained destinations in the non-router case. I didn't see any text about packet reordering in the document. I'd guess that the Internet is about the most likely point-to-point medium to re-order packets. Vijay Devarapalli wrote: > In general, I like the the idea of using ROHC in the tunnel between > the mobile router and the home agent, to reduce the tunnel overhead. > I would like to see this draft standardized. > > one quick comment. > >> As the addresses are classified as static, each time the MR changes >> its attachment point the ROHC context will be initialized. > > > wonder why? the MR could just send a binding update to the HA from the > new CoA. binding updates are sent reliably. when the HA processes the > binding update, its updates the ROHC context with the new CoA. > once the MR receives a binding acknowledgement which shows success > status, it also updates the local ROHC context with the new CoA. Actually, I'm not sure that the draft text itself was accurate. If addresses INSIDE the tunnel changed, then there would have to be changes to the binding or to the context. Why would there need to be changes to the context if the transporting tunnel endpoint addresses - the outer addresses (which aren't subject to compression) change? The data transferred on the tunnel doesn't change because of the CoA change. I'd like to see this document develop maybe as informational if no NEMO- specific protocol issues arise. Greg ------------------------------ Message: 3 Date: Fri, 15 Apr 2005 09:18:46 +0200 From: Carsten Bormann Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt To: greg.daley@eng.monash.edu.au Cc: nemo@ietf.org, Vijay Devarapalli , Carsten Bormann , "'rohc@ietf.org'" , Henrik Levkowetz Message-ID: <3355b6f47b3836070b9015aca6515b30@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed I'm not sure the present draft is really doing much more than pointing out a potential use for ROHC. To get interoperability, one would need to -- specify how the use of ROHC is negotiated or otherwise initiated between the parties -- specify the encapsulation -- specify how to deal with reordering (see also draft-ietf-rohc-over- reordering-02.txt, which just went to WGLC) -- possibly select a subset of the now no longer trivial gamut of ROHC profiles to choose from. A standards-track document should nail down these (and anything I might have forgotten). We can do without a rehash of ROHC fundamentals. (A couple of diagrams/examples pointing out how the result of the whole thing will look like would be nice, though.) RFC 3241 is one example for the kind of "ROHC-over-X" document needed. Clearly, the two working groups will need to collaborate on this. I don't have a strong feeling which working group should be the "home" WG. Given that similar considerations apply in other uses of ROHC in a mobile IP environment, I'd like to spend some time hallway-discussing this with the usual suspects in Paris. Gruesse, Carsten ------------------------------ _______________________________________________ Nemo mailing list Nemo@ietf.org https://www1.ietf.org/mailman/listinfo/nemo End of Nemo Digest, Vol 12, Issue 15 ************************************ From nemo-bounces@ietf.org Tue Apr 19 09:28:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNslo-0008UV-CC; Tue, 19 Apr 2005 09:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNslm-0008TK-La for nemo@megatron.ietf.org; Tue, 19 Apr 2005 09:28:02 -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 JAA09340 for ; Tue, 19 Apr 2005 09:27:57 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNswi-0006zm-Bn for nemo@ietf.org; Tue, 19 Apr 2005 09:39:23 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IF700I01429TM@mailout1.samsung.com> for nemo@ietf.org; Tue, 19 Apr 2005 22:27:45 +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 <0IF700MTT429X7@mailout1.samsung.com> for nemo@ietf.org; Tue, 19 Apr 2005 22:27:45 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IF700B7N426XZ@mmp2.samsung.com> for nemo@ietf.org; Tue, 19 Apr 2005 22:27:45 +0900 (KST) Date: Tue, 19 Apr 2005 18:56:37 +0530 From: Ranjitsinh Wable Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-DACTION:draft-minaburo-rohc-nemo-00.txt To: nemo@ietf.org Message-id: <033001c544e3$71d3d460$41476c6b@sisodomain.com> 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; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200504031354.j33Ds1Rl019822@mmlab.snu.ac.kr> <29ed16a4050406063152628e54@mail.gmail.com> <425EBC50.2070005@iprg.nokia.com> <425F11DD.6090901@eng.monash.edu.au> <3355b6f47b3836070b9015aca6515b30@tzi.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I agree with Greg and Carsten. The draft just suggest that we can use ROHC in the NEMO but does not cover any details about actual usage of it. Further disucssions and the modification to the draft will help in the generating better document. --Wable ----- Original Message ----- From: "Carsten Bormann" To: Cc: ; "Vijay Devarapalli" ; "Carsten Bormann" ; ; "Henrik Levkowetz" Sent: Friday, April 15, 2005 12:48 PM Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-DACTION:draft-minaburo-rohc-nemo-00.txt > I'm not sure the present draft is really doing much more than pointing out > a potential use for ROHC. > > To get interoperability, one would need to > -- specify how the use of ROHC is negotiated or otherwise initiated > between the parties > -- specify the encapsulation > -- specify how to deal with reordering (see also > draft-ietf-rohc-over-reordering-02.txt, which just went to WGLC) > -- possibly select a subset of the now no longer trivial gamut of ROHC > profiles to choose from. > A standards-track document should nail down these (and anything I might > have forgotten). > We can do without a rehash of ROHC fundamentals. > (A couple of diagrams/examples pointing out how the result of the whole > thing will look like would be nice, though.) > > RFC 3241 is one example for the kind of "ROHC-over-X" document needed. > > Clearly, the two working groups will need to collaborate on this. > I don't have a strong feeling which working group should be the "home" WG. > Given that similar considerations apply in other uses of ROHC in a mobile > IP environment, I'd like to spend some time hallway-discussing this with > the usual suspects in Paris. > > Gruesse, Carsten > > > > From nemo-bounces@ietf.org Mon Apr 25 08:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ31k-0005xT-Qj; Mon, 25 Apr 2005 08:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ31X-0005wX-0G for nemo@megatron.ietf.org; Mon, 25 Apr 2005 08:49: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 IAA12524 for ; Mon, 25 Apr 2005 08:49:08 -0400 (EDT) Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ3Da-0007ql-Fu for nemo@ietf.org; Mon, 25 Apr 2005 09:01:49 -0400 Received: from trust ([220.121.192.89]) by mmlab.snu.ac.kr (8.12.10/8.12.10) with ESMTP id j3PCwoFY031382; Mon, 25 Apr 2005 21:58:50 +0900 (KST) (envelope-from eun@mmlab.snu.ac.kr) Message-Id: <200504251258.j3PCwoFY031382@mmlab.snu.ac.kr> From: "Eun Kyoung PAIK" To: "'Ranjitsinh Wable'" , Subject: RE: [rohc] Re: [nemo] Fwd: FW:I-DACTION:draft-minaburo-rohc-nemo-00.txt Date: Mon, 25 Apr 2005 21:48:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AcVE5RMvKaaRBA/JSnWjeb8R8ZNR3QEri66g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <033001c544e3$71d3d460$41476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: anacarolina.minaburo@enst-bretagne.fr X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Folks, Thank you for all of your interest and comments on our draft. We will resolve the comments on this mailing list and announce the new version of draft soon. Best Regards, Eun Kyoung > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of > Ranjitsinh Wable > Sent: Tuesday, April 19, 2005 10:27 PM > To: nemo@ietf.org > Subject: Re: [rohc] Re: [nemo] Fwd: FW:I-DACTION:draft-minaburo-rohc-nemo- > 00.txt > > Hi, > > I agree with Greg and Carsten. The draft just suggest that we can use ROHC > in the NEMO but does not cover any details about actual usage of it. > > Further disucssions and the modification to the draft will help in the > generating better document. > > --Wable > > ----- Original Message ----- > From: "Carsten Bormann" > To: > Cc: ; "Vijay Devarapalli" ; "Carsten > Bormann" ; ; "Henrik Levkowetz" > > Sent: Friday, April 15, 2005 12:48 PM > Subject: Re: [rohc] Re: [nemo] Fwd: FW: > I-DACTION:draft-minaburo-rohc-nemo-00.txt > > > > I'm not sure the present draft is really doing much more than pointing > out > > a potential use for ROHC. > > > > To get interoperability, one would need to > > -- specify how the use of ROHC is negotiated or otherwise initiated > > between the parties > > -- specify the encapsulation > > -- specify how to deal with reordering (see also > > draft-ietf-rohc-over-reordering-02.txt, which just went to WGLC) > > -- possibly select a subset of the now no longer trivial gamut of ROHC > > profiles to choose from. > > A standards-track document should nail down these (and anything I might > > have forgotten). > > We can do without a rehash of ROHC fundamentals. > > (A couple of diagrams/examples pointing out how the result of the whole > > thing will look like would be nice, though.) > > > > RFC 3241 is one example for the kind of "ROHC-over-X" document needed. > > > > Clearly, the two working groups will need to collaborate on this. > > I don't have a strong feeling which working group should be the "home" > WG. > > Given that similar considerations apply in other uses of ROHC in a > mobile > > IP environment, I'd like to spend some time hallway-discussing this with > > the usual suspects in Paris. > > > > Gruesse, Carsten > > > > > > > > >