Subject: [v6ops] advertisement of IPv6 MTU by the CPE to LAN devices

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 20 Sep 2011 16:17:11 +0300

Hello,

I'm trying to find a doc describing the expected behavior regarding the advertisement of IPv6 MTU by the CPE to LAN devices.

The only relevant, but not clear enough, is the following from RFC 4861

The MTU option is used in Router Advertisement
                      messages to ensure that all nodes on a link use the
                      same MTU value in those cases where the link MTU is
                      not well known.

                      This option MUST be silently ignored for other
                      Neighbor Discovery messages.

                      In configurations in which heterogeneous
                      technologies are bridged together, the maximum
                      supported MTU may differ from one segment to
                      another.  If the bridges do not generate ICMP
                      Packet Too Big messages, communicating nodes will
                      be unable to use Path MTU to dynamically determine
                      the appropriate MTU on a per-neighbor basis.  In
                      such cases, routers can be configured to use the
                      MTU option to specify the maximum MTU value that is
                      supported by all segments.

Can someone please enlighten me about the the following?

If the WAN MTU is somehow manually/automatically configured in the DSL CPE, what should happen with the LAN (interface) 
& RA (included in LAN Router Advertisement) MTUs?

1a) The LAN MTU should always be 1500
1b) The LAN MTU should be equal to WAN MTU

2a) The RA MTU should always be 1500
2b) The RA MTU should be equal to LAN MTU
2c) The RA MTU should be equal to WAN MTU

I'm not putting user configurable as an option, since i haven't seen that in most retail CPEs.

Vendors seem to prefer options 1a and 2a, which seem wrong to me, because if the host respects the RA MTU, then you can 
avoid the "packet too big" messages sent by the CPE.

-- 
Tassos

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 20 Sep 2011 15:24:38 +0200 (CEST)

On Tue, 20 Sep 2011, Tassos Chatzithomaoglou wrote:

> Vendors seem to prefer options 1a and 2a, which seem wrong to me, 
> because if the host respects the RA MTU, then you can avoid the "packet 
> too big" messages sent by the CPE.

I have 1a and 2c in my home.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Sep 2011 06:45:34 -0700

On Sep 20, 2011, at 6:17 AM, Tassos Chatzithomaoglou wrote:

> If the WAN MTU is somehow manually/automatically configured in the DSL CPE, what should happen with the LAN (interface) & RA (included in LAN Router Advertisement) MTUs?

Let me outline a picture for you. Chair hat off.

                  //---\\            //---\\
                   ISP 1              ISP 2
                  \\---//            \\---//
                    /                   /
                   /                   /
                  /                   /
            +----+---+          +----+---+
            |Router 1|          |Router 2|
            +---+----+          +---+----+
                |                   |
         -----+-+-----------------+-+--------
              |                   |
           +--+---+          +----+---+
           |Host 1|          |Router 3|
           +------+          +--+-----+
                                |
                        --------+-+----------
                                  |
                               +--+---+
                               |Host 2|
                               +------+

Now, to your premise, the link between Router 1 and its ISP has a tunnel in it and as a result is using a reduced PMTU. Host 2 has three obvious targets for sessions it might open - Host 1, other hosts via ISP 1, and still other hosts via ISP 2. What PMTU should it use for those various sessions? How would that information be communicated? I could imagine that R1-ISP1 has a PMTU of 1280, R2-ISP2 has a PMTU of 1500, and the two LANs and R3 are quite happy with a 9K PMTU.

If you need it more complicated, imagine that during a session the route between the two peers changes from ISP 2 to ISP 1.

From my perspective, Path MTU is a characteristic of the route, and the fact that one potential route requires a certain value doesn't imply that another does. Hence, whatever signaling is involved is something along the route and needs to be able to happen at any point in the life of a session.

The usual approach is to apply one of two technologies:

https://tools.ietf.org/html/rfc1981
1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J.
     Mogul. August 1996. (Format: TXT=34088 bytes) (Status: DRAFT
     STANDARD)

