Subject: Re: [mobile-ip] RE: Comments on draft-tsirtsis-dsmip-problem-01.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Sep 2003 17:39:31 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Pekka Savola wrote:
>>> If you wanted a tunnel setup protocol, you would not need MIP in 
>>> the first place, just dynamic VPN mechanism.
>> 
>> => Like what ?? MIP sets up tunnels dynamically between the MN and 
>> HA (v4 and v6) and any-to-any (MIPv6 RO).
> 
> 
> If you just wanted MN<->HA communication, all you would need is a VPN
>  which updates your care-of address to the HA regularly.  RO is the 
> thing that sets it apart.  I would not call MIPv6 RO a tunnel, and it
>  is not parcticularly useful in this context as the transport is 
> heavily IPv6-specific.

Sorry for interfering, me too risking to trivialize and loose sight, I
would summarize Mobile IPv6 behaviour as dynamic tunnel setup and RO and
also proxy ND.

With respect to dual-stacks, the thing I'd like to have is the Mobile
IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of v6-in-v6, and
moreover that tunnel to drill through the NAT gateway, and even stay up
when applications are silent (heartbeats bubbling or such).  This would
allow an IPv6 mobile host to attach to an exclusively-v4
public-access-private-address ISP, and then to another, while
maintaining a fixed IPv6 Home Address.  By my reading, the draft already
covers this case, so I don't complain.

Alex
GBU

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 10:57:11 +0300 (EEST)

I'm picking up one issue here which may be interesting for a bigger 
audience too.  I'm also tailing down the Cc: list.

On Mon, 1 Sep 2003, Alexandru Petrescu wrote:
[...]
> covers this case, so I don't complain.

My concern is this: we already have about half a dozen IPv4 NAT traversal 
techniques (IPsec, MIPv4, STUN, TURN, a number of others) -- and some have 
been proposed to allow IPv6-in-IPv4 tunneling to also traverse NAT (none 
taken up by this WG, at the moment, though.).

So you want to implement and specify one for dual-stack Mobile IPv6 *too*?  
:...-(((

My _personal_ two top priorities in this context: 

 1) make sure NAT traversal stays an _IPv4_ problem.  Traverse a NAT to 
get a global IPv4 address, then activate an IPv6 transition mechanism.  
Everything is transparent to the IPv6 transition mechanism.

 2) failing that, provide *one*, *very simple* (most likely, a
bidirectional tunnel or something like that) mechanism which is close to
bulletproof to enable IPv6 tunneling over NAT.  When you have an IPv6
connectivity, you don't have to worry about NAT's anymore in any of the
scopes listed above (MIP, IPsec, etc.etc.).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Sep 2003 12:38:59 +0200

Pekka Savola wrote:
>> With respect to dual-stacks, the thing I'd like to have is the
>> Mobile IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of
>> v6-in-v6
> 
> My concern is this: we already have about half a dozen IPv4 NAT
> traversal techniques (IPsec, MIPv4, STUN, TURN, a number of others)
> -- and some have been proposed to allow IPv6-in-IPv4 tunneling to
> also traverse NAT (none taken up by this WG, at the moment, though.).

Good to have a rich set of proposals, selecting is easier than building.

> So you want to implement and specify one for dual-stack Mobile IPv6 

No, I want Mobile IPv6 to not require its MN-HA tunnel to be v6-in-v6
but to require it to be either v6-in-v6 or v6-in-v4.

> 1) make sure NAT traversal stays an _IPv4_ problem.

I've heard this concern before, so I guess it is right.  Also, there 
were concerns expressed that NAT's are unqualifiable and unclassifiable 
beasts, so one can not really find a common means to drill through all 
of them.  Which is perfectly right to a certain extent.

> Traverse a NAT to get a global IPv4 address, then activate an IPv6
> transition mechanism. Everything is transparent to the IPv6
> transition mechanism.

> bidirectional tunnel or something like that) mechanism which is close
> to bulletproof to enable IPv6 tunneling over NAT.  When you have an
> IPv6 connectivity, you don't have to worry about NAT's anymore in any
> of the scopes listed above (MIP, IPsec, etc.etc.).

Sounds like a good stepwise scheme, provided that one can identify that
most simple bullet-proof mechanism, and that mechanism is not an "IP
over SMTP" April's fool.

Because I doubt that, I'm bringing back the mobility aspect: mobility
systems are deployed only in a limited set of kinds of systems (say GPRS
and hotspots, but there are others), cover only a limited set of types 
of NAT; for those 3-5 types of NAT's maybe a common NAT traversal 
mechanism can be found.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Sep 2003 23:40:37 +0300 (EEST)

> Good to have a rich set of proposals, selecting is easier than building.

That's one perspective, with a set of tradeoffs.  Some (many?) people also 
argue otherwise: with too much choice, the user if faced with a dilemma on 
what to choose, and the vendor is faced with the dilemma on what to 
implement (so it has to implement all), etc.
 
> but to require it to be either v6-in-v6 or v6-in-v4.

But because you'd like that to work also where v4 NAT is done, a simple 
v6-in-v4 tunnel would not be enough -- it would have to be able to handle 
NAT traversal -- right?
 
> of them.  Which is perfectly right to a certain extent.

Well, I think this depends *very* much on how big holes you want to drill.  
Bidirectional tunneling?  No problem.  Drilling through from pretty much 
everywhere?  Certainly there are issues.

[...]
> of NAT; for those 3-5 types of NAT's maybe a common NAT traversal 

I'm not sure if we can make that kind of assumptions about Mobile IP 
deployment, but if we can, fine -- it's still a lot.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 08 Sep 2003 15:35:09 +0200

=> you can't do that with Mobile IPv6 itself but it is still possible
to use an alternative, i.e., something which looks like Mobile IPv6
but works for both IP versions. If you wouldn't like to get routing
optimization (something a bit hard in this case :-), I suggest the
"road warrior" IPsec VPN. But, even if RFC 2401 is clearly for any
combination of IP versions, I am afraid that the v6-in-v4 is rarely
supported...

Regards

[email-masked]