Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WGs document

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Apr 2005 10:58:39 +0200

Vijay Devarapalli wrote:
>> - you specify UDP encapsulation for NAT traversal, but no keepalive
>> 
> 
> okay. will fix this.

How are you going to fix this Vijay?  I use 15s keepalive with ICMP.
Would you do similarly?

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Apr 2005 11:14:44 +0200

Sri Gundavelli wrote:
> We have implementations based on draft-thubert-nemo-ipv4-traversal
> and some good thinking went in to that proposal and it is
> important that we review all these solutions in the context
> of the agreed upon problem space.

We also have an implementation but it is not documented, however, 
experiments were reported on Section 3 of expired draft 
draft-lach-nemo-experiments-overdrive-01.txt http://tinyurl.com/3om6x

It uses IPv6 in UDPv4 for NAT traversal.  The HA and the Gateway are not 
co-located.

That does not use IPv4 CoA for MIP6 simply because when behind NAT it's 
little relevant.

It uses UDP port scanning to find out open ports and 15s icmp "heart 
beats" to maintain port state unchnaged in the NAT devices.

When sending big packets over asymmetric wireless links (like GPRS and 
UMTS) the v4 stack fragments but the v6 stack does not fragment.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 31 Mar 2005 19:21:35 -0800

hi Sri,

Sri Gundavelli wrote:
>>
>>regarding Sri's concerns, we do intend to address them. dont
>>worry about that. we have an assumption in the draft.
>>
>>- the HA's IPv4 address is reachable through the IPv4 internet
>>
>>Sri is questioning this assumption. he is claiming this is
>>not so easy. he doesnt want IPv4 routing inside his IPv6
>>network. the HA is deep inside in the IPv6 network. for the
>>HA's IPv4 address to be reachable, you might need a box in
>>the DMZ, which traps the packets for the HA's IPv4 address
>>and tunnels them to the HA deep in the IPv6 network. but here
>>we end with extra tunneling between the box sitting in the
>>DMZ and the HA deep in the IPv6 network. another option is to
>>place the HA in the DMZ. but he doesnt want to do that. I
>>will be discussing with him to see how we can come up with a
>>solution. Sri, let me know if I still dont understand the
>>issue you are bringing up.
> 
> We need to agree on the most common scenarios that we need to
> address and so we need a problem statement. That should be the
> basis for defining a solution. Further, we need to have some
> gap analysis on each of the three present solutions and
> leverage some thing from them. I agree, we cannot afford to
> spend too much on that, but at the same time adopting a
> solution with out having an understanding of the deployment
> models is not right either.

here your concern is that we are not looking at enough scenarios.

so, you have two issues. 1) how to make the HA's IPv4 address
accessible through the IPv4 Internet and 2) we need to step back
and look at more scenarios.

I agree we need to address 1). and there are some solutions.
you havent responded to them in my mail. but for 2) I am afraid
you havent given any justification. draft-larsson has an
exhaustive catalog of all kinds of scenarios. please point to
the scenario which you think is important and we can take it
from there.

Vijay

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 01 Apr 2005 11:10:50 +0900 (JST)

Hi all,

From: [email-masked]
Date: Wed, 30 Mar 2005 13:33:19 -0600

> The chairs would like to hear your thoughts in order to see if there
> is consensus to make it a WG document and progress it as a standards
> track RFC. Comments should be sent to both the NEMO and MIP6 WGs. 

I agree that we need a mechanism for mobile hosts/routers to keep IPv6
mobility functions even if they jump into IPv4 network.

Personally, I am not sure if we need to save 40bytes instead of using
some other general tunneling mechanism.  But, I also personally feel
that we need much time if we wait for a general tunneling mechanism to
be defined, which we don't want to.  Defining a simple traversal
mechanism in MIP6/NEMO protocol makes sense to me.

The proposal (draft-wakikawa-nemo-v4tunnel) is simple enough and it
looks easy to implement from implementor's point of view.  It only
focuses IPv6 mobility which seems a good tradeoff to me.

However, I still don't fully understand the pros and cons between
draft-wakikawa-nemo-v4tunnel and draft-soliman-v4v6-mipv6.  I want to
see which is better for our purpose.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Apr 2005 16:31:53 +0300 (EEST)

On Thu, 31 Mar 2005, Vijay Devarapalli wrote:
>>> we do want to keep it to just one level of encapsulation.
>> 
>> Why, exactly?
>
> well, if its doable, dont we always want minimal encapsulation?

Not necessarily.  There's always room for optimization but the 
tradeoff is worth considering.  The question is what level is "good 
enough".

> it is doable if the following assumptions from the draft are valid.
>
> - HA has v4 and v6 interface
> - MN is dual-stack
> - HA's v4 address is reachable from the IPv4 Internet.

I've no doubt that it's doable,a nd these assumptions seem OK to me.

>> There are existing mechanisms out there which have been deployed for years, 
>> widely implemented, etc. to deal with exactly these issues.
>
> I am not sure I understood. we are not defining any new tunneling
> mechanisms. the idea is to use the existing tunneling mechanisms.

But instead of using mechanisms which require no protocol 
modifications or new code at all, you're plugging v4 tunneling 
functionality to MIPv6.  In other words, inventing something new.

That's a bit uncomfortable because MIPv6 was not designed for v4:
There are a couple of things why I think this is a problem:
  - People could even leverage the length of v6 addresses e.g., for 
CGA-based authorization instead of return routability (or something 
like that).  But extending MIPv6 in a manner that would eliminate that 
room for expansion.
  - We may not (yet) be fully aware which parts of the spec this has 
(non-obvious) implications to
  - we end up having to re-invent a lot of stuff, like NAT traversal, 
keepalives, possibly needing to also do NAT traversal to reach the 
Home Agent, etc.  And we have a number of encapsulation mechanisms. 
All of this seems like something that we do NOT want to re-invent in 
MIPv6 unless it can be justified that using existing mechanisms and 
existing configuration methods is not good enough (the crutch appears 
to be saving 20 or 40 bytes of payload).

>> You're arguing we need to design protocol extensions to save 20 or 40 
>> bytes.  Is it worth it ?
>
> well, the protocol extension is only to bind an IPv4 CoA to IPv6
> HoA. it is minor enough that we dont have to worry about it.

Would the next step be to bind an IPv4 CoA to IPv6 CN ?

>> A couple of quick comments on the ID:
>>  - which encapsulation types are mandatory-to-implement?  There must be at 
>> least one or a couple, to ensure interoperability.
>
> right. we havent picked a mandatory-to-implement mechanism
> yet. IPv6-in-UDP-over-IPv4 and IPv6-over-IPv4? suggestions are
> welcome.

Those seem OK, though I'm not sure what the security folks would say.

>>  - I guess it should be possible to discover the v4 home agent address 
>> without having to use (v6-only) DHAAD?
>
> DNS is one mechanism to discover the v4 address of the home agent.

Yep.. but it's non-standard, right?  How can products from different 
vendors and operators interoperate?

-- 
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: Sri Gundavelli <[email-masked]>
Date: Fri, 1 Apr 2005 08:47:03 -0800 (PST)

Hi Vijay,

> the scenario which you think is important and we can take it

One Issue #1, You slightly restated #1. The HA need not be
configured with IPv4 address. You have made extensive arguments
in the previous IETF's regarding doors using a double tunnel
by having a NEMO tunnel in a transition tunnel and that this
current draft does not do that. You have not made it clear as
how you were able to avoid that extra tunnel. The draft does
not talk about the scenario where the transition gateway and
the home agent functions are decoupled. However, we are now
saying that this draft can do all that by what ever schemes.
No thoughts went in to see how the Doors solves the same issues
and if Doors required the home agent address to be configured.

Issue#2, Yes. We need to step back. We cannot just say the
current draft is the basis for the solution. Before we narrow
down on one solution draft, there have to be some discussions
on the problem scope. I'll not just identify the scenario from
your list, there has to be some debate and consensus on the
problem scope and that will come out when we look at all the
current solution drafts that are out there. So, the problem
scope will come out when we review all the current solution
drafts. This is my view, you are free to disagree.

Sri

---

From: "Alpesh" <[email-masked]>
Date: Fri, 1 Apr 2005 09:05:19 -0800

Raj:

In general I agree that the v4 traversal problem should be solved.
My concern is adopting the draft you mention below as the working
Group item and adopting it as the basis of the solution. 

During last ietf, a number of issues were raised. We need to 
address those issues - is all forms of NAT supported; why should the
Solution mandate v4 and v6 collapsed at the HA; what are the pros/cons
Of proposed solution vs other proposals - doors draft, draft 
from Hesham/George et.al?

Vote YES for a solution for v4 traversal.
Vote NO for adopting this draft as "the base solution".

-a

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, March 30, 2005 11:33 AM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] Consensus call on making ID 
> draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document
> 
> 
> One of the major barriers to the deployment of Mobile IPv6 
> today is the fact that most access networks are IPv4 only. A 
> number of hosts are already dual-stack capable. While Mobile 
> IPv6 works well in IPv6 networks, it is essential that IPv6 
> mobility service continue to work even when the mobile host 
> is attached to an IPv4 network. The same applies to a NEMO 
> mobile router as well. 
> 
> A number of transition scenarios have been identified in IDs: 
> 1. draft-larsson-v6ops-mip-scenarios-01
> 2. draft-tsirtsis-dsmip-problem-03
> While discussion of these scenarios in the larger scope makes 
> sense, there is a need to focus on the most critical scenario 
> that would address the MIP6 host and router problem. The 
> problem in a single sentence can be stated as: "Mobile IPv6 
> hosts and routers (NEMO) need to be able to reach its (IPv6) 
> home agent and services when roaming in and attached to an 
> IPv4 access network."
> It makes sense to focus on just this one scenario and solve 
> the problem immediately. 
> 
> The ID: draft-wakikawa-nemo-v4tunnel-01 solves the problem of 
> a MIPv6 mobile node or a NEMO mobile router roaming onto a 
> IPv4 only access network in a simple manner. 
> It is intended that the standardization of this solution in the IETFs
> MIP6 and/or NEMO working groups proceed. The working group 
> chairs have reviewed and discussed this work item. It has 
> also been presented at the MIP6 and NEMO WGs at IETF62. 
> 
> The chairs would like to hear your thoughts in order to see 
> if there is consensus to make it a WG document and progress 
> it as a standards track RFC. Comments should be sent to both 
> the NEMO and MIP6 WGs. 
> 
> If we have consensus, then the document will be pursued as a 
> dual WG item and called draft-ietf-mip6-nemo-v4tunnel-xx.txt 
> 
> Make I-D draft-wakikawa-nemo-v4tunnel a MIP6/NEMO WG ID:
> 	For 		[  ]
> 	Against 	[  ]
> 
> 
> - MIP6 and NEMO WG chairs
> 
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 04 Apr 2005 13:24:31 +0900

Hi Sri

my understanding is that this mechanism willnot be solo solution for
transition scenario. Your concerns are correct for some deployment
scenarios.  However, our approach is a way to solve the transition
problem and provides additional features such as less tunnel overhead
and no infrastructure supports. These features are important for
service providers.

regards,
ryuji

At Wed, 30 Mar 2005 22:21:04 -0800 (PST),
Sri Gundavelli wrote:
> 
> Hi Ryuji,
>           Please see inline ...
> 
> 
> On Thu, 31 Mar 2005, Ryuji Wakikawa wrote:
> 
> > Hello Sri
> >
> > > Other way to say is we would not an extra encap layer, when
> > > the home agent and the transition gateway functions are spread
> > > out.
> >
> > OK, but there is a problem,  "double tunneling".
> > Packets have, at least,  three IP headers when MN roams to v4 network.
> > Extra bits and processing costs are burden for MIP6/NEMO in IPv4.
> >
> 
> That is the cost for going over a transition gateway. The
> transition solutions should not expect the networks to
> overlap, they should provide a way for the network
> administrators to systematically move the v4 network
> out from the v6 cloud in a segmented approach. The solution
> we are debating is about the tight coupling of the v4 and
> v6 networks and requiring fundamental changes to the binding
> cache entries for associating v4 addresses. If the solution
> requires a v4 network all the way to the Home Agent,
> a dual stacked Mobile Router, a modified home agent to
> understand v4 address semantics, wonder why we can't go to
> the next step of replacing the v6 home agent with a v4 home
> agent. Clearly, the solution cannot disregard the problem
> scenarios such as a home agent in a v6 cloud and disjointed
> transition gateway to the v4 cloud.
> 
> All I'm saying is that we should agree up on the problem
> scenarios, review the current solutions including doors and
> work towards a solution.
> 
> Regards
> Sri
> 
> 
> 
> 
> 
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 04 Apr 2005 13:26:59 +0900

