Subject: Re: A comment about MAST

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Sep 2003 23:51:06 -0700

Eugene,

thank you for the comments.

EMK> completely hidden from upper-level applications so they will still
EMK> identify the connection as between IP.a, Port.l, and IP.y, Port.r
EMK> (communication endpoints).  Although this is the least intrusive
EMK> approach, I think this is not enough if applications that `leak' those
EMK> endpoints over the wire were to benefit from MAST.  This is somewhat
EMK> similar to the classic NAT problem.

I think it is exactly the same, yes.

EMK> My suggestion is to expose the address changes to upper-level
EMK> applications through some backward-compatible API extension, which shall
EMK> notify applications that addresses are being added to or removed from
EMK> the local or remote endpoint identifier.

More generally, you are suggesting a line of consideration that the draft
probably should mention.  Namely, it might discuss additional areas for
development.  There is already a small amount of such commentary in the
document. The suggestion you are making is an interesting one for this.  Some
sort of "roadmap" would probably be helpful.

In general, IETF protocol work does not specify APIs, though of course there
are exceptions.  Certainly it would be useful to suggest this separate
information channel to the application.

EMK>   Complex applications (and
EMK> protocols they implement) that do care about and use endpoint
EMK> identifiers over the wire can be modified to utilize MAST and this new
EMK> API so they can propagate address changes accordingly.  If they ignore
EMK> the new API, their operation will break at the moment an original
EMK> endpoint address, local or remote, becomes invalid; but since they will
EMK> break anyway without MAST at all at that moment, this seems to be a
EMK> non-issue.

Right.  And a good discussion worth adding to the proposal is about
application awareness of current addresses.

EMK> I am not suggesting that the MAST proposal should define such APIs with
EMK> it; IMO they are better left out as future work items as individual
EMK> operating systems implement MAST.

Yes, but I do think the proposal will benefit from having some discussion
about the issue.  Thank you for raising it.

EMK> P.S. Which is the main discussion list for MAST, and could you forward
EMK> this to the list if there is one?

multi6.  I have forwarded your note, and copied you.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 8 Sep 2003 23:49:07 -0700

Forwarded, at the author's request. my reply follows.

d/

===== Forwarded message =====
From: Eugene M. Kim <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Date: Monday, September 8, 2003, 10:16:17 PM
Subject: A comment about MAST

Greetings,

I have a comment regarding your MAST proposal; I apologize if this have
already been addressed before:

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

My suggestion is to expose the address changes to upper-level
applications through some backward-compatible API extension, which shall
notify applications that addresses are being added to or removed from
the local or remote endpoint identifier.  Simple applications that do
not care about nor use endpoint identifiers can safely ignore this new
API and still work across address changes.  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.  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.

I am not suggesting that the MAST proposal should define such APIs with
it; IMO they are better left out as future work items as individual
operating systems implement MAST.

Regards,
Eugene

P.S. Which is the main discussion list for MAST, and could you forward
this to the list if there is one?
===== End of original message text =====

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 9 Sep 2003 17:23:25 +0859 ()

Dave;

> 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

> Complex applications (and
> API so they can propagate address changes accordingly.

That is the old argument for NAT lovers.

> break anyway without MAST at all at that moment, this seems to be a

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

---

From: "Eugene M. Kim" <[email-masked]>
Date: Tue, 9 Sep 2003 07:27:27 -0700

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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Sep 2003 17:21:09 +0859 ()

Eugene;

Granted, we need some architecturally solid and sound solution, i.e. the
ultimate, long-term goal, to the address exhaustion problem.  However,
that will probably mean changing the IP protocol and applications must
adapt itself to the new world order.

And, NAT was introduced.

> I do hate NAT,

You don't, really.

						Masataka Ohta

PS

With proper API, most applications works as is even with ID/LOC
separation.

---

From: "Eugene M. Kim" <[email-masked]>
Date: Wed, 10 Sep 2003 09:28:03 -0700

Sorry, you seem to have filtered `this isn't some 10 years ago' part.  I
do admit that MAST is strikingly similar to NAT in a sense you have
pointed out below.  What intended to be a short term solution becoming
prevalent.  Yes, very unfortunate.

Now, what led to that NAT havoc?  IMO there are two reasons.  One is
lack of the long-term solution developed in reasonable timeline, and
the other is difficulty of phasing out NAT.  The former is as simple as
developing a new solution (which I hope is something we are here for :p)
so I don't think it is too terrible a situation for it's a ball in our
hands.

The latter is what people might be worried about, because, if MAST is as
hard to phase out as NAT is, it will be very frustrating when we finally
have the real solution ready for deployment.  But no, IMO, MAST is a lot
less harmful than NAT is in that sense.

NAT affects the entire network design, namely what address is being
allocated to each and every machine in the network.  Having to redesign
and reconfigure an entire network is every network administrator's
nightmare, especially considering what will result in when he makes a
mistake doing so (which is an entire network broken, of course).  So,
unless there is a *very* compelling reason that affects the everyday
operation, they will simply refuse to give up NAT.

However, MAST does not affect the network design and configuration
because it is a host-to-host protocol.  That means there will be a lot
less network structural changes, and in turn, less administrative
overhead, less headache for administrators.  They will have to upgrade
networking stack of operating systems running on their machines, but
they don't have to do it all at once (provided the new solution can
coexist with MAST, which I think must be done and is not terribly hard
to achieve); they can start upgrading less critical machines first, one
by one, then they can tackle more critical machines.  As you see here, a
conservative and gradual phase-out is possible, making its risk a lot
lower than phase-out risk of NAT.

Finally, I'm afraid I cannot fully see what you said in your postscript;
could you elaborate?

Eugene

P.S. Yes, I do hate NAT.  I just try to have a calmed-down view about
it, so I don't hate things just because they resemble NAT in some
aspect. =)

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Sep 2003 12:40:09 +0859 ()

Eugene;

> prevalent.  Yes, very unfortunate.

A permanent solution which does not require any change to
most applicaitons already desinged, implemented and has been running
for more than a year.

> the other is difficulty of phasing out NAT.

> nightmare,

Wrong.

Removal of NAT boxes is as easy as upgrading of routers.

The difficulty is in reconfiguring all the end systems.

But, that is not you argument, at all.

You proposed to have API to accomodate MAST which also accomodate NAT,
which shows your love for NAT.

Your proposal is to keep MAST and NAT forever.

> Finally, I'm afraid I cannot fully see what you said in your postscript;

Just say LIN6.

							Masataka Ohta

---

From: "Eugene M. Kim" <[email-masked]>
Date: Wed, 10 Sep 2003 22:20:46 -0700

> Your proposal is to keep MAST and NAT forever.

I don't understand.  What I proposed is an API that communicates socket
endpoint address changes to the application layer; how does that API
accomodate/facilitate NAT?

> > Finally, I'm afraid I cannot fully see what you said in your postscript;

Thank you for the pointer. =)

Eugene

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Sep 2003 15:23:49 +0859 ()

Eugene;

> accomodate/facilitate NAT?

Read ML log for my past reply.

							Masataka Ohta

---

From: "Eugene M. Kim" <[email-masked]>
Date: Thu, 11 Sep 2003 13:43:49 -0700

Hello,

If you meant your original reply to what Dave forwarded here, all that
there is seems to be `This argument is so similar to what NAT lovers say
(in order to defend NAT), so it must be automatically shot down.'  I can
see your frustration there, but it would be appreciated if you gave a
technical, not political, insight about how the proposed API for MAST
also technically, not politically, accomodated NAT.

If you were referring not to that post but to an earlier one, could you
give a pointer?  It's almost impossible to read all your posts here one
by one over a slow HTML archive.

BTW, is there an archive of this list in plain UNIX mbox format? (-- to
other ML subscribers)

Thanks,
Eugene

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Sep 2003 07:44:42 +0859 ()

Eugene;

My mail reader says on your mail:

	[Charset ks_c_5601-1987 unsupported, skipping...]

Use ASCII.

						Masataka Ohta

PS

ISO-8859-1, which some people are carelessly (or arrogantly?) using,
is also bad, though my mailer filters out non-ASCII part.

---

From: "Eugene M. Kim" <[email-masked]>
Date: Thu, 11 Sep 2003 16:58:08 -0700

Oops, sorry, especially if a lot of other people could not read the
message either (although KSC 5601-1987, or KS X 1001, is backwards
compatible with ASCII with just one exception; the backslash is
displayed as the Korean currency sign).

Anyhow, here's the link from the web archive:
http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in
ISO 8859-1).

Eugene

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Sep 2003 15:06:15 +0859 ()

Eugene;

My mail reader now complains:

	[Charset iso-8859-1 unsupported, filtering to ASCII...]

> displayed as the Korean currency sign).

ISO-8859-1 includes 96 characters with 8th bit on and is local
to scripts of western europe that it is worse than KSC 5601-1987 for
the International communication.

Use ASCII.

> http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in

OK. My comment on the API extension is right on the thread at:

	http://ops.ietf.org/lists/multi6/multi6.2003/msg01586.html

I'm afraind you still don't recognize the technical nature of the API.

							Masataka Ohta

---

From: "Eugene M. Kim" <[email-masked]>
Date: Fri, 12 Sep 2003 08:13:42 -0700

Hello,

Thank you for the pointer.

If I understood you correctly, your concern seems to be that, with the
proposed MAST API, some applications are required to be modified just to
suit MAST as they had to with NAT.  Is this correct?

Assuming the answer is yes, I still don't think it's a definitively
prohibiting reason against the API.  I say this under the assumption
that MAST will be just a transition protocol, or a stopgap, with which,
again, simple applications can work without any modifications.  I am
also assuming that MAST will be deprecated in a strong manner with,
for example, a MUST clause in a formal deprecation document.

With these two assumptions, authors of complicated application (i.e.
those that must be modified to take advantage of MAST) have two choices:

1. They wait until the long-term solution is established, then opt for
the new solution, once and for good.
2. They first opt for MAST, then later switch to the new solution.

Opting for MAST and not switching to the new solution is not an option
here because MAST will be deprecated (for example, it will not be part
of newer operating systems).

One may argue that `application authors will try to save time by
just waiting for the new solution, so the MAST API does not have any
merit'.  However, I do think that there will be a number of application
authors who feel they need MAST despite the additional work involved
because they decide that the amount of work is outweighed by other
reasons that call for MAST, e.g. customer feedback/market pressure.

Thanks,
Eugene

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Sep 2003 00:48:20 +0859 ()

Eugene;

> suit MAST as they had to with NAT.  Is this correct?

Wrong. There is no MAST API. It is NAT API. Applications for the API
is, behind NAT, notified address of a NAT box and tell it to its peer.

Of course, application on the peer also need modification, which is
practically impossible.

Try to design the API of a host and its peer, for example, for FTP.

> again, simple applications can work without any modifications.

You miss the point that MAST does not solve *THE* problem
and is useless even as an intermediate solution.

Worse, you miss the other point that no intermediate solution
is necessary.

Worst, your hidden assumption is that almost all the hosts use MAST,
which is not a sound assumption for an intermediate, if any, solution.

> those that must be modified to take advantage of MAST) have two choices:

Completely wrong.

Those applications that must be modified to take advantage of
multihoming with multiple addresses have a single choice to
be modified so with no further modification.

							Masataka Ohta

---

From: "Eugene M. Kim" <[email-masked]>
Date: Fri, 12 Sep 2003 13:46:25 -0700

> is, behind NAT, notified address of a NAT box and tell it to its peer.

Not verbatim.  In order for that to work, a new protocol is needed
between a NAT gateway and machines behind it so the gateway can notify
address changes to them.  To the best of my knowledge, none of the
existing IETF protocols do this, much less can MAST.  I think you are
worried about something that does not even exist.  If you or anyone else
could point me to an existing, widely implemented standard that serves
this purpose, I would stand corrected.

> Try to design the API of a host and its peer, for example, for FTP.

Do we have to modify FTP further than RFC 2428 in order to accomodate
MAST if it provided the API to get the up-to-date peer address for the
control connection?  If so, why?

> and is useless even as an intermediate solution.

I'm afraid you did not communicate what was `*THE* problem' you were
trying to solve here.  And before putting your answer in a short phrase
such as `multihoming' or `roaming', please bear in mind that there are
people who lock on different facets of those vague subjects.

OT: Actually I was reading your E2E multihoming draft this morning then
encountered a similar problem; you apparently believed in the concept of
E2E by using phrases like `end to end _principle_' but failed to clarify
what `end-to-end' exactly implied.  If you meant some concept widely
believed in by other people, perhaps adding at the end of the draft a
reference to some other document that discusses the concept would help
the uninformed camp (including me) understand you and your proposal
better.

> Worse, you miss the other point that no intermediate solution

Only if we can come up with a real solution in rather a short timeframe.
I thought it would be rash to draft, implement and adopt something as a
standard in such a short timeframe that existing needs need not be met
at all in the meantime.

> which is not a sound assumption for an intermediate, if any, solution.

MAST does not worsen the case where one host knows MAST and the other
does not, because it is designed in such a way that it does not impede
the transport later without first verifying that the peer also knows how
to do it.  So it need not be worried about if the peer doesn't speak
MAST, because in that case MAST will not kick in but the communication
will proceed as if neither party knew MAST.

> be modified so with no further modification.

Again, you seem to be assuming that we can come up with the long-term
solution in a really short timeframe.  Unless you can show me some
proposal is already up for that task, including deployment plans and
scenarios, I still think such an assumption is rash.

Thanks,
Eugene

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 14:19:03 -0700

Eugene, et al,

>> is, behind NAT, notified address of a NAT box and tell it to its peer.

EMK> Not verbatim.  In order for that to work, a new protocol is needed
EMK> between a NAT gateway and machines behind it so the gateway can notify
EMK> address changes to them.

NAT boxes do address translation and MAST does address translation. In a very
theoretical sense there is, therefore, some similarity between them. However
MAST is not a "network" address translation service and it really has nothing
to do with the controversy surrounding NATs.

So I am not understanding criticism of MAST that is essentially a continuation
of the criticism about NATs.  They are separate and I think the debates should
be kept separate.

As for a "MAST API", none is needed.

MAST hides the multiple addresses from transport and above.  That is one of
its features.

I believe that any application protocol that uses direct IP addresses has a
problem with any multi-homing/mobility solution.

Also, as soon as the application needs to benefit from knowing about -- and
giving guidance about -- the availability of multiple addresses, then it needs
an be nice to enhanced API. That is true for any multi-addressing solution,
not just MAST.

EMK> To the best of my knowledge, none of the
EMK> existing IETF protocols do this, much less can MAST.

Correct.

EMK>   I think you are
EMK> worried about something that does not even exist.

Correct.

>> and is useless even as an intermediate solution.

EMK> I'm afraid you did not communicate what was `*THE* problem' you were
EMK> trying to solve here.

Yes, it would be nice to hear a clear and coherent description of "the"
problem.

d/

---

From: "Eugene M. Kim" <[email-masked]>
Date: Fri, 12 Sep 2003 14:36:14 -0700

Dave,

> of the criticism about NATs.  They are separate and I think the debates should

Agreed.

> MAST hides the multiple addresses from transport and above.  That is one of

I see.  Looks like I misunderstood MAST in that sense. =)

> an be nice to enhanced API. That is true for any multi-addressing solution,

Also agreed.

A random idea: How about making MAST support these two operating mode?

1. The original scenario, where the transport layer such as TCP does not
know how to handle multiple endpoint addresses nor requests MAST to
notify about address changes.  MAST operates as originally proposed in
this case.

2. The new scenario, where the transport layer such as TCP knows how to
handle multiple endpoint addresses and requests MAST to notify about
address changes.  MAST then propagates such changes up to the transport
layer, which, in turn, may decide to propagate such changes up to the
applications via a suitable API.  What I meant by `the MAST API' was,
in fact, this.

Thanks,
Eugene

---

From: "Eugene M. Kim" <[email-masked]>
Date: Fri, 12 Sep 2003 14:42:36 -0700

> the uninformed camp (including me) understand you and your proposal

A mea-culpa self-reply... =)  It seems that concept has been already
documented for more than 20 years: Saltzer et al, `End-to-End Arguments
in System Design', found online at
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt; could
you add this to your e2e-multihoming draft as a reference?

Thanks,
Eugene

---

From: Tim Chown <[email-masked]>
Date: Sat, 13 Sep 2003 00:18:06 +0100

There was a nice presentation on this topic by Harald Alvestrand at
Nordunet 2003.   Unfortunately his slides aren't online after the event,
but he may be able to point you at them somewhere online ("Where is the 
'End' in end-to-end")

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Sep 2003 08:43:19 +0859 ()

Eugene;

> > what `end-to-end' exactly implied.

Nor did I clarify what the Internet implied.

> documented for more than 20 years:

And, it is *THE* principle of the Internet that anyonw who don't know
the principle does not understand the Internet.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Sep 2003 08:51:27 +0859 ()

Eugene and Dave;

> EMK> Not verbatim. 

The API is verbatim.

> In order for that to work, a new protocol is needed

and NAT lovers are working on it.

> to do with the controversy surrounding NATs.

NAT translate "network address". MAST is identical.

> MAST hides the multiple addresses from transport and above.  That is one of

Dave, Eugene point it out it is untrue, just as NAT does not hide
the multiple addresses.

> problem with any multi-homing/mobility solution.

Wrong concept.

Any application protocol that uses direct IP identifiers does not have a
problem with a multi-homing/mobility solution.

Instead, any application protocol that uses direct IP addresses has a
problem with NAT (and MAST, of course).

> an be nice to enhanced API. That is true for any multi-addressing solution,

Wrong concept. See above.

> EMK> worried about something that does not even exist.

It's nice that MAST dose not exist.

> Yes, it would be nice to hear a clear and coherent description of "the"

Read the draft or my response to MAST.

							Masataka Ohta

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 17:19:30 -0700

Eugene,

>> MAST hides the multiple addresses from transport and above.  That is one of

EMK> I see.  Looks like I misunderstood MAST in that sense. =)

the next version of the proposal should make things clearer.

EMK> A random idea: How about making MAST support these two operating mode?

excellent. you are anticipating some of the changes I am plan for the next
version. thank you...

d/

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Sep 2003 09:03:53 +0859 ()

Eugene;

> control connection?  If so, why?

What is your point?

RFC 2428 is "FTP Extensions for IPv6 and NATs" and, as I said, "the
peer also need modification".

It is nothing more than an illusion that NAT/MAST were transparent.

> standard in such a short timeframe that existing needs need not be met

Good argument against MAST, which does not worse implementation and
adoptation effort.

We should deploy only a long term solution with the interoperability to
leagacy protocols in mind.

> will proceed as if neither party knew MAST.

Exactly, and there is no reason to have MAST.

> scenarios, I still think such an assumption is rash.

As was presented at Vienna, the long term solution based on LIN6
is running and is interoperating with leagacy stack.

							Masataka Ohta

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 12 Sep 2003 19:21:43 -0700

since you asked:

http://www.alvestrand.no/speeches/end2end-iceland.pdf

have fun - but don't expect too much :-)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 15:44:57 -0700

Eugene,

The first draft of the proposal was rather confusing, about a number of
issues.  Please let me know if the second draft (released last night) is more
clear about this.

>> an be nice to enhanced API. That is true for any multi-addressing solution,

EMK> Also agreed.

EMK> 1. The original scenario, where the transport layer such as TCP does not
EMK> know how to handle multiple endpoint addresses nor requests MAST to
EMK> notify about address changes.  MAST operates as originally proposed in
EMK> this case.

EMK> 2. The new scenario, where the transport layer such as TCP knows how to
EMK> handle multiple endpoint addresses and requests MAST to notify about
EMK> address changes.

This sounds like a very good proposal to me.  A core API that is backward
compatible -- in fact, it _is_ the old API.  And then an extended API for the
extended functionality.

d/