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

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 13 Aug 2001, Michel Py wrote:
> Some of your questions have been adressed in the not-yet-published -01
> available here:
>
> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt

Isn't this what we wanted to avoid with IPv6? :-)  I believe Steve Deering
would be tearing his hair by now :-)

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.

ICMP by intermediate nodes is not the only issue with NAT techniques like
this.  I fear this might have unforeseen consequences.

I'm also a bit unsure whether this just moves the multihoming problem to a
separate table, where it would be contained until some new mechanisms are
developed.  Some improvements are naturally made, but I fear the all the
effects couldn't be properly analyzed and planned beforehand.

I have think _some_ multihoming methods will be developed before the
number of "multihomed prefixes", were there not filtering, would reach
critical bounds (perhaps 5 years, who knows).  If this kind of scenario
("race against time") is sought, perhaps just a separate prefix, allocated
to multihomed sites (and they would also have a primary prefix), would be
sufficient.  The prefix wouldn't be aggregated as strictly.  I believe the
thought has already been mentioned.  This way, "99.5%" or the like would
always be reachable through strictly aggregated DFZ, and people who care
about multihoming could play around with the other prefix until it
"explodes" or better ways are made up.

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