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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 4 Apr 2005 11:03:14 +0200

| -----Original Message-----
| From: Ryuji Wakikawa [mailto:[email-masked]]
| Sent: Monday, April 04, 2005 6:27 AM
| To: Pascal Thubert (pthubert)
| Cc: [email-masked]; [email-masked]; [email-masked];
| [email-masked]; [email-masked]; [email-masked]
| Subject: Re: [nemo] Re: [Mip6] Consensus call on making ID
draft-wakikawa-
| nemo-v4tunnel a MIP6/NEMO WGs document
| 
| 
| Hello Pascal
| 
| At Fri, 1 Apr 2005 15:56:39 +0200,
| pascal wrote:
| >
| > | 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
| 
| Hmm, I feel that Doors, itself, is complicated.
| 
| My major comments to Doors are
| - Doors brought security vulenerability in terms of IP header
|   modification at intermediate gateways. Do we really want another NAT
|   like mechanism in IPv6?

Note that (but for DHAAD) the careof address is not the source address
and does not interact with the upper layer checksum. So changing the
careof is not the same thing as a NAT, by far.

Also, this happens only in the case of a NAT/PAT/RNAT on the way.
Otherwise, the CoA is not changed.

Finally, there is a threat coming from the IPv4 NAT when it is present.
The source address is changed. We have to cope with that if we find a
valid attack against the mechanism that we propose. 

Now, Doors shows that there's value in combining MIP6 and NAT traversal
as opposed to doing them separately. MIP6 provides the keep alive and
the states (hidden in the COA), and an evolution from 6to4 provides the
gateway and the routing within the IPv6 network.

This results in a very little footprint in terms of implementation (once
you have MIP6 or NEMO to start with) and yet features like NAT traversal
... even for reverse and symmetrical NATs.

| - IPsec operation is not clear to me.
| 

Yes. If there is to be a new version, we'll have to detail this. Then
again, the study of the risk that the IPv4 NAT introduces might be
necessary as part of the problem statement for IPv5 traversal,
regardless of the solution.

| > 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.
| 
| You customers are not only clients using MIP6:-)
| There are also requirements such as no infrastructure support and
| less tunnel overheads. I don't have customers like cisco, but I know
| there are companies seeking a solution for the requirements.
| 

The customers we have been dealing with had more addressing and routing
constraints then they had with bandwidth. The only place where bandwidth
is critical is over the radio between the MN/MR and the fixed
infrastructure using a PPP over your 2.5/3G telephone. This problem
exists today and is usually dealt with using Van Jacobson Header
Compression and RFC 1976. 

We could easily include the MRHA header in the Van Jacobson Header
Compression. But it might be a little complex to deploy widely. Depends
on the success of MIP6 in the first place. 

| > 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.
| 
| Goal of Doors and our solution is cleary different. We assume
| different deployment scenarios. We should not compare doors or other
| transition mechanism in this thread.
| 
| > 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.
| 
| Agree. I always like similicity:-)

:)

Pascal

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 4 Apr 2005 18:56:15 +0900

Hello Pascal

> careof is not the same thing as a NAT, by far.

OK

> Otherwise, the CoA is not changed.

Well, but it happens when MN moves to NAT network.
Most of IPv4 address which I can get in Japan is NAT address...
Do we really need address translation in IPv6 for NAT traversal..

> regardless of the solution.

Do you have any section for the study in doors draft?!
> on the success of MIP6 in the first place.

Header compression is one way.
Compression processing cost may be burden though.
We need IPv4 traversal to use MIP6 at this point.
People said that IPv6 is deployed in japan, but not in wireless 
networks.

regards,
ryuji

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 13:34:28 +0200

> Do we really need address translation in IPv6 for NAT traversal..

We don't need IPv6 NAT but we're imposed NAT when v6 traverses v4 
networks...

>> valid attack against the mechanism that we propose.

Yes, and securing this excludes IPsec, and can only rely on tokens in 
UDP messages, eventually within the non-BU keepalives.

> Header compression is one way.

Isn't header compression a non-end-to-end feature?  I thought HC happens 
only between the terminal and the first hop.  So if the requirement is 
not to touch the v4 network (just traverse it) then HC is no use.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 14:52:09 +0300 (EEST)

On Wed, 6 Apr 2005, Alexandru Petrescu wrote:
> Isn't header compression a non-end-to-end feature?  I thought HC 
> happens only between the terminal and the first hop.  So if the 
> requirement is not to touch the v4 network (just traverse it) then 
> HC is no use.

For v4 header compression, sure. (But very constrained environments 
probably employ v4 and UDP HC on their own in any case).  HC for v6 
headers is still possible without touching v4 network, of course.

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