IETF Logo Mail Archive

Re: [Int-area] Route Information Options in Redirect Messages

Tomoyuki Sahara <tsahara@iij.ad.jp> Thu, 12 January 2017 07:28 UTC

Return-Path: <tsahara@iij.ad.jp>
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 5E3B5129474; Wed, 11 Jan 2017 23:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.2
X-Spam-Level:
X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp
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 y1REjHD6a70o; Wed, 11 Jan 2017 23:28:31 -0800 (PST)
Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 104321270B4; Wed, 11 Jan 2017 23:28:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=tsahara@iij.ad.jp;s=omgo2;t=1484206107;x= 1485415707; bh=MmYVYqnvZDJviW/WJUhjbswD7vFi3Aq6gCU103/g0yE=; b=Vv2O7/vVTSXQLMMW 5kr+73bJ4IIb2Xi8z6VymBDcUj3eI12HAtOqq+zcnJNsplLcud/n6Zh/2s5OJSPcRJh5EemA5jo8n AGVC8GAvh0Kud92V9I/HsMaX2vY8xfwrWvkl2i52KaK4ZwoKVXRUUqVub8heY4DDw8sEd4175Qcl0 5NhZZT4FNya8dfgp+BSGLK4rMSFehK80D3435fiNBLk5PhHVH7DyuHio1Av9s6CEc6qwMxI701pr3 c98PUuyQzLTzaD6Hl8gqfQ9yZ4Qmfz7W6IQM+MpnUAecqbzI4r0WMt2SVuP//3nIRbdEHvMz7tVwS Z+Gt5wBa2bJ/OhyRyA==;
Received: by omgo.iij.ad.jp (mo900) id v0C7SRps012210; Thu, 12 Jan 2017 16:28:27 +0900
X-MXL-Hash: 5877301a50347d82-0feda34deffb7ae393f185bb3107c5c694651757
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [Int-area] Route Information Options in Redirect Messages
From: Tomoyuki Sahara <tsahara@iij.ad.jp>
In-Reply-To: <d12b5166bf0b41f1b85021f6e1410b16@XCH15-06-08.nw.nos.boeing.com>
Date: Thu, 12 Jan 2017 16:28:25 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <113477DD-778C-4C0E-899C-A75C8D04A878@iij.ad.jp>
References: <b0d15d2e8b3e414abf4e87c60d39e252@XCH15-06-08.nw.nos.boeing.com> <AEE70A51-720C-4957-AA1C-8D213EB366D8@google.com> <d12b5166bf0b41f1b85021f6e1410b16@XCH15-06-08.nw.nos.boeing.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/x7IqbdPZXt5AoP6cMQ74noz-4sk>
Cc: INT Area <int-area@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 12 Jan 2017 07:28:36 -0000

Hi, Fred

> If the concern is for backwards compatibility with legacy deployments,  the
> proposal honors backwards compatibility per RFC4861. What do you think?

From the section 3. of the draft:

      "The contents of the Reserved field, and of any unrecognized
      options, MUST be ignored.  Future, backward-compatible changes to
      the protocol may specify the contents of the Reserved field or add
      new options; "

RIO options in Redirect Message are not "unrecognized" options
but are "not specified to be used with Redirect memssages". The
next pragraph in RFC4861 is better text to be quoted:

   The contents of any defined options that are not specified to be used
   with Redirect messages MUST be ignored and the packet processed as
   normal.  The only defined options that may appear are the Target
   Link-Layer Address option and the Redirected Header option.

   ( https://tools.ietf.org/html/rfc4861#page-74 )

Once the draft is published as a RFC, it shall update the second sentence.


Thanks,
Tomoyuki

v2.23.0 | Report a Bug | By Email