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

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

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

Tell me about it. 48-hour DNS nightmare. I apologize for the
inconvenience (although none of my doing). It appears to be
back and I will soon have THREE DNS servers....

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

No they would not, see below.

>> I thought, perhaps I didn't read carefully enough, that the
translation
>> process, "the intelligence", would only be needed at the edges.

Yes. If a router in the middle is not MHTP-aware and has to deal
with multihomed traffic, it will send it wherever the aggregates to the
multihomed space point to, which is the closest MHTP rendezvous point.

Note that this is sub-optimal path, and hitting the MHTP rendezvous
point
is acceptable in some situations only. (initial deployment and ICMP
error messages and some other).


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

It does not matter if the node that sends the packet is multihomed
or not. What matters is if the destination address is multihomed,
because this is what is translated by MHTP.

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

Even if it does, it does not know about the translation table in
the router that originally sent the traffic, so it does not know
the original source address (before it was translated) and it would
not be able to translate the payload no matter what.
THis issue is similar as IPv4 NAT, not all routers in the path need to
support it.

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

Correct.

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

Correct again, and the place to do that is definitely the MHTP client
that made the original translation. I am grateful that you brought
the issue, because there needs to be special handling of ICMP messages
that hit an MHTP client, and I have not reached that point in the draft.


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

Evilness.


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

In that situation, MHTP is definitely a one-way NAT, and it does need to
be handled. I do not intend to re-invent the wheel and I think the best
approach here is to follow what the folks that design IPv6 NAT do.

Thanks
Michel.