Subject: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

From: Stewart Bryant <[email-masked]>
Date: Thu, 09 Feb 2017 07:19:53 -0800

Reviewer: Stewart Bryant
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Stewart Bryant
Review Date: 9/Feb/2017
IETF LC End Date: 1/Mar/2017
IESG Telechat date: unknown

Summary: This draft is on the right track but has open issues,
described in the review.

This review together with the lengthy discussion on the IETF list
suggest that this draft has a number of issues that need to be
addressed  before publication.

I wonder if we would best serve both our future and our heritage
if we declared RFC1981 as historic, and either left the idea there,
or declared it as historic and wrote a new text from a clean start?

Major issues:

Nits points out a number of faults with the document, but the only
one of substance is:

The text has a lot of RFC2119 language, but no RFC2119 declaration.

The document could use a thorough RFC2119 scrub

The document lists the three original authors one with an affiliation

change, but no email addresses. Has this been agreed with the
original
authors, and have arrangements been put in place for the RFC editor 
to process auth48?

It is concerning that the draft does not talk in any detail about
how modern ECMP works, i.e. using the five tuple, and noting that
the PMTU may be different depending on the transport layer port
numbers.

Given that a very large fraction of packets will traverse an MPLS
network at some point, I am surprised that there is no text talking
about the importance of providing support for this feature in the 
MPLS domain. RFC3988 talks to this point, but is only experimental.

======

   If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
   could use the flow id as the local representation of a path. 
Packets
   sent to a particular destination but belonging to different flows
may
   use different paths, with the choice of path depending on the flow
   id.  This approach will result in the use of optimally sized
packets
   on a per-flow basis, providing finer granularity than PMTU values
   maintained on a per-destination basis.

SB> How widely is flow-id supported in networks? I thought that the 
SB> current position was that it was unreliable as an ECMP indicator
SB> and thus routers tended to glean information from the packet
themselves.

======

      Note: if the original packet contained a Routing header, the
      Routing header should be used to determine the location of the
      destination address within the original packet.  If Segments
Left
      is equal to zero, the destination address is in the Destination
      Address field in the IPv6 header.  If Segments Left is greater
      than zero, the destination address is the last address
      (Address[n]) in the Routing header.

SB> So this has the effect that a traffic engineered packet and
SB> a non-traffic engineered packet will have the lower of the 
SB> two PMTUs. This was all harmless when source routing was a
curiosity
SB> as far as mainstream networking was concerned, but may be
SB> more of a problem as a result of the SPRING work.

=======

5.3.  Purging stale PMTU information

   Internetwork topology is dynamic; routes change over time.  While
the
   local representation of a path may remain constant, the actual
   path(s) in use may change.  Thus, PMTU information cached by a
node
   can become stale.

   If the stale PMTU value is too large, this will be discovered
almost
   immediately once a large enough packet is sent on the path.  No
such
   mechanism exists for realizing that a stale PMTU value is too
small,
   so an implementation should "age" cached values.  When a PMTU
value
   has not been decreased for a while (on the order of 10 minutes),
the
   PMTU estimate should be set to the MTU of the first-hop link, and
the
   packetization layers should be notified of the change.  This will
   cause the complete Path MTU Discovery process to take place again.

SB> Should that be an RFC2119 SHOULD?
SB> The impact of this advice is going to be a disruption to what
might
SB> be a critical service every 10 mins.
SB> Should there be some advice along the lines of noting the 
SB> importance of service delivery as part of deciding whether to
SB> test for bigger PMTU vs improving efficiency?

=======

Minor issues:

   IPv6 defines a standard mechanism for a node to discover the
   PMTU of an arbitrary path.

SB> Do you mean "This document defines ....."? Otherwise this needs
SB> a reference.

=======

   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer
Path
SB> Rather than have the reader figure out what "It" is, perhaps
SB> s/It/RFC4821/
=======

   Upon receipt of such a
   message, the source node reduces its assumed PMTU for the path
based
   on the MTU of the constricting hop as reported in the Packet Too
Big
   message.

SB> We should perhaps state up front that this procedure
SB> hunts for the worst case of the ECMP set associated with the 
SB> ingress nodes PMTU classifier.
=======

   If a node receives a Packet Too Big message reporting a next-hop
MTU
   that is less than the IPv6 minimum link MTU, it should discard it.

SB> Should that be an RFC2119 SHOULD?
=======

5.2.  Storing PMTU information

   Ideally, a PMTU value should be associated with a specific path
   traversed by packets exchanged between the source and destination
   nodes.  However, in most cases a node will not have enough
   information to completely and accurately identify such a path.
   Rather, a node must associate a PMTU value with some local
   representation of a path.  It is left to the implementation to
select
   the local representation of a path.

SB> Is it worth noting the five tuple since that is how a lot of
SB> load balancers work?
=======

   The set of paths in use to a
   particular destination is expected to be small, in many cases
   consisting of a single path.  

SB> I am not sure that remains true in modern networks.
=======

   One approach to implementing PMTU aging is to associate a
timestamp
   field with a PMTU value.  This field is initialized to a
"reserved"
   value, indicating that the PMTU is equal to the MTU of the first
hop
   link.  Whenever the PMTU is decreased in response to a Packet Too
Big
   message, the timestamp is set to the current time.

   Once a minute, a timer-driven procedure runs through all cached
PMTU
   values, and for each PMTU whose timestamp is not "reserved" and is
   older than the timeout interval:

   -  The PMTU estimate is set to the MTU of the first hop link.

   -  The timestamp is set to the "reserved" value.

   -  Packetization layers using this path are notified of the
increase.

SB> Such detailed implementation advice is uncommon in modern RFCs. It
has
SB> the disadvantage of de-facto standardizing something that should
be left to
SB> the innovation of the implementer.

=======

5.4.  TCP layer actions

SB> TCP implementations have moved on a lot since this section was
SB> written. Is this still current best practise?

=======

5.5.  Issues for other transport protocols

   Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed
to
   repacketize when doing a retransmission.  

SB> How much TP4 is there going over IPv6? Doesn't this example 
SB> show the IETF as not being in the modern age?

=======

Nits/editorial comments: 

   upper layer         a protocol layer immediately above IPv6.
                       Examples are transport protocols such as TCP
and
                       UDP, control protocols such as ICMP, routing
                       protocols such as OSPF, and internet or lower-
                       layer protocols being "tunneled" over (i.e.,
                       encapsulated in) IPv6 such as IPX, AppleTalk,
or
                       IPv6 itself.

SB> Everything in the list above is in the well known list, except
SB> IPX, so technically it needs expansion. However it might be nice
SB> to use some modern example in common use.
=======

   link                a communication facility or medium over which
                       nodes can communicate at the link layer, i.e.,
                       the layer immediately below IPv6.  Examples
are
                       Ethernets (simple or bridged); PPP links;
X.25,
                       Frame Relay, or ATM networks; and internet (or
                       higher) layer "tunnels", such as tunnels over
                       IPv4 or IPv6 itself.

SB> Technically X.25 needs a reference, since it is not "well known"
=======

   path                the set of links traversed by a packet between
a
                       source node and a destination node.

SB> Is it a set of links, or a set of links and nodes?

========
 
    the value of MMS_S, the "maximum send transport-message size". 
SB> The modern convention is full-name(abbreviation)

========

   The Sun Network File System (NFS) uses a Remote Procedure Call
(RPC)
   protocol [RPC] that, when used over UDP, in many cases will
generate
   payloads that must be fragmented even for the first-hop link. 
This
   might improve performance in certain cases, but it is known to
cause
   reliability and performance problems, especially when the client
and
   server are separated by routers.

SB> Perhaps this should point to RFC7530 (the current NFS Spec),
assuming
SB> the behaviour description is still correct.

=========

   The former can be accomplished by associating a flag with the
path;
   when a packet is sent on a path with this flag set, the IP layer
does
   not send packets larger than the IPv6 minimum link MTU.

SB> We do not normally give this level of implementation advice

========================

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Feb 2017 16:25:44 +1300

Stewart,

On 10/02/2017 04:19, Stewart Bryant wrote:
...
> or declared it as historic and wrote a new text from a clean start?

I don't see that. It's a stable, widely deployed, interoperable
mechanism. That is rather orthogonal to the issue that has been raised,
which is that faulty ICMPv6 filtering blocks it on many, many paths
across the Internet.

...
> the PMTU may be different depending on the transport layer port

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?

> MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?

>    could use the flow id as the local representation of a path. Packets
>    sent to a particular destination but belonging to different flows may
>    id.  This approach will result in the use of optimally sized packets
> SB> and thus routers tended to glean information from the packet themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency with other
recent RFCs.)

I think your other comments are all valuable.

Regards
    Brian

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 10 Feb 2017 10:20:35 +0000

> which is that faulty ICMPv6 filtering blocks it on many, many paths

I will not debate whether it is faulty or not, but it seems that in 
practice the
Internet breaks the mechanism. However it breaks it is a way that seems
disruptive to some user traffic. The document is really guidance
one how hosts might use  ICMP for optimization, and arguable need
not be a standard at all.

My remark about heritage is that this vintage draft is very much a 
product of
its time, and really needs modernizing, and after modernizing ought to
look quite different, and thus maybe we should employ a procedure
other than a simple replacement.

> contain ECMP setups with different MTUs on different paths?

I don't know if anyone has looked. Since the mechanism is 
self-correcting albeit
with some disruption to user traffic it looks to the application and the 
application
user, just like the Internet not working for a few moments.

In a well managed SP network there should not be, but neither should there
be asymmetric path costs, but there are. The less well manage private
networks are less well managed.

> segments along the path affect end-to-end PMTUD?

The point that RFC3988 makes is that MPLS looks like a single hop to IP 
and the
PE has to fragment or has to reply with an ICMP error message to support
PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
result
in the right response at the end node.

My point is that the draft is silent on the subject, and perhaps it 
should not be.

However your question make me ask a further question. The draft is also 
silent
on NATs. Is there any advice needed for people designing and configuring 
NATs?

> (But it would be better to call it the Flow Label for consistency with other

Well the question is whether it is simply limited today, or broken today 
in a manner that
is irrecoverable? I don't know, but I do know that the mainstream ECMP 
approach
is the five-tuple. There is something akin to the flow label being 
deployed in MPLS. However
what distinguishes the MPLS Entropy Label is that it is inserted (and 
removed) by the
service provider and is therefore trusted by the service provider.

> I think your other comments are all valuable.
Thank you.

Stewart

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 10 Feb 2017 15:38:57 +0000

Hi, about ECMP I think RFC1981bis should be OK even if ECMP is used in the
network as long as ICMP PTBs are not blocked. RFC1981bis will eventually
converge to the minimum MTU of all paths in the multipath, and so it is
still OK to store the MTU in the network layer where it would be shared
by all flows.

ECMP does present challenges for RFC4821, however. If a first transport
session discovers a large MTU and shares it with a second transport
session, the second session may take a very different path where there
is a smaller MTU and encounter a black hole. IMHO, it might be a good
idea to file an erratum to RFC4821 explaining how ECMP might cause
problems if discovered MTUs are shared between sessions.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Friday, February 10, 2017 2:21 AM
> To: Brian E Carpenter <[email-masked]>; Stewart Bryant <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2017 08:45:41 +1300

> I will not debate whether it is faulty or not, but it seems that in 

It's faulty by the standard of RFC4890 (which is Informational).

> not be a standard at all.

I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes.

> other than a simple replacement.

It's proposed for Internet Standard. That means it must replace the
PS document and must specify the same thing, plus corrections, minus
unused features.

> My point is that the draft is silent on the subject, and perhaps it 

Well, in general it's silent on tunnels. They have to emulate links,
as stated in section 2. I still don't see why an MPLS tunnel is a special case.

> on NATs. Is there any advice needed for people designing and configuring 

Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't".

> is irrecoverable? 

Nothing's broken. It's just underused.

> I don't know, but I do know that the mainstream ECMP
> approach is the five-tuple.

Sure, but see RFC6438 for some of the difficulties that
causes with IPv6.

> There is something akin to the flow label being

Exactly the same for ECMP tunnels, in RFC6438. Guess what, my co-author
was from a provider.

   Brian

> .

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 09:50:37 +0000

Hi Fred

Looks like a good point on RFC4821.

As to you first point remember that the convergence process disrupts the 
traffic flow as it does so, and that this will repeat every 10 mins as 
it tries to re-optimise.

- Stewart

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Feb 2017 15:50:27 +0000

HI Stewart,

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2017 1:51 AM
> To: Templin, Fred L <[email-masked]>; Brian E Carpenter <[email-masked]>; Stewart Bryant
> <[email-masked]>; [email-masked]

OK.

> traffic flow as it does so, and that this will repeat every 10 mins as

Yes, you are right. So, even in the case of RFC1981bis it might not be a
good idea to store discovered MTUs in the network layer when there
is ECMP in the path. (Which could be any time at all.)

You briefly mentioned the authorship in your earlier post. As you well
know, the corporate affiliation of two of the authors no longer exists.

Thanks - Fred

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 16:13:03 +0000

> is ECMP in the path. (Which could be any time at all.)

Yes, I think if you really care about disruption due to packet loss your 
best bet is
to go with the minimum supported MTU.

Forwarding performance is not a issue these days, and core link are over 
provisioned
so you have to wonder how important the efficiency gain is in practice.  
The efficiency
gain produced by this protocol in most networks (1276 vs 1496) is only 
about 15% anyway.

> know, the corporate affiliation of two of the authors no longer exists.
My concern was that some authors cannot take part in Auth48 due to not 
providing
active email addresses.

- Stewart

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Feb 2017 16:25:15 +0000

Hi Stewart,

> Sent: Tuesday, February 14, 2017 8:13 AM

So, that would leave us with RFC4821 plus per {session,destination}
probing instead of just per-destination probing. Or, just stick with the
IPv6 minMTU (1280)?

Thanks - Fred

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 16:45:04 +0000

Fred
*If*  you care about packet loss, then your only option is to probe the 
path with with
synthetic data that exactly mimics the live data, or not to probe at all 
and live
with the 1280. As I said 1280 is pretty close to 1496 which is all most 
networks
will give you in practice.

When I think about the people asking for fast re-route to minimise 
packet loss, it seems
very strange to deliberately induce loss to try to stretch the MTU by 15%.

- Stewart

---

From: [email-masked]
Date: Tue, 14 Feb 2017 19:33:09 +0100

Stewart,

> *If*  you care about packet loss, then your only option is to probe the path with with
> synthetic data that exactly mimics the live data, or not to probe at all and live
> with the 1280. As I said 1280 is pretty close to 1496 which is all most networks

Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of the minimum MTU was to give space for tunnel headers (1500-1280).

> When I think about the people asking for fast re-route to minimise packet loss, it seems

Please show the data that there is significant loss. The measurements I have found has not shown that.
If not, then let's please leave that argument on the shelf.

(And please don't read me wrong, I think we should get DNS fixed, that we should fix the IP tunnelling protocols, and that we should get IP fragmentation deprecated).

But right here, right now. PMTUD is for many problems the only solution on the table.
We as a community can choose not to elevate the standard of course, and that will of course not have any big consequence.
Are you afraid that elevating 1981, will hinder people from working on new and better solutions?

Best regards,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 18:53:47 +0000

Ole

Maybe we could sort this out faster with a short phone call.

As I read the spec it says hunt for a new upper  limit every 10 mins, 
won't there be packet as it sends out oversized packets looking for a 
higher MTU?

Stewart

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Feb 2017 10:54:25 -0800

> On Feb 14, 2017, at 10:33 AM, [email-masked] wrote:
> 

I'm confused by that statement. https://tools.ietf.org/html/rfc7676#section-3.2 indicates that a GRE tunnel on IPv6 and carrying an IPv6 payload works with a PMTU of 1280, and AFAIK it is among the larger tunnel headers. What tunnels does a PMTU of 1280 not work for?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Feb 2017 18:54:33 +0000

Hi Ole,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2017 10:33 AM
> To: Stewart Bryant <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]; 6man WG
> <[email-masked]>; [email-masked]; [email-masked]

But, if non-tunnel links set a 1280 MTU which is perfectly OK with the standard then
there is no space for headers. Given the issues with classical PMTUD then (plus the
non-applicability of RFC4821 for tunnels) the only solution for tunnels is fragmentation.
I'll let Joe step in if he wants to.

Thanks - Fred

---

From: [email-masked]
Date: Tue, 14 Feb 2017 20:14:56 +0100

Stewart,

> Maybe we could sort this out faster with a short phone call.

Yes, we can certainly do that!

> As I read the spec it says hunt for a new upper  limit every 10 mins, won't there be packet as it sends out oversized packets looking for a higher MTU?

Yes.

Best regards,
Ole

---

From: [email-masked]
Date: Tue, 14 Feb 2017 20:16:56 +0100

Fred,

> I'll let Joe step in if he wants to.

You are correct. "Does not work for IP tunnels without fragmenting the outer header" is what I should have written.
Of course it appears IPv6 fragments have a order of magnitude higher drop probability than ICMP PMTUD messages.

Pick your poison.

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Feb 2017 19:46:06 +0000

Hi Ole,

> Sent: Tuesday, February 14, 2017 11:17 AM
> To: Templin, Fred L <[email-masked]>
> Cc: Stewart Bryant <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]; 6man WG
> >> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of the minimum MTU was to give space for tunnel
> headers
> >> (1500-1280).
> >

Right. Depending on the encapsulation, however, fragmentation might occur as
some mid-layer between the outer and inner IP headers. For example, a UDP
encapsulation that includes its own fragmentation control fields. In that way,
the network would only see UDP/IP packets - it would not see IPv6 fragments.

GUE is an example UDP encapsulation that include its own fragmentation
control fields:

https://datatracker.ietf.org/doc/draft-herbert-gue-extensions/

> Pick your poison.

As far as RFC 2473 is concerned, you are right. Other encapsulations that
can do the fragmentation at a mid-layer between the inner and outer
IP headers should be OK.

Thanks - Fred

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Feb 2017 20:08:20 +0000

> On Feb 14, 2017, at 2:14 PM, [email-masked] wrote:
> 
> Stewart,
> 
> 

Let me know if you would like me to call in as well. 

Thanks
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Feb 2017 23:00:47 +0000

Hi Stewart,

> *If*  you care about packet loss

I can say that, for air traffic communications at least, we do care very
much about packet loss.

> then your only option is to probe the path with with
> synthetic data that exactly mimics the live data

Yes, that is exactly correct - so, the probing must be on a per
(session,destination) basis and not just per-destination.

> or not to probe at all and live with the 1280

That is the case for tunnels for sure, but many tunneling specs have
been published with an "optimistic" outlook assuming that the
network can support as much as 1500 minus the length of the 
encapsulation headers. Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get through.

> As I said 1280 is pretty close to 1496 which is all most networks

Still, I wish for the day that we may eventually see larger path MTUs.
It seems that the only way for sources to safely discover them
however is to employ per-session RFC4821.

Thanks - Fred

> Sent: Tuesday, February 14, 2017 8:45 AM
> To: Templin, Fred L <[email-masked]>; Stewart Bryant <[email-masked]>; Brian E Carpenter
> <[email-masked]>; [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Feb 2017 12:40:32 -0800

On Feb 14, 2017, at 15:00, Templin, Fred L <[email-masked]> wrote:
> 
> Unless there is operational assurance of some size X>1280, however, tunnels have to use fragmentation to guarantee that - at a minimum - packets up to 1280 will get through.

Given the growing prevalence of IPv6 using 6LoWPAN on IEEE 802.15.4, which is always MTU=1280 everywhere, c.f. RFC 4944, I think we can forget about ever getting that operational assurance in practice.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 13:08:47 -0800

Hi, Ole,

> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of the minimum MTU was to give space for tunnel headers (1500-1280).
I'm in the process of revising draft-intarea-tunnels to make this more
clear, as well as to provide a TSV ART review of this doc, but in preface:

There are two IPv6 minimum sizes: link MTU of 1280 and EMTU_R of 1500.

Support for source fragmentation and the difference between these two
values is what gives space for tunnel headers.

No amount of link MTU management can ever avoid source fragmentation
without violating the link MTU minimums in RFC2460.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 13:12:14 -0800

Brian (et al.),

On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
> PMTUD is not an optimisation. Without it, you get black holes
PMTUD is an optimization to avoid fragmentation.

Without it, you use fragmentation (which has overheads and other
consequences, notably for IPv4).

However, it is only *with* PMTUD (and ICMP blocking) that you get black
holes.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2017 10:26:50 +1300

> consequences, notably for IPv4).

In IPv6, you don't even know you *need* fragmentation without PMTUD,
since only the source is allowed to fragment. (That was one of the
many failure modes for 6to4, which is why the only safe approach was
to use 1280 always.) 

> However, it is only *with* PMTUD (and ICMP blocking) that you get black

True for v4.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 13:32:20 -0800

Hi, Brian,

> many failure modes for 6to4, which is why the only safe approach was
A compliant IPv6 source can send 1500 byte packets that a source without
PMTUD, which would need to be fragmented based on the assumption that
the path MTU is at its required minimum of 1280.

A compliant IPv6 source can send larger packets, which would work if the
receiver supported larger reassembly limits than 1500. There is no
currently standard mechanism to determine the receiver reassembly limit
in IPv6, but this IS supported in TCP.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Feb 2017 15:59:56 +0000

On 14/02/2017 23:00, Templin, Fred L wrote:
> Unless there is operational assurance of

In that case there really needs to be a note about MPLS.

You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.

Stewart

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 10:49:58 -0800

> In that case there really needs to be a note about MPLS.

IMO, this doc shouldn't be discussing tunneling as any different from
any other link.

> You can fragment into an IP tunnel, but not an MPLS tunnel, because
> you cannot fragment the payload as you can in IPv4 and you cannot
> fragment MPLS.

There's no such thing as an "MPLS tunnel"; at best, it's "MPLS over X",
e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
while it can't support fragmentation it would never need it either. It
would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
needed fragmentation.  If that can't be supported, then the addition of
MPLS would just reduce the effective MTU of the MPLS-over-X link.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Feb 2017 08:59:15 +1300

> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.

I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
fragments and re-assemble them at the other end - if it's an avian carrier tunnel
it might have to use several pigeons per packet*. None of this matters to the IPv6
nodes concerned; the physical MTU of the tunnel technology is irrelevant except
to the tunnel end points.

   Brian

*In RFC 6214, we didn't consider this, but we should have.

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 13:09:40 -0800

> to the tunnel end points.
There are too many systems that try to optimize the link MTU to
represent the size of the payload of the link source, rather than the
reassembly limit of the link receiver.

It's trying to make PMTUD work multiple layers down rather than stopping
at the IP layer (which I think is where it should stop).

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Feb 2017 21:29:02 +0000

On 16/02/2017 18:49, Joe Touch wrote:
> There's no such thing as an "MPLS tunnel";

In the MPLS world an "MPLS tunnel" is a common name for an MPLS LSP that
is used to carry some payload such as IP.

> at best, it's "MPLS over X",

It was of course IPv6 over MPLS that concerned me.

S

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 13:42:42 -0800

> is used to carry some payload such as IP.

MPLS just adds the label tags; there's no length field.  It's only a
tunnel when it goes over some other encapsulation layer, e.g., IP or
Ethernet.

> It was of course IPv6 over MPLS that concerned me.

IPv6 over MPLS isn't yet a tunnel. It would be IPv6 over MPLS over IPv6,
presumably (IPv6 over IPv4 isn't guaranteed to work because IPv4 EMTU_R
is only 576, and for an IPv6 tunnel it would be required to be at least
1280+encaps).

An IPv6 packet can traverse an IPv6 over MPLS over Ethernet tunnel (with
a 1500B payload) as long as the MPLS headers are smaller than 1500-1280
bytes.

An IPv6 packet can traverse an IPv6 over MPLS over IPv6 tunnel as long
as the MPLS + added IPv6 headers are smaller than 1500-1280 bytes.
However, if the arriving (transit) packet is larger than
1280-MPLS-IPv6ecaps, the MPLS tunnel ingress would need to do source
fragmentation inside the tunnel (with the egress doing reassembly).

Again, all these cases are discussed in draft-ietf-intarea-tunnels but
none have relevance IMO to this doc.

Joe