IETF Logo Mail Archive

Re: END SID Without SRH

Ole Troan <otroan@employees.org> Fri, 14 June 2019 17:41 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 9CDDF120151 for <ipv6@ietfa.amsl.com>; Fri, 14 Jun 2019 10:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 Gw5dWFd540wz for <ipv6@ietfa.amsl.com>; Fri, 14 Jun 2019 10:41:00 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0141200E9 for <ipv6@ietf.org>; Fri, 14 Jun 2019 10:41:00 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [217.197.164.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id B53A5FECC241; Fri, 14 Jun 2019 17:40:59 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 596BF17663FA; Fri, 14 Jun 2019 19:40:57 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: END SID Without SRH
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAO42Z2zhm_XHdt6sK23KTukOn0o2rx7O5_16C_GQ-FTwe6FJjg@mail.gmail.com>
Date: Fri, 14 Jun 2019 19:40:57 +0200
Cc: David Farmer <farmer@umn.edu>, 6man WG <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8A8F1E6-934D-4840-BB84-57811EC9DD08@employees.org>
References: <BYAPR05MB42456C75487CF9283A0ED1D0AE100@BYAPR05MB4245.namprd05.prod.outlook.com> <CAO42Z2y_D-xe+tX9n-KQYjnk5bkYXibO0Zs3E=JfAWWMZnJcSA@mail.gmail.com> <3030A68F-6CE1-4179-930C-D60BEB73063A@employees.org> <CAO42Z2yLkCRNXKp8KKnqh8VRRo6p1dx4h0-gyLBFZ=Jq0xQj2w@mail.gmail.com> <0C40BEFF-B050-40A1-BCB7-F76ADF18E3E0@employees.org> <BYAPR05MB42457C37AE7DC3F4CACC8FD7AEEC0@BYAPR05MB4245.namprd05.prod.outlook.com> <B254E985-A848-4FC4-868D-E2F04CF7E0DB@cisco.com> <104B106B-8130-4931-9DBF-2FE5C5633CB0@gmail.com> <B0D2092F-CC6E-4990-857B-E88229FA80AF@cisco.com> <277E6E14-8FD4-45A3-9350-E30B82C0FA86@gmail.com> <CAN-Dau1MDKpFrmmDFpj3s4cZYwFyB0KnWMrc-yjw_m5mO_8REw@mail.gmail.com> <CAO42Z2wgZ8gE1pTDy2xbxetdLqf8EWpKRmbi=n7qfgEALwVmVQ@mail.gmail.com> <BBB1A2A3-DE78-4E97-B193-9B6980B82358@employees.org> <CAO42Z2zhm_XHdt6sK23KTukOn0o2rx7O5_16C_GQ-FTwe6FJjg@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xGRgPjJwzcl-u_sPTEg_W9aiAj0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Jun 2019 17:41:03 -0000

Mark,

> The ambiguity and I think non-compliance with RFC 8200 is when
> dropping isn't occurring, and how to process the packet is singularly
> encoded in the DA address. This is instead of following what is
> explicitly encoded in the following EHs and transport layer headers.
> This is contrary to IPv6 host processing of DA match -> EH processing
> -> Transport layer -> Application Layer packet processing.
> 
> (I started down this path a few years ago by thinking about the
> scenario of buying a router (device) from a router vendor, and then
> running it as a BGP route reflector or server that isn't ever in the
> packet forwarding path. Is it still a "router", or is it now a host?
> Per RFC 8200, not a router, only a host, even if it still looks like a
> router (device) with a router vendor's logo on it).

To make another analogy.
Let's say I give my BGP application an IPv6 address. Not an interface, not the "host stack", but the application itself.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email