Subject: Re: [lisp] [lisp-interest] LISP PMTU - 2 methods in draft-farinacci-lisp-11

From: David Meyer <[email-masked]>
Date: Tue, 27 Jan 2009 04:31:07 -0800

Forwarding on behalf of Robin. Robin, the lisp list is at
	[email-masked] these days.

	Thanks,

	Dave

On Tue, Jan 27, 2009 at 04:29:22PM +1100, Robin Whittle wrote:
> Short version:  Stateless approach is a really bad idea in the future
>                 when ~9000 byte MTU ITR to ETR paths become common.
> 
>                 Stateful approach somewhat resembles Ivip's approach
>                 - which is documented in greater detail and limits
>                 the number of traffic packets for which state must
>                 be stored in case a PTB is received.
> 
> Here my thoughts on the two techniques (Stateless and Stateful) for
> LISP Path MTU Discovery management in the latest (19 December) draft.
> 
> My understanding of the whole problem (for Ivip's map-encap modes or
> for any other map-encap scheme, such as LISP or APT), together with
> my solution for Ivip, is here:
> 
>   http://www.firstpr.com.au/ip/ivip/pmtud-frag/
> 
> 
> Here is my critique of the Stateless approach, assuming L = 1500, as
> is recommended at the end of:
> 
>   http://tools.ietf.org/html/draft-farinacci-lisp-11#section-5.4.1
> 
> The stateless approach was rejected by the OpenLISP team:
> 
> http://tools.ietf.org/html/draft-iannone-openlisp-implementation-01#section-6.8.1
> 
> 
> Stateless IPv4 DF=0
> -------------------
> 
>   L is chosen for the entire global LISP system to be a minimum
>   value of MTU which can be expected of any ITR->ETR tunnel.  Here
>   I assume 1500 bytes, as is recommended in the last line of section
>   5.4.1.  Perhaps it would need to be less, such as 1470 or less.
>   Google servers regularly send 1470 byte DF=0 packets:
> 
> http://www.firstpr.com.au/ip/ivip/ipv4-bits/actual-packets.html#google-no-pmtud
> 
> 
>   IPv4 DF=0 packets longer than some size S will be fragmented
>   into two fragments, each of which will be encapsulated.  The
>   ETR decapsulates them separately and sends the two fragments
>   to the destination network.
> 
>   S is set globally to a value is L minus the encapsulation
>   overhead = 36 bytes.  (IPv4, UDP and LISP headers, in section
>   5.1).  So S = 1464 bytes.
> 
>   This will not work when the packet length is more than about
>   twice S (since fragmentation produces two packets whose
>   combined length is marginally longer than the original packet).
> 
>   The statement:
> 
>     "This will ensure that the new, encapsulated packets are of
>      size (S/2 + H), which is always below the effective tunnel MTU."
> 
>   will not apply when the incoming packets are more than about
>   twice S in length.
> 
>   Still, with a bit of tightening of the spec, I see no major
>   problems with this approach to IPv4 fragmentable packets compared
>   to what I propose for Ivip.  I don't think a core-edge separation
>   scheme should be required to support DF=0 packets longer than
>   something like 1470 bytes into the indefinite future.
> 
>   RFC 1191 PMTUD has been around since the early 1990s and I think
>   it is time that hosts stopped expecting the network to fragment
>   packets.  The IPv6 designers evidently thought the same in 1996.
> 
> 
> 
> Stateless IPv4 DF=1 and IPv6
> ----------------------------
> 
>   This approach makes no sense for the long-term future since it
>   forces all traffic to be in packets no longer than 1464 (IPv4)
>   bytes:
> 
>       the ITR will drop the packet when the size is greater than L,
>       and sends an ICMP Too Big message to the source with a value of
>       S, where S is (L - H).
> 
>   Replacing the variables with constants for IPv4, this means:
> 
>       the ITR will drop the packet when the size is greater than 1500
>       bytes, and sends an ICMP Too Big message to the source with a
>       value of 1464 bytes.
> 
>   For IPv6, the limiting size is set by the 56 byte overhead, to 1444
>   bytes.
> 
>   A proper solution should keep working well when the DFZ includes
>   MTUs of 9000 bytes between ITR and ETR - and should allow the
>   sending host to generate packets of nearly this size, so that once
>   encapsulated they still fit within whatever the MTU is for the
>   path to this ETR.
> 
>   Fred Templin raised similar concerns:
> 
>   http://www.irtf.org/pipermail/rrg/2009-January/000884.html
> 
>   (My guess is that the non-DF=0 part of this approach was written
>   with an assumption that L would be individually determined by the
>   ITR for each ETR - but that is not the way the I-D is written: L is
>   fixed at 1500 bytes, and any such method would be stateful.)
> 
> 
> Stateful approach for all packets
> ---------------------------------
> 
> I am reading the LISP version - I have not looked in detail at the
> OpenLISP source of this approach.
> 
> This makes no reference to IPv4 DF=0 packets.  So this approach of
> the ITR sending a PTB packet to the sending host when a DF=0 packet
> exceeds some length is not going to result in any action on the part
> of the sending host.  Such a DF=0 packet will be dropped by the ITR.
>  That may be OK - Ivip will do much the same - but it needs to be
> specified clearly.
> 
> This approach of determining the MTU to each ITR by receiving ICMP
> messages from an intermediate router needs to be done securely.
> 
> It requires the ITR to cache significant amounts of information for
> every packet it sends which might trigger such a PTB.
> 
> The intermediate router would need to send back sufficient of the
> original packet to ITR to include the LISP nonce.  Otherwise, PTBs
> spoofed by off-path attackers would be accepted and the whole system
> could easily be DoSed.
> 
> The ITR needs to store an initial fragment of each incoming traffic
> packet for some time, so it can generate a PTB message for the
> sending host.  It can't rely on enough of the original packet coming
> back in the PTB from the intermediate router.  The ITR needs to cache
> this for a second or two at least - while it waits for a possible
> PTB.  This is an onerous requirement in a high-volume ITR.
> 
> Ivip map-encap ITRs need to perform a stateful PMTU determination
> process which is somewhat similar to this.  However, the Ivip
> approach quickly narrows the zone of uncertainty so that the number
> of packets involved in testing PMTU is very limited.
> 
> The Ivip approach is specified in greater detail, including
> occasionally sending longer packets (if and when the current or some
> other sending host generates them) to see if the MTU has grown
> since the last PTB set a limit on it, as far as the ITR was concerned.
> 
>  - Robin
> 
> 
> 
> 
> 
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Robin Whittle <[email-masked]>
Date: Wed, 28 Jan 2009 00:25:04 +1100

