Subject: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

From: "Black, David" <[email-masked]>
Date: Wed, 14 May 2014 16:52:40 -0400

<WG chair hat off>

Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains
some text on dealing with the fragmentation and MTU effects of tunnels.
I thought I'd ask for some early review of this text, given recent IESG
excitement around fragmentation and Path MTU topics in another draft:

http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/ 

I believe that the nvo3 draft is in better shape in these areas.  Nonetheless,
I've included its current text on fragmentation and path MTU below, and (on
behalf of the draft authors and nvo3 WG chairs) I'm looking for input on
what that text should say and why.

In nvo3 terminology, an overlay network is an inner network that is tunneled
over an outer underlay network.  The nvo3 WG also uses "Tenant System" as
the term for a sender/receiver of network traffic because multi-tenancy is
an important motivation for the WG's activities in network virtualization.

--------------------------------------

3.5. Path MTU

       The tunnel overlay header can cause the MTU of the path to the
       egress tunnel endpoint to be exceeded.
    
       IP fragmentation SHOULD be avoided for performance reasons.
    
       The interface MTU as seen by a Tenant System SHOULD be adjusted such
       that no fragmentation is needed. This can be achieved by
       configuration or be discovered dynamically.
    
       Either of the following options MUST be supported:
    
          o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
            Extended MTU Path Discovery techniques such as defined in
            [RFC4821]
    
          o Segmentation and reassembly support from the overlay layer
            operations without relying on the Tenant Systems to know about
            the end-to-end MTU
    
          o The underlay network MAY be designed in such a way that the MTU
            can accommodate the extra tunnel overhead.

--------------------------------------

</WG chair hat off>

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 15 May 2014 07:38:25 +0000

Hi,

>           Extended MTU Path Discovery techniques such as defined in

Will the NVO3 dataplane protocols have mechanisms to detect loss, so they can actually do RFC4821?

(I've often seen 4821 cited alongside 1981, because people think it's a drop-in replacement when it isn't.)

Lars

---

From: "Black, David" <[email-masked]>
Date: Thu, 15 May 2014 10:44:58 -0400

> they can actually do RFC4821?

That would definitely be worth calling out; I'll see about writing
some text ... in my "copious spare time" ;-).

> a drop-in replacement when it isn't.)

Some of the dataplane protocols under consideration do not have that
ability, and in addition, there's a strong tendency in nvo3 to shove
this problem up the stack, i.e., expect the applications using the
overlay to do their own MTU discovery.

Thanks,
--David

> -----Original Message-----
> From: Eggert, Lars [mailto:[email-masked]]
> Sent: Thursday, May 15, 2014 3:38 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts
> draft
> 
> Hi,
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 May 2014 13:44:48 -0700

On 5/15/2014 3:40 PM, Templin, Fred L wrote:
>> From: tsv-area [mailto:[email-masked]] On Behalf Of Black, David
>> Sent: Wednesday, May 14, 2014 1:53 PM
>> To: [email-masked]; [email-masked]
>> Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft
>>
>> <WG chair hat off>
...
> Over in the intarea, there have been sporadic ongoing discussions about
> how to recommend generic MTU mitigations for tunnels. Joe Touch and Mark
> Townsley have been working for a long time on a document titled
> "Tunnels in the Internet Architecture":
>
> http://tools.ietf.org/id/draft-ietf-intarea-tunnels-00.txt
>
> That document should be the place to put generic recommendations for
> tunnel MTU handling that apply to all tunnel types.
>
> Tunnel MTU issues keep popping up in all places, and this is just
> another example. Is it time to revive Joe and Mark's document?

It's being revived - Mark and I already discussed it, and I'm preparing 
a revision; my cycles are thin, though - I just completed one on TCP 
security and another on transport ports, but this is next on my table.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 May 2014 18:27:44 +0000

> tunnel MTU handling that apply to all tunnel types.

In case you are wondering what I think "generic recommendations for
tunnel MTU handling" should look like, here is what I think:

   The tunnel link Maximum Transmission Unit (MTU) is 64KB minus the
   encapsulation overhead for IPv4 [RFC0791] and 4GB minus the
   encapsulation overhead for IPv6 [RFC2675].  This is the most that
   IPv4 and IPv6 (respectively) can convey within the constraints of
   protocol constants, but actual sizes available for tunneling will
   frequently be much smaller.

   The base tunneling specifications for IPv4 and IPv6 typically set a
   static MTU on the tunnel ingress to 1500 bytes minus the
   encapsulation overhead or smaller still if the tunnel is likely to
   incur additional encapsulations on the path.  This can result in path
   MTU related black holes when packets that are too large to be
   accommodated over the tunnel are dropped, but the resulting ICMP
   Packet Too Big (PTB) messages are lost on the return path.  As a
   result, tunnels use the following MTU mitigations to accommodate
   larger packets.

   Tunnels set their ingress MTU to the larger of the
   underlying interface MTU minus the encapsulation overhead, and 1500
   bytes.  Tunnels optionally cache per-egress MTU values in
   the underlying IP path MTU discovery cache initialized to the
   underlying interface MTU.

   Tunnels admit packets that are no larger than 1280 bytes minus the
   encapsulation overhead (*) as well as packets that are larger than
   1500 bytes into the tunnel without fragmentation, i.e., as long as
   they are no larger than the tunnel ingress MTU before encapsulation
   and also no larger than the cached per-egress MTU following
   encapsulation.  For IPv4, the ingress sets the "Don't Fragment" (DF)
   bit to 0 for packets no larger than 1280 bytes minus the encapsulation
   overhead (*) and sets the DF bit to 1 for packets larger than 1500
   bytes.  If a large packet is lost in the path, the ingress may
   optionally cache the MTU reported in the resulting PTB message or may
   ignore the message, e.g., if there is a possibility that the message
   is spurious.

   For packets admitted into the tunnel that are larger than 1280 bytes
   minus the encapsulation overhead (*) but no larger than 1500 bytes,
   the ingress uses IP fragmentation to fragment the encapsulated packet
   into two pieces (where the first fragment contains 1024 bytes of the
   fragmented inner packet) then sends the fragments to the egress.
   If the outer protocol is IPv4, the node sends the fragments with
   DF set to 0 and subject to rate limiting to avoid
   reassembly errors [RFC4963][RFC6864].  For both IPv4 and IPv6, the
   ingress also sends a 1500 byte probe message (**) to the egress,
   subject to rate limiting. To construct a probe, the ingress prepares
   an ICMPv6 Neighbor Solicitation (NS) message with trailing padding
   octets added to a length of 1500 bytes but does not include the
   length of the padding in the IPv6 Payload Length field.  The ingress
   then encapsulates the NS in the outer encapsulation headers (while
   including the length of the padding in the outer length fields), sets
   DF to 1 (for IPv4) and sends the padded NS message to the neighbor.
   If the egress returns an NA message, the ingress may then send whole
   packets within this size range and (for IPv4) relax the rate limiting
   requirement. (Note that for tunnels that do not perform IPv6 neighbor
   discovery, an ICMP echo request message can be used instead of NS.) 

   The egress MUST be capable of reassembling packets up to 1500 bytes
   plus the encapsulation overhead length.  It is therefore RECOMMENDED
   that the egress be capable of reassembling at least 2KB.

   (*) Note that if it is known without probing that the minimum Path
   MTU to a tunnel egress is MINMTU bytes (where 1280 < MINMTU < 1500)
   then MINMTU can be used instead of 1280 in the fragmentation threshold
   considerations listed above.

   (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used
   for MTU probing purposes, since smaller probes may be fragmented if
   there is a nested tunnel somewhere on the path to the egress.
   Probe sizes larger than 1500 bytes MAY be used, but may be
   unnecessary since original sources are expected to use [RFC4821]
   when sending large packets.

I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go
as a set of generic recommendations to be cited by other documents.

Comments?

Thanks - Fred
[email-masked]

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, May 15, 2014 3:41 PM
> To: Black, David; [email-masked]; [email-masked]
> Cc: Mark Townsley; [email-masked]
> Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> Hi,
> 
> All tunnels have trouble with path MTU, and in some cases have no choice
> but to fragment. However, they should strive to tune out fragmentation
> and forward whole packets whenever possible.
> 
> Thanks - Fred
> fred.l.templin@boeing.
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 May 2014 19:09:39 +0000

Hi Linda,

The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum
MTU for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the
IPv4 network itself is the link layer for the tunnel. For tunnels over
IPv6, the IPv6 network is the link-layer. That means that the largest
encapsulated packet that will fit over an IPv4 "link" is 64KB minus
the encapsulation overhead, and the largest over an IPv6 "link" is
4GB minus overhead. But, typical values will be much smaller than
this because most underlying links configure smaller MTUs.

Thanks - Fred

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Friday, May 16, 2014 11:56 AM
> To: Templin, Fred L; Black, David; [email-masked]; [email-masked]
> Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> I am confused of the math here. If most physical links MTU is 1500 bytes (or 2000 bytes for some), how
> do we have""4GB"" minus the encapsulation overhead for IPv6, as the "tunnel link Maximum Transmission
> Unit (MTU)".
> 
> Is 4GB correct ???
> 
> Linda
> 
> Sent: Friday, May 16, 2014 1:28 PM
> In case you are wondering what I think "generic recommendations for tunnel MTU handling" should look
> like, here is what I think:
> 
> I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go as a set of generic
> recommendations to be cited by other documents.
> 
> Comments?
> 
> Thanks - Fred
> > > Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03
> > > contains some text on dealing with the fragmentation and MTU effects of tunnels.
> > > I thought I'd ask for some early review of this text, given recent
> > > IESG excitement around fragmentation and Path MTU topics in another draft:
> >
> > All tunnels have trouble with path MTU, and in some cases have no
> > choice but to fragment. However, they should strive to tune out
> > fragmentation and forward whole packets whenever possible.
> >
> > Over in the intarea, there have been sporadic ongoing discussions
> > about how to recommend generic MTU mitigations for tunnels. Joe Touch
> > and Mark Townsley have been working for a long time on a document
> > titled "Tunnels in the Internet Architecture":
> >
> > > I believe that the nvo3 draft is in better shape in these areas.
> > > Nonetheless, I've included its current text on fragmentation and
> > > path MTU below, and (on behalf of the draft authors and nvo3 WG
> > > chairs) I'm looking for input on what that text should say and why.
> > >
> > > In nvo3 terminology, an overlay network is an inner network that is
> > > tunneled over an outer underlay network.  The nvo3 WG also uses
> > > "Tenant System" as the term for a sender/receiver of network traffic
> > > because multi-tenancy is an important motivation for the WG's activities in network
> virtualization.
> > >
> > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > St., Hopkinton, MA  01748

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 May 2014 20:13:27 +0000

Hi Linda,

> Sent: Friday, May 16, 2014 1:02 PM
> Can we challenge the 4GB MTU size recommendation by RFC2675? Network consists of nodes and links. The
> MTU of a network should be limited by the MTU of the links.

Yes, the path MTU is the minimum MTU of all links in the path. The
path MTU minus the encapsulation is the largest packet that will
traverse the tunnel without fragmentation. But, consider that the
path MTU may be as large 64KB for IPv4 or 4GB for IPv6.

> With 4GB MTU recommendation, it would require the network ingress node to fragment packets and egress
> node to reassemble packets.

No, if you look further into my text you will see that we will never
allow fragmentation for packets larger than 1500 bytes; anything
larger will go as an unfragmented whole packet or will be dropped
at a link within the tunnel that configures an insufficient MTU.
64KB/4GB are not "recommendations"; they are protocol constants.

> If the network ingress can fragment and egress can reassemble packets, there is no need to define the
> network MTU size. Therefore, this recommendation is meaningless.

Fragmentation and reassembly limit is 1500 bytes; larger packets
go through unfragmented or not at all. Take care of the smalls,
and let the bigs take care of themselves.

Thanks - Fred
 
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Friday, May 16, 2014 2:10 PM
> To: Linda Dunbar; Black, David; [email-masked]; [email-masked]
> The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MTU for an IPv6 link is 4GB
> (per RFC2675). For tunnels over IPv4, the
> IPv4 network itself is the link layer for the tunnel. For tunnels over IPv6, the IPv6 network is the
> link-layer. That means that the largest encapsulated packet that will fit over an IPv4 "link" is 64KB
> minus the encapsulation overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But,
> typical values will be much smaller than this because most underlying links configure smaller MTUs.
> 
> Thanks - Fred
> > I am confused of the math here. If most physical links MTU is 1500
> > bytes (or 2000 bytes for some), how do we have""4GB"" minus the
> > encapsulation overhead for IPv6, as the "tunnel link Maximum Transmission Unit (MTU)".
> >
> > Is 4GB correct ???
> >
> > Linda
> >
> > I think this applies to all IP-in-(foo)-in-IP tunnel types, and could
> > go as a set of generic recommendations to be cited by other documents.
> >
> > Comments?
> >
> > Thanks - Fred
> > > about how to recommend generic MTU mitigations for tunnels. Joe
> > > Touch and Mark Townsley have been working for a long time on a
> > > document titled "Tunnels in the Internet Architecture":
> > >
> > > > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmenta
> > > > ti
> > > > on/ballot/
> > > >
> > > > In nvo3 terminology, an overlay network is an inner network that
> > > > is tunneled over an outer underlay network.  The nvo3 WG also uses
> > > > "Tenant System" as the term for a sender/receiver of network
> > > > traffic because multi-tenancy is an important motivation for the
> > > > WG's activities in network
> > virtualization.
> > > >

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 May 2014 20:56:54 +0000

Hi Linda,

> Sent: Friday, May 16, 2014 1:45 PM
> Fred,
> Thanks for the clarification.
> 
> Since the topic is about tunneling, a.k.a. encapsulating additional headers to data packets that
> increases the risk of exceeding link MTU, we should focus on the Path MTU, not the network Layer MTU.
> 
> So we shouldn't use the 64K/4GB recommended by RFC2675 for "The tunnel link Maximum Transmission Unit"

The "link" for a tunnel over IPv4 is the IPv4 network. The maximum MTU
for traversing an IPv4 network is 64KB.

The "link" for a tunnel over IPv6 is the IPv6 network. The maximum MTU
for traversing an IPv6 network is 4GB.

These are protocol constants; not recommendations. In order to change
them, we would need to (bis) RFC0791 and RFC2675.

If you read further in the text (say, beginning with the next sentence)
all will be made clear.

Thanks - Fred

> No, if you look further into my text you will see that we will never allow fragmentation for packets
> larger than 1500 bytes; anything larger will go as an unfragmented whole packet or will be dropped at
> a link within the tunnel that configures an insufficient MTU.
> > If the network ingress can fragment and egress can reassemble packets,
> > there is no need to define the network MTU size. Therefore, this recommendation is meaningless.
> 
> Fragmentation and reassembly limit is 1500 bytes; larger packets go through unfragmented or not at
> all. Take care of the smalls, and let the bigs take care of themselves.
> 
> Thanks - Fred
> > the encapsulation overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But, typical
> values will be much smaller than this because most underlying links configure smaller MTUs.
> >
> > Thanks - Fred
> > > > That document should be the place to put generic recommendations
> > > > for tunnel MTU handling that apply to all tunnel types.
> > >
> > > I think this applies to all IP-in-(foo)-in-IP tunnel types, and
> > > could go as a set of generic recommendations to be cited by other documents.
> > >
> > > Comments?
> > >
> > > Thanks - Fred
> > > > > I thought I'd ask for some early review of this text, given
> > > > > recent IESG excitement around fragmentation and Path MTU topics in another draft:
> > > >
> > > > That document should be the place to put generic recommendations
> > > > for tunnel MTU handling that apply to all tunnel types.
> > > >
> > > > > is tunneled over an outer underlay network.  The nvo3 WG also
> > > > > uses "Tenant System" as the term for a sender/receiver of
> > > > > network traffic because multi-tenancy is an important motivation
> > > > > for the WG's activities in network
> > > virtualization.
> > > > >
> > > > > David L. Black, Distinguished Engineer EMC Corporation, 176
> > > > > South St., Hopkinton, MA  01748

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 14 May 2014 22:02:33 +0000

I think that the "fragmentation and path MTU text" should be seriously discussed in SFC WG that is considering Service Chain Header format. 

I've heard people mentioning encoding the explicit Service Chain path as metadata to the data packet header for some scenarios where head-end SC classifier node determines the chain path dynamically. 

Just imagine having IPv6 addresses encoded in the packet header to show explicit service chain path, which can be very long.  

Cheers,

Linda

-----Original Message-----
From: tsv-area [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, May 14, 2014 3:53 PM
To: [email-masked]; [email-masked]
Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft

<WG chair hat off>

Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains some text on dealing with the fragmentation and MTU effects of tunnels.
I thought I'd ask for some early review of this text, given recent IESG excitement around fragmentation and Path MTU topics in another draft:

I believe that the nvo3 draft is in better shape in these areas.  Nonetheless, I've included its current text on fragmentation and path MTU below, and (on behalf of the draft authors and nvo3 WG chairs) I'm looking for input on what that text should say and why.

In nvo3 terminology, an overlay network is an inner network that is tunneled over an outer underlay network.  The nvo3 WG also uses "Tenant System" as the term for a sender/receiver of network traffic because multi-tenancy is an important motivation for the WG's activities in network virtualization.

3.5. Path MTU

    

    

</WG chair hat off>

Thanks,
--David

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 15 May 2014 03:46:13 +0000

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Linda Dunbar
> 发送时间: 2014年5月15日 6:03
> 收件人: Black, David; [email-masked]; [email-masked]
> 抄送: [email-masked]
> 主题: Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> I think that the "fragmentation and path MTU text" should be seriously discussed
> in SFC WG that is considering Service Chain Header format.
> 
> I've heard people mentioning encoding the explicit Service Chain path as
> metadata to the data packet header for some scenarios where head-end SC
> classifier node determines the chain path dynamically.

To allow the classifier to determine the service path dynamically, why not directly encoding the explicit service path information within the SR (source routing or segment routing) header (see http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00), especially the MPLS label stack based SR header if MTU is still a concern? 

Best regards,
Xiaohu

> Just imagine having IPv6 addresses encoded in the packet header to show
> explicit service chain path, which can be very long.

> I thought I'd ask for some early review of this text, given recent IESG excitement
> around fragmentation and Path MTU topics in another draft:
> 
> I believe that the nvo3 draft is in better shape in these areas.  Nonetheless, I've
> included its current text on fragmentation and path MTU below, and (on behalf
> of the draft authors and nvo3 WG chairs) I'm looking for input on what that text
> should say and why.
> 
> the term for a sender/receiver of network traffic because multi-tenancy is an
> important motivation for the WG's activities in network virtualization.
> 
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 May 2014 22:40:58 +0000

Hi,

Thanks - Fred
fred.l.templin@boeing.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 16 May 2014 18:56:14 +0000

I am confused of the math here. If most physical links MTU is 1500 bytes (or 2000 bytes for some), how do we have""4GB"" minus the encapsulation overhead for IPv6, as the "tunnel link Maximum Transmission Unit (MTU)". 

Is 4GB correct ???

Linda 

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, May 16, 2014 1:28 PM
To: Black, David; [email-masked]; [email-masked]
Cc: Mark Townsley; [email-masked]
Subject: Re: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

> tunnel MTU handling that apply to all tunnel types.

In case you are wondering what I think "generic recommendations for tunnel MTU handling" should look like, here is what I think:

I think this applies to all IP-in-(foo)-in-IP tunnel types, and could go as a set of generic recommendations to be cited by other documents.

Comments?

Thanks - Fred

> > because multi-tenancy is an important motivation for the WG's activities in network virtualization.
> >

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 16 May 2014 20:02:09 +0000

Can we challenge the 4GB MTU size recommendation by RFC2675? Network consists of nodes and links. The MTU of a network should be limited by the MTU of the links. 

With 4GB MTU recommendation, it would require the network ingress node to fragment packets and egress node to reassemble packets.  

If the network ingress can fragment and egress can reassemble packets, there is no need to define the network MTU size. Therefore, this recommendation is meaningless. 

Linda

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, May 16, 2014 2:10 PM
To: Linda Dunbar; Black, David; [email-masked]; [email-masked]
Cc: Mark Townsley; [email-masked]
Subject: RE: [Int-area] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

Hi Linda,

The maximum MTU for an IPv4 link is 64KB (per RFC0791) and the maximum MTU for an IPv6 link is 4GB (per RFC2675). For tunnels over IPv4, the
IPv4 network itself is the link layer for the tunnel. For tunnels over IPv6, the IPv6 network is the link-layer. That means that the largest encapsulated packet that will fit over an IPv4 "link" is 64KB minus the encapsulation overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But, typical values will be much smaller than this because most underlying links configure smaller MTUs.

Thanks - Fred

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 16 May 2014 20:45:18 +0000

Fred, 

Since the topic is about tunneling, a.k.a. encapsulating additional headers to data packets that increases the risk of exceeding link MTU, we should focus on the Path MTU, not the network Layer MTU. 

Linda

-----Original Message-----

No, if you look further into my text you will see that we will never allow fragmentation for packets larger than 1500 bytes; anything larger will go as an unfragmented whole packet or will be dropped at a link within the tunnel that configures an insufficient MTU.
64KB/4GB are not "recommendations"; they are protocol constants.

> there is no need to define the network MTU size. Therefore, this recommendation is meaningless.

Fragmentation and reassembly limit is 1500 bytes; larger packets go through unfragmented or not at all. Take care of the smalls, and let the bigs take care of themselves.

Thanks - Fred
 
> the encapsulation overhead, and the largest over an IPv6 "link" is 4GB minus overhead. But, typical values will be much smaller than this because most underlying links configure smaller MTUs.
> 
> Thanks - Fred