Subject: [pmtud] pmtud ietf57 vienna minutes, version 0

From: Matthew J Zekauskas <[email-masked]>
Date: Thu, 21 Aug 2003 18:05:37 -0400

Due to a misunderstanding on my part, these are a little late...
Let us know if you have comments (stuff with XXX, in particular,
indicates areas where none of the note-takers captured the
conversation).  I expect these were actually due last week,
although I haven't had any of the usual reminder mail from
the proceedings editor; reading sooner rather than later would
be helpful, however.)

Matt M's original slides are here
http://www.psc.edu/~mathis/papers/pmtud200307/

A hacked version of the pdf file to try and get a clearer xplot
slide is here:
<http://people.internet2.edu/~matt/pmtud/meetings/ietf57/pmtud200307-mz.pdf>
==================================================================
Path Maximum Transmission Unit Discovery Pre-WG (pmtud)
Thursday, 17-July-2003 from 13:00 to 15:00
=======================================================

The meeting was chaired by Matt Mathis and Matt Zekauskas.
Al Morton, Itojun Hagino, and Matt Z. took notes, which were
assembled into these minutes by the chairs.

Agenda
------
 * Preliminaries: Blue sheets, Note takers, etc
 * WG Status
 * Short history and work to date
 * Robustness Issues
 * Other Stakeholders
 * Plans

Matt Mathis led off the meeting presenting the new co-chair, the
agenda, the changes to the proposed charter, and the aggressive
milestones.

The group status is that some parts of the administrative preparation
did not get done, but IESG has approved, hence "Pre WG".  This will be
a fast development, silence will be acceptance (at the start as sections
are integrated).  PMTUD is a re-activation of path MTU WG, which was
a very similar effort.  To participate, you must subscribe to IETF list
([email-masked]).  Matt Zekauskas volunteered to Co-chair the group.
The charter was broadened so as not to restrict to a single method.
Milestones are aggressive, and need for implementation to test is clear.

No one disagreed, nor were there suggestions for other methods to
study.  Matt Mathis will make another editorial pass at the document
(which was a rewrite, starting from RFC 1981, instead of an update to
the previous BOF input).  Sections will be added based on mailing list
comments and any input from stakeholder communities.

Matt Mathis sketched the previous algorithm and noted some of the
problems.  He then sketched the new algorithm, noting that there
is just a small amount of MUST/SHOULD language: under what circumstances
can losses be ignored as a congestion signal.  The rest is heuristics;
it doesn't need to be the same for every application, and permits
vendor diversity.

Question: when can the algorithm be used by TCP?  Just after 3-way
handshake, or before real communication?  Matt responded that it
uses live payload data, and the draft has a recommendation not
to attempt the algorithm unless the congestion window is at least
twenty packets, so the connection is well established before the
algorithm starts.  Thus, this could slow down tiny files -- the
exact algorithm is a heuristic, so you could choose to perform
it differently.  There are tradeoffs.

The request for collaborators in the IPsec & security area led to a
big discussion on tunnel issues.  People were positive about the
method, but there are corner cases to consider.  Input has been
promised to the mailing list.  (In the IPv4 world, lack of PMTUD is
noted as a major problem with IPsec VPNs and providing services.)

This started around slide 11, "Plans for the Next Draft".  One
of the collaborators was folks from the multicast area; one possibility
is a generalization of the algorithm for reliable delivery.
This would solve an ICMP implosion problem if the current MTU
discovery technique was used.  Someone noted that the behavior
as specified in IPv4 and IPv6 was different, in  6 you respond,
in v4 you don't. [XXX]

Another collaborating group would be IPsec; currently the security
architecture document has major sections dealing with the interaction
of MTU discovery and IPsec (because tunnels are created); the new
technique might obsolete many of those sections.

One audience member [Itojun, I think -XXX] noted that the interaction
between IPsec and and TCP depends on if the TCP stack is aware of IPsec.
If the TCP stack does not take care of the IPsec header size, the
algorithm would need to be revised.

Matt M. responded that the detail in the draft needs to be resolved
in a consistent way.  You can count the IPsec header as part of the
IP header or TCP header.  The really nasty cases involve additional
layers, for example IPsec on a VPN, ICMP messages could go back to
the wrong place.

