Re: Next steps on Extension Header Insertion

Fernando Gont <fgont@si6networks.com> Thu, 03 November 2016 03:25 UTC

Return-Path: <fgont.mobile@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 40BAB1294C3 for <ipv6@ietfa.amsl.com>; Wed, 2 Nov 2016 20:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rlYqsh8HS_v1 for <ipv6@ietfa.amsl.com>; Wed, 2 Nov 2016 20:25:08 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 AB7C612940F for <ipv6@ietf.org>; Wed, 2 Nov 2016 20:25:08 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id x186so29476842vkd.1 for <ipv6@ietf.org>; Wed, 02 Nov 2016 20:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Vyfogtx+fqE9oNXQ26Mk/hlWv3wCQAiyDotnGpxjQbY=; b=LOmr3WJnpd4cynSa4hy4Kh7cfp+h/2PiAHTn+crOQo2iEDEe9G/g/XsoOxhXThLtak l569xieZWZ3f8zb7q6+T8Uaxcbwch9DfYoRP/WSORDVGMhhl3SHw6H5koX+rMXJkOMJa xUOCw08RFW7tz4ApdKNntgR5IIvAE/TRh7N/tmKrXFJnBynob8Ge4kxD3OtKN76n0bB/ v2nL4otL67ylRAXjdMUfFuPkFjbzbr3m40qGG8KmqDfc9Cpq6Tj00O2+G/9udqTlWwvg LDHzGtVBTEuAuoRQzw2vL0a9AzKAK9PbUaTd3m9Yh3nvs+DuGezr6T33lDBUE7a1J5Yy mPyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Vyfogtx+fqE9oNXQ26Mk/hlWv3wCQAiyDotnGpxjQbY=; b=Kc4RpvM7yI97DeG+HCRbs9tzxU12SeUjGG1jzCbX1WOyu2ujLhAgEDCQblmgKuctai l2VR2enN0t8kcEOPQCDzj0lX+C4dPrDTnJM9gQukX3A0mTZpimzAWUSXfqbCQ/eg1/zr OQ4yRH0lYX64V5fYcTab8E4s5ly5QXXm3ohwqfvSnJ+WJGuHJY5jhKWYNJt5lO4Yvqyh Au4JJ1uVFgq7rfnFToDjTra5wF8k9s2pt095gpx3RjjISZOGE+3pTETl13W+GqlnVPb7 vq4CYkAZ1wBTsxb81yq7SRIn9FsPoD+Zg/5Z6cLMUgRcGX88uqUi/R7vkLiGmyAo4NsY n7NQ==
X-Gm-Message-State: ABUngvcMCh1yP1wSKqg+0LxtmxqM3R9N28K3LLPWL+uOPZUkAlWjEVCWmZoOd6zRTyt8hHjLohncoNUzgNX5Xw==
X-Received: by 10.31.129.12 with SMTP id c12mr5253932vkd.67.1478143507762; Wed, 02 Nov 2016 20:25:07 -0700 (PDT)
MIME-Version: 1.0
Sender: fgont.mobile@gmail.com
Received: by 10.103.109.134 with HTTP; Wed, 2 Nov 2016 20:25:07 -0700 (PDT)
Received: by 10.103.109.134 with HTTP; Wed, 2 Nov 2016 20:25:07 -0700 (PDT)
In-Reply-To: <3C56AA77-18E4-4254-BB6A-A447CE115392@employees.org>
References: <B291E9E6-A803-423F-BFA5-87A74DCFB784@gmail.com> <dfe00826-1bcd-80ae-e6dc-7763c506cbe4@si6networks.com> <9CA73891-B4FA-47DF-82E1-A4867DBC6A3F@steffann.nl> <3C56AA77-18E4-4254-BB6A-A447CE115392@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Date: Thu, 03 Nov 2016 00:25:07 -0300
X-Google-Sender-Auth: u3vKvnukCqk7ImKt-vIuQkCLGlQ
Message-ID: <CAG6TeAtJdUua3saSGz0SX7DW6hwf74yAexpnfYoP1bg6v1eywA@mail.gmail.com>
Subject: Re: Next steps on Extension Header Insertion
To: Ole Troan <otroan@employees.org>
Content-Type: multipart/alternative; boundary="001a114583e8b51a2b05405d1a31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VubfMkuyfWqkwuo9ozMWVCZ9F64>
Cc: 6man WG <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 03:25:10 -0000

El 3/11/2016 00:39, <otroan@employees.org> escribió:
>
> >> To make my point clear: I'm rather agnostic about SR, but I'm against
> >> ambiguity in a std track documents, particularly when behind such
> >> ambiguity there's the potential for a lot of problems.
> >
> > Well said. Ambiguity is harmful here and will cause serious problems
later.
>
> There is absolutely no evidence that the lack of normative text here has
led to any problems...

Because nobody before proposed or pushed into code the idea of mangling
packets in the middle of the network with IPv6

> Regardless, it is also impossible to specify all the things creative
people shouldn't be allowed to do. And that's probably not the purpose of
standardisation either. It is to specify enough to make implementation
interoperable.

If IPsec, Path-MTU, and normal troubleshooting could all break as a
resultar of this, yes, we do have a say, and we should say so.

We should clearly state what the architecture is, including whether packets
are meant to be end2end, or  expect anyone to do their own thing.

If I read the v6 spec, at the very least, I want to be able to tell whether
I can expect that whatever I received in a packet was produced by the
source, or whether it could have been produced by the network itself. Since
a layer-3 protocol is supposed to be something quite simple, and such
question is core to the architecture, I'd expect the spec to answer the
question.

Clearly, it was obvious to everyone that intermediate systems don't mangle
v6 packets  But since all this discussion seems to indicate it wasn't so
obvious to everyone, the spec should make this important point very clear.

I'd say that some of the options given in the poll are rather misleading...
Because truth is that as of today, header insertion is not allowed. So any
discussion about "preferred way of doing eh insertion" seems like an
implicit update/"relax of the spec" to me.

> I'm just trying to point out that we shouldn't blow this issue out of
proportion. Whatever we end up doing here, it is hard to see it being
particularly important, nor have any big consequences.

Is that a politically-correct way of saying we're just irrelevant?

Cheers,
Fernando