Subject: RE: [nemo] carrying IPv4 traffic using MIP6/NEMO

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 8 Aug 2005 10:53:27 -0400

> 
 > Generally it looks like an interesting idea.  Why restraining the
 > binding to a fixed /32 full v4 address when binding a variable prefix
 > (1...32) could bring the benefit of giving v4 access to all 
 > nodes in the
 > moving network (not only to the MR).  So this may look as an obvious
 > advantage.
 > 
 > However, I was wondering how much would this addition extend 
 > the current
 > scope of the DT work, whose goal was mainly to give v6 (not 
 > v4) access
 > to MR and mobile nodes when MR connects to a v4 network.
 > 
 > Giving continuous v4 access to mobile nodes in a moving 
 > network whose MR
 > connects to a v4 access network can naturally be obtained by running
 > Mobile IPv4 on the MR, too.
 > 
 > What does the DT think?

=> We discussed this and I had extended draft-soliman to represent
the IP address as : address/prefixlen, where prefixlen is anything up
to 32. It's a useful feature that only adds another 5 mins of work so why
not. 

Hesham

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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 9 Aug 2005 00:11:28 +0900

Hello Hesham

I thought you were opposed to support NEMOv4 during the discussion in  
DT.

Are there any big differences between draft-soliman(w/prefixlen)
and draft-keiichi for NEMO support?

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Aug 2005 11:31:21 +0200

Hello Hesham,

Soliman, Hesham wrote:
>> binding to a fixed /32 full v4 address when binding a variable 
>> prefix (1...32) could bring the benefit of giving v4 access to all 
>> nodes in the moving network (not only to the MR).  So this may look
>> as an obvious advantage.
>> 
>> However, I was wondering how much would this addition extend the 
>> current scope of the DT work, whose goal was mainly to give v6 (not
>>  v4) access to MR and mobile nodes when MR connects to a v4 
>> network.
>> 
>> Giving continuous v4 access to mobile nodes in a moving network 
>> whose MR connects to a v4 access network can naturally be obtained 
>> by running Mobile IPv4 on the MR, too.
>> 
>> What does the DT think?
> 
> => We discussed this

Great, does the DT have a requirement for giving v4 access to nodes in a
moving network whose MR runs Mobile IPv6 and connects to a v4 access
network?

If yes, does the requirement include v4 session continuity?  Does the
requirement include reachability at a permanent v4 address?  These
aspects are important, at least for deciding on whether or not to use
NAT within the moving network (see draft-shima).

> and I had extended draft-soliman to represent the IP address as :
> address/prefixlen, where prefixlen is anything up to 32. It's a
> useful feature that only adds another 5 mins of work so why not.

Hesham, did you encode the prefixlen on 8 or 5 bits?  Anyways, I don't
think simply adding a v4 prefixlen into a message format is as easy as
it may look.  Conceptually - yes, just use a prefixlen, but from there
to a protocol may be a longer way.  For example, what happens when MR's
v4 Home Address is independent of the Mobile Network Prefix (they differ
starting at the 0th bit).

I think giving v4 access to nodes in the moving network would best be
done by a NEMOv4 protocol.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 21:54:54 +0900

Hi Alex.

> NAT within the moving network (see draft-shima).

Using NAT in the mobile network is possible if MR has at least one  
global v4 address.
I attach discussion in DT ML.

ryuji

> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>
>

On 2005/07/22, at 8:26, Soliman, Hesham wrote:

>
>
>
>>>> If a MR uses IPv4 feature of MIP6, it may use the IPv4
>>>> global address
>>>> for NATed mobile network.
>>>> This is one way to provide v4 connectivity to NEMO, but I prefer
>>>> clean solution.
>>>>
>>>>
>>>
>>> => Please elaborate on the scenario you're describing, a picture
>>> might help. If the MR has an IPv4 prefix for the MNNs behind it,
>>>
>>
>> something like this.
>>
>>                                IPv4 global            IPv4 private
>> HA----Internet --- MR (NAT) -------Mobile Networks
>>
>> MR sends BU including IPv4 global address to HA as you proposed and
>> uses the IPv4 global address for NATed mobile network.
>> MR acts as NAT BOX for mobile network.
>>
>
> => Ok, this is exactly the same as a mobile host. The same should
> work regardless of it being an MR.
>
>
>> If NEMO is operated with implicit mode and dynamic routing protocol
>> like OSPF,
>> it fines. However, if MR sends BU with MNP options (no OSPF
>> running),
>> how can MR notify the IPv4 prefix to HA?
>> This is the same problem with MIP6, isn't this?
>>
>
> => You just showed an example where the MR is a NAT. If
> you want to propose a nemo basic solution for IPv4 then
> this is not the right place to solve it. IF there is a nemo
> solution for v4 we can easily add the IPv4 prefix option.
> This is a 5 min job, *if* that solution exists.
>
> Hesham
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Aug 2005 15:17:01 +0200