Michael Richardson expanded on this as an IPsec implementer.  The
worst case is common at meetings such as this -- you have a corporate
address on your laptop, and a VPN back to the corporate space, so
all traffic goes back to HQ.  Try to visit a bank, and they have
ICMP filters.  Your gateway is sending out ICMP messages to the
bank, and they drop them.  This proposed algorithm should work
really well.  Many times VPNs are blamed, when the problem is really
a bad ICMP filter.

However, there is a problem, if you raise the MTU and the tunnels do
not toss large messages but fragment them anyway, you will end up
always fragmenting.  Someone working on a Linux version mentioned that
he did not honor the DF bit; having a poor(er) performing
implementation was better than one that didn't work at all.  ("Poor
performance is better than no security.") Perhaps there could be a
heuristic that worked for a short term solution so these mechanisms
don't interact badly... the endpoint would need to be updated for this
algorithm, so IPsec tunneling could be updated at the same time.  This
behavior is often a kernel option, too.  Perhaps you could fragment
into tunnel, but retain the DF bit, and if set don't do anything
weird.  Itojun related KAME experience; there they ended up not
setting the DF bit on output header when IPsec tunnels are created.

Another point was that IPv6 (on IPv4?) tunnels have the same issue.
IPv6 tunnels should have a MTU of 1280 by default so a minimum MTU
can be maintained.

Matt M. mentioned that he's aware that a large number of tunneling
implementations don't copy the DF bit from inner packet to outer
header.  He's not yet sure if the document needs a specific section
covering tunnels and tunnel migration; an intermediate ground that
works is to let tunnels behave this way in the interim, and discourage
a mode where end systems ignore can't fragment messages.

Someone else pointed out that mobility might add additional headers;
so a tunnel MTU of 1280 might not be enough.

Itojun stated that he was thinking of configured tunnels and not mobile
IPv6.  If you send a packet with mobile headers, the TCP stack needs
to be aware of the size of the mobile IP headers and reduce MSS
appropriately -- maintain the total MTU size.

Another person agreed that 1280 is particularly bad, 1380 would be
better.

Matt Mathis noted that there was definitely a subgroup interested in
considering tunneling and MTU discovery; he encouraged folks to
join the mailing list and contribute the various circumstances where
there are potential problems.

Lars Eggert mentioned that RFC2003 specifies some things related
to MTU discovery, and RFC2401 specifically prohibits some of the
mechansims in RFC2003 for security reasons.

As to other transport protocols, Matt Z. reported that he had
quickly skimmed SCTP and DCCP documents, and that SCTP looked
possible, but DCCP says specifically that the MTU can't be raised.
No one that claimed to be an SCTP expert was in the room (or at
least didn't comment negatively on the applicability to SCTP).
Eddie Kohler noted that this behavior was revised in the
DCCP WG meeting this week.   Matt Z. prompted him to send some DCCP text.

Matt M. emphasized that the point with getting a draft done early
is to encourage implementation as soon as possible.  The algorithm
will use specific details of other protocols, and we're dependent
on the uniformity of implementation of certain features.  We need
to learn what implementations really do; ideally get a custom
implementation run on servers and real field data to feed back
into the document.

Matt M also noted two cases that he's worried about (although
these are just examples; others are encouraged to consider other
cases, or report back implementation experience).  First, what
happens if a path is striped across multiple links, and the MTU
is not the same across the stripes?  You can require that the
MTU is not raised until a certain number of segments are received
successfully.  You need to understand the interaction between random
losses and whether the MTU is or is not raised.  Second, what happens
if there is a parametric failure -- when raising the MTU causes the
error rate to increase?  An actual case is one particular 10G gbic;
it was error free with 1500 byte packets, but not with 9000 byte
packets.  There is an opportiunity for different heuristics here,
for example use a smaller MSS if you cannot fill a window.

For hard, repeated, timeouts the first thing you want to do is
reduce congestion variables, then reduce MTU.  At some point want
to restart the checks to increase MTU.

There are other possible protocol interactions, too: for example,
SCTP can use multiple endpoints.  What if it changes addresses,
and the new path has a smaller MTU?

Michael felt that it was important to focus where the production
environments hurt most with the current MTU scheme.  Matt M noted
that different things hurt in different environments.  Michael
expanded that the most frequent case will likely be large port 80
responses to a client.  And it's the client that would decide that
the path is stupid or broken, and other A record should be tried.
The web server is getting the timeouts, not the client.  This won't
deploy if we can't solve the web server case.

Matt M noted another case he had thought about, but not seen: what
happens if raising the MTU causes link stability problems (as opposed
to hard failures) -- say the link "goes away" for 10 seconds and then
returns.  He's thought about using a state machine to catch this case...
the link is broken, and we don't necessarily want to fix it with
an MTU discovery algorithm.

On ignoring DF bits, so that a tunnel fragments large packets: Matt M
contended it was worse for a 1500 tunnel fragmenting a 9000 packet
than a tunnel fragmenting a 1500 packet by the tunnel overhead.
Michael didn't understand this at first; Matt explained that
the problem is that with many fragments the odds are greater that
you lose a fragment, and hence the whole packet than if there
are only two fragments.

In thinking about other stakeholders, one person felt that the
algorithm would work for RTP over UDP; there you have some
extensions to share information -- reliable instrumentation of
losses. [XXX]

Itojun said that we should contact [email-masked] for SCTP.

In the multicast case, it was argued that this algorithm might cause
an ACK implosion that is worse than a ICMP-message-too-big implosion.

[something about DSS/MPP? bridges & MSS flapping hack that I didn't catch.
delete if you don't know anything about it.
mr:
dss/mpp bridges doing is MSS flapping hack.  maybe should write it down
and say please don't do it, do it instead
XXX]

Someone commented that the document as written is very TCP specific.
The algorithm should be better separated from actual deployment.
Matt M said that's the intention.

Another question was what, exactly, is the definition of MTU?  End-to-end
or link-specific.  Matt M said that we were talking about IP MTU
when using a particular link layer; how the IETF uses it, not what
hardware specifications say.

It was also argued that IPv6 might not need this at all; the algorithm
could arguably make performance worse (since the MSS size would ramp
up instead of being decided once by ICMP-message-too-big); However,
the new algorithm would prevent against implementation or
configuration bugs and also work in the cases where L2 MTUs were
different on a switch.

One audience member said that this should be documented in detail.
Since v6 has no DF bit, people that block ICMPv6 won't get connectivity,
so people won't block it.

Matt M noted that some stacks have IPv4 mimic IPv6 -- they always set
DF, even on fragments,  and attempt to fragment only at the endpoints.

However, there's no requirement that routers send the too big messages
in v4, but there is a requirement in v6.

Another comment was tha the MTU in Router Advertisement messages should
solve this problem.  If operational experience says this isn't happening,
it should be reflected to the v6 working group.

Matt M said that in all cases the problems with path MTU discovery
are bugs.  There are a large set of problems.

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Aug 2003 19:50:23 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Matthew" == Matthew J Zekauskas <[email-masked]> writes:
    Matthew> Michael Richardson expanded on this as an IPsec implementer.  The
    Matthew> worst case is common at meetings such as this -- you have a
    Matthew> corporate address on your laptop, and a VPN back to the
    Matthew> corporate space, so 
    Matthew> all traffic goes back to HQ.  Try to visit a bank, and they have
    Matthew> ICMP filters.  Your gateway is sending out ICMP messages to the
    Matthew> bank, and they drop them.  This proposed algorithm should work
    Matthew> really well.  Many times VPNs are blamed, when the problem is
    Matthew> really a bad ICMP filter.

  But, the key thing is that the "new" item is the VPN, not the ICMP filter.

    Matthew> However, there is a problem, if you raise the MTU and the
    Matthew> tunnels do 
    Matthew> not toss large messages but fragment them anyway, you will end up
    Matthew> always fragmenting.  Someone working on a Linux version
    Matthew> mentioned that 
    Matthew> he did not honor the DF bit; having a poor(er) performing
    Matthew> implementation was better than one that didn't work at all.

  That was me. I am the FreeS/WAN technical lead.
 
    Matthew> ("Poor performance is better than no security.") Perhaps there
    Matthew> could be a heuristic that worked for a short term solution so
    Matthew> these mechanisms don't interact badly... the endpoint would need
    Matthew> to be updated for this algorithm, so IPsec tunneling could be
    Matthew> updated at the same time.  This 

  The key point is that I, the IPsec developer can't control:
      1) the ICMP filter.
      2) the TCP on the machine behind it.

  I can have *some* influence on the TCP at the receiving end of the flow,
