Re: END SID Without SRH

Ole Troan <otroan@employees.org> Wed, 12 June 2019 07:29 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 6BDC51200F5 for <ipv6@ietfa.amsl.com>; Wed, 12 Jun 2019 00:29:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZkMgsTZJB_rY for <ipv6@ietfa.amsl.com>; Wed, 12 Jun 2019 00:29:45 -0700 (PDT)
Received: from bugle.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 B91BE1200A4 for <ipv6@ietf.org>; Wed, 12 Jun 2019 00:29:45 -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 bugle.employees.org (Postfix) with ESMTPSA id C956FFECC1D3; Wed, 12 Jun 2019 07:29:44 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 0E05F172B732; Wed, 12 Jun 2019 09:29:42 +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: <CAO42Z2y_D-xe+tX9n-KQYjnk5bkYXibO0Zs3E=JfAWWMZnJcSA@mail.gmail.com>
Date: Wed, 12 Jun 2019 09:29:41 +0200
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3030A68F-6CE1-4179-930C-D60BEB73063A@employees.org>
References: <BYAPR05MB42456C75487CF9283A0ED1D0AE100@BYAPR05MB4245.namprd05.prod.outlook.com> <CAO42Z2y_D-xe+tX9n-KQYjnk5bkYXibO0Zs3E=JfAWWMZnJcSA@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/4WcrWKHvI0mrdNQEFo-hd36Y7JY>
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: Wed, 12 Jun 2019 07:29:47 -0000

> Per RFC 8200's definition of host and router, the packet has arrived at the destination host, so the TCP segment should be handed up to the TCP layer for processing, and if there is no matching TCP port, a TCP reset is sent back to the source.
> 
> I don't think any other processing would be compliant with RFC 8200, and operationally it would be very confusing - the value in the packet's destination address field isn't being used by a device holding that address as a destination address.

Traditionally an address identifies an interface (or set of interfaces).
But we use addresses in many different ways. Ranging from NAT64 IPv6 prefixes that represent the IPv4 Internet to IPv6 addresses being used to represent data blocks in a video.
In userland networking one could imagine an IPv6 address representing an individual TCP application.

My understanding (which might be flawed, mind you) is that the SID is an "forwarding instruction" or represents a service. It is not the address of an interface point of attachment.

Ole