RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt

Fred,

I am not sure what you are saying...a dual stack MIPv6 MN encountering a v4
network will have no hope in sending a MIPv6 BU to its v6HA in any way that
would allow real mobility.

I guess one can imagine that such a mobile detecting a v4 only network could
start going through the ngtrans tools and see what may work so that it can
somehow get an IPv6 address and then tunnel a MIPv6 BU to its HA....as I
said not real mobility.

Then I do not understand why you talk about this as if there needs to be
"IPv6 over IPv6 over IPv4" tunneling involved. If the HoA is IPv6 and the
CoA is IPv4 and MIP could be extended to create a binding between the two
then an "IPv6 over IPv4" tunnel would be created.

George

-----Original Message-----
From: Fred Templin [mailto:ftemplin=LXTkK8GSST62oZ/[email protected]] 
Sent: Wednesday, July 30, 2003 5:53 PM
To: Tsirtsis George
Cc: 'Alain Durand'; Mobile-Ip ([email protected]);
[email protected]; Soliman Hesham; 'Thomas Narten'
Subject: Re: [mobile-ip] Re: FW: I-D
ACTION:draft-tsirtsis-dsmip-problem-00.txt


George,

Tsirtsis George wrote:

>Now, when the mobile is  not at home but in some other network, there 
>is an issue about what kind of v4/v6 support there is in the foreign 
>network. The nice thing about Mobile IP is that it is based on tunnels 
>and thus it provides natural way of tunneling over networks that are 
>not compatible with the mobile ...if only Mobile IP could configure v4 
>over v6 and v6 over v4 tunnels (as opposed to just v4 over v4 and v6 
>over v6 tunnels). A dual stack mobile in a v4 only foreign network 
>would then be able to create a v4&v6 over v4 (forward and reverse) 
>tunnel with its HA and thus maintain all its connectivity.
>
When a dual-stack MIPv6 MN encounters a v4-only foregin network, I see (at
least) three possibilities for the v6-in-v4 tunnel endpoint:

 1) the tunnel endpoint resides in the home network; perhaps
    even co-located with the HA (potential use case for configured
    tunnels)

 2) the tunnel endpoint resides in the visited netwok (potential
    use-case for isatap)

 3) the tunnel endpoint resides in some 3rd party network
    (potential use-case for tunnel broker)

In any case, the v6-in-v4 tunnel should present an MTU large enough to
encapsulate 1280 bytes PLUS the size of the outermost IPv6 header so that
the inner MIPv6  IPv6-in-IPv6 tunneling does not incur harmful fragmentation
(see RFC 2473, section 7). But, most v6-in-v4 tunneling specifications cap
their MTUs at 1280 bytes. Does this seem like a potential performance issue
waiting to bite us?

Fred
ftemplin=LXTkK8GSST62oZ/[email protected]