RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Fri, 01 April 2005 16:12 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09109 for <mip6-web-archive@ietf.org>; Fri, 1 Apr 2005 11:12:53 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOsp-00085u-Vk for mip6-web-archive@ietf.org; Fri, 01 Apr 2005 11:20:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOja-00074M-8r; Fri, 01 Apr 2005 11:10:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOjW-00073x-OV; Fri, 01 Apr 2005 11:10:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08918; Fri, 1 Apr 2005 11:10:52 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOqq-00080G-GD; Fri, 01 Apr 2005 11:18:30 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2005 18:10:43 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j31GAUtD016439; Fri, 1 Apr 2005 18:10:38 +0200 (MEST)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Apr 2005 18:10:32 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document
Date: Fri, 01 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)" <pthubert@cisco.com>
To: Vijay Devarapalli <vijayd@iprg.nokia.com>, Henrik Levkowetz <henrik@levkowetz.com>
X-OriginalArrivalTime: 01 Apr 2005 16:10:32.0149 (UTC) FILETIME=[5460C850:01C536D5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Content-Transfer-Encoding: quoted-printable
Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Content-Transfer-Encoding: quoted-printable


| -----Original Message-----
| From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf
Of
| Vijay Devarapalli
| Sent: Thursday, March 31, 2005 10:02 PM
| To: Henrik Levkowetz
| Cc: nemo@ietf.org; mip6@ietf.org; Basavaraj.Patil@nokia.com
| Subject: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-
| nemo-v4tunnel a MIP6/NEMO WGs document
| 
| 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.

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. 

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. 

The Doors GW is fully stateless and inherits from 6to4. 

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.  

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












| 
| 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