IETF Logo Mail Archive

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

joel jaeggli <joelja@bogus.com> Fri, 02 October 2015 22:27 UTC

Return-Path: <joelja@bogus.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 924901A8A56 for <ipv6@ietfa.amsl.com>; Fri, 2 Oct 2015 15:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 fVIrKJtH-DTn for <ipv6@ietfa.amsl.com>; Fri, 2 Oct 2015 15:27:08 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 AE9A11A889D for <ipv6@ietf.org>; Fri, 2 Oct 2015 15:27:08 -0700 (PDT)
Received: from mb.local ([IPv6:2601:1c0:c102:22fb:b44b:2d95:8134:de3a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t92MR6Wd007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Oct 2015 22:27:07 GMT (envelope-from joelja@bogus.com)
Subject: Re: RFC2460bis and draft-previdi-6man-segment-routing-header-08
To: Bob Hinden <bob.hinden@gmail.com>, Brian Carpenter <brian.e.carpenter@gmail.com>
References: <560EDAF6.1030906@gmail.com> <773A174A-6313-4E98-AB98-09A004CA132C@gmail.com>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <560F04B9.3060403@bogus.com>
Date: Fri, 02 Oct 2015 15:27:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Thunderbird/41.0
MIME-Version: 1.0
In-Reply-To: <773A174A-6313-4E98-AB98-09A004CA132C@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="8J3KtoUV9PKr0JtaKAJ1qSbjVk4WC5t0G"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/8OGisNT9up3-I6oRmbaxttEHuKs>
Cc: IPv6 List <ipv6@ietf.org>
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 22:27:10 -0000

On 10/2/15 2:49 PM, Bob Hinden wrote:
> Brian,

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

it's very hard to conceive of disallowing on-wire fragmentation without
precluding the addition of headers on intermediate hops.

encapsulation however has no such problem and conveniently tells the
network where the wrapper should be sent to be processed.

> Bob
> 
> 
>>
>>   Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> 
> --------------------------------------------------------------------
> 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