Re: Fwd: A comment about MAST

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

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