Short version:     Luigi suggests a method by which the ITR
                   can perform PMTUD to an ETR without having
                   to cache the original packet.  This requires
                   three things to be done to achieve the goals
                   without the most obvious DoS vulnerabilities:

                   1 - The intermediate router sends back at least
                       16 bytes of original packet in the PTB -
                       8 bytes more than RFC 1191 requires.

                   2 - It is acceptable for the system not to
                       deliver the first "too long" packet.

                   3 - The sending host sends a second "too long"
                       packet after the ITR has received and
                       processed the PTB from the intermediate
                       router.

                   If the system is supposed to work without the
                   PTB check requiring the LISP nonce in the PTB's
                   original packet fragment, then I think the ITR
                   still needs to store some details of recently
                   sent packets, to force the attacker to set some
                   other parts of the PTB's original packet fragment
                   to hard-to-guess actual values of packets sent.

                   I modify my critique of LISP accordingly - this
                   looks like a reasonable way to do PMTUD without
                   the ITR maintaining a lot of state.  However the
                   smallest amount of state would be the LISP
                   nonce of recently sent packets and this requires
                   all intermediate routers which might have an
                   MTU problem to send back more than the RFC 1191
                   minimum of 8 bytes.

                   The process of checking PTBs in a busy ITR could
                   become so expensive (due to the large number of
                   LISP nonces or other details to be checked, of
                   recently sent packets) that it could become a DoS
                   vulnerability in itself.

                   How I think an off-path attacker could find the
                   addresses of some, many or most ITRs which are
                   tunneling packets to some ETR the attacker wants
                   to DoS.

                   An ITR occasionally needs to allow longer packets
                   to the ETR than its current MTU setting allows -
                   otherwise it has no way of adapting to an
                   increased actual path MTU.

Hi Luigi,

Thanks for your reply, in which you wrote:

> As a member of the OpenLISP team, let me say that we do not
> *accept* or *reject* anything.  AFAICT, that is left to the
> community and to the (future) LISP WG.

OK - "rejected" was my way of stating that you didn't find the
stateless approach suitable for OpenLISP:

   6.8.1. OpenLISP local MTU Management

   During preliminary tests, we observed that the MTU issue is at the
   origin of many problems.  OpenLISP does not (and will not)
   implement the fragmentation mechanism proposed in Sec. 5.4 of
   [I-D.farinacci-lisp].  The reason is because the proposed method
   sounds very primitive and does not appear to be efficient.  The
   original LISP specification is based on an architectural constant
   used by the xTR to limit the MTU of LISP encapsulated packets.
   OpenLISP uses a more advanced solution, based on the real MTU of
   the local RLOCs present on the xTR, as described below.

> What we proposed is just an alternative approach that takes advantage of
> ICMP messages (if they are present).

OK - your approach makes sense.  I am reading it now.

> The text that we provided is just a first cut. I agree that there are
> several points to clarify.

OK.

> Am I wrong if I say that this means to change the ICMP protocol?

I meant securely enough to prevent spoofing by an off-path attacker
intent on DoS.  (Full description below.)

The LISP nonce should do the trick - but that requires the
intermediate router to send back to the ITR, in the PTB message, the
8 byte LISP header after the UDP header.  RFC 1191 only requires it
to send back the outer IP header and the next 8 bytes - which in a
LISP packet is the UDP header.

This was a pretty short-sighted requirement, I think.  I don't know
how DFZ routers behave, but I recall someone (Bill Herrin?) stating
some months ago that it was common to send back more bytes than the
bare minimum of 8.  If LISP or something similar was implemented in 5
years time, I guess it wouldn't be too much to ask the router
manufacturers to create firmware updates if their routers don't
already send back a decent number of bytes such as 32 or whatever.

Without this, the ITR can't "securely" respond to ICMP PTB messages.

> Our goal was not to introduce new mechanisms in the core, but rather to
> take advantage of what exists.

OK.

> Why should the ITR cache information?

Skip the following if you like:

    My understanding of what ITRs would have to do, before I read the
    rest of your message:

    For every encapsulated packet the ITR sends which might generate
    a PTB message in some router en-route to the ETR, the ITR needs
    to cache - I mean store for a few seconds - the start of the
    original packet and the nonce it put in the LISP header of the
    encapsulating header.   I guess the ITR needs to store it for a
    few seconds, since it might take that long for the PTB to come
    back.  Technically, maybe it should hold it for longer, but my
    guess is that 2 seconds should do the trick.

    Then, when a PTB arrives, the ITR needs to compare the LISP nonce
    in the PTB's fragment of the initial packet (see discussion above
    about how this requires more bytes than RFC 1191 requires) with
    its cached information about recently sent packets.  It should
    also check other things such as the destination address in the
    packet fragment, to ensure it is the same as the ETR to which it
    tunnelled the packet.  This will enable the ITR to uniquely
    identify one of the packets it recently sent.  Then it can adjust
    for that ETR its record of path MTU, and generate a PTB packet to
    be sent to the sending host, from its cached fragment of the
    start of the original packet.

    After that, the ITR can use the stored value of MTU for that ETR
    and use it to decide whether to accept or reject with a PTB any
    packet to be tunneled to that ETR.

I don't think your I-D doesn't mention this, but the ITR also needs
to occasionally let a longer packet be encapsulated to this ETR - a
packet long enough that once encapsulated it would exceed the ITR's
current notion of path MTU to this ETR.  This will only occur if and
when one of the following occur:

  1 - The original sending host, in the same communication session
      tries its luck with a longer packet for the same reason.  RFC
      1191 specifies the one sending host should not try a longer
      packet to a given destination address for 10 minutes after
      receiving a PTB.

  2 - Some other sending host sending a longer packet through this
      ITR to an EID address which is mapped to the same ETR.

  3 - The same sending host, in the same or another application,
      sending a long packet to a different destination address,
      which may or may not be in the same EID as the first
      destination address, which is mapped to the same ETR.

Then, if the longer packet does not result in a PTB, the ITR should
probably raise its notion of the MTU to that ETR accordingly.

However, packet loss here (loss of the too long packet before the
intermediate router with the limiting MTU, or loss of the PTB message
from that router) could result in a too-long MTU setting in the ITR.
This is not such a problem, since it would probably soon be corrected
if subsequent packets passed through the ITR due to this too-high
value and did result in a PTB being received by the ITR.

The Ivip approach can use PTBs from intermediate routers, but does
not rely on them absolutely.  It uses positive and negative
acknowledgement from the ETR for a small subset of packets which,
once encapsulated, are of a length which falls within the ITR's "zone
of uncertainty" for the path MTU to this ETR.  This zone is reduced
by every such packet and would, in general, quickly diminish to zero
- after which the technique is only needed occasionally to test
whether the MTU limit has risen.

I think would be best to store the path MTU value in a separate body
of data from however you store the mapping information.  The mapping
information is indexed on EID, I assume.  You might have in the
mapping cache thousands of entries which all use the same ETR.  It
makes no sense to store the ETR's path MTU in every one of those
entries.  I think the encapsulation process needs to check the path
MTU to the ETR after it has determined which ETR address to tunnel
each packet to.

> Probably there is a DoS risk, but IMO is from on-path attackers. How can
> an off-path attacker know that a specific ITR is sending packets to a
> specific ETR and send a fake ICMP message to shrink the MTU toward that
> specific ETR?

It is easy to find out where the ITRs of a particular ISP or end-user
network are.  Attackers could discover this by various means, but
here is one:  They get their own EID space, which is mapped to an
RLOC address of one of their own machines - which pretends to be, or
is, an ETR.  Then, the attacker sends to some host in the ISP or
end-user network a ping packet or any other packet which will elicit
a response.  That packet has a source address in the attacker's EID
range, so the targeted host will send back a response to that
address.  The ITR in the targeted site will look up the mapping for
the attacker's EID address and so tunnel the response packet to the
attacker's "ETR".  With LISP, APT and TRRP, the encapsulation outer
header's source address is that of the ITR, so the attacker's "ETR"
learns the address of the ITR.  (With Ivip, the source address is
that of the sending host.)

So attackers can easily find the address of an ITR in some network of
its choice where there are sending hosts.  It could do this en-masse
and so discover the addresses of ITRs in many such networks.

The attacker presumably has some idea of where the sending hosts are
for the destination network it wants to DoS.

The attacker could find the addresses of Proxy Tunnel Routers which
handle the attacker's EID.  The attacker simply send packets from one
of its own EID addresses to random IP addresses to get responses from
a bunch of hosts, many of which will use a PTR (all those which don't
have an ITR in their own network).  If there were a single set of
PTRs which handled every EID, then this would suffice to locate all
PTRs in the world.

However, at least in the Ivip model, there probably won't be OITRDs
(the Ivip version of LISP's PTR) which handle every micronet.  There
seems to be no business plan for LISP PTRs, so I can't say how they
would be organised.  Assuming that there is one set of PTRs for one
subset of the EID address space, and another set for another subset,
then the above method will only allow the attacker to discover the
PTRs which handle its subset.

I can't easily think of a way an off-path attacker could find the
addresses of the PTRs which handle the EID space of some network
which the attacker wants to DoS.  Nonetheless, attackers in general
could figure out the addresses of PTRs in various PTR networks and
share this information between themselves.

So an attacker could find the addresses of some, many or most ITRs
which might be tunneling packets to the site they want to DoS.

The attacker presumably has a motivation to DoS a particular ETR.  If
the attacker wants to DoS the ETR(s) of a particular organisation, it
can easily look up the mapping for that organisation's EID prefix to
obtain the ETR addresses.

With the ETR address and a list of ITR addresses, the attacker can
inexpensively generate a sequence of spoofed PTB packets.  (But see
discussion below on how much information the ITR needs to store about
recently sent packets, to force the attacker to correctly set length,
checksum and (IPv4 only) Identification bits to match a packet
actually sent, which the attacker, being off-path, can't see.

Each such spoofed PTB, if recognised by the ITR, can be used to
clobber the MTU the ITR perceives for the targeted ETR, so causing
significant and reasonably persistent DoS for a potentially large
number of sending hosts which rely on that ITR - and a potentially
large number of destination hosts in potentially multiple destination
networks which rely on this ETR.

If the ITR requires the LISP nonce to be in the PTB fragment, then
the system is secure against such spoofing, but then this PMTUD
system will only work if all the intermediate routers which might
cause an MTU problem send back at least 16 bytes rather than the RFC
1191 minimum of 8 bytes after the IP header.

> No. This is not the case.
> Assume the following topology:
> 
> H1-----------ITR1-----<DFZ>----------ETR2-----------H2
> 
> where host H1 send packets to host H2.  If a first packets triggers a
> ICMP PTB in the DFZ, this is sent back to ITR1, which sjust stores the
> fact that to reach ETR2 a smaller MTU must be used. Nothing is sent back
> to H1.

But that involves data loss.  The Ivip approach is intended to avoid
this.

> H1 sends a second packet. On the ITR1 there will be a check on the MTU
> triggering a second ICMP PTB to be sent back to H1.

Ahh . . . OK, you can make it work this way if you accept data loss
on the first large packet, expecting the sending host to generate
another similarly large packet, which seems reasonable.

I don't think this technique can be used with Ivip, but I will
consider it when I write the PMTUD I-D.

I withdraw my critique of LISP's stateful approach to PMTUD requiring
storage of the initial part of longer packets for a few seconds.
However, I think the text of draft-farinacci-lisp and your own
OpenLISP I-D should be revised to make this process clearer.

Still, if you are to check the nonce, you do need to store each nonce
of recently sent packets.

To do a proper check of the PTB, you need to store some packet
details - to force the attacker to generate the correct
Identification (IPv4 only) and Length bits from the IP header.

Likewise, if you store the UDP checksum of recently sent packets,
then you can force the attacker to get that right, which would be
generally impossible except by lots of attempts for data packets.  It
would be easier to spoof the checksum and length of TCP SYN packets
or some other commonly used short packets.  To protect against that,
your ITR would need to store the length of such (generally short)
packets and make sure the potentially spoofed PTB message's MTU limit
was not longer than the actual packet.  This, combined with some
general limit on how low you would accept the MTU to be according to
any PTB, would probably make the system immune to this kind of attack.

Also, I think you need to either check the LISP nonce (and accept the
system will fail if the PTB original packet fragment doesn't contain
it) or not expect it and so recognise that the system is open to a
powerful DoS attack if you don't store a bunch of details of recent
packets, and use them to carefully check all PTBs.

This PTB checking process itself could represent a DoS vulnerability
for a busy ITR.  If it has a lot of details of packets recently sent
- potentially hundreds of thousands or millions, I guess, and you are
not requiring LISP nonces, then you still have to search through some
long and constantly changing lists of packet details such as length,
UDP checksum (IPv4 only) Identification etc.  for every PTB received.

This could easily get way out of hand - those cached lists of recent
packet details are expensive enough to add to and clean out, and I
guess they can't inexpensively be optimised for inexpensive searching
to see which one matches a PTB.

PTB messages are pretty short (inexpensive for the attacker to send)
and could chew up a lot of ITR CPU power to process.  Checking only a
fraction of these PTBs (in order to limit the CPU time spent chewing
through a flood of spoofed PTBs) would slow down the ITR's ability to
adapt properly to actual MTU problems.

> So, you need two big packets in order to make the feedback reach the
> original sender, but the ITR does not need to store packets.
> 
> Hope this clearer now.

Yes - thanks.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 30 Jan 2009 13:06:35 +1100

Hi Fred,

Thanks for these references, and some other PMTUD discussion in
the "Please respond: Questions from the IESG as to whether a WG
forming BOF is necessary for LISP" thread, which I will respond
to here:

>> I stand corrected about LISP's approach to PMTUD - the latest
>> draft does include an outline of a workable solution.
>
> I don't know if you were fishing for a response,

No.  I meant it was at least going to work, if the PTBs
contained the nonce.  It may not work very well, but that is
better than the stateless approach, which won't work at all.

> but the
> stateful solution outlined in the latest LISP draft still
> has problems. It should also be mentioned that the approach
> (drop first; return PTBs for subsequent) is not new and
> has been proposed many times over the years.

I hadn't heard of this approach before.  I still think it has
problems.

> The approach in the current LISP draft still relies on ICMPs
> coming from anonymous network middleboxes (which Dino himself
> has said that we cannot depend on),

Dino clarified this to say that he thinks we can rely on PTBs
being sent - and generally rely on them being received:

  http://www.irtf.org/pipermail/rrg/2009-January/000899.html

    But ICMP TooBig and Time-Exceeded message are sent and are
    more dependable. That is, they can get lost when they are
    transmitted since they are single transmitted datagrams. But
    at least they are sent.

I assume this is true - it makes sense.  Anyone configuring a
DFZ router or an internal router between any ITR and ETR would
be badly mistaken not to allow generation of any PTBs.

> and provides insufficient
> means for authenticating any ICMPs that may come. For example,
> even if the ICMPs were delivered, and even if they included
> the LISP nonce, it would be impractical for the ITR to cache
> enough nonces of enough recently-sent packets especially at
> high data rates.

I tend to agree, but it depends on how smart the ITR is about
recognising "longer packets" and only caching details for that
subset.  There's no need for the ITR to cache a LISP nonce for
the purposes of PMTUD if the packet is shorter than some
constant below which it can be assumed there are no MTU
problems.  So VoIP packets and quite a few others will not need
to have any nonce or other details cached.

I wonder if there is a cryptographic approach to generating 32
bit nonces such that it is not necessary to cache each one in
order to be able to verify that a nonce in a PTB matched a
recently sent packet?

For instance, for a period of a second or two, set a randomly
selected set of 16 bits in the 32 bit nonce to some particular
bit pattern, which is pseudo-random, which remains the same for
the period and is cached.  Then, change the other 16 bits for
each generated nonce.

Hmmm - this just makes it easier for an attacker to spoof a nonce.

Maybe send the same nonce for all packets for 0.1 seconds . . .
No - if an attacker can get a tunneled packet from this ITR to
its own ETR then it use the nonce to spoof a PTB apparently from
a tunnel to another ETR.

Maybe there is some snappy crypto approach to this, but it needs
to be lightweight when checking the nonce in a PTB - and
knowledge of another recent nonce must not allow an attacker to
improve their chances of spoofing a valid nonce of another
packet tunneled to some other ETR.

My plan in:

is that a very small subset of packets get the special PMTUD
treatment.  Every such packet will result in a reduction of the
zone of uncertainty about the path MTU to the ETR.  Data will
either be delivered or the ETR and therefore the destination
network or the ITR will send a valid PTB to the sending host.

Pretty quickly, ordinary RFC 1191 sending host behaviour will
result in the zone of uncertainty being reduced to zero.  Then,
except for occasional attempts to try longer packets than the
current estimate allows, or to confirm that packets are getting
through when they are close to, or at, the current MTU limit,
there is no special treatment of packets and so nothing to
cache.  (In Ivip, ordinarily tunneled packets hitting an MTU
limit will not generate a PTB to the ITR - the PTB will go to
the sending host and not be recognised there.)

> So, the only option is to ignore ICMPs (leads to black holes)
> or honor ICMPs (leads to denial of large packet service).

If the ITR doesn't attempt to recognise PTBs, then it needs some
other way of determining PMTU to the ETR - which involves
special protocols between the ITR and ETR.  This is part of what
I am proposing.

My approach does recognise PTBs if they are sent with enough of
the offending packet to contain the nonce in the "Packet B",
which is the same length as the original traffic packet would
become with ordinary Ivip encapsulation.  This requires the
intermediate router send back at least 8 bytes more than the
bare minimum 8 bytes required by RFC 1911.

I think it is reasonable to expect DFZ and internal routers to
do this.  I recall someone writing that many do it already.  It
would be a straightforward config change or firmware update to
make sure they all did it in time for the introduction of Ivip
or any similar system.

So secure recognition of PTBs is used by my system, but the
system will still work without PTBs.

> I have said this before, but AFAICT DF=1 is busted.

I don't understand why.  My approach should support any RFC 1191
 sending host creating DF=1 packets as long as it likes,
including as more and more paths between ITRs and ETRs change
from ~1500 to ~9000 or whatever in the future.

It is the DF=0 packets I think are a problem.  I intend to
handle them up to a certain length - something a little below
1500 bytes.  Longer than that and the ITR will drop them.

I think it is unreasonable for a sending host to expect the
network to fragment its excessively long packets ca. 2015 or
whenever Ivip or the like is deployed.  RFC 1191 is a perfectly
good approach and has been available since 1990.

  - Robin