but not a lot. *If* the IPsec tunnel terminates on the same machine as the 
TCP, then in theory, the TCP can learn about the reduced MTU, and set the
MSS appropriately. In practice, probably only KAME, Microsoft and Sun are
well enough integrated to do this right now. Probably Linux 2.6 will be able
to do so as well. 
  We do have an option to hack the MSS on the encapsulator's side already,
alas. 
 
  So, I need a mechanism that I, as the guy who is about to send the ICMP
can do to help things along. 

http://www.freeswan.ca/cgi-bin/viewcvs.cgi/linux/net/ipsec/ipsec_xmit.c?rev=1.2&cvsroot=FreeS%2FWAN&content-type=text/vnd.viewcvs-markup

	/* 
	   If the sender is doing PMTU discovery, and the
	   packet doesn't fit within ixs->prv->mtu, notify him
	   (unless it was an ICMP packet, or it was not the
	   zero-offset packet) and send it anyways.

	   Note: buggy firewall configuration may prevent the
	   ICMP packet from getting back.
	*/
	if(sysctl_ipsec_icmp
	   && ixs->prv->mtu < ntohs(ixs->iph->tot_len)
	   && (ixs->iph->frag_off & __constant_htons(IP_DF)) ) {
		int notify = ixs->iph->protocol != IPPROTO_ICMP
			&& (ixs->iph->frag_off & __constant_htons(IP_OFFSET)) == 0;
			
#ifdef IPSEC_obey_DF
		KLIPS_PRINT(debug_tunnel & DB_TN_CROUT,
			    "klips_debug:ipsec_xmit_encap_bundle: "
			    "fragmentation needed and DF set; %sdropping packet\n",
			    notify ? "sending ICMP and " : "");
		if (notify)
			ICMP_SEND(ixs->skb,
				  ICMP_DEST_UNREACH,
				  ICMP_FRAG_NEEDED,
				  ixs->prv->mtu,
				  ixs->physdev);
		ixs->stats->tx_errors++;
		bundle_stat = IPSEC_XMIT_CANNOTFRAG;
		goto cleanup;
#else /* IPSEC_obey_DF */
		KLIPS_PRINT(debug_tunnel & DB_TN_CROUT,
			    "klips_debug:ipsec_xmit_encap_bundle: "
			    "fragmentation needed and DF set; %spassing packet\n",
			    notify ? "sending ICMP and " : "");
		if (notify)
			ICMP_SEND(ixs->skb,
				  ICMP_DEST_UNREACH,
				  ICMP_FRAG_NEEDED,
				  ixs->prv->mtu,
				  ixs->physdev);
#endif /* IPSEC_obey_DF */
	}

    Matthew> behavior is often a kernel option, too.  Perhaps you could
    Matthew> fragment into tunnel, but retain the DF bit, and if set don't do
    Matthew> anything weird.  Itojun related KAME experience; there they
    Matthew> ended up not 
    Matthew> setting the DF bit on output header when IPsec tunnels are
    Matthew> created. 

  This refers to the question of whether or not to set DF bit on resulting
packet. That's a problem, but a different problem.

  If we go with the proposed algorithm, that we send probes with DF set, and
if they don't make progress, assume that they were broken, then we MUST have
all tunnel protocols copy the DF bit to the outside.

  The problem with this is that the tunnel system doesn't really know if the
sender is using the new or old algorithm, so it really can't adapt.

    Matthew> Someone else pointed out that mobility might add additional
    Matthew> headers; 
    Matthew> so a tunnel MTU of 1280 might not be enough.

  1500-1280 = 220 bytes, which is 11 layers of IP/IP tunnels, and 5 layers
