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

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

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

=> You're discussing a separate topic here. I didn't make any comments
about this. Are you talking about MIPv4? If so, then there is no 
encapsulation. MIPv4 assumes that it is possible for the MN to
use it's home address in a foreign network and that ingress 
filtering will not drop the packet. It also allows the FA to reverse
tunnel. If you choose reverse tunnelling then I don't understand
where the extra overhead in encapsulation is.

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

=> No! Please read the draft again. The draft says:
 - IPv6 in IPv4 (foreign network using public IPv4 addresses only)
 - IPv6 in UDP/IPv4 (if a NAT is detected).

That IPv6
 > encapsulation is pure overhead.

=> Yes and we don't do it...

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

=> That's the *goal* of the draft. We discussed this in IETF when the
scenarios and requirements were presented. No one disagreed with
this requirement.

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

=> Sure, we can add that. 

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

=> I disagree. FW traversal sounds like port scanning. We're not in 
the business of standardising attacks on a closed network. 
What do you do if a FW disables the mobility header?? Should we
encapsulate MIPv6 in HTTP?

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

=> You're objecting to something we never did. I agree it's not needed!
We don't do that.

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

=> MIPv6 was not chosen over MIPv4. We're standardising a MIPv6 solution
in the MIP6 WG and I'm going to ask the MIP4 WG to do the same thing 
for MIPv4. I don't know why you assume we *chose* MIPv6 over MIPv4.

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

=> Do you assume that all hosts will use IPv6 applications and 
only communicate with other IPv6 hosts? If the answer is no, then
you need to provide them a stable IPv4 address (read:home address). 
And you need to provide mobility for that address. This is what the
draft does.

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

=> See my reply. BTW, there is no IPv4 IPsec and IPv6 IPsec. The same 
protocol works for both.

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

=> I think the draft proves that this goal is easily achievable.

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 21:54:28 +0200

Soliman, Hesham wrote:
>>  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.
> 
> => You're discussing a separate topic here. I didn't make any 
> comments about this. Are you talking about MIPv4?

Yes, I am talking about MIPv4.

> If so, then there is no encapsulation. MIPv4 assumes that it is 
> possible for the MN to use it's home address in a foreign network and
>  that ingress filtering will not drop the packet. It also allows the 
> FA to reverse tunnel. If you choose reverse tunnelling then I don't 
> understand where the extra overhead in encapsulation is.

I agree.  The extra overhead may appear if a DSMIPv6 MR is used to give
v4 access to LFNs, instead of MIP4.  I don't think DSMIPv6 draft tries
to give v4 access to LFNs, because it does not encode MNPs in its
messaging, which is a good thing.

>> encapsulates LFN IPv4 packets in IPv6 and then again in IPv4.
> 
> => No! Please read the draft again. The draft says: - IPv6 in IPv4 
> (foreign network using public IPv4 addresses only) - IPv6 in UDP/IPv4
>  (if a NAT is detected).

Ok, I read.  I agree.

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

We aren't, so call it UDP path discovery instead of port scanning.

> encapsulate MIPv6 in HTTP?

Well, people could do whatever they want.  If attacks are going to
happen because of the Mobility Header then that's sure being disabled.

About encapsulating MIP6 over HTTP.  People who absolutely want to run
IPv6 on their nodes today go to encapsulating v6 in many things and it
works.

But I agree there's only so much it can be done about some NAT/FW
traversal scheme.

>> See above where I explain that MIP6 MR giving IPv4 LFN 
>> unnecessarily encapsulates in v6 when connecting to a v4 network.
> 
> => You're objecting to something we never did. I agree it's not 
> needed! We don't do that.

I think I agree I'm objecting to something I may have misinterpreted.
So I suggest that since this draft talks about NEMO at several places to
mention that this draft does not offer enhancements to NEMOv6 MR to give
IPv4 access to LFNs.

Let me explain:  the abstract says
      "The current Mobile IPv6 and NEMO specification support only IPv6.
       Hence, this specification extends those standards to allow the
       registration of IPv4 addresses and prefixes, respectively"

Why would one need to register IPv4 addresses and prefixes with MIP6 and
not with MIP4?

This specification should provide something to offer IPv6 permanent Home
Addresses to a MIP6 node connecting to a v4-only network, no?  I don't
think there is any need to provide IPv4 Home Addresses to MN with MIP6
(when MN connects to a v4 network).

> => MIPv6 was not chosen over MIPv4. We're standardising a MIPv6 
> solution in the MIP6 WG and I'm going to ask the MIP4 WG to do the 
> same thing for MIPv4. I don't know why you assume we *chose* MIPv6 
> over MIPv4.

Right...

>> 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.
> 
> => Do you assume that all hosts will use IPv6 applications and only 
> communicate with other IPv6 hosts?

Right, some applications are still v4.

> If the answer is no, then you need to provide them a stable IPv4 
> address (read:home address). And you need to provide mobility for
> that address. This is what the draft does.

Yes, and please provide it with MIP4, not with v4 MIP6 enhancements.
MIP4 does it better when it comes to IPv4 Home Addresses, no?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 22:17:13 +0200

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

I was there at the last meeting and I disagreed at the microphone about
this solution offering v4 access to LFNs.  That's my rememberings.
Whether that gets through or not is another issue.

Anyways, not between me and you to agree, right?  It's a WG.

Alex