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

[Pekka Savola <pekkas@netcore.fi>]

[strip off Michel Py <michel@arneill-py.sacramento.ca.us> as the MX isn't
reachable from here]

On Tue, 14 Aug 2001, Michel Py wrote:
> >> 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, ...).
>
> For most packets, instead of translating something inside the payload,
> it would be a lot simpler to translate the header back to the way it was
> when it was sent and MHTP takes care of that.

This way all the routers between MHTP endpoints would have to support
MHTP, right?  I'm not sure if that's an acceptable approach (there are
always some plain ipv6 routers that don't..).  I thought, perhaps I didn't
read carefully enough, that the translation process, "the intelligence",
would only be needed at the edges.

> Let's say a TCP packet expires its TTL. It does not make much of a
> difference if the router sends the "time expired" ICMP message to the
> multihomed or the corresponding singlehomed source address, either one
> would reach the host.
>
> Could you bring up a specific situation where a router in the middle
> would have to inspect/translate the payload?

Perhaps I didn't say this clearly (or maybe didn't understand the
workings of MHTP..).  What I meant, was something like:

multihomed node sends TCP packet [with some additional headers, like
  routing header]

the destination address gets converted by MHTP, the packet is passed on

Hop count expires while in transit, the router does not know about MHTP.

The router sends back ICMP message to the source address, _but_ the
  original headers have been added to the ICMP payload as is normal to
  make the original sender recognize the packet ICMP was generated for.

  However, the payload address has been translated by MHTP, so the
  original sender does not recognize the ICMP unless it's de-translated
  too.

  You would have to go through all of the ICMP message, looking for things
  to alter, change addresses and recalculate the checksum.

  Additional headers, like routing header, might make this even more
  complicated.



This is handled by NATv4, at least to some extent (I'm not sure whether
anyone has analyzed how ipv6 extension headers might affect this if there
was NATv6), but then the MHTP would have to be fully bidirectional, or..?


"Political" side:

>>> (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.
>
> I am not sure such a comparison could be made. There is a similarity in
> the sense that the path taken by the traffic is going to be altered at
> the edge, but MHTP does not add a label to the data. My reading of MPLS
> is that it is mostly about VPNs and QOS. Packets translated by MHTP have
> nothing special and could be labelled by MPLS.

You could think MHTP addressing as MPLS tags (added and removed at the
edge), and MHTP routing tables as MPLS LDP.

Sure, I didn't say it _is_ MPLS, but there are some resemblances :-)

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