IETF Logo Mail Archive

Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 06 March 2012 21:08 UTC

Return-Path: <brian.e.carpenter@gmail.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 9097B21E80BF for <ipv6@ietfa.amsl.com>; Tue, 6 Mar 2012 13:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.429
X-Spam-Level:
X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrW0pTO0mhC5 for <ipv6@ietfa.amsl.com>; Tue, 6 Mar 2012 13:08:38 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0D21E802A for <ipv6@ietf.org>; Tue, 6 Mar 2012 13:08:17 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3481258wgb.13 for <ipv6@ietf.org>; Tue, 06 Mar 2012 13:08:16 -0800 (PST)
Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.180.86.105 as permitted sender) client-ip=10.180.86.105;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.180.86.105 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com
Received: from mr.google.com ([10.180.86.105]) by 10.180.86.105 with SMTP id o9mr27285375wiz.4.1331068096121 (num_hops = 1); Tue, 06 Mar 2012 13:08:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U1VFWVKvtlaxAxBvm09SY/pZA+xF+qrkK1+QGKVbRqM=; b=vKXfuAqQHqAVUN8w3ckFLiT2kpb2KStEJ2h0t08ygrNLgpIR8tdGnO7A7Q7hgdZKwN JlRashxfaJQ/ZXzAzfxYtNsgkK5KZpU0Ntyfey7aKeirXSgjegtf8SrHWSaO7vXdF8f1 ojPQKT05O5FbyapzZq4OFDEBTTyVKXaA/1FVdD9+x7EkUHggFjyhQ9aPgmoavps4w3Tu NZhydQrg5LxJey8HK+a2+9dgyt1sVi+Cti0F+9eNEVm9O4uF32hEwrW9xEHqsbujhp3R tsFDHDb5QAr1snmu8Da+FFDEoaYeA7Xh/ZRBuS5Pvsbr2qL5SdbNOcaD1d6BMPCdsAOg fKOw==
Received: by 10.180.86.105 with SMTP id o9mr21615383wiz.4.1331068096078; Tue, 06 Mar 2012 13:08:16 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id fl2sm84312305wib.4.2012.03.06.13.08.13 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 13:08:15 -0800 (PST)
Message-ID: <4F567CB8.6000902@gmail.com>
Date: Wed, 07 Mar 2012 10:08:08 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: sreenatha <sreenatha.b@huawei.com>
Subject: Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt
References: <mailman.55.1330977606.16998.ipv6@ietf.org> <000701ccfb53$e5517540$aff45fc0$@com>
In-Reply-To: <000701ccfb53$e5517540$aff45fc0$@com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 06 Mar 2012 21:08:38 -0000

Hi,

> As we mentioned in the draft, only Jumbo-gram and MLd options apart
> from the padding options can be inserted in Hop-By-Hop header. 

I don't understand this statement. MLD is a subset of Router Alert,
and various other HbH options are defined:

0x26 Quick-Start [RFC4782]
0x7  CALIPSO [RFC5570]
0x63 RPL [RFC-to-be draft-ietf-6man-rpl-option]
0x1e (etc.) Experimental [RFC4727]

I don't think we can assert that none of these need to be
processed at the source without analysis, which is of course
impossible for the experimental values or for unknown future
options.

I also think that stating that Router Alert doesn't need
to be processed at the source is dubious. If the source
is acting as both a host and a router (e.g. in an Internet
Connection Sharing scenario), you would be courageous to
state that there is no case in which node in its role as
a router should look at a Router Alert that it set in its
role as a host.

It seems reasonable to state that implementors MAY omit
processing at the source, if and only if they know by
construction that no HbH option that requires local processing
is created elsewhere in the host stack. But even so, they need
the code to skip over the HbH extension header if present.
We cannot replace

   if HbH header present, skip to next header
by
   No-op

Regards
   Brian Carpenter

v2.23.0 | Report a Bug | By Email