IETF Logo Mail Archive

Re: RFC2460bis and draft-previdi-6man-segment-routing-header-08

Bob Hinden <bob.hinden@gmail.com> Fri, 02 October 2015 21:49 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454C1A891A for <ipv6@ietfa.amsl.com>; Fri, 2 Oct 2015 14:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 dix_7rI_r1Tm for <ipv6@ietfa.amsl.com>; Fri, 2 Oct 2015 14:49:41 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 8D1851A8896 for <ipv6@ietf.org>; Fri, 2 Oct 2015 14:49:41 -0700 (PDT)
Received: by qgt47 with SMTP id 47so106507633qgt.2 for <ipv6@ietf.org>; Fri, 02 Oct 2015 14:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=YE8ziPyg4WPT1PakHOsr0fVYK/t67TdOWWyGRS0vfwE=; b=Sj62t1NOBh19RB+Nvfodzc9LnvDO9Zt/FfiG9HIDg5HqZRZbkElHpbS9sXrn1qisfk Y/eCZdIcpZF3+SgJRAReT2ZzQUmQOHXb0nX2kh/sq9E7SgTUX8b5sRKMnxe+6cBy/5vK xzdd9RlkVzg5qzLUbI4YANp3JQ3AE8tzIahzTXPslU/iowrYojX3OJpPOP3ErcPrRHta bJfX/Yb7Ra9kmUAnZEepO/0V6kNOzrdelHILLqQfPiLSdIF+Zht6RB/YDzc9ByB+oeW7 a67Scta2jqY82iqvrJHKSpHO50BeGVvvdnb2RjNkLwna1XeAVlahm/5sWFevvCKqF/3x Hfhw==
X-Received: by 10.140.32.200 with SMTP id h66mr21999629qgh.99.1443822580686; Fri, 02 Oct 2015 14:49:40 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 200sm5465238qhh.26.2015.10.02.14.49.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 14:49:39 -0700 (PDT)
Subject: Re: RFC2460bis and draft-previdi-6man-segment-routing-header-08
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_151EA7DE-7476-48D1-8DEF-638AC983E78B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <560EDAF6.1030906@gmail.com>
Date: Fri, 02 Oct 2015 14:49:35 -0700
Message-Id: <773A174A-6313-4E98-AB98-09A004CA132C@gmail.com>
References: <560EDAF6.1030906@gmail.com>
To: Brian Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/24XKlrol7w1me3XrECA2byjfxjg>
Cc: IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Oct 2015 21:49:43 -0000

Brian,

> On Oct 2, 2015, at 12:28 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Hi,
> 
> I'm glad to see this statement in draft-previdi-6man-segment-routing-header-08:
> 
>>   While the source routing model defined in [RFC2460] doesn't mandate
>>   which node is allowed to insert (or modify) the SRH, it is assumed in
>>   this document that the SRH is inserted in the packet by its source.
> 
> Now my reading of RFC 2460 has always been that extension headers are
> only created by the source node, but I do agree that the present text is
> not explicit on that point.

The current relevant text from Section 4. is:

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.

Where the exception is the hop by hop header (described in the next paragraph).

I also have trouble reading that as allowing any node other than the source node to add them to a packet.

> 
> I would like this to be clarified one way or the other in RFC 2460bis.

How about something like this:

    Extension headers are only allowed to be added to packets at
    the source node.

I think that was always the intent and this would be a clarification to the specification.

Bob


> 
>   Brian
> 
> --------------------------------------------------------------------
> 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