RE: MHTP draft (draft-py-multi6-mhtp-00.txt)

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 14 Aug 2001, Michel Py wrote:
> >> Does this work properly if a router between to MHTP points notices
> hop
> >> count has reached zero, and emits ICMP TTL expired to the source?
> (if the
> >> TTL failure is delivered to the end node properly, the headers in
> ICMP
> >> payload would have to be translated too.
>
> I don't see any issues here. If the source prefix is singlehomed, the
> TTL failure would naturally go back to the source node.
>
> If the source prefix is multihomed, it will at some point hit an MHTP
> enabled router. Thanks for bringing that point, it
>
> makes me think that ICMP error packets might not be subject to proxying
> limits on MHTP rendezvouspoints.

To clarify (and elaborate a bit),

Well, basically you'd have to analyze all the possible packets routers
between two MHTP points could send.  For some of these, there might have
to be payload address translation.  You might not always know the format
of the data there (though, e.g. for ICMP, this should be rather
straightforward ... but what if you're using e.g. additional headers (e.g.
routing) where more are stored, ...).

> the end and leaves end-to-end traffic unchanged, and
> that will take care of most of the NAT-related issues.

Of end-to-end traffic, yes.  But as noted, ICMP and friends are not
necessarily end-to-end, rather end-to-some_router (if one assumes that
ICMP generated by a MHTP router should be transmitted and translated all
the way back to the originating node), there might be some similar
"evilness".

> You are making my point here. Everyone assumes that a good solution will
> be available when we need it. In the meantime, some
>
> people are or will be reluctant to implement IPv6 until a good solution
> is found. MHTP is not a good solution for IPv6
>
> multihoming, but I think it is a good contingency plan. What is wrong in
> developping a contingency plan before it is needed?

Yes, especially business people might be reluctant (or, some might say,
this might give them a good excuse for not considering IPv6 yet!) -- one
might not take IPv6 seriously if multihoming is not possible.

I'm pretty certain some contingency plans will be made, whether sanctioned
by IETF/IESG or not; this is a tough problem and can't be solved
overnight.  But one you're proposing makes fundamental changes to the way
people regard IP routing (one might consider it as a kind of lightweight
"MPLS over IP" I suppose), and it may not be thought as a "clean enough"
contingency plan.

And there is also an issue of opening a can of worms, so to speak.  If
this was taken to use, you would need very strong applicability statements
and whatever, so that people wouldn't think IETF is advocating a certain
kind of network design, protocol layering hacks, etc.  This might be a
start of a landslide in IPv6 world.

(I wasn't around when NAT was introduced to IETF the first time.  I wonder
how people felt what was coming then.)

If there is more interest in this, I think it might be useful to briefly
study the tunneling mechanism too.  That is viewed generally as a more
acceptable approach, and it's (mis)features have been more widely
experienced already.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords