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

Giles Heron <> Thu, 23 February 2017 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662CF12968B; Thu, 23 Feb 2017 10:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oIlNY0tyehd4; Thu, 23 Feb 2017 10:43:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4D771295F3; Thu, 23 Feb 2017 10:43:20 -0800 (PST)
Received: by with SMTP id x71so5970572qkb.0; Thu, 23 Feb 2017 10:43:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=e4HUsc1xR93Wb9keeQ11NPfkNI4UAK0Mn19fwabDzjc=; b=WbWcRHOkxRDsVNiLF43zeTtECSECItFVRjVksmPeavNdMEIoF4zdx3dvRjXmoH0If1 PG/jRT9gx4uy35adCCl6CXmHpqH0E/GxZpTdX0LplLg0tyMHiM1Y2209zJ6SSNKM9RJW ZymHUb4kZ+W5C1sr6Zo3DhUzoJcE6iycNlqftOgG1X1abZ9eZwlOgzemNEaCdRh4Zsze C+Y1BlXwv97yHUSl9LWw1xO7YSp/1k78Ugb9+R4MSWLF2fq4HJ5tJrAdVtORVTAfsM+I KheOnbBzdJQ3zkbJJSi+UKvw5YDL0JjLiXfG01CkQHcOIxkwsjyfuXyZj6UsQ3UDQyeN C2FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=e4HUsc1xR93Wb9keeQ11NPfkNI4UAK0Mn19fwabDzjc=; b=nMGD5WWAGBtbULJB8WtOQVXRSi7IWitGEJWNBfWaa1nxLrlPCaNuyB7FXow+thntsS kQeQh4DF9MOSMjRBrdYGUINs7zZxQ0s1AqAYm8++lJDcncbjLrq0eCbTSVvAjzO56jQ+ fpbUl/2eVPE1CvefVdqhmwaCZD6LzwWErJoDvgTyFDHfeS42MhOX+zGNRKiBGAz5Rjnb Wlsy5g1YhNelFPdE1ESm2FOOzdEIb2Jh3M5ZavzJOJjHoKASQQJMNw9ewnbkZXQYxOV4 NGWZ/VeP8sg7ZYda3I5CJwUol7IfXO6DfvvvHhgjJjOnNeAYuzf8LaTKWme9mYPgAPwI dm4A==
X-Gm-Message-State: AMke39ntm1Nc+Nv8ZabB5p3XnzoGXivE7d52Y7NpEzty4BiT1aEBzBN9a35tvNUAe4Wa+w==
X-Received: by with SMTP id d206mr36260731qke.233.1487875400069; Thu, 23 Feb 2017 10:43:20 -0800 (PST)
Received: from ([]) by with ESMTPSA id u6sm3174841qkh.66.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 10:43:19 -0800 (PST)
From: Giles Heron <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_770E01B6-9AB5-4B23-9034-5610C061B8FC"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 23 Feb 2017 13:43:17 -0500
In-Reply-To: <>
To: Suresh Krishnan <>
References: <> <> <>
X-Mailer: Apple Mail (2.3259)
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 18:43:23 -0000

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?


> Thanks
> Suresh