Erik,
We were discussing the static (stateless) MTU value to assign for tunnel
interfaces when a dynamic MTU determination scheme is not used. It seems
to me that the current text in 'draft-ietf-v6ops-mech-v2-00.txt', section
3.2 is a bit too restrictive on this point for the reasons outlined in
my note to the list on 3/18 (see below).
We would like to maximize efficiency while minimizing IPv4 fragmentation,
but since 'mech-v2' strongly encourages an MTU of only 1280 bytes the
efficiency goal suffers. 'draft-ietf-ngtrans-isatap-13.txt', section 6.1
says the following:
"o Nearly all IPv4 nodes connect to physical links with MTUs of 1500
bytes or larger (e.g., Ethernet)
o Sub-IPv4 layer encapsulations (e.g., VPN) may occur on some paths
o Commonly-deployed VPN interfaces use an MTU of 1400 bytes
To maximize efficiency and minimize IPv4 fragmentation for the
predominant deployment case, the ISATAP interface MTU, or "LinkMTU"
(see: [RFC2461], Section 6.3.2), SHOULD be set to no more than 1380
bytes (1400 minus 20 bytes for IPv4 encapsulation)."
Can we have something similar for mech-v2?
Fred
ftemplin@iprg.nokia.com
Fred L. Templin wrote:
Erik Nordmark wrote:Having the encapsulator discover the IPv4 MTU doesn't allow us to reduce the amount of ressembly that the decapsulator needs to perform. And I don't think the level of fragmentation is harmful - especially given that most Internet paths support an MTU of 1500 bytes.Yes, most paths support an MTU of 1500 bytes. But, the majority of those that don't will fragment at 576 bytes. Hence, an MTU closer to 1480+20 bytes will result in no more fragments (i.e., 3) than 1280+20 in most cases. Still to be considered are bumps in the stack/wire and middleboxes that add further layers of encapsulation (e.g., L2TP, IPsec, etc.) so a safe bet is to choose something like 1380+20 leaving 100bytes for additional encapsulation.