Subject: RE: v4 CoA and route optimization [Re: [Mip6] draft-soliman anddraft-wakikawa]

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

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf
Of
| Pekka Savola
| Sent: Monday, April 04, 2005 12:56 PM
| To: Henrik Levkowetz
| Cc: [email-masked]; [email-masked]; Ryuji Wakikawa
| Subject: v4 CoA and route optimization [Re: [Mip6] draft-soliman
anddraft-
| wakikawa]
| 
| On Mon, 4 Apr 2005, Henrik Levkowetz wrote:
| >>> Mph.  There is quite a bit more to say about NAT traversal.
| >>> That the current wakikawa draft is under-specifying this is
| >>> putting it mildly ,:-)
| >>
| >> Your updates would be always appreciated.
| >
| > We covered a lot of area in RFC 3519.  You could start by
| > checking off the issues covered there, and how they are to be
| > handled.
| >
| > For MIP6 there is the additional issue of how to handle various
| > types of NAT when you're doing route optimization - many of those
| > are the same as those covered quite well in
| > draft-huitema-v6ops-teredo-04.txt .
| 
| Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel
| is likely going to be rather simple (if keepalives are considered OK
| in the scenario; as Hesham points out, they might be completely
| unacceptable in some sceanrios [but that's why it could be possible to
| turn them off it there is no NAT on the path]).
| 

Note that MIP has a periodic rebinding, which is the heartbeat of the
tunnel. Maybe we need some practical recommendations on how to use it in
the face of a NAT but it has a few properties, one being that it can
change overtime:

- because the MN uses a different interface
- because a network condition occurs
- you name it

In particular, in the face of a NAT, the lifetime can be adapted to be
used as a keep alive. In our tests, we usually use 30s as a lifetime, in
order to detect the MR unreachability quickly enough from the HA
standpoint. This appears to work fine with the NATs we faced.

| NAT traversal for route optimization would be reinventing Teredo
| (i.e., rather complex and definitely not worth the effort), but as far
| as I understand, the authors are not proposing addressing this
| particular thing.
| 
| MNs could only use the bidirectional tunnel, and if they wanted to do
| route optimization, they would have to initiate regular transition
| mechanism on the side.
| 
| Authors, is this understanding correct?
| 

It is true that Doors only deals with MRHA. Note that NEMO does not have
RO in the first place, so it's hard to say what it's going to be at that
point. 

Some of the proposed NEMO RO schemes have to do with nested NEMO, and
that much can be all IPv6. Others happen fully in the IPv6
Infrastructure (as opposed to end to end) and could be limited to the
fully IPv6 part of the way... 

Pascal

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

---

From: [email-masked]
Date: Mon, 4 Apr 2005 09:30:51 -0700

> >>> Mph.  There is quite a bit more to say about NAT traversal.
> >>> That the current wakikawa draft is under-specifying this is
> >>> putting it mildly ,:-)
> >>
> >> Your updates would be always appreciated.
> >
> > We covered a lot of area in RFC 3519.  You could start by
> > checking off the issues covered there, and how they are to be
> > handled.
> >
> > For MIP6 there is the additional issue of how to handle various
> > types of NAT when you're doing route optimization - many of those
> > are the same as those covered quite well in
> > draft-huitema-v6ops-teredo-04.txt .
> 
> Note that AFAIK, NAT traversal between the bidirectional MN-HA tunnel 
> is likely going to be rather simple (if keepalives are considered OK 
> in the scenario; as Hesham points out, they might be completely 
> unacceptable in some sceanrios [but that's why it could be 
> possible to 
> turn them off it there is no NAT on the path]).
> 
> NAT traversal for route optimization would be reinventing Teredo 
> (i.e., rather complex and definitely not worth the effort), 
> but as far 
> as I understand, the authors are not proposing addressing this 
> particular thing.
> 
> MNs could only use the bidirectional tunnel, and if they wanted to do 
> route optimization, they would have to initiate regular transition 
> mechanism on the side.
> 
> Authors, is this understanding correct?

yes. thats right.

Vijay