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

From: Conny Larsson <[email-masked]>
Date: Fri, 01 Apr 2005 09:10:02 +0200

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: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of [email-masked]
>>Sent: Wednesday, March 30, 2005 9:33 PM
>>To: [email-masked]; [email-masked]
>>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
>>[email-masked]
>>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 
>[email-masked]. Thank you
>====================================================================
>
>  
>

---

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 01 Apr 2005 16:14:12 +0200

Hi Vijay,

please see below..

> > interesting one and I'm favor of focusing on it immediately. 
> 
> great.
> 
>  > However I
> 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).
> 
> 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.
> 
> 2) There are people who have deployed MIPv4. They want to move to
>     MIPv6.
> 
> 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. 
 
> > scenario in a very similar way. 
> 
> 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.
> 

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. 

> > The main difference is the BU message
> > message. 
> 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.
> 

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