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

[Tsirtsis George <G.Tsirtsis@flarion.com>]

Inline..

-----Original Message-----
From: Fred Templin [mailto:ftemplin@IPRG.nokia.com] 
Sent: Thursday, July 31, 2003 5:40 PM
To: Tsirtsis George
Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org
Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0
0.txt


George,

Tsirtsis George wrote:

>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.
>

Yes, this is the scenario I was referring to. First order of business is 
to get
some level of IPv6 connectivity in the visited network even if ip-proto-41
is required.

GT> Or alternatively use MIPv4 and register you IPv6HoA to the IPv4CoA
binding to the HA without having to get an IPv6 address using ngtrans tools.


>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.
>
The IPv6-in-IPv6-in-IPv4 part comes when 1) the HA needs to tunnel IPv6 
packets
to a MN in an IPv4-only visited network or 

GT> This is where I am not getting through. My aim is to extend MIP so that
you only need IPv6 over IPv4 when you have IPv6HoA and you can only get an
IPv4CoA.

2) the MN in an IPv4-only network needs to reverse-tunnel IPv6 packets
through the HA to reach a CN. Not sure how you mean about  MIP being
extended to create a binding between IPv6 and IPv4. Do you see a way around
the nested tunneling? (And, is there a specification somewhere that tells
how to do it?)

GT> Maybe it a little bit more clear now? In any case I expect to send out
the MIPv4 extensions proposal for this early next week some time...and MIPv6
extensions so time later...I hope this will help.

Thanks
George

>
>George
>
>-----Original Message-----
>From: Fred Templin [mailto:ftemplin@iprg.nokia.com]
>Sent: Wednesday, July 30, 2003 5:53 PM
>To: Tsirtsis George
>Cc: 'Alain Durand'; Mobile-Ip (mobile-ip@sunroof.eng.sun.com);
>v6ops@ops.ietf.org; 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@iprg.nokia.com
>
>
>  
>