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

"Carlos Pignataro (cpignata)" <> Tue, 21 February 2017 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 381A71293E4; Tue, 21 Feb 2017 06:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v3UDLxWVSpPo; Tue, 21 Feb 2017 06:42:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C374D1294C0; Tue, 21 Feb 2017 06:42:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17318; q=dns/txt; s=iport; t=1487688138; x=1488897738; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wWUNgHOiv0KPhfdrznA9EEJttUf5sMvMUWxtNLFUUFk=; b=PdgjpFTyearWS36lt2aknefPjAA4b1TjHWSG3ZTODtW0XuqWLbxQiTrd oOTR9MdpjjnzJFpHdkqeimNA7RqyFe2Mngg+0RGw/6dUFY+NKt5LzgmZW PoKKtRT6M+eZRjha/OlbMmAbZdueQLSY1BS5zKSH60t0nXJlp2JJD6H8m Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAgBgUaxY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1SKCJF3iCuHfIUsgg0fAQqFLkoCGoJTPxgBAgEBAQE?= =?us-ascii?q?BAQFiKIRxAgQBASFLCxACAQg/AwICAh8GCxQRAgQOBYlWAxUOri2CJoc4DYQTA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFCIJiglGBVREBgyIugjEFiQ+MUYV?= =?us-ascii?q?uOgGGc4cOhBuBe4UbiXiKQYRIhBoBHzh4CFMVPhEBhDgdGYFIdQGIYYEhgQ0BA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.35,190,1484006400"; d="scan'208,217";a="209329557"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 14:42:17 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v1LEgGCR007941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 14:42:17 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 09:42:16 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 09:42:16 -0500
From: "Carlos Pignataro (cpignata)" <>
To: Mark Townsley <>
Thread-Topic: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Thread-Index: AQHSgi3rQByL0vOCCUq1aVjh0x6Kx6Ffv2aAgBQxcoA=
Date: Tue, 21 Feb 2017 14:42:15 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_09370626A6104E2BBF88945E0B7D0FE7ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, Suresh Krishnan <>, "" <>, 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: Tue, 21 Feb 2017 14:42:20 -0000

Hi, Suresh,

Did you get a chance to see the responses from Giles and Mark, regarding your Discuss on this document?


Carlos Pignataro,<>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Feb 8, 2017, at 1:20 PM, Mark Townsley <<>> wrote:

RFC 4623, section 5.1 essentially says "Try not to be in a situation where you must fragment. If you must, try to use native PW fragmentation and reassembly if available. IP frag as a last resort." - which I think is the spirit of what you are trying to say here, though the all caps in #3 may be coming across as overkill to the reviewer (as if v6 host frag is somehow evil or broken - it's not, it's just hard for network gear that isn't used to this kind of thing, and we'd rather avoid it).

- Mark

On Feb 8, 2017, at 6:07 PM, Giles Heron <<>> wrote:

Sorry for the delay in responding.

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

In case 3 (as in case 2) the ingress router will fragment and the egress router will reassemble.

or have I missed something?


On 3 Nov 2016, at 04:04, Suresh Krishnan <<>> wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-l2tpext-keyed-ipv6-tunnel-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


* Section 5
I am having a hard time seeing how fragmentation is expected to work

  It is NOT RECOMMENDED for routers implementing this specification to
  enable IPv6 fragmentation (as defined in section 4.5 of RFC2460) for
  keyed IP tunnels.  IP fragmentation issues for L2TPv3 are discussed
  in section 4.1.4 of RFC3931.

And that specific section of RFC3931 recommends using RFC2473 to tunnel
the packets which again ends up using the RFC2460 fragment header that
this draft is trying to forbid.

So, can you please clarify exactly what happens when the size of the
packet to be tunneled exceeds the MTU?

L2tpext mailing list<>

L2tpext mailing list<>