Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used." -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used."
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4? More contentious is that Path MTU discovery is "strongly recommended" in IPv6. Surely it's mandatory whenever you're exchanging datagrams larger than 1280 octets? Otherwise the sender can't fragment. Joe
On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used."
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
Hi Joe, Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off. Regards, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2011-02-15, at 10:36, William Herrin wrote:
Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default?
I am not, but I'd still be vaguely interested in an actual study :-) The last time I tangled with v4 pMTUd it actually was a decade or more ago. At that time wholesale ICMP blocking caused all kinds of problems for clients with a sub-ethernet MTU in their path. If the world has moved on, that seems good :-) Joe
On Feb 15, 2011, at 10:36 54AM, William Herrin wrote:
On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used."
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
Hi Joe,
Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off.
All modern TCPs support it; many firewalls are configured to block the necessary ICMPs. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Tue, 15 Feb 2011, Steven Bellovin wrote:
On Feb 15, 2011, at 10:36 54AM, William Herrin wrote:
On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used."
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
Hi Joe,
Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off.
All modern TCPs support it; many firewalls are configured to block the necessary ICMPs.
Then probably blackholing themselves the firewall operators.... Best Regards, Janos Mohacsi
Subject: Re: NIST and SP800-119 Date: Tue, Feb 15, 2011 at 05:46:01PM +0100 Quoting Mohacsi Janos (mohacsi@niif.hu):
All modern TCPs support it; many firewalls are configured to block the necessary ICMPs.
Then probably blackholing themselves the firewall operators....
And the replies when you try to fix it simmer with contempt for those so unresponsible as to even contemplate allowing any ICMP at all. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Where's the Coke machine? Tell me a joke!!
On Feb 15, 2011, at 10:36 AM, William Herrin wrote:
On Tue, Feb 15, 2011 at 10:09 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
Well, according to this document IPv4 path MTU discovery is, "optional, not widely used."
Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
Hi Joe,
Are you aware of a TCP implementation in an OS that shipped within the last decade but doesn't enable IPv4 pMTUd by default? Each version of Windows and all the major unixes use it on every TCP connection unless you explicitly turn it off.
IOS does not support it unless explicitly turned on. It will result in decreased network performance for some things (eg: BGP Updates) as the negotiated mss will be really small. They likely don't want to change some sacred default either as it would break other things. If you run larger than ~500 mtus internally, you may want to enable 'ip tcp path-mtu-discovery' and watch your BGP convergence improve significantly. Router#sh ip bgp neighbors | inc max data segment Broken setups will show something like this: Datagrams (max data segment is 1240 bytes): Datagrams (max data segment is 516 bytes): Datagrams (max data segment is 536 bytes): Others may show something much larger depending on your infrastructure. IMHO, path-mtu-discovery is REQUIRED, not optional. Anyone saying otherwise has a broken network and you should not give them your money. - Jared
On 2011-02-14, at 21:41, William Herrin wrote:
On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw<tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular. Well, according to this document IPv4 path MTU discovery is, "optional, not widely used." Optional seems right. Have there been any recent studies on how widely pMTUd is actually used in v4?
More contentious is that Path MTU discovery is "strongly recommended" in IPv6. Surely it's mandatory whenever you're exchanging datagrams larger than 1280 octets? Otherwise the sender can't fragment. Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. See Section 5 in rfc2460. (1280 minus 40 for the IPv6 header and 8 for the Fragment
On 2/15/11 11:09 PM, Joe Abley wrote: header.) Bill suggested this could even be smaller. This also ignores likely limited resources to resolve addresses within a /64. Public facing servers might be placed into much smaller ranges to avoid supporting 16M multicast. Also there might be a need to limit ICMPv6 functions as well, depending upon the features found in layer-2 switches. -Doug
On 2011-02-16, at 02:44, Douglas Otis wrote:
Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. See Section 5 in rfc2460.
I've heard that interpretation of 2460 before from Bill Manning, but I still don't see it myself. The text seems fairly clear that 1280 is the minimum MTU for any interface, regardless of the type of interface (tunnel, PPP, whatever). In particular, Links that have a configurable MTU (for example, PPP links [RFC- 1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation. That same section indicates that pMTUd is strongly recommended in IPv6 rather than mandatory, but in the context of embedded devices that can avoid implementing pMTUd by never sending a packet larger than the minimum MTU. Such devices would break if there was an interface (of any kind) in the path with a sub-1280 MTU. Joe
On 2011-02-16, at 02:44, Douglas Otis wrote:
Routers indicate local MTUs, but minimum MTUs are not assured to have 1280 octets when IPv4 translation is involved. See Section 5 in rfc2460. I've heard that interpretation of 2460 before from Bill Manning, but I still don't see it myself. The text seems fairly clear that 1280 is the minimum MTU for any interface, regardless of the type of interface (tunnel, PPP, whatever). In particular,
Links that have a configurable MTU (for example, PPP links [RFC- 1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation.
That same section indicates that pMTUd is strongly recommended in IPv6 rather than mandatory, but in the context of embedded devices that can avoid implementing pMTUd by never sending a packet larger than the minimum MTU. Such devices would break if there was an interface (of any kind) in the path with a sub-1280 MTU. Bill makes a good point. Ensuring a minimum MTU of 1280 octets over v6 connections carrying protocol 41 will not allow subsequent v4 routers to fragment based upon discovered PMTUs. This could influence maximum UDP
On 2/16/11 10:57 PM, Joe Abley wrote: packets from a DNS server for example, where path MTU discovery is impractical. To be assured of continued operation for critical infrastructure, minimum MTUs of 1280 for v6 connections that might handle protocol 41 packets, becomes 1280 - 40 - 8 = 1232 or less as indicated in RFC2460. As suggested, there might be another 18 octet header, like L2TP, where the maximum MTU safely assumed becomes 1214. Perhaps IPv6 should have specified a required minimum of 1346 octets, where 1280 octets could be safely assumed available. A SHOULD is not a MUST, but critical operations MUST be based upon the MUSTs. How much longer will native v4 be carried over the Internet anyway? :^) -Doug
I've spent some time reading through it over the past couple of days and it seems to be very good so far (have read up to end of section 3). On Mon, Feb 14, 2011 at 7:24 PM, TR Shaw <tshaw@oitc.com> wrote:
Just wondering what this community thinks of NIST in general and their SP800-119 ( http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf ) writeup about IPv6 in particular.
participants (9)
-
Douglas Otis -
Jared Mauch -
Joe Abley -
Mans Nilsson -
Mohacsi Janos -
Rafael Rodriguez -
Steven Bellovin -
TR Shaw -
William Herrin