IETF Logo Mail Archive

Re: Please review: 6MAN WG Adoption call: draft-baker-6man-hbh-header-handling-03

Mark Smith <markzzzsmith@gmail.com> Tue, 20 October 2015 11:05 UTC

Return-Path: <markzzzsmith@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 51F781A88F8 for <ipv6@ietfa.amsl.com>; Tue, 20 Oct 2015 04:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=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 0-6jsV1vqo-l for <ipv6@ietfa.amsl.com>; Tue, 20 Oct 2015 04:05:47 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 ED0D51A88F7 for <ipv6@ietf.org>; Tue, 20 Oct 2015 04:05:46 -0700 (PDT)
Received: by vkex70 with SMTP id x70so7513063vke.3 for <ipv6@ietf.org>; Tue, 20 Oct 2015 04:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vfAjkUye+cEBb4/q8gTtIx7HwLV5M0m+NA0duUoxMW4=; b=U7kPEqUwCMq/33Qx8RoKK+RMq49s13i08QmXC/wAGhjEv/YiwgrBNgePdVyDaaocdk lT5bClDCaPIqGLS2hMaeufTyQaTcSGrdqEvp4pkR8AGPxTC+qnMqQJmpzCNKkove8JVv f08v0M27eILaX1L5mb1ui/KxVGChHQGL5/ILFHwic6useSsooRCqWF34TUOy0QlCvqM1 JlQBIYd53thbWTbgoF5cTYNxe1+Gkup24mDCuzKd2OTqJ3oLtMZGrR5BC/59+Rh0CXTJ PL1YvOIHL3dkSNNU+vnkrWcS0do6jaIJwJICxvXDw+GI86v7UH8GVmpBJOf7Q1YnAovd jvDQ==
X-Received: by 10.31.168.79 with SMTP id r76mr1613131vke.102.1445339146161; Tue, 20 Oct 2015 04:05:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.67.194 with HTTP; Tue, 20 Oct 2015 04:05:16 -0700 (PDT)
In-Reply-To: <5623F573.6070105@gmail.com>
References: <8BD907B6-DCCF-4F3B-917C-DC82A8D49BB0@employees.org> <5623F573.6070105@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 20 Oct 2015 22:05:16 +1100
Message-ID: <CAO42Z2z=Ge-mSmK5fzmtRki1w9YaFpnaehuy6Wy1WUygV9+1CQ@mail.gmail.com>
Subject: Re: Please review: 6MAN WG Adoption call: draft-baker-6man-hbh-header-handling-03
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/kJwGm_-g_C5stRP3B-LqYDz7u5A>
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <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: Tue, 20 Oct 2015 11:05:48 -0000

On 19 October 2015 at 06:39, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> Hi,
>
> Yes, I think the WG should adopt this topic. In particular, I support
> the key recommendation:
>
>> Packets containing the Hop-by-Hop Extension Header SHOULD be
>> processed at substantially the same rate as packets that do not.
>
> I do have a few comments on the current text:
>
>> At this writing, there are several defined Hop-by-Hop options:
>
> This list should probably mention the experimental options defined
> in RFC 4727.
>
>> 2.3.  Adding headers or options in transit
>
> I have extreme doubts about this. I believe that RFC 2460 intended to
> forbid this but was loosely worded ("extension headers are not processed
> by any node along a packet's delivery path"). When the time comes, I will
> argue  that 2460bis should correct this.

I would also agree.

The unicast source address in a packet indicates the source of all
information in a packet - the packet originator.

If a device in the network adds information, such as extension
headers, the unicast source address value has lost some if its
meaning, because it now doesn't identify the source of all of the
contents of the packet.

The packet is now a "multi-source" packet, rather than a single or
"uni-source" packet, yet only the first of the packet content sources
is available in the packet's unicast source address field.

Any mechanisms that depend on a source address identifying the single
and original source of the packet, such as PMTUD, may now fail.

Encapsulation of the packet in another when information is added in
the network allows the multiple packet sources, and what was added by
each of them, to be easily determined. There is now no ambiguity as to
which single or unicast source added what to the packet.

Regards,
Mark.


> In any case, if this section is
> retained, it needs to discuss MTU issues. I don't see why that belongs
> in the Security Considerations.
>
>> 3.  Interoperation with RFC 2460
>
> Should probably be adjusted to refer to 2460bis.
>
> Regards
>    Brian Carpenter
>
> --------------------------------------------------------------------
> 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