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

Joe Touch <> Thu, 16 February 2017 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B418129629; Thu, 16 Feb 2017 13:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S3zi_UkbCitB; Thu, 16 Feb 2017 13:43:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0ADF512967D; Thu, 16 Feb 2017 13:43:13 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1GLggFI007094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 13:42:42 -0800 (PST)
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: Stewart Bryant <>, "Templin, Fred L" <>, Brian E Carpenter <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Thu, 16 Feb 2017 13:42:42 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 21:43:14 -0000

On 2/16/2017 1:29 PM, Stewart Bryant wrote:
> On 16/02/2017 18:49, Joe Touch wrote:
>> On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>>> On 14/02/2017 23:00, Templin, Fred L 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.
>>> 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";
> 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.

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

>> 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.
> 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

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

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.