https://tools.ietf.org/html/rfc4821
4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner.
     March 2007. (Format: TXT=75665 bytes) (Status: PROPOSED STANDARD)

To be honest, I personally prefer the latter, although it doesn't right now have wide deployment. We see operators filtering out ICMP and ICMPv6, and as a result short-circuiting RFC 1981. RFC 4821 specifically addresses that issue.

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Sep 2011 07:32:23 -0700

> 2c) The RA MTU should be equal to WAN MTU

Bringing it back specifically to this, I would expect that the LAN MTU is technology-specific. IEEE 802.3 generally specifies an MTU of 1500 bytes, but gigabit interfaces often (non-standardly) in fact support MTUs of 9180 bytes. On such a LAN, I don't see any purpose in forcing the hosts to use 1500 byte MTUs. If you look at other RFCs that discuss topics like this, notably RFC 1191, this has wide variation. The following is from page 17 of RFC 1191:

   Plateau    MTU    Comments                      Reference
   ------     ---    --------                      ---------
              65535  Official maximum MTU          RFC 791
              65535  Hyperchannel                  RFC 1044
   65535
   32000             Just in case
              17914  16Mb IBM Token Ring           ref. [6]
   17914
              8166   IEEE 802.4                    RFC 1042
   8166
              4464   IEEE 802.5 (4Mb max)          RFC 1042
              4352   FDDI (Revised)                RFC 1188
   4352 (1%)
              2048   Wideband Network              RFC 907
              2002   IEEE 802.5 (4Mb recommended)  RFC 1042
   2002 (2%)
              1536   Exp. Ethernet Nets            RFC 895
              1500   Ethernet Networks             RFC 894
              1500   Point-to-Point (default)      RFC 1134
              1492   IEEE 802.3                    RFC 1042
   1492 (3%)
              1006   SLIP                          RFC 1055
              1006   ARPANET                       BBN 1822
   1006
              576    X.25 Networks                 RFC 877
              544    DEC IP Portal                 ref. [10]
              512    NETBIOS                       RFC 1088
              508    IEEE 802/Source-Rt Bridge     RFC 1042
              508    ARCNET                        RFC 1051
   508 (13%)
              296    Point-to-Point (low delay)    RFC 1144
   296
   68                Official minimum MTU          RFC 791

                Table 7-1:  Common MTUs in the Internet

As to the RA's MTU, I can imagine two rules:

(1) since the address can be used on the LAN the RA is advertised on, the MTU should be that of the LAN.
(2) since the host presumably has at least a link-local address that it can use on the LAN, the RA should advertise the MTU that is to be used (or used first) when using a source address within that prefix.

In my example above, I'm at a loss for a way to tell Hosts 1 and 2 that they can communicate with each other using a 9K MTU if the RA's MTU is that of its WAN link (e.g., is following the second rule), from which it presumably derived the prefix being advertised in the RA.

Hence, I think it has to be rule (1), and leave the "but what if..." cases to PMTU.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 21 Sep 2011 09:43:45 +0300

Thanks for taking the time to answer Fred,

> Hence, I think it has to be rule (1), and leave the "but what if..." cases to PMTU.

I was actually hoping to find a doc describing the required behavior by the CPE (RFC6204 doesn't provide any hint, nor 
does the advanced draft).
Although i'm not an expert, maybe something along the scopes of RFC4191 or the mif area (i.e. dhcpv6-route-option) could 
be used to also pass MTU information per prefix, so that communication between hosts in the same LAN uses the max MTU 
available (like 9k), while all other communication uses the WAN MTU as the upper limit.Then it would be up to the host 
to use a PMTUD method for further refinement.

Regards,
Tassos

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Sep 2011 10:23:23 -0400

> I'm trying to find a doc describing the expected behavior regarding
> the advertisement of IPv6 MTU by the CPE to LAN devices.

