Re: Manual PMTUD [was ...rfc2460bis-08]

Robert Raszuk <robert@raszuk.net> Fri, 17 March 2017 23:12 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A01124B0A; Fri, 17 Mar 2017 16:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ha1JL9c_hxDr; Fri, 17 Mar 2017 16:12:48 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 141551296A4; Fri, 17 Mar 2017 16:11:51 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id w124so38753636itb.1; Fri, 17 Mar 2017 16:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9F3zUQU/lJrvO1QlYxMpZH8ah+JSZZEuWyLDvrcq8TM=; b=sadO/iGMS+DwNidtNLiCHW9/69KXU0HN21uE/tsSC988ES2lVB8hyAkAoBmjL1R7QX 0yecQ4Xx0QPl8hS1PMEZLW8lC5UhUC/y9VuM+hx8ni/VqA/LKGAh6J/a5SWpx5ZtIsor F04ZAcyS3ZfGIR5xpK7NoDNlmjLkZLgou3D09gC7vrdyM6MUT4pdk0sMb+ClolLpzw9U ogtUCsZbMWmnxdJegT+QwOKDt/9jctlDoG7kA4pQfSZ+iUeYOfSLidCMDrPiMyq1NQs0 rQg1oIIFe46NJQYGlzMDO5r79AfuHq1srauC4ChR+EYIODw1fZQQRWQ2+D21+obDBbDE 02DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9F3zUQU/lJrvO1QlYxMpZH8ah+JSZZEuWyLDvrcq8TM=; b=NVuBNyxs21NVoceog9lmTjuc6/GDHzsWLPfymP4N/Hpf1ayvuRuxcWzqtZVSETsSY9 hIL3U4gLQfTbEzEshUeNaA9ey97KFLrd2OYY/zVLuYszgSFfUeOWUpZwZjVNj4dK/ptN j5pLt3zP/f5F1ONUo/LSg5MYdxB2eD5EIfokbDeqFXPvVv4AqhWxatxVpUfJIIB07+F5 e3EEExYGooxY6m3/0KRiiK47mUdCcI6pey5YEsxRuI8sd/tyI2iFJ65Fe3NxafnO0yNy kT9xHvMIZ4Y0Kh6uTAGatriPdo22rxBkT+a6W9o/G8wXE8zVyO3QSjFJB39VVu2Aj+po o5LQ==
X-Gm-Message-State: AFeK/H2vgIyaJTkYckbtAgddguZ6VZxCk+J/kBEXYY02o0yIAcIjtUpGV2Cv90cazO2IfSgIIGRWxT2n95d3Jg==
X-Received: by 10.36.46.81 with SMTP id i78mr667836ita.39.1489792310377; Fri, 17 Mar 2017 16:11:50 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.35.207 with HTTP; Fri, 17 Mar 2017 16:11:49 -0700 (PDT)
In-Reply-To: <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <37ED3E78-B23A-4D29-8597-5A63236129B1@cisco.com> <887bd0f0-32a5-56f1-9ac9-703ecb97a760@gmail.com> <80D8FFF0-2674-48A7-A935-11681F5C5A4D@jisc.ac.uk> <A67E1C07-282B-4422-A2FF-86F6CACBD775@cable.comcast.com> <ab7c95a5-9776-24b5-7c26-4c5987d4c948@isi.edu> <ed2f5144-52fb-dda5-1fb4-62be1625b341@gmail.com> <401F52B1-3D41-4174-9425-50571B2D0B9E@jisc.ac.uk> <6d51de4b-3a9d-0f34-1cd2-5bb30caed75e@gmail.com> <DE16D91D-AE7B-4D3C-B8EA-0CB644FB96BD@cable.comcast.com> <CA+b+ER=6dXLiwvLJa84uvpVeH0daGnZ-06P16JD0UutTrbUYyA@mail.gmail.com> <2a808465-58c9-1d5e-700b-f04043b33c1c@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 18 Mar 2017 00:11:49 +0100
X-Google-Sender-Auth: V0rU-6c01-YlTpC0FLNxslQEX4Q
Message-ID: <CA+b+ERnL6FjPVRZgVzoay81gX-SkujkgTfd6EB3PM1Sq_HM9yA@mail.gmail.com>
Subject: Re: Manual PMTUD [was ...rfc2460bis-08]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Leddy, John" <John_Leddy@comcast.com>, Stewart Bryant <stewart.bryant@gmail.com>, Tim Chown <Tim.Chown@jisc.ac.uk>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a93ce7311f2054af54d52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/05O26RrMnk8Auzsr_sjEefIFdAE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 23:12:52 -0000

Hello Brian,

I do suffer from MTU issues over both intranets and Internet the same way
as you do ... or maybe even more.

As example there are transit ISPs out there who provide now extra new fancy
services of DDoS detection except they do not tell that to direct your data
stream packets to screening devices they encapsulate it in another entire
IP header to redirect it to this service.

MPLS encapsulation is also another one. While other then 6PE it happily
leaves v6 Internet alone there are active proposals in IETF to take it on
target as well.

However allowing or not allowing header insertion into IPv6 is IMHO
orthogonal here. The fact that you forbid it will only result in bigger
size encapsulation hence lower effective MTU. Services have moved to
overlay and that requires decoupling them from transport. And in some
networks service is not just fancy firewall or load balancer ... service is
basic IPv4 lookup, basic VPN segmentation or tenant micro segmentation. And
the last one even if it starts on end host it starts not in sourcing VM,
but in the forwarding host OS kernel's RIB.

MTU is a valid problem and we should work on it but I don't think it should
stop IPv6 based services and IPv6 innovation till it is solved. I can use
today SRv6 features in my data centers where I consistently know that all
interfaces are set for jumbo frames and where hopefully I do not need to
worry about MTU since hosts have much lower max MTU configured.

Kind regards,
Robert.


On Fri, Mar 17, 2017 at 11:51 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Robert,
>
> (cc's trimmed)
>
> I remember well, back when serial modems were still the norm, sitting
> in hotel rooms manually cranking back the IPv4 MTU size on my laptop
> until it was possible to establish TCP connections. Fortunately,
> somebody had written a piece of freeware that made this possible on
> Windows 95. I seem to remember having to set the MTU to 256 in Vienna,
> for example.
>
> It is really unthinkable to me to allow header insertion on the Internet
> until we have a working solution to PMTUD in all circumstances, which we
> don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB,
> and due to RFC4821 being a rarity.
>
> When this major operational problem has been solved, it will be time to
> seriously consider header insertion (including its very non-trivial
> security implementations).
>
> Regards
>    Brian Carpenter
>
>
>
> On 18/03/2017 06:06, Robert Raszuk wrote:
> > All,
> >
> > This is very interesting thread indeed.
> >
> > I think header insertion at *any* network element be it host, router,
> > service chain device is highly desired. IPv6 deployments will be much
> more
> > successful if we clear any obstacles which otherwise prevent it from
> > delivering required by customers and operators functionality.
> >
> > And I would state that this should be not only limited to one's own IGP
> or
> > BGP domain. It should be legal Internet wide.
> >
> > Today Internet as a entire system lacks tools to accomplish path
> > engineering, fast connectivity restoration, p2mp delivery of content etc
> > ... Some of those are possible with MPLS based tools however as we all
> know
> > MPLS has no NNI and does not really work across domains. Here we stand
> very
> > close to have a chance to fix it.
> >
> > And if one would forbid by spec the header insertion performed by network
> > elements what's the alternative ... IPv6 in IPv6 encapsulation which may
> > suffer with even more overhead yet will still require IANA allocation of
> > SRH type as well as TLV codepoints as effectively encapsulating network
> > element will be acting as IPv6 sender.
> >
> > Concluding I do hope that we can try to collectively make IPv6 protocol
> > flexible enough to satisfy customer and operator's requirements what in
> > turn will enrich and speed up IPv6 global adoption.
> >
> > Kind regards,
> > Robert.
> >
> >
> > On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <John_Leddy@comcast.com>
> wrote:
> >
> >> Thanks Stewart,
> >>
> >> This really supports my point and hopefully not the intent or result of
> >> the discussions here.
> >>
> >> We are trying to work through the IETF process to come up with standards
> >> and solutions that address real operational challenges faced in
> >> deployments.  For operators, dealing with legacy and migrations are a
> big
> >> challenge.
> >>
> >> Wishing these issues away and as a result having non-standard
> >> functionality in “middle boxes” that are ignored in the architecture is
> not
> >> productive.  NATs are a way of life, dark space is being deployed by
> other
> >> operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels,
> tunnels
> >> everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way
> >> down”.
> >>
> >> We are very aggressively migrating to a V6 infrastructure, but there is
> a
> >> large amount of old legacy systems/applications/services that need to be
> >> addressed.  At the same time the allure of “Cloud” attracts systems that
> >> should never be moved without being re-architected and the
> virtualization
> >> environments fully supporting V6 (both Vendors and OpenSource) – but
> they
> >> do move and vendors help make that possible.
> >>
> >> Hopefully we can keep the discussions going and keep tools available
> until
> >> we know we have solutions to deal all the activity happening outside a
> >> clean end-to-end Architecture,
> >>
> >> John
> >>
> >>
> >>
> >> On 3/16/17, 6:44 AM, "Stewart Bryant" <stewart.bryant@gmail.com> wrote:
> >>
> >>     > In another form, the answer to John is that there are no protocol
> >> police,
> >>     > so what consenting adults do inside their own networks simply
> isn't
> >> an
> >>     > issue that an Internet-wide spec can or should address.
> >>
> >>     That is not quite true, the inability to gain an IANA allocated
> >>     codepoint can make long
> >>     term private deployments very difficult, either for the protocol
> >>     squatting on a codepoint
> >>     because they could not get one allocated, or to the deployment of a
> new
> >>     protocol
> >>     legitimately allocated a conflicting codepoint.
> >>
> >>     - Stewart
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
>
>