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

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 24 Aug 2003, Soliman Hesham wrote:
>  > > If the MN generates a 6-to-4 address then an IPv6 node contacted
>  > > it using that address after the MN has left the home network, how
>  > > does the HA forward those IPv6 packets to the MN? 
>  > 
>  > Easily.  Note that those are *NOT* IPv6 packets.  They're 
>  > proto-41 IPv4 
>  > packets :-).
>  > 
>  > It's double encapsulation, but hey.. it works and is trivial!
> 
> => As I described earlier, double encapsulation is one 
> option, there are others. The aim is not necessarily 
> to provide a trivial solution at all cost (it's obviously
> your aim but not mine). If you read the mipv4 solution
> (draft-tsirtsis) you can see that it's possible, but there
> is a need for a more BW-efficient solution.

Obviously, the problem statement should elaborate why double encapsulation 
does not solve the problem.

>  > > The same goes for traffic sent from the MN using 
>  > 2002:HADDR_v4::/48. 
>  > 
>  > Works equally well, as above.
> 
> => No it doesn't. How does the MN reverse tunnel to the
> HA? MIPv4 does not assume reverse tunnelling.

It has worked just fine for me w/ Dynamics 
(http://www.cs.hut.fi/Research/Dynamics/), AFAIR.

Are you saying that mobile nodes do not tunnel back to the HA themselves, 
just (optionally) rely on the FA's doing it?

>  > > It doesn't setup
>  > > a tunnel between the MN and the HA in any way.
>  > 
>  > For some weird reason, you keep having this fixation that 
>  > tunnel MUST BE 
>  > between MN and the HA.  There is *NO* reason for that.  The 
>  > tunnel can be 
>  > to whatever box in the network, as long as it provides IPv6 support.
>  > 
>  > However, it could very easily be the HA too, just by being 
>  > the 6to4 relay 
>  > or the (somehow) configured tunnel's endpoint.  But that's 
>  > certainly *not* 
>  > a requirement. 
> 
> => I don't understand how you assume that 6-to-4 provides
> bidirectional communication... This is why I think the HA
> is a good TEP because it's there, doesn't assume 6-to-4
> relays, and doesn't assume that the CNs have 6-to-4 addresses.

If you're worried about bidir communication, all you have to do is to give 
the HA also a 6to4 address: then 6to4 gives you bidirectionality as well.
 
>  > > if you're saying that you could have a configured tunnel inside
>  > > the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then
>  > > gets tunneled to the MN's IPv4 care-of address (the MIP part)
>  > > then yes this is possible and it is explained in the draft
>  > > that George announced on the list.
>  > 
>  > Yes, that's exactly the possibility.  It needs to go to the problem 
>  > statement (if you keep considering there being a problem) to 
>  > be taken 
>  > seriously.
> 
> => I don't think the problem statement should consider solutions.
> In fact, perhaps we need to change the recommendations section
> to indicate that a gradual transition based on existing standards
> is needed without being more specific. 

You don't have to consider solutions.  What I'm saying is that it would be
useful to try to phrase the _problem statement_ so that it excludes
certain solutions you do not consider appropriate (instead of just
silently rejecting them).  I.e., this seems to indicate that the problem 
statement is not worded as well as it could be.

>  > > But there is a more 
>  > > BW effifcient scenario that would require some assistance 
>  > > from the FA. Both options are explained in the solutions
>  > > draft (MIPv4 one) that George sent to the MIP mailing list.
>  > 
>  > Bandwidth efficiency is just ONE trade-off here.  
> 
> => Ah, one important trade-off! If you ask anyone deploying
> or working with a WWAN how important BW is, they'll
> choose it over simplicity anytime.

You may have different WWAN's in mind, but I disagree.  For example 802.11 
deployments have ample capacity, and it is much more important to have 
simple solutions which require no upgrades to network components or mobile 
nodes.
 
>  > Actually, maybe the document should be called "goals" or 
>  > "requirements", 
> 
> => If it were a requirements doc we would call it so, but 
> we were asked to describe the problem, that's why it's 
> a problem statement. 

Requirements can also describe a problem, but additionally those give a 
better idea how to evaluate solutions to the problem.

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