Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 25 Oct 2005 14:00:55 -0400

Alex, 

Thanks for the reasoning. Comments inline

 > >> I do not agree with the MR obtaining a v4 CoA and then 
 > sending a BU
 > >>  with a v4 Mobile Network Prefix.
 > > 
 > > => Why?
 > 
 > Because MIP4 could do it better.  Using MIP4 instead of MIP6 in this
 > particular scenario would avoid going through v6, so a level of
 > encapsulation eliminated.

=> MIPv4 does not do it any better, whatever your definition of 
"better" might be. It does it differently. There is less encapsulation
in the case where the MN is using an FA and no NATs are located between
the MN and the HA. However, this argument becomes less significant when
you consider the following:

- The whole point of the draft is to allow MIPv6 to be used regardless
of the access network capabilities. Please read the problem statement. 
- Most large scale deployments of IPv4 in public networks use NATs. For
those scenarios there is no difference in encapsulation.

 > >> It is natural for MR to obtain a v4 CoA and then send a 
 > MIP4 RegReq
 > >>  containing a v4 Mobile Network Prefix (and not a v6 BU).  Would 
 > >> you agree with this?
 > > 
 > > => Please read the problem statement where it is clearly 
 > stated that
 > >  running MIPv4 and MIPv6 simultaneously in inefficient
 > 
 > I've read it.  Two technical reasons raised my interest: (1) MIP6 is
 > better than MIP4 because has DHAAD and RO, (2) sending BU and RegReq
 > each time is not efficient.

=> This is not the problem statement. I was referring to:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt

 > > [running MIP4 and MIP6 simultaneously] prevent a node from having 
 > > mobility across different networks supporting different IP 
 > versions.
 > 
 > This can not be true, tell me.  Having both MIP4 and MIP6 in a same
 > node can not prevent mobility across different networks supporting
 > different IP versions.  

=> Please read the draft above.

 > If the application needs to have a permanent v4/v6 Home 
 > Address even if
 > connected to the other IP version network then yes, one could use
 > enhancements.  

=> So, you are aware of those problems. 

  But even in that case I have remarks I'd keep 
 > separate.

=> What are they?

 > >> Normally I agree, but here we talk IP version numbers.
 > > 
 > > => The whole point of this work is to make MIP work without being 
 > > tied to "version numbers"..
 > 
 > That's a good goal.  But more precise would be to make MIP6 (not MIP)
 > beeing tied to "version numbers".

=> I assume you meant "..not being tied to...". If you agree it's a good
goal then I'm very confused about your objections.

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 20:36:56 +0200

Soliman, Hesham wrote:
>> Because MIP4 could do it better.  Using MIP4 instead of MIP6 in 
>> this particular scenario would avoid going through v6, so a level 
>> of encapsulation eliminated.
> 
> "better" might be. It does it differently. There is less 
> encapsulation in the case where the MN is using an FA and no NATs are
>  located between the MN and the HA.

The fact that FAs or NATs are present don't influence MR having to
encapsulate packets from a v4 LFN.  Whatever MR connects to - v4 or v6,
FA or NAT - the MR must encapsulate packets from LFN, for NEMO reasons.

If MR connects to a v4 network and MIP6 is used (no MIP4) then MR
encapsulates LFN IPv4 packets in IPv6 and then again in IPv4.  That IPv6
encapsulation is pure overhead.

> However, this argument becomes less significant when you consider the
>  following:
> 
> - The whole point of the draft is to allow MIPv6 to be used 
> regardless of the access network capabilities.

Yes, I agree.  It goes further than just that though, at least because
it suggests offering IPv4 access to LFNs, without real MIP4 support.

For example, although the draft proposes using permanent IPv4 Home
Addresses with MIP6, and suggests HA has an IPv4 address, it says
nothing about that HA doing proxy ARP for the v4 address received in the BU.

> Please read the problem statement. - Most large scale deployments of
>  IPv4 in public networks use NATs.

YEs, and most large scale deployments use Firewalls coupled to NATs and
there's no large scale IPv6 access network deployments for wireless
mobiles.  Hence the suggestion to move focus from v4-LFN to Firewall
traversal.

> For those scenarios there is no difference in encapsulation.

See above where I explain that MIP6 MR giving IPv4 LFN unnecessarily
encapsulates in v6 when connecting to a v4 network.

>> I've read it.  Two technical reasons raised my interest: (1) MIP6 
>> is better than MIP4 because has DHAAD and RO, (2) sending BU and 
>> RegReq each time is not efficient.
> 
So what I've read in the DSMIPv6 draft about MIP6 being selected over
MIP4 because RO and DHAAD is not conformant to:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt

>> If the application needs to have a permanent v4/v6 Home Address 
>> even if connected to the other IP version network then yes, one 
>> could use enhancements.
> 

I am deeply aware of the following problem: a MIPv6 MH connecting to a
NAT-v4-only network can't normally use its permanent IPv6 Home Address.

I am not aware of a problem where an IPv4 LFN with an IPv6 MR connecting
to a v4-only network needs to communicate.  The problem statement may
mention it though, but I don't find it to be a problem other than on paper.

>> But even in that case I have remarks I'd keep separate.
> 
> => What are they?

See the Security thread and wonder how could one protect against the
threats mentioned there and think that using IPv4 IPsec (in addition to
IPv6 IPsec) may be a good solution.

>> That's a good goal.  But more precise would be to make MIP6 (not 
>> MIP) beeing tied to "version numbers".
> 
> => I assume you meant "..not being tied to...". If you agree it's a 
> good goal then I'm very confused about your objections.

Yes, that's what I meant.  I agree it is a good goal to the point of
thinking it may be a too high goal to provide all possible combinations
of v4/v6 MR/MH/LFN simply with v4 enhancements of MIP6.

Alex