IETF Logo Mail Archive

Re: Comments on draft-herbert-ipv6-update-dest-ops

Ole Troan <otroan@employees.org> Mon, 20 August 2018 16:33 UTC

Return-Path: <otroan@employees.org>
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 0C9591286E3 for <ipv6@ietfa.amsl.com>; Mon, 20 Aug 2018 09:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pgcy_ZINs0Bl for <ipv6@ietfa.amsl.com>; Mon, 20 Aug 2018 09:33:21 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595C6126BED for <ipv6@ietf.org>; Mon, 20 Aug 2018 09:33:21 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id F09AF2D4FAB; Mon, 20 Aug 2018 16:33:20 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C0CF9430564; Mon, 20 Aug 2018 18:33:18 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Comments on draft-herbert-ipv6-update-dest-ops
From: Ole Troan <otroan@employees.org>
In-Reply-To: <f0be4512-b05c-0975-97e2-454a500c8c37@joelhalpern.com>
Date: Mon, 20 Aug 2018 18:33:18 +0200
Cc: Tom Herbert <tom@herbertland.com>, "C. M. Heard" <heard@pobox.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <693EA4C7-5A76-4685-ABC5-E8579A1F8B5C@employees.org>
References: <CACL_3VF+EoKOEF-TkB3179UsmN_Yhaqt60jh_h2d2GLnE0EWDA@mail.gmail.com> <CALx6S356TVnbnZ_zp5+aK_x-DmMJUTidw0Wzbc3Tn=cscTd7VA@mail.gmail.com> <CACL_3VGUUs1FS4Qog6pzJ2WZyir2-keEVZTU6opzXQ4t0M-XUw@mail.gmail.com> <CALx6S35q5EqZt26KSPTGHBXZpzaNYyFBO9UxVNsi4is1BxUHrQ@mail.gmail.com> <CACL_3VGfMj6DjAWsxib6Hw_x=5X3CWASKU1oiGqvFdksDuFXDw@mail.gmail.com> <CALx6S37c_WCa+A3aD7X-rq-kj_RTGfGur8HVekt_LWTg6Os18g@mail.gmail.com> <F01E55CE-0E88-47BF-A30B-B83A0B7F5F0F@employees.org> <f0be4512-b05c-0975-97e2-454a500c8c37@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9ltfNea3xD5qMuZ_JDNu7SnbfhM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 20 Aug 2018 16:33:23 -0000

Joel,

> I can see two sides to this.  On the one hand, we want tunnel termination logic to be fast and effecient.  Requiring that it have only the necessary information, and not other random things, is part of our tool kit for achieving that.
> 
> On the other hand, the outer IP header, in the case of v6, is clearly destined for the tunnel terminator.  And the IPv6 spec is very clear that certain kinds of processing for IPv6 destination options are mandatory at such a destination.  For example, retunring an error if ther eia an unknown IPv6 destination option with the bit set to force errors.
> 
> Clearly, doing the checks for that is more expensive.  Equally, it seems to be clearly required by our current specs.

Yes, to both.

Best regards,
Ole

v2.23.0 | Report a Bug | By Email