Hi Ryuji,

Ryuji Wakikawa wrote:

>>>> Generally it looks like an interesting idea.  Why restraining
>>>> the binding to a fixed /32 full v4 address when binding a
>>>> variable prefix (1...32) could bring the benefit of giving v4
>>>> access to all nodes in the moving network (not only to the MR).
>>>> So this may look as an obvious advantage.
>>>> 
>>>> the current scope of the DT work, whose goal was mainly to give
>>>> v6 (not v4) access to MR and mobile nodes when MR connects to a
>>>> v4 network.
>>>> 
>>>>  whose MR connects to a v4 access network can naturally be
>>>> obtained by running Mobile IPv4 on the MR, too.
>>>> 
>>>> What does the DT think?
>>>> 
>>> 
>>> => We discussed this
>>> 
>> 
>> Great, does the DT have a requirement for giving v4 access to nodes
>> in a moving network whose MR runs Mobile IPv6 and connects to a v4
>> access network?
>> 
>> If yes, does the requirement include v4 session continuity?  Does
>> the requirement include reachability at a permanent v4 address?
>> These aspects are important, at least for deciding on whether or
>> not to use NAT within the moving network (see draft-shima).
> 
> 

I agree using NAT in the mobile network is possible.  I also agree that
if NAT is used in the mobile network then there can be no mip6trans
requirement for reachability at a permanent v4 address (behind NAT the
v4 nodes are not reachable, somebody can't connect() to them).

All in all, IMHO, mip6trans should not waste effort on giving v4 access
to nodes in the moving network; if it does (because consensus) then
shouldn't do it with NAT.

My oppinion,

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 22:29:57 +0900

Hi Alex

> v4 nodes are not reachable, somebody can't connect() to them).

Well, that is limitation of NAT...

> to nodes in the moving network; if it does (because consensus) then

We should work on v4 reachability, because MIP6 WG already has the
problem statement draft (draft-ietf-dsmip),
And It makes sense to have a similar/common solution, because
both goals are to establish tunnel between HA-MN after all.

The question may be whether we should split document or not?!

> shouldn't do it with NAT.

Do you mean doing NAT in mobile networks?

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Aug 2005 16:04:43 +0200

Ryuji Wakikawa wrote:
>> All in all, IMHO, mip6trans should not waste effort on giving v4 
>> access to nodes in the moving network; if it does (because 
>> consensus) then
> 
> problem statement draft (draft-ietf-dsmip), And It makes sense to 
> have a similar/common solution, because both goals are to establish 
> tunnel between HA-MN after all.

I am confused.  dsmip problem statement is not mip6trans
problem-statement/reqs/scenarios.

The mip6trans and dsmip problem statements are different at least in size.

In my understanding, I was thinking that the problem mip6trans is trying
to solve was to give IPv6 access to a MH connecting to a v4 network.
Or, this requirement is not even listed now in the mp6trans requirements.

dsmip problem statement looks more wider reach, doing all v4/v6 mobility
by extending only the Mobile IPv6 protocol.

> The question may be whether we should split document or not?!

If "split" means separate the dsmip documents and the mip6trans
documents, goals, requirements, scenarios, I'd vote for it.

If "split" means separate draft-soliman from draft-shima with respect to
v4 access, I'd vote against.  Better have a unique document that does
Mobile IPv6-based dsmip-v4-access than two.  But not for mip6trans.

> Do you mean doing NAT in mobile networks?

Yes, that's what I meant.  In detail, if v4 access to nodes in the
mobile network is to be developped anywhere, then don't do it in
mip6trans and don't do it with NAT in the mobile network.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 10 Aug 2005 23:20:52 +0900

Alex

> Or, this requirement is not even listed now in the mp6trans  

it is included.

> Mobile IPv6-based dsmip-v4-access than two.  But not for mip6trans.

I just tried to get back to the original question of keiichi:-)
If we have a unique solution for MIP6 and NEMO v4 access, I am fine  
either way.

> mip6trans and don't do it with NAT in the mobile network.

If MR can get v4 HoA through Hesham idea, MR can do NAT without any  
modifications.
I don't know whether we need additional modification after v4 HoA  
assignment. NAT is NAT:-)

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Aug 2005 17:08:53 +0200

>> Or, this requirement is not even listed now in the mp6trans 

Sorry, mistake, I think I've missed it when copy/paste.  I've looked
again and it's there.

Alex