Doors for IPv6 connectivity [RE: comparaison grids presented in meeting]

[Pekka Savola <pekkas@netcore.fi>]

Hi,

On Mon, 8 Mar 2004, Pascal Thubert (pthubert) wrote:
> MIPv6 (or Nemo for that matter) does the bulk of the work, and Doors is
> just opportunistically using the states that MIPv6 installs at the HA to
> store the UDP encapsulation parameters. Doors goes through all forms of
> NATs, AFAIK. Actually, in the case of a nested Nemo, a single PAT state
> in the network covers the full nested cloud.
> 
> I'm afraid that the draft has expired but it can still be found at the
> nemo site:
> http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver
> sal-01.txt 

Actually, I think this is conceptually similar to 
http://www.watersprings.org/pub/id/draft-soliman-v4v6-mipv4-00.txt -- 
just adding some IPv4 glue in the MIPv6 HA implementations to create a 
tunnel.

My kneejerk reaction to that was, why not co-locate a tunnel 
server/broker implementation with the HA, and get around the issue 
without modifying MIPv6 (to include IPv4 specific components).  After 
all, IPv6 connectivity in IPv4 networks (and NAT traversal) is a more 
generic problem than that.

Actually, it's even better not to co-locate the v4 tunnel endpoint 
with IPv6 HA -- that way, if a tunnel endpoint close by, closer than 
the HA, there are some route optimization benefits.

(This is the "mobility thoughts" topic which was discussed on Thursday 
session, and next a problem statement/scenario -like draft is probably 
going to be written.)

Pascal, is there something obvious I missed when I glanced through 
your idea?

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