of IPsec. 4 layers of NAT-IPsec.

    Matthew> happens if a path is striped across multiple links, and the MTU
    Matthew> is not the same across the stripes?  You can require that the
    Matthew> MTU is not raised until a certain number of segments are received
    Matthew> successfully.  You need to understand the interaction between
    Matthew> random 
    Matthew> losses and whether the MTU is or is not raised.  Second, what

  I think that one has to have hysteris in the MTU discovery. If it keeps
bouncing, then leave it at the lower value longer.

    Matthew> On ignoring DF bits, so that a tunnel fragments large packets:
    Matthew> Matt M 
    Matthew> contended it was worse for a 1500 tunnel fragmenting a 9000 packet
    Matthew> than a tunnel fragmenting a 1500 packet by the tunnel overhead.
    Matthew> Michael didn't understand this at first; Matt explained that
    Matthew> the problem is that with many fragments the odds are greater that
    Matthew> you lose a fragment, and hence the whole packet than if there
    Matthew> are only two fragments.

  btw, I'm happy to learn more about the problems of dealing with 9000 byte
packets, I'll provide the gigE port, and my address, if you'll pay for a
connection to a GigE backbone :-)

    Matthew> Someone commented that the document as written is very TCP
    Matthew> specific. 

  Is there anything we can do about non-TCP?
  For instance, ESP is definitely *not-TCP*, but it isn't really a transport
protocol in that it doesn't have a backflow channel.

    Matthew> Matt M said that in all cases the problems with path MTU discovery
    Matthew> are bugs.  There are a large set of problems.

  I think that we won't make progress in getting the bugs fixed without a
good testbench. If there are Cisco PIX people around, their customers seem 
to be the most clueless about ICMP. Maybe that's because the PIX is way too
easy to use? :-)

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 22 Aug 2003 10:54:29 +0900 (JST)

> algorithm would need to be revised.

	it's me i guess.

> setting the DF bit on output header when IPsec tunnels are created.

	(sorry, this is not a comment to the minute itself)
	draft-ietf-v6ops-mech-v2-00.txt provides two choices for tunnels:
	- tunnel ingress router doesn't set outer DF bit set.  tunnel
	  ingress/egress router does not need to keep track of MTU on the
	  tunnel path.  tunnel MTU is static.  simpler to implement,
	  no wacky translation from inner ICMP message to outer ICMP message.
	- tunnel ingress router keeps track of tunnel path MTU (= outer DF bit
	  is set).  tunnel MTU is dynamic.  wacky translation from inner ICMP
	  message to outer ICMP message needed.

> Another person agreed that 1280 is particularly bad, 1380 would be

	this two comments were from Dave Thaler @ microsoft, IIRC.

itojun

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Aug 2003 21:57:31 -0400

-----BEGIN PGP SIGNED MESSAGE-----

As we discussed at the meeting last month, the plpmtud proposal breaks
when there are tunnelling systems that do not obey the DF bit. A second
order effect is when tunnelling systems do not copy the DF bit to the
outer header when they encapsulate.

The problem is that the DF-ignoring code is there for a reason - because
otherwise the network breaks.  Unfortunately, any proposal that requires
that the sending end-point upgrade fails - in 99% of the situations
where classic PMTUD is broken, it is due to actions that the administrators
of that end point have done.  Getting the end point to upgrade to plpmtud
is nice, and perhaps some end points will get upgraded as part of regular
OS-upgrades, but I doubt any will be motivated to upgrade just for that
"feature".

If the IETF wants to do something at the political layer, then there is
plenty that we can do in the document and then embarass route. A la ECN.
(Which still doesn't work everywhere, btw)

My impression is that many of the problems seem to be caused by a single
popular product.  I could be wrong here - but I've pursued this problem with
multiple organizations. Some of them, for instance, called me to complain
that I was attacking them with ICMP messages! This has happened multiple
times. Some complained about ICMP Fragneeded, others about
port-unreachable. {In each case they had a comprised mail server being
used to send spam... which generally involves large packets)

The remainder is by ISPs who have filtered out all of ICMP because they have,
e.g. DSL-aggregators from dead companies that are vulnerable to
directed-broadcast ICMP echo requests.   

I believe that most of the problems occur between web clients and web
servers, with the large packets going from server to client.  

Ideally, we would be able to document a change to TCP that would work if
only the receiver was upgraded. The receiver generally wants to receive the
information (the web page), and so has some motivation to fix things.

The only tool that the recipient has right now is setting a lower MSS
when initiating the connection. We aren't allowed to use that option again
later on. That's a shame, because it would otherwise provide an easy way
for a receiver to possibly recover. The receiver could run an algorithm 
which permitted the MSS to grow.

- --- back to DF-ignoring

The risk to pmtumtud of DF-ignoring systems is that they cause the 
algorithm to fail, since all probes would get through. The result is more
fragments, and possible much higher changes of failure to communicate.

But please understand that "fixing" the DF-ignoring systems causes 100% 
communication failure. 

=== variant proposal

I suggest that in addition to the process described in plmtud, that we
also define a new TCP option which the system using the algorithm would
add to its packet with the SYN set. In the web client/server situation,
this means that the web server adds this when it is upgraded. We have learnt
with ECN, that adding things on the client is just a loss with same above
mentioned popular product.

We also create a new TCP option to set a new MSS or relax re-use of
TCP MSS option to permit it to be used at any time.

The receiver (web client), if it is aware of pmtud-prime, seeing that option,
would observe the maximal size of fragments received (if any). It would be
particularly interested in any that reassemble with the DF bit set. The 
receiver would then use the new TCP option to let the sender know about the
maximal MSS.

The option part of the algorithm is specific to TCP. SCTP would need
something similar. UDP based protocols would have to do their own thing.
(NFS/UDP for instance, might change the read size that it asks for).

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Aug 2003 11:21:23 +0200

Hi,

Some comments on the minutes.

> extensions to share information -- reliable instrumentation of

I think this is my comments. With usage of RTCP extensions for packet 
loss vectors (there are two available) the method is possible to use.

As an outside of the minutes comment:
There is probably some more considerations to make when using it for 
RTP/UDP. However I think there is certainly need for something like 
this. There is some RTP payload formats that generate extremely high 
bit-rates, on the order of Gigabits, so there is definitely need to 
check for the path MTU.

> Matt M said that's the intention.

This is also my comment.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Matt Mathis <[email-masked]>
Date: Fri, 22 Aug 2003 15:34:12 -0400 (EDT)

> outer header when they encapsulate.

... snip ...

> fragments, and possible much higher changes of failure to communicate.

In this environment connections don't fail: the endsystem would raise the MTU,
the out-of-spec tunnels endpoint ignore DF and fragment, and the packet is
delivered at the cost of wasted resources - mostly CPU on the tunnel endpoint.
This is no worse than the current situation.  Plpmtud only failed to make it 
better.

During the meeting, I suggested that the tunnel endpoint might use some
additional criteria to minimize extra overhead, for example honoring DF (and
tossing the packet) if the upper fragment would be larger than a tunnel header.  
I believe that with this additional check, changing the mtu discovery algorithm
does not change the consequences/impact of non-DF compliant tunnels.

But I think there are ways to do even better.  For example if you have a
heuristic to detect probes (e.g. the first over sized packet after several more 
than half sized packets) you can discard suspected probes.  This has a slight
impact on the old algorithm for a large gain on the new.   As you sharpen the 
heuristic I bet you will be able to do really well.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 28 Aug 2003 14:59:32 +0100

>>fragments, and possible much higher changes of failure to communicate.

Why not have the frag-reassembling IP fire back an icmp saying "needed reassembly"?

Cheers,
   Jeremy

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Aug 2003 11:56:16 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jeremy" == Jeremy Harris <[email-masked]> writes:
    Jeremy> Why not have the frag-reassembling IP fire back an icmp saying
    Jeremy> "needed reassembly"?

  What's what I have proposed.

  If the receiver observed that they had to reassemble fragments, they
could figure out an MTU that did work.  (A lot depends upon how the
fragmentation was done. Chop in half, or big/little bit)

  If we were permitted to use the MSS option again, we could use that.

  This does not directly solve the problem of fragmentation *outside*
of a tunnel - it depends on where the ESP (for instance) packet is
reassembled.  For the *road-warrior* situation, the ESP and TCP termination
are co-located, so this can work.