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

Suresh Krishnan <> Fri, 24 February 2017 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC05F12950E; Thu, 23 Feb 2017 20:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KhSmjP0cUaHe; Thu, 23 Feb 2017 20:29:11 -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 D5575129512; Thu, 23 Feb 2017 20:29:10 -0800 (PST)
X-AuditID: c6180641-c53ff70000000a06-8d-58af7040d9f6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F9.D4.02566.0407FA85; Fri, 24 Feb 2017 00:29:05 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 23 Feb 2017 23:29:08 -0500
From: Suresh Krishnan <>
To: Giles Heron <>
Thread-Topic: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Date: Fri, 24 Feb 2017 04:28:48 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXRPoK5jwfoIgx07zSw+vdvBYtG8dT2b xf/WlywWT4/OYLSY8Wcis8X+Ax1sFnt+/WF3YPeY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZ llqkb5fAlbFtylrmgg7Nio8HUhsYGzS6GDk5JARMJF73zGbvYuTiEBJYzyhx6ch9ZghnOaPE lNe3mUGq2ICqNuz8zARiiwioS3TM2cYEUsQs0MQscev3MXaQhLBArsTUz/vZIYryJL71zmWE sN0krs/oAYuzCKhKXG15zApi8wrYSzzb8poNYttLRom2ORvZQBKcArYST4+0gTUwCohJfD+1 Bmwzs4C4xK0n85kg7haQWLLnPDOELSrx8vE/sKGiAnoSD+/dZIWIK0nMeX0NqIYDqFdTYv0u fYgx1hK9O/dCjVSUmNL9kB3iHkGJkzOfsExgFJ+FZNsshO5ZSLpnIemehaR7ASPrKkaO0uKC nNx0I8NNjMCIPCbB5riDcW+v5yFGAQ5GJR7eDQfWRQixJpYVV+YeYpTgYFYS4Z2waX2EEG9K YmVValF+fFFpTmrxIUZpDhYlcd7rIffDhQTSE0tSs1NTC1KLYLJMHJxSDYyzZnxZqVjnKbpO 6vwS848Xp51fzRGhfWaW6qmXv2bHys8+N7W7Smup5JM39m/Vs9TnVfKudFB1+GojdC76zJlr ebnN2XOcmdZuEhfkTGcwWHKNS1l78kn2LRFTHj1ieZXqYSm7btv3vmVTV1RWr92WadF08JfI recPip3FExz/3FuWqnfOastSJZbijERDLeai4kQAsciAtMQCAAA=
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: Fri, 24 Feb 2017 04:29:13 -0000

Hi Giles,
  That sounds good to me.


On 2/23/17, 1:43 PM, "Giles Heron" <>; wrote:

    Hi Suresh,
    On 23 Feb 2017, at 00:44, Suresh Krishnan <>; wrote:
    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.
    Sure, RFC2473 is about tunnelling packets over IPv6.  But section 7.1 (the section referred to from section 4.1.4 of RFC3931) is about carrying IPv6 payloads over IPv6 tunnels.   Our ref to section 4.1.4 of RFC3931 from section 5 of our draft is related to
     potential IPv6 fragmentation issues when tunnelling Ethernet frames.  So perhaps we should just drop the reference - since it’s causing confusion?
    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).
    right - and that text is specific to IPv6 *payload*, correct?
    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?
    right - so as I say, maybe we just drop the ref?