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

From: "Michel Py" <[email-masked]>
Date: Tue, 14 Aug 2001 16:23:16 -0700

I split the thread into two parts, technical and political.
Also, if the WG thinks this is annoying and Pekka and I should discuss
the matter privately, please say so.

Technical:
----------

Pekka Savola 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.

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?

>> Of end-to-end traffic, yes.  But as noted, ICMP and friends
>> are not necessarily end-to-end, rather end-to-some_router

or "some_router-to-end" as well

>> (if one assumes that ICMP generated by a MHTP router should be
>> transmitted and translated all the way back to the originating node)

This is the way it works now. The host that sent the traffic is the one
that gets back the "Time expired" or "unreachable".

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

My original design was based on tunnels; I detailed in the draft why I
moved to NAT. Back to the ICMP TTL expired scenario, a tunnelled
solution would not notify the host that originally sent the offending
traffic but the router that tunnelled it (unless the router specifically
decapsulates the tunnel, a lot of work).

Political:
----------

>> there might be some similar "evilness".

There will be. Most network protocols have experienced some "evilness"
during their development.

>> But one you're proposing makes fundamental changes to the
>> way people regard IP routing

I would not qualify MHTP as "fundamental" as related to IP routing. BGP4
could be optimized for MHTP but does not need to be modified and will
still be the one that routes packets over the cloud.

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

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

Candid question:
Does this workgroup generally think that a contingency plan is a good
idea,
and should it be sanctionned by the IETF/IESG ?

Michel.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Aug 2001 17:05:59 +0300 (EEST)

[strip off Michel Py <[email-masked]> as the MX isn't
reachable from here]

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

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

> 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