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

Giles Heron <giles.heron@gmail.com> Wed, 08 February 2017 17:08 UTC

Return-Path: <giles.heron@gmail.com>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843D129C88; Wed, 8 Feb 2017 09:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYANddLw3nQ8; Wed, 8 Feb 2017 09:08:07 -0800 (PST)
Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEE6129C36; Wed, 8 Feb 2017 09:08:00 -0800 (PST)
Received: by mail-wr0-x241.google.com with SMTP id o16so9315104wra.2; Wed, 08 Feb 2017 09:08:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4JA+CWRQ3hv6pSTEoU5UDbLbyKTf1Ew00m6qEzM6dhY=; b=WuJ4KA1kIUVB1Gn4dx/T4UVTBfLl1EsNMqCaWcCX1vGVVVi3vdal0adtlKfNFuNjUH J6Z6ThVfiREHsdiwoYkNHFk4Jwapp/CHmIaMSnJufyX1bRi2lrfGgAmI46ONTyx8YMCB Kab1MK/c65y0pRqTbynD5Qcr0Cbfo2lbZhmjHoh2yxm3TuO5UyFwyd7TXSdG/nrI+0XN 2quAMjowiuucD9qspctiLe616AHk/o0Y5ngSwcY1PQ8SabHAURFoNz83f3vVTpRN0ir4 qUlFLTLTOysp/gYgJJepAkew/O9aGbxRQO8l5HD9Q+NEtnK3oYCOiO/wvzTcNaisE8Bj 6ckw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4JA+CWRQ3hv6pSTEoU5UDbLbyKTf1Ew00m6qEzM6dhY=; b=ugTCk4gXFZX/Njr4piMLjo1obhMhBOurwx63lcXoigiHucYRXV7cOKBXwzekAttJtL CXAiZFYgd7XCYgzPLIoxfw0Bvl1qWNWu/MrPEz2m+sy+ewMmDxQ6c2z2+Ah5uRkLXxFV Cz6iW58ERM6pC99AEk0vsEAdYxeUVK15jW8+gMMbMPQO0dOmxdQsoWjT/v3eo7Lvgb9C 4c5nWNhot5jUt3HMYWsY14yVxUSbgbTC7typ21QToigenKwnIQJTOjH7PKwXdBYPbIew ejGdMx+IKhccP0cnT2Ox0juaslYz8XwQ+tP0YC/3EkUHqHQ15iXKpYMdi+kubStjbTjx s5Iw==
X-Gm-Message-State: AIkVDXIjthZ6SjtrSWjd5na334KWPsB2wSLqOQojbInx9mNcW5OkHRDahZDaRiB9Fv1xyA==
X-Received: by 10.223.177.202 with SMTP id r10mr19977355wra.94.1486573679399; Wed, 08 Feb 2017 09:07:59 -0800 (PST)
Received: from ams-giheron-nitro3.cisco.com ([173.38.220.38]) by smtp.gmail.com with ESMTPSA id c133sm4317713wmd.13.2017.02.08.09.07.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 09:07:58 -0800 (PST)
From: Giles Heron <giles.heron@gmail.com>
Message-Id: <D8644A5A-4E67-4120-8F37-1AC4E511461D@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4B420EDA-C9D0-49FA-BD53-19397E5178A5"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 8 Feb 2017 17:07:56 +0000
In-Reply-To: <147814587027.24024.3232023685298654420.idtracker@ietfa.amsl.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <147814587027.24024.3232023685298654420.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2tpext/Gp9dVr9gLrJSJ9Gh9t3A8QHEUBQ>
Cc: cpignata@cisco.com, draft-ietf-l2tpext-keyed-ipv6-tunnel@ietf.org, l2tpext@ietf.org, draft-ietf-l2tpext-keyed-ipv6-tunnel.all@ietf.org, The IESG <iesg@ietf.org>, l2tpext-chairs@ietf.org
Subject: Re: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 17:08:09 -0000

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?

Giles


> On 3 Nov 2016, at 04:04, Suresh Krishnan <suresh.krishnan@ericsson.com>; 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * 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@ietf.org
> https://www.ietf.org/mailman/listinfo/l2tpext