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

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

> 
 > I agree.  The extra overhead may appear if a DSMIPv6 MR is 
 > used to give
 > v4 access to LFNs, instead of MIP4. 

=> I can't see hoe this could possibly be true.

  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.

=> It does. The address/prefix format allows an MR to request an 
IPv4 prefix.

 > > => I disagree. FW traversal sounds like port scanning. 
 > We're not in 
 > > the business of standardising attacks on a closed network.
 > 
 > We aren't, so call it UDP path discovery instead of port scanning.

=> It doesn't matter what you call it, it's still port scanning.
IETF should not be trying to penetrate closed networks despite 
the administrator.

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

=> Please read the problem statement.

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

=> Please read the problem statement, otherwise it's not useful to continue
this discussion. 

Hesham

 > Alex

===========================================================
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 22:34:55 +0200

[snipping some stuff for whatever reason]
Soliman, Hesham wrote:
>> 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.
> 
> => It does. The address/prefix format allows an MR to request an IPv4
>  prefix.

Well, ok.  That was precisely what I was trying to avoid.

Usually IPv4 prefixes are requested with DHCP-PD.

IPv4 prefixes may be registered with a Registration Request too.

Why using an IPv6 BU for that, especially when connected to a v4-only
network?  My claim is that there's no advantage in doing that.

> => It doesn't matter what you call it, it's still port scanning. IETF
>  should not be trying to penetrate closed networks despite the 
> administrator.

How about non-intrusive UDP path detection then?

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

The problem statement mostly says "running MIP4 and MIP6 simultaneously
is a burden" and the DSMIPv6 solution looks nothing short of a bigger
burden.

Would you please summarize your thoughts in a few lines about why not
using MIPv4 for v4 Home Addresses?  If it's not possible to have a 3
liner on that for a 30seconds elevator speech I don't think the problem
is valid.

A good problem shows that something breaks, while the only thing
mentioned in the Problem Statement that may seem to break is the following:
> A final point to consider is that even if both mobility protocols are
>  supported by a mobile node seamless connectivity would not in fact
> be guarantied since that also depends on the IPv4/IPv6 capabilities
> of the networks the mobile is visiting i.e.: a dual stack node 
> attempting to connect via a IPv4 only network would not be able to 
> maintain connectivity of its IPv6 applications and vice versa.

which is basically presenting an apparent paradox: if both MIP6 and MIP4
are run then no seamless IPv4 and IPv6 connectivity, because an
application can't seamlessly switch its stream from v4 to v6.  Well, an
application seamlessly switching its streaming from a v4 socket to a v6
socket is something not in the field of MIP I believe, and could be
achieved without MIP techniques.

If you wish, we could discuss the above paragraph separately.  My
conclusion about it is that it addresses a problem that is not in the
scope of MIP itself, or largely surpasses it.

>> Yes, and please provide it with MIP4, not with v4 MIP6 
>> enhancements. MIP4 does it better when it comes to IPv4 Home 
>> Addresses, no?
> 
> => Please read the problem statement, otherwise it's not useful to 
> continue this discussion.

I've just read.

The problem statement draft is not the problem I know.

I guess you won't agree to the relevance of the problem I know (MIPv6
MN, v6 app, connect to v4-only access network), so let me also say I
don't agree with the problem statement.

Alex