Subject: [Softwires] PMTU Discovery and ICMPv6 filtering

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 03 Feb 2010 12:20:45 -0500

One of my colleagues received a long comment on Path MTU Discovery recommendations his organization published and is seeking advice.  I recall this has been discussed several times at IETF meetings, not sure which WG, so this may be redundant.  I've tried to summarize the salient points below, and have two broad questions on this:  Are these points already covered in RFCs (other than 4459, 4890) or current Internet-Drafts? If so, I would appreciate pointers.  If not already covered by current publications, is there interest in documenting the problem and comparing the solutions/drawbacks?

The commenter basically wrote:

IPv4 and IPv6 treat packets exceeding MTU differently - IPv4 will fragment packets that are "too big" but IPv6 will drop the packet and respond with ICMPv6 "too-big" error message. [The subject publication] recommends using the Path MTU Discovery Protocol to discover the end-to-end PMTU, which relies on ICMPv6 error messages. These may be blocked by various "filters" and IPsec gateways, which is the case in many operational networks.

However, even when ICMPv6 is not blocked, IPsec gateways (in tunnel mode) add extra headers, and there can be more than one tunnel header involved (routers also create tunnels). When a "too-big" message is sent the router will return put in its ICMPv6 message the value of the MTU on the next link at layer 2. The host receiving this MTU value in an ICMP message at part of the Path MTU Discovery Protocol has no way of knowing how many extra tunnel headers are added along the path, and so if it just takes the reported MTU value without allowing for these extra headers the process will keep on failing and will not recover. We have seen this behavior in our experiments. 

This can be prevented by ensuring that the maximum packet size sent by the host is smaller than the layer 2 limit: smaller by an amount estimated to be sufficient to allow room for extra headers to be added along the path. Several ways of achieving this are possible: 

(1) Set this reduced MTU value on the on the IPSec gateway LAN interface; the host then discovers this MTU through the PMTUD. 

(2) Statically configure this reduced MTU value into the host and switch off PMTUD. 

(3) Set a reduced MTU at the IPSec gateway WAN interface; The IPSec gateway acts as a host on this interface and so can do packet fragmentation.

(4) Provide the capability in the IPSec gateway to discover the MTU on its WAN interface, subtract the maximum header size that this gateway will add to packets presented on its LAN interface, which the host can then discover through the PMTUD.

Method (4) would be the best solution, but is not currently available in the IPSec gateway products. 
The next best solution is (1), which has been used [in commenter experiments]. This is not as good as (4) because it requires manual intervention, and an understanding of how to calculate the appropriate (reduced) MTU value.  
The next best solution is (2), the only disadvantage of this approach is that only one value can be set for all paths and so the worst case (lowest) value has to be used. In a complex network it may not always be obvious what the worst case path is, and so a conservative estimate may be necessary. Even so this could be preferable in some deployment scenarios since the path-MTU discovery protocol relies on the passage of ICMP messages which are sometimes blocked by firewalls and other security devices.  
Approach (3) is the worst solution since it will cause many IP packets to be fragmented which is inefficient (both because, unlike IPv4, the IPv6 header has to be extended to include the fragmentation offset field, and because it will result the second fragment being very small, i.e. the ratio of user-data to IP header size will be poor). 

It is likely that for immediate use option (1) should be used although (4) would be better if it were supported in the relevant products. 

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Feb 2010 13:22:20 -0500

Ed, there are a number of things to say.
First, behaviour 4 is mostly described by RFC4301, I believe.
Yes, section 8.2.1.
If you find it is not available, then you need to talk to your vendors.

Behaviour 3 (which, in IPv4 speak, is essentially not copying the DF
bit), is often necessary, but it can mess up the plpmtu mechanism.

Second, PLPMTUD was publiched by the pmtud WG as RFC4821.
This is the best suggestion.

I wrote about what Freeswan/Openswan KLIPS tried to do, which was a
variation of #3, because we wanted the network to work...   it is at:
    http://www.sandelman.ca/SSW/ietf/ipsec/fragment/draft-richardson-ipsec-fragment.txt

Most of these ideas were incorporated into RFC4821.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Feb 2010 11:09:59 -0500

{resend with my subscribed email}

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2010 14:17:04 -0800

