IETF Logo Mail Archive

Re: [spring] How CRH support SFC/Segment Endpoint option?

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 24 May 2020 23:48 UTC

Return-Path: <jmh@joelhalpern.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 BC0113A0B74; Sun, 24 May 2020 16:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 IXCrssUw1kdd; Sun, 24 May 2020 16:47:59 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB333A0DFB; Sun, 24 May 2020 16:47:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49VcNZ4MbGz1ntHZ; Sun, 24 May 2020 16:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590364078; bh=7MpWpBfOz8A3GSZj+6YUb1jgSxyWwsFkOiizXPa2TSI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LJrJ3mZWD4PzNdHiMf3h5Chj4Kzj6/si+CkuEmN3ATcs/dbDDsNivuVeFYNgFxFpS SOB4Ac49AlXz2i/EHIZKUA94bqYC2rBmDZotRKLH6wIxtreZnFKgcD/glslkVjrHK9 TlLfsnMb/oD7nVXPC1uLnv596A8sGLxP6bxWxrRE=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49VcNY5w4tz1nsN9; Sun, 24 May 2020 16:47:57 -0700 (PDT)
Subject: Re: [spring] How CRH support SFC/Segment Endpoint option?
To: Robert Raszuk <robert@raszuk.net>
Cc: "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
References: <C7C2E1C43D652C4E9E49FE7517C236CB02A2CD12@dggeml529-mbx.china.huawei.com> <DM6PR05MB63482CFA4D5AB938D5A4B818AEB40@DM6PR05MB6348.namprd05.prod.outlook.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A37DC6@dggeml509-mbs.china.huawei.com> <DM6PR05MB63489256A7C8357BEF526EE2AEB20@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMGLj9OgFCcsB21oWXbcCqHZ7B4qTvCcrK9LXuKDYVu_vQ@mail.gmail.com> <CALx6S36yJ5CS6ykQhd_sW3T6=PjVJNOqewtg2joUtHnbsZPxSA@mail.gmail.com> <CAOj+MMHoTGBg4inhMqoK2DN053KnJ7CuCsg0zro33bt07vUR6Q@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <bc413ba5-2c03-b018-e31f-2e33c5b3c2fb@joelhalpern.com>
Date: Sun, 24 May 2020 19:47:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMHoTGBg4inhMqoK2DN053KnJ7CuCsg0zro33bt07vUR6Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1OcKuXuJIDloXG30pww7R8CPmxE>
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: Sun, 24 May 2020 23:48:05 -0000

There can be a destination options header before the routing header. 
And there can be one after the routing header.  The former is examined 
at every addressed destination.  The later is examined when the routing 
header reaches its final destination.
That is the RFC 8200 defined behavior.

Yours,
Joel

On 5/24/2020 5:33 PM, Robert Raszuk wrote:
> Hi Tom,
> 
> Thank you !
> 
> That confirms my understanding ie that DOH will be examined at each 
> segment endpoint hop if DOH is present.
> 
> So just like PSSI or TPF suggest a build in filtering (for example by 
> target ID) is required to avoid misuse.
> 
> Kind regards,
> Robert.
> 
>     Robert,
> 
>     Look at Destination Options before the routing header in RFC8200.
>     These are intended to be processed at every intermediate destination
>     in the routing header and precede any fragment header.
> 
>     Tom
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email