Re: Fwd: A comment about MAST

["Eugene M. Kim" <gene@nttmcl.com>]

Mr. Ohta, I'm afraid you are misinterpreting (and misrepresenting) me;
I do hate NAT, and I am a firm believer in IPv6.

Granted, we need some architecturally solid and sound solution, i.e. the
ultimate, long-term goal, to the ID/LOC problem.  However, that will
probably mean introducing a new namespace for either identifier or
locator (depending on which purpose we decide to use the current IP
address space for), and applications must adapt itself to the new world
order.

On the other hand, applications can start benefiting from MAST almost
immediately, especially when they do not care about communication
endpoint addresses.  And a lot of existing applications fall into this
category.  I think, therefore, MAST can serve as a good stopgap while
a permanant solution is being developed and deployed.

This is not some ten years ago when people started (ab)using NAT without
realizing its full consequence.  Provided we have some bigger picture,
or a roadmap, I think MAST still has its merits when used accordingly to
the roadmap even though it inherits some of the same problematic natures
from NAT as you pointed out.

As for the roadmap itself, I think I just explained my crude idea about
it; make a permanant solution that cleanly separates identifiers from
locators, and use MAST as a stopgap. =)

Regards,
Eugene

On Tue, Sep 09, 2003 at 05:23:25PM +0859, Masataka Ohta wrote:
> Dave;
> 
> > Forwarded, at the author's request. my reply follows.
> 
> > My understanding of the architectural model as described and illustrated
> > in 4.1 suggests that the address changes and handovers will be
> > completely hidden from upper-level applications so they will still
> > identify the connection as between IP.a, Port.l, and IP.y, Port.r
> > (communication endpoints).  Although this is the least intrusive
> > approach,
> 
> That is the stupidity not to be overlooked.
> 
> What we learned from NAT is that NAT is worst intrusive.
> 
> > I think this is not enough if applications that `leak' those
> > endpoints over the wire were to benefit from MAST.  This is somewhat
> > similar to the classic NAT problem.
> 
> > Complex applications (and
> > protocols they implement) that do care about and use endpoint
> > identifiers over the wire can be modified to utilize MAST and this new
> > API so they can propagate address changes accordingly.
> 
> That is the old argument for NAT lovers.
> 
> > API so they can propagate address changes accordingly.  If they ignore
> > the new API, their operation will break at the moment an original
> > endpoint address, local or remote, becomes invalid; but since they will
> > break anyway without MAST at all at that moment, this seems to be a
> > non-issue.
> 
> Wrong.
> 
> It is merely that NAT approach unnecessarily break some application.
> 
> It is, of course, possible to have NAT penetration protocol and
> its API and you can argue as "If they ignore the new API, ... this
> seems to be a non-issue".
> 
> In addition, the statement:
> 
> 	their operation will break at the moment an original
> 	endpoint address, local or remote, becomes invalid;
> 
> assumes a lot of restriction on when to change addresses, lack
> of argument on which is, as has been pointed out by some, the
> fatal flaw of MAST draft.
> 
> People who believe NAT least intrusive should keep using IPv4 with
> NAT.
> 
> Rest of us work on IPv6.
> 
> PERIOD.
> 
> 							Masataka Ohta