Hi Ed,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ed Jankiewicz
> Sent: Wednesday, February 03, 2010 9:21 AM
> To: Behave WG; [email-masked]
> Subject: [BEHAVE] PMTU Discovery and ICMPv6 filtering
> 
> One of my colleagues received a long comment on Path MTU Discovery recommendations his organization
> published and is seeking advice.  I recall this has been discussed several times at IETF meetings,
> not sure which WG, so this may be redundant.  I've tried to summarize the salient points below, and
> have two broad questions on this:  Are these points already covered in RFCs (other than 4459, 4890)
> or current Internet-Drafts? If so, I would appreciate pointers.  If not already covered by current
> publications, is there interest in documenting the problem and comparing the solutions/drawbacks?
> 
> IPv4 and IPv6 treat packets exceeding MTU differently - IPv4 will fragment packets that are "too big"
> but IPv6 will drop the packet and respond with ICMPv6 "too-big" error message. [The subject
> publication] recommends using the Path MTU Discovery Protocol to discover the end-to-end PMTU, which
> relies on ICMPv6 error messages. These may be blocked by various "filters" and IPsec gateways, which
> is the case in many operational networks.
> 
> However, even when ICMPv6 is not blocked, IPsec gateways (in tunnel mode) add extra headers, and
> there can be more than one tunnel header involved (routers also create tunnels). When a "too-big"
> message is sent the router will return put in its ICMPv6 message the value of the MTU on the next
> link at layer 2. The host receiving this MTU value in an ICMP message at part of the Path MTU
> Discovery Protocol has no way of knowing how many extra tunnel headers are added along the path, and
> so if it just takes the reported MTU value without allowing for these extra headers the process will
> keep on failing and will not recover. We have seen this behavior in our experiments.
> 
> This can be prevented by ensuring that the maximum packet size sent by the host is smaller than the
> layer 2 limit: smaller by an amount estimated to be sufficient to allow room for extra headers to be
> added along the path. Several ways of achieving this are possible:
> 
> (3) Set a reduced MTU at the IPSec gateway WAN interface; The IPSec gateway acts as a host on this
> interface and so can do packet fragmentation.
> 
> (4) Provide the capability in the IPSec gateway to discover the MTU on its WAN interface, subtract
> the maximum header size that this gateway will add to packets presented on its LAN interface, which
> the host can then discover through the PMTUD.
> 
> The next best solution is (1), which has been used [in commenter experiments]. This is not as good as
> (4) because it requires manual intervention, and an understanding of how to calculate the appropriate
> (reduced) MTU value.
> The next best solution is (2), the only disadvantage of this approach is that only one value can be
> set for all paths and so the worst case (lowest) value has to be used. In a complex network it may
> not always be obvious what the worst case path is, and so a conservative estimate may be necessary.
> Even so this could be preferable in some deployment scenarios since the path-MTU discovery protocol
> relies on the passage of ICMP messages which are sometimes blocked by firewalls and other security
> devices.
> Approach (3) is the worst solution since it will cause many IP packets to be fragmented which is
> inefficient (both because, unlike IPv4, the IPv6 header has to be extended to include the
> fragmentation offset field, and because it will result the second fragment being very small, i.e. the
> ratio of user-data to IP header size will be poor).
> 

(1) seems like a safe option at face value, but can lead
to undesirable inefficiencies. Consider for example the
diagram below:

            L1    L2               L3
            |     |                |
        W --|--R--|--GW1<====>GW2--|--Z
            |     |   (Internet)   |
               X--|     L4, L5,
               Y--|     L6, etc.

Here, we have a tunnel beteen 'GW1' and 'GW2' over the
Internet to connect two networks. 'GW1' sets a reduced
MTU 'M' on its LAN interface connected to link 'L2', and
also advertises 'M' in the Router Advertisements it sends
on 'L2'. Hosts 'X' and 'Y' pick up the reduced MTU from
the RA and limit the size of the packets they send to at
most 'M' bytes. But, host 'W' connected to link 'L1' does
not see the MTU reduction, and hence will routinely send
packets larger than 'M' to any hosts beyond router 'R'
such as 'X', 'Y' and 'Z'. These packets will be dropped
with an ICMPv6 PTB returned, then 'W' will be forced to
reduce its packet size and retransmit. The only way to
prevent this is to drive the reduced MTU 'M' deeply into
the entire network stacked up behind 'GW1', which may
contain arbitrarily many additional routers and links.

Now, even if the reduced MTU 'M' were propagated deeply
throughout the 'GW1' network, if most communications
remain localized hosts would only be able to use a packet
size of at most 'M' even if their links natively support
a much larger MTU. Consider for example that link 'L2'
in the diagram has a native MTU of 9kb, but the effective
MTU across the 'GW1'<====>'GW2' tunnel is only 1400. 'GW1'
will advertise 1400 on link 'L1', and communications
betweenhosts 'X' and 'Y' will be restricted to using at
most 1400 byte packets when they could have used 9kb.

There are a couple of factors to consider in terms of
what might be a better solution. First, what are the
expected data rates over the 'GW1'<====>'GW2' tunnel,
and second what are the performance characteristics of
those gateways? If the data rates are such that GW1 and
GW2 are already operating at their peak performance even
without taking on any additional processing overhead,
then the best solution would be to make sure that all
links over which the tunnel might travel (e.g., 'L4',
'L5', 'L6', etc.) are large enough to "hide" the tunnel
encapsulation artifact. For example, if all links 'L4'
'L5', 'L6', etc. configure a native MTU of no smaller
than 1600 and the encapsulation overhead for the tunnel
is 100 bytes, then all routers and hosts on the LAN side
of 'GW1' would be able to happily use a 1500 MTU. If the
MTUs of 'L4', etc. cannot be controlled, however, then
there is no recourse but to use option (1) and cope with
the inefficiencies.

On the other hand, if the data rates across the tunnel
are nominal and/or 'GW1' and 'GW2' have more than
sufficient processing capability to take on a modest
amount of additional overhead, the GWs can use tunnel
fragmentation so that 'GW1' can present a solid MTU on
its LAN side interface that does not reflect the size
of the tunnel encapsulation headers. If the tunnel
fragmentation could accommodate an MTU of at least 1500
in this way, then 'GW1' would be able to observe the
"de facto Internet cell size" of 1500. If we further
assume that the vast majority of hosts in the world
today either limit their packet sizes to no more than
1500 bytes or are willing to assume the risk of silent
loss of packets larger than 1500 due to MTU restrictions,
then there is no need to place artificial restrictions
on the size of packets that can be used within the 'GW1'
network. This latter class of hosts (those that send
packets larger than 1500) would be best served to use
their own host-based MTU probing mechanisms for sending 
packets larger than 1500 in case the network is somehow
silently dropping PMTUD messages. RFC4821 was specifically
designed for this purpose.

End result - whenever it is practically possible, tunnel
routers should use tunnel fragmentation and hosts should
use RFC4821.

Fred
[email-masked]
     
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dave Dolson" <[email-masked]>
Date: Mon, 8 Feb 2010 10:13:34 -0500

Fred,

Quoted from below (by Ed Jankiewicz):
> > Method (4) would be the best solution, but is not currently
available
> in the IPSec gateway products.

I believe this is referring to mapping of ICMP "too big" messages. When
a tunnel end-point receives a "too big" message, it would have to map
the message to an ICMP message for the original host. I believe this
could be done in a stateless manner using the packet quoted in the
message. (RFC2463 says the "too big" message will include "As much of
invoking packet as will fit without the ICMPv6 packet exceeding the
minimum IPv6 MTU")

In my opinion, this suggestion is indeed the best solution, and should
have MAY or perhaps RECOMMENDED status despite lack of current
availability.

The network will operate most efficiently without fragmentation. When
1500-byte packets are *always* fragmented, there are twice as many of
these packets, and the probability of packet loss is doubled, especially
problematic when the tunnel passes over a network that can experience
congestion. (Only one fragment has to be lost for the entire packet to
be lost.) This will impact the throughput of bulk traffic the most. This
is why TCP went to "don't fragment" mode many years ago.

Therefore I respectfully disagree with your assertion that "whenever it
is practically possible, tunnel routers should use tunnel
fragmentation."

I suggest that tunnel gateways SHOULD send the ICMP "too big", but MAY
instead fragment. A vendor could provide fragmentation or ICMP
configuration options, either of which could be useful depending on the
reliability of the network that carries the tunnel. (Of course the
network carrying the tunnel could simply have a larger MTU.) The
receiving end of the tunnel would have to support reassembly of tunnel
fragments for multi-vendor interop.

As for ICMP black-holes, is this likely to be standard practice with
ICMP6 as well (vs. being done to protect old IPv4 routers from attacks
on their expensive control-path processing) ?

David Dolson
Software Architect, Sandvine Incorporated.
http://www.sandvine.com

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Templin, Fred L
> Sent: Friday, February 05, 2010 5:17 PM
> To: Ed Jankiewicz; Behave WG; [email-masked]
> Subject: Re: [Softwires] [BEHAVE] PMTU Discovery and ICMPv6 filtering
> 
> Hi Ed,
> 
> > not sure which WG, so this may be redundant.  I've tried to
summarize
> the salient points below, and
> > but IPv6 will drop the packet and respond with ICMPv6 "too-big"
error
> message. [The subject
> > link at layer 2. The host receiving this MTU value in an ICMP
message
> at part of the Path MTU
> > so if it just takes the reported MTU value without allowing for
these
> extra headers the process will
> > (1) Set this reduced MTU value on the on the IPSec gateway LAN
> interface; the host then discovers
> > this MTU through the PMTUD.
> >
> > Method (4) would be the best solution, but is not currently
available
> in the IPSec gateway products.
> > The next best solution is (2), the only disadvantage of this
approach
> is that only one value can be
> > relies on the passage of ICMP messages which are sometimes blocked
by
> firewalls and other security
> > devices.
> > It is likely that for immediate use option (1) should be used
> although (4) would be better if it were
> > supported in the relevant products.
> 
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Rémi Després <[email-masked]>
Date: Mon, 8 Feb 2010 18:49:01 +0100

> on their expensive control-path processing) ?

Does anyone know a reference where a good reason would be documented to Discard ICMP error messages, even when they contain valid addresses?
(In the absence of such good reason, forwarding them should IMHO be MUST.)

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Feb 2010 13:08:01 -0800

Hi Dave,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Dolson
> Sent: Monday, February 08, 2010 7:14 AM
> To: Templin, Fred L; Ed Jankiewicz; Behave WG; [email-masked]

But, if the packet-in-error encapsulated in the ICMP
PTB message is encrypted and not complete (i.e., only
the leading 1200 or so bytes of the encrypted packet
are included), how will the tunnel ingress know how to
decrypt it in order to do the stateless translation?

Also, there seems to be some evidence that ICMPv6 PTB
messages are being dropped in the network. And, there is
ample evidence that ICMPv4 PTB messages are frequently
dropped in the network.

> is why TCP went to "don't fragment" mode many years ago.

The optimum solution comes when through good fortune
the network happens to have link sizes that are large
enough to hide the tunnel overhead artifact. Some have
suggested that almost all links in the Internet core
configure an MTU of ~4KB or greater. That seems like
a fairly bold statement to me, but I have no way of
confirming or refuting it. In that case, it is a
safe bet that packet of up to 1500 bytes will get
through without the need for fragmentation even after
the tunneling overhead is required.

> is practically possible, tunnel routers should use tunnel

OK, I can see how my statement may have been alarming
without sufficient supporting background (which I
failed to provide). First I am not recommending
steady-state segmentation and reassembly; it is
greatly preferable that segmentation and reassembly
be avoided when it is not absolutely necessary. But,
the key is to be able to sense *when* segmentation
and reassembly is necessary, and then only use it
for those cases. That is what SEAL does - it uses
data packets as implicit probes to tell when the
path MTU is too small to pass original packets of
up to 1500 bytes (i.e., before the tunnel headers
are added). If the path MTU is large enough, SEAL
will pass the original packets in one piece w/o
further fragmentation. If the path MTU is too
small, SEAL uses segmentation to produce a "packet
pair" that gets pasted back together at the tunnel
far end. (SEAL will support longer trains of
segments as well, but that would be a deeper
discussion.)

> instead fragment.

I would amend this to say that for DF=1 packets the tunnel
ingress MUST send an ICMP PTB when the packet is larger
than a fixed minimum tunnel MTU and also too large to
traverse the tunnel in a single piece. For packets that
are no larger than the fixed minimum tunnel MTU, the
tunnel ingress SHOULD use tunnel fragmentation (i.e.,
SEAL segmentation and reassembly). Presumably, the tunnel
ingress would choose a fixed minimum tunnel MTU that is
large enough so that source hosts will not see excessive
data loss and retransmissions due to path MTU discovery
interactions.

For many/most deployments, a fixed minimum tunnel MTU of
1500 bytes would seem advisable.

> A vendor could provide fragmentation or ICMP

Studies have been cited on the RRG list showing
non-negligible losses of ICMPv6 PTB messages as
well as significant losses of ICMPv4 PTB messages.
Trusting an untrustworthy network seems like at
best a tenuous approach.

Thanks - Fred

---

From: Rémi Després <[email-masked]>
Date: Tue, 9 Feb 2010 10:58:46 +0100

Le 8 févr. 2010 à 22:08, Templin, Fred L a écrit :

> messages are being dropped in the network.

In IPv6, I hope it will be possible to agree at least that PTB messages SHOULD be forwarded (if not MUST).
Reasons to not agree should IMHO be seriously documented.

> ... for DF=1 packets the tunnel

In my understanding, we can keep the current IPv6 value of 1280 as the minimum that has to traverse ALL tunnels, and note that if a tunnel has an internal mechanism to fragment at entrance and reassemble at exit (e.g. SEAL), the tunnel advertised MTU can become independent from that of the traversed infrastructure. 

Thoughts?

Cheers,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 9 Feb 2010 07:48:31 -0800

Tero,

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, February 09, 2010 6:03 AM
> To: Templin, Fred L
> Cc: Dave Dolson; Ed Jankiewicz; Behave WG; [email-masked]
> Templin, Fred L writes:
> If we are talking about IPsec, then that ICMP packet will have the SPI
> of the packet, so the gateway can find the related IPsec SA for the
> the packet which caused the PTB message to be sent. After that it
> simply stores the maximum path MTU it got from the ICMP message to the
> IPsec SA.

That would be a stateful means for determining path MTU.
I was responding to the assertion that a stateless method
was possible.

Fred
 
> When the next packet comes through which is bigger than what the MTU
> stored for the SA (where the MTU is already modified accordingly to
> match the overhead of IPsec headers), it will directly send PTB
> message back to the original sender of the packet.
> 
> I.e. it will dynamically find out the PMTU for each IPsec SA (taking
> the overhead in to account, as it does know the overhead), and then
> send PTB messages if packet is bigger than that.
> 
> See section 8.2.1 of RFC4301:
> ----------------------------------------------------------------------
> 8.2.1.  Propagation of PMTU
> 
>    When an IPsec implementation receives an unauthenticated PMTU
>    message, and it is configured to process (vs. ignore) such messages,
>    it maps the message to the SA to which it corresponds.  This mapping
>    is effected by extracting the header information from the payload of
>    the PMTU message and applying the procedure described in Section 5.2.
>    The PMTU determined by this message is used to update the SAD PMTU
>    field, taking into account the size of the AH or ESP header that will
>    be applied, any crypto synchronization data, and the overhead imposed
>    by an additional IP header, in the case of a tunnel mode SA.
> 
>    In a native host implementation, it is possible to maintain PMTU data
>    at the same granularity as for unprotected communication, so there is
>    no loss of functionality.  Signaling of the PMTU information is
>    internal to the host.  For all other IPsec implementation options,
>    the PMTU data must be propagated via a synthesized ICMP PMTU.  In
>    these cases, the IPsec implementation SHOULD wait for outbound
>    traffic to be mapped to the SAD entry.  When such traffic arrives, if
>    the traffic would exceed the updated PMTU value the traffic MUST be
>    handled as follows:
> 
>        Case 1: Original (cleartext) packet is IPv4 and has the DF
>                bit set.  The implementation SHOULD discard the packet
>                and send a PMTU ICMP message.
> 
>        Case 2: Original (cleartext) packet is IPv4 and has the DF
>                bit clear.  The implementation SHOULD fragment (before or
>                after encryption per its configuration) and then forward
>                the fragments.  It SHOULD NOT send a PMTU ICMP message.
> 
>        Case 3: Original (cleartext) packet is IPv6.  The implementation
>                SHOULD discard the packet and send a PMTU ICMP message.
> --
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Feb 2010 16:02:58 +0200

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 9 Feb 2010 12:26:59 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Tuesday, February 09, 2010 1:59 AM
> To: Templin, Fred L
> Cc: [email-masked]; Behave WG
> In IPv6, I hope it will be possible to agree at least that 
> PTB messages SHOULD be forwarded (if not MUST).

Ben Stasiewicz's tests [*] on the IPv6 Internet show that 56% of
IPv6 hosts do not properly respond to ICMPv6 packet-too-big
with an MTU<1280.  I do not believe additional MUSTs in RFCs 
from the IETF would have a noticeable effect.

[*] http://www.ietf.org/mail-archive/web/behave/current/msg08093.html

-d

> In my understanding, we can keep the current IPv6 value of 
> 1280 as the minimum that has to traverse ALL tunnels, and 
> note that if a tunnel has an internal mechanism to fragment 
> at entrance and reassemble at exit (e.g. SEAL), the tunnel 
> advertised MTU can become independent from that of the 
> traversed infrastructure. 
> 
> Thoughts?
> 
> Cheers,
> RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 9 Feb 2010 22:14:04 +0100

Dan,

There must have been a confusion: I am AGAINST IPv6 PTB messages with MTU<1280.
(Your last message, addressed to both Fred and me suggests you believe I support them.)

My personal point is AGAINST networks purposely losing "normal" PTB error messages, i.e. with MTB>1280.

Considering that these losses become a MAY, even in IPv6, just because it is believed that some networks lose them would be IMHO a mistake, at least without a good understanding of where and why it is done. 

Regards,

RD

Le 9 févr. 2010 à 21:26, Dan Wing a écrit :

>> ...
> with an MTU<1280.

Not related to the point I made. 

>  I do not believe additional MUSTs in RFCs 

A SHOULD is the proposal.
AFAIK it is not written anywhere that networks are authorized to do otherwise.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 9 Feb 2010 17:06:29 -0800

> >>>>> "Dan" == Dan Wing <[email-masked]> writes:
>     >> In IPv6, I hope it will be possible to agree at least that PTB
>     >> messages SHOULD be forwarded (if not MUST).  Reasons 
> to not agree
>     >> should IMHO be seriously documented.
> 
>     Dan> Ben Stasiewicz's tests [*] on the IPv6 Internet show that 56%
>     Dan> of IPv6 hosts do not properly respond to ICMPv6 
> packet-too-big
>     Dan> with an MTU<1280.  I do not believe additional MUSTs in RFCs
>     Dan> from the IETF would have a noticeable effect.
> 
> We need to push out plpmtud.

I agree with you.  But that isn't in scope for BEHAVE or SOFTWIRE.  Perhaps
TCPM, maybe; I'm not sure.

-d

> ] [email-masked] 
> http://www.sandelman.ottawa.on.ca/ |device driver[
>    Kyoto Plus: watch the video 
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 9 Feb 2010 17:17:09 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Tuesday, February 09, 2010 1:14 PM
> To: Dan Wing
> Cc: [email-masked]; 'Templin, Fred L'; 'Behave WG'
> Subject: Re: [BEHAVE] [Softwires] PMTU Discovery and ICMPv6 filtering
> 
> Dan,
> 

Sorry if I mis-characterized.

> My personal point is AGAINST networks purposely losing 
> "normal" PTB error messages, i.e. with MTB>1280.
> 
> Considering that these losses become a MAY, even in IPv6, 
> just because it is believed that some networks lose them 
> would be IMHO a mistake, at least without a good 
> understanding of where and why it is done. 

Remi,

I can tell I'm not fully understanding what you're saying.  But perhaps if you
read 
Ben Stasiewicz's analysis of ICMPv6 PTB with MTU=1280, you'll be happier -- it
shows much higher sucess than his later tests using MTU<1280.  His MTU=1280
test is at:

http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708
.html

-d

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Feb 2010 15:55:03 -0500

>> messages SHOULD be forwarded (if not MUST).  Reasons to not agree

    Dan> Ben Stasiewicz's tests [*] on the IPv6 Internet show that 56%
    Dan> of IPv6 hosts do not properly respond to ICMPv6 packet-too-big
    Dan> with an MTU<1280.  I do not believe additional MUSTs in RFCs
    Dan> from the IETF would have a noticeable effect.