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
- Next steps on Extension Header Insertion Bob Hinden
- Syntax glitch [Re: Next steps on Extension Header… Brian E Carpenter
- Re: Syntax glitch [Re: Next steps on Extension He… Bob Hinden
- Re: Syntax glitch [Re: Next steps on Extension He… Mark Smith
- Re: Syntax glitch [Re: Next steps on Extension He… otroan
- Re: Next steps on Extension Header Insertion 神明達哉
- Re: Next steps on Extension Header Insertion Bob Hinden
- Re: Next steps on Extension Header Insertion 神明達哉
- Re: Next steps on Extension Header Insertion Fred Baker
- Re: Next steps on Extension Header Insertion Fernando Gont
- Re: Next steps on Extension Header Insertion 神明達哉
- Re: Next steps on Extension Header Insertion Sander Steffann
- Re: Next steps on Extension Header Insertion Jan Zorz - Go6
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Mark Smith
- Re: Next steps on Extension Header Insertion otroan
- Reminder, poll on header insertion closes soon Bob Hinden
- Re: Next steps on Extension Header Insertion Fernando Gont
- RE: Next steps on Extension Header Insertion mohamed.boucadair
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Tim Chown
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Sander Steffann
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Sander Steffann
- Re: Next steps on Extension Header Insertion Jan Zorz - Go6
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Sander Steffann
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Sander Steffann
- Re: Next steps on Extension Header Insertion Mark Smith
- Re: Next steps on Extension Header Insertion Brian E Carpenter
- Re: Next steps on Extension Header Insertion Brian E Carpenter
- Re: Next steps on Extension Header Insertion Mark Smith
- Re: Next steps on Extension Header Insertion Tim Chown
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion Fernando Gont
- Re: Next steps on Extension Header Insertion Fernando Gont
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion Mark Smith
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion Brian E Carpenter
- Re: Next steps on Extension Header Insertion otroan
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion 神明達哉
- Re: Next steps on Extension Header Insertion Brian E Carpenter
- Re: Next steps on Extension Header Insertion Stefano Previdi (sprevidi)
- Re: Next steps on Extension Header Insertion Tim Chown