Re: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)

Suresh Krishnan <> Thu, 23 February 2017 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 159C41295C9; Wed, 22 Feb 2017 21:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5V6sM1qnY3WI; Wed, 22 Feb 2017 21:44:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E53E1295B8; Wed, 22 Feb 2017 21:44:56 -0800 (PST)
X-AuditID: c618062d-14208980000009d8-93-58ae8724dbf7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4C.39.02520.4278EA85; Thu, 23 Feb 2017 07:54:28 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 23 Feb 2017 00:44:52 -0500
From: Suresh Krishnan <>
To: Giles Heron <>
Thread-Topic: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Thread-Index: AQHSNYdolHbhYzGYAU6NaB9xY2zBaKFgRIsAgBbUHoA=
Date: Thu, 23 Feb 2017 05:44:52 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_CD1CAB1C-2F56-4337-8CBB-174C48739F11"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUyuXRPlK5K+7oIg0u/TSw+vdvBYtG8dT2b xf/WlywWT4/OYLSY8Wcis8X+Ax1sFnt+/WF3YPeY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZ llqkb5fAlbFu5hqWgiVZFRubv7M0MD6J72Lk5JAQMJFY+uMeexcjF4eQwHpGifk/LzODJIQE ljNKTD0cDGKzARVt2PmZCcQWEVCX6JizjQmkgVmgiVni1u9j7CAJYYFciamf97NDFOVJfOud y9jFyAFkW0lsXZgPEmYRUJX49W0ZK4jNK2Av0bjnCwvE4gZGiXNXOxhBEpwCthLPz/1jAbEZ BcQkvp9aA7aYWUBc4taT+UwQV4tIPLx4mg3CFpV4+fgfK4StJDHn9TVmiOOmMEq0vj3IBrFN UOLkzCcsExhFZiGZNQtZ3SwkdRBFSRI3n95lhbC1JZYtfM0MYWtK7O9ezoIpriHR+W0iVL2p xOujHxkhbGuJGb8g5jMLKEpM6X7IvoCRexUjR2lxQU5uupHBJkZgfB+TYNPdwXh/uuchRgEO RiUe3g3310YIsSaWFVfmHmJUAWp9tGH1BUYplrz8vFQlEV7RoHURQrwpiZVVqUX58UWlOanF hxilOViUxHnjVt8PFxJITyxJzU5NLUgtgskycXBKNTDusZ/UuzuuWCG8nbfoahzHjaPFH8yr bMOCZ3KY5smtXLYiN3hd7BcF/b7ifRZb3zKe1jJmcix89zbkY8rh0+cCg5dcnjL5y+V/px9O 2LrgoRLvfM3pZxk9bz1oa7o1/eW5i8/M12m7sRx3aBaOdmm6MLfo1bnZnzrVo6WvMjlVbTQK bbRTSNVWYinOSDTUYi4qTgQAzkAySvcCAAA=
Archived-At: <>
Cc: "Carlos Pignataro \(cpignata\)" <>, "" <>, "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 05:44:59 -0000

Hi Giles,

> On Feb 8, 2017, at 12:07 PM, Giles Heron <> wrote:
> Sorry for the delay in responding.

No worries. It took me a bit of time to get back my context as well.

> At any rate I don’t think this is an issue.  As far as I can tell the mention of RFC2473 in section 4.1.4 of RFC3931 pertains to an IPv6 payload, not to IPv6 transport.  

I think this is where our disconnect is. RFC2473 is all about tunneling packets over IPv6 ("This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets”) and hence is pertinent to IPv6 transport.

> Our draft doesn’t discuss payload fragmentation - as we’ve generally assumed systems are acting as LACs rather than as LNSes (i.e. just forwarding at layer 2, not routing between a L2 circuit and a “home network”), though there’s nothing to stop an implementation that routes into a keyed IPv6 tunnel from fragmenting IPv4 packets before forwarding them into the tunnel, or performing L2TPv3 fragmentation for IPv4 or IPv6 packets.
> In terms of preference the draft is pretty clear that it’s:
> (1) ensure MTU is sufficient
> (2) use L2TPv3 fragmentation
> (3) NOT RECOMMENDED - use IPv6 fragmentation.

This (3) is where I see a contradiction. The draft says NOT RECOMMENDED but then proceeds to point to Section 4.1.4. RFC3931 which says either send a Packet Too Big or perform Fragmentation. This is the text from RFC3931

   If an IPv6 packet arrives at an LCCE from a Remote System that, after
   encapsulation with associated framing, L2TP and IP, does not fit in
   the available path MTU towards its L2TP peer, the Generic Packet
   Tunneling specification [RFC2473], Section 7.1 <> SHOULD be followed.
   In this case, the LCCE should either send an ICMP Packet Too Big
   message to the data source, or fragment the resultant L2TP/IP packet
   (for reassembly by the L2TP peer).

I am fine with Mark’s suggestion to say IPv6 fragmentation is the last resort. Alternatively, I am also fine with saying IPv6 fragmentation is NOT RECOMMENDED and an ICMPv6 Packet Too Big MUST be sent. I don’t have a strong preference either way. But pointing to RFC3931 that allows fragmentation as one of the options, while explicitly forbidding fragmentation in this draft, does not work. Does that make my position clear?