In most cases, and by default, there is no reason for a CPE to set the
MTU value in RAs. One needs to set it only if one needs to override
the standard value for the link MTU.

>                       supported by all segments.

I think the above is actually pretty clear, and this is the first time
I can recall that anyone raising a question about it.

If you read 4861 (or just look at all references to MTU), it's pretty
clear that the above refers to the "link MTU", not a "path MTU". The
example above (about bridges) refers specifically to a single link
(from an IP perspective) that has bridged components, where the
different components have different MTUs, but the bridges don't send
ICMP packet too big. So a host on a segment that thinks the link MTU
should be X (a big number) may not be able to send packets
successfully to another node on the same link (but on a different
segment) where the segment/link MTU value is smaller.

The case above may well be a non-issue these days (I'm not sure). But
back when we wrote the above, token rings still existed (they have
bigger MTUs than ethernet), and there were devices that bridged
between token ring and Ethernet. So you could have IP links where by
default, hosts would use different values for the link MTU.

For a CPE on a typical home network, there is no need for the CPE to
include the link MTU in RAs.

And taking the MTU from the WAN side to decide what the MTU should be
on the link side is totally wrong. Fred outlined how you can get into
trouble.

Hope this helps...

Thomas

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 22 Sep 2011 14:48:18 -0500

> > If the WAN MTU is somehow manually/automatically configured in the
DSL CPE,
> what should happen with the LAN (interface) & RA (included in LAN
Router
> Advertisement) MTUs?	

The (RA) advertised MTU, by default, must correspond to LAN interface
media on which the RA is sent. 

Sure, one could allow for the config to override it. 

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred
> Baker (fred)
> Sent: Tuesday, September 20, 2011 10:32 AM
> To: Tassos Chatzithomaoglou
> Cc: [email-masked] WG
> Subject: Re: [v6ops] advertisement of IPv6 MTU by the CPE to LAN
devices
> >> If the WAN MTU is somehow manually/automatically configured in the
DSL CPE,
> what should happen with the LAN (interface) & RA (included in LAN
Router
> Advertisement) MTUs?
> > Now, to your premise, the link between Router 1 and its ISP has a
tunnel in
> it and as a result is using a reduced PMTU. Host 2 has three obvious
targets
> for sessions it might open - Host 1, other hosts via ISP 1, and still
other
> hosts via ISP 2. What PMTU should it use for those various sessions?
How would
> that information be communicated? I could imagine that R1-ISP1 has a
PMTU of
> 1280, R2-ISP2 has a PMTU of 1500, and the two LANs and R3 are quite
happy with
> a 9K PMTU.
> > If the WAN MTU is somehow manually/automatically configured in the
DSL CPE,
> what should happen with the LAN (interface) & RA (included in LAN
Router
> Advertisement) MTUs?	
> Bringing it back specifically to this, I would expect that the LAN MTU
is
> technology-specific. IEEE 802.3 generally specifies an MTU of 1500
bytes, but
> gigabit interfaces often (non-standardly) in fact support MTUs of 9180
bytes.
> On such a LAN, I don't see any purpose in forcing the hosts to use
1500 byte
> MTUs. If you look at other RFCs that discuss topics like this, notably
RFC
> 1191, this has wide variation. The following is from page 17 of RFC
1191:
> (1) since the address can be used on the LAN the RA is advertised on,
the MTU
> should be that of the LAN.
> (2) since the host presumably has at least a link-local address that
it can
> use on the LAN, the RA should advertise the MTU that is to be used (or
used
> first) when using a source address within that prefix.
> 
> In my example above, I'm at a loss for a way to tell Hosts 1 and 2
that they
> can communicate with each other using a 9K MTU if the RA's MTU is that
of its
> WAN link (e.g., is following the second rule), from which it
presumably
> derived the prefix being advertised in the RA.
> 
> Hence, I think it has to be rule (1), and leave the "but what if..."
cases to
> PMTU.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops