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

Hi Vijay/Vidya,

On Thu, 31 Mar 2005, Vijay Devarapalli wrote:

> Henrik,
>
> there is some mis-understanding regarding the relation
> between draft-soliman and draft-wakikawa. both solve the
> scenario of a v6 MN or MR accessing its v6 home agent from
> a v4 only access network. draft-soliman talks about using a
> IPv4 mapped IPv6 address to convey the IPv4 CoA to the
> HA. draft-wakikawa uses a new mobility option to carry
> the IPv4 CoA. I personally prefer carrying it in a separate
> mobility option, because it makes processing on the HA easier.
> we can debate the pros and cons of this later. but this *does*
> not impact the scenario. both solve the same scenario.
>
> there are other scenarios, but IMHO, they are not relevant.
>
> 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

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

Vidya,

Any transition solution should offer a way for a phased
migration. I do not see how the current solution will
enable the operator to push the v4 network in a phased
manner. The requirements that the HA should be on the
edge or if 90% of the deployments will go for that model
is debatable and can only be answered by going for a
problem statement.

Regards
Sri

On Thu, 31 Mar 2005, Narayanan Vidya-CVN065 wrote:

> Sri,
> I also understood your comments exactly as Vijay did. A couple of years ago, I did hear about some concerns
on placing the HA in the DMZ, but I didn't think any of those were very deep. Is there really a deployment
issue in placing the HA in the DMZ?
>
> Actually, even if you did place the HA deep in the IPv6 network, forcing the need for a tunneling box in the
DMZ that does v4-v6 tunneling, is that really that bad?
>
> If most deployments don't have an issue with the placement of the HA in the DMZ and a small percentage of the
cases do, it does not seem too bad to me to say that a solution is simple since it solves the 90% case. I'd vote
for that rather than make it really complex to also solve the 10% case.
>
> My 2 cents,
> Vidya

Re: [nemo] RE: Consensus call on making IDdraft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document

Hi Vijay and All,

> ah.. you werent at the MIP4 WG meeting. the question about multiple
> transition scenarios came up. there was an agreement on the following
> scenarios. (if I am wrong, those who were at the MIP4 WG meeting,
> please correct me).
> 
> 1) There are people who want to deploy MIPv6 (and NEMO). they dont
>     use MIPv4 currently. For these folks the most important scenario
>     is to reach the IPv6 Home Agent (and services) from an IPv4 access
>     network.
> 
> 2) There are people who have deployed MIPv4. They want to move to
>     MIPv6.
> 
> then there are other scenarios, for example, an MIPv4 node ending up
> on a pure IPv6 access network. I think those scenarios should be
> excluded. not realistic.
> 
> I am not sure there was concensus, but the general mood in the meeting
> was that the MIP4 WG will look into the second scenario. IMHO, MIP6
> should deal with 1).

You're right if my understanding is correct.
Through MIP4 WG session at the IETF62, MIP4 WG folks wanted to 
tackle the scenario 2.

--Junghoon

_______________________________________________

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

Hi all,

From: Basavaraj.Patil <at> nokia.com
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 <keiichi <at> iijlab.net>
KAME Project <keiichi <at> kame.net>

Re: RE: [Mip6] Consensus call on making ID draft-wakikawa-nemo-v4tunnel aMIP6/NEMO WGs document

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

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

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

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

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

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

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

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

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

| If most deployments don't have an issue with the placement of the HA
in
| the DMZ and a small percentage of the cases do, it does not seem too
bad
| to me to say that a solution is simple since it solves the 90% case.
I'd
| vote for that rather than make it really complex to also solve the 10%
| case.
| 

Hi Vidya

I see words about complexity from you and Keiichi. I agree we need to
look at how complex the proposals are:
- in terms of standardization
- in terms of coding
- and mostly in terms of deployment

Obviously, a solution that has less constraints is easier to deploy.
Ending the IPv4 at the HA is a constraint. We have experiments with
customers who could not do that for very pragmatic reasons. Details
might be given mater.

In terms of coding, I guess that people have to read and understand all
proposals on the table before they can assess that one thing is more
complex than another. I would assert that a solution that does not
change the home agent causes less regression testing then one that does.
For instance, Doors is a very small footprint hack that leaves the end
to end MIP untouched.

In terms of standardization, I'd guess that the same applies. Changing
MIP inside is not as simple as changing it on the surface. Doors just
acts on the transport. The Doors gateway can be installed on the HA,
close to the HA, or by an external provider anywhere.

I'd just suggest that we, as a group, do not presuppose that because
Doors provides additional features it is necessarily more complex.
Sometimes, simplicity brings a lot of good things with it.

Pascal