Hello Pekka

At Thu, 31 Mar 2005 09:43:41 +0300 (EEST),
Pekka Savola wrote:
> 
> On Wed, 30 Mar 2005, Vijay Devarapalli wrote:
> >> Also, the draft's claim that they are
> >> avoiding one extra encap layer is not true, the moment
> >> you move the transition gateway from the home agent,
> >> indeed an extra encap layer is needed.
> >
> There are existing mechanisms out there which have been deployed for 
> years, widely implemented, etc. to deal with exactly these issues.

If there are exiting transition mechanisms and MN gets v6 address, MN
can operate without changes.  This is fine if we forget redundant
tunnel overheads.

However, what happen when a mobile node roams to just v4 networks.
Can we expect that all wireless networks will deploy with v6 or some
transition mechanism?  It makes sense that MIP6 has some way to handle
v4 address by itself (no infrastructure supports). 

>   - which encapsulation types are mandatory-to-implement?  There must 
> be at least one or a couple, to ensure interoperability.

I got similar comments from several people. 
We'll limit one or two encapsulation types in the next version.

> without having to use (v6-only) DHAAD?

I'm not sure if we need an original dynamic discovery mechanism only
for this. For example, if a mobile node knows a home agent's FQDN
while in v6 network, it can also gets v4 address by DNS.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 04 Apr 2005 13:27:03 +0900

Hello Pekka

I agree that we should not re-invent NAT traversal and encapsulation
mechanisms.  

And if this is your concern, we can simply say using IKEv2 and RFC3948
for NAT traversal and using v4-v6 tunnel for non NAT networks. We'll
use the BU/BA for tunnel end points establishment, but this is same as
MIP6. This is simple extension to MIP6 (for me).

regards,
ryuji

At Fri, 1 Apr 2005 16:31:53 +0300 (EEST),

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 04 Apr 2005 13:24:52 +0900

Hello Pekka

thanks
ryuji

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 08:22:31 +0300 (EEST)

> v4 address by itself (no infrastructure supports).

I expect that those nodes might end up running in a network without 
MIPv6 Home Agent support (e.g., a WLAN interface at home).

I assume it would be "really important" for those nodes to obtain IPv6 
connectivity (even without Mobile IPv6) in those cases as well. (This 
is because the node has IPv6 applications which it will continue need 
to support.)

So, I expect the vendors would implement IPv4-IPv6 
tunneling/transition mechanisms on the nodes as well (and this has 
already happened, e.g., look at the Symbian stack).

I do not expect that all such wireless networks deploy a transition 
mechanism, but if a node ends up in one which doesn't, it can always 
use Teredo, 6to4, a tunnel broker, IPsec tunneling or some other 
alternative to obtain IPv6 access.

However, your scenario does not really differ from here at all. 
Instead of assuming that the Home Agent is reachable from anywhere at 
all using v4 (+NAT traversal), we're assuming that a tunnel server is 
available from anywhere at all using v4 (+NAT traversal) _or_ that the 
host implements/is able to use 6to4, Teredo, or a number of other 
mechanisms.

Hence, if we don't need to restrict the solution space based on the 
encapsulation overhead, decoupling the tunneling configuration from 
Mobile IP protocols seems to make a lot of sense -- because re-using 
transition mechanisms gives you the superset of functionality.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 4 Apr 2005 10:42:11 -0700 (PDT)

Hi Ryuji,

> and no infrastructure supports. These features are important for

Sure. The problem you are trying to address and what the doors draft
is addressing is not totally different, just the constraints are
different. It is better if we first agree up on the problem and
look at all these solutions in perspective.

Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 11 Apr 2005 05:02:35 +0900

Hello Pekka

I believe seamless connectivity is KEY to make mobility services
deploy. MN can keep communication by v6 HoA regardless of v4/nat/v6
network. It will be similar invention, but it makes sense to work on
this. This is because MIP6/NEMO are also protocols creating tunnel
between MN and HA. Simply extend MIP6/NEMO tunnel to support v4/NAT
traversal.

ryuji

At Mon, 4 Apr 2005 08:22:31 +0300 (EEST),