Re: Route Information Options in Redirect Messages (updated)

神明達哉 <> Wed, 01 February 2017 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35107129A4A for <>; Wed, 1 Feb 2017 13:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10vbVrHv0uGb for <>; Wed, 1 Feb 2017 13:30:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9278C129A3F for <>; Wed, 1 Feb 2017 13:30:13 -0800 (PST)
Received: by with SMTP id k15so288016387qtg.3 for <>; Wed, 01 Feb 2017 13:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mPhQsaghE47HQCGroE40i78HIEahRfsscQDUXOWJ2r4=; b=hTSd2NJR+SB+NU7WNHOSQXwetClJ/Nr8/X51j/QVf8CwfKIM5VtqHlCiWtrPTAzqD5 4om17zlGngWNhIFkpoJFT2GD9m7/2n1JVvYuh/3HkutGYaYY2GN1/MXPfTnSCvM9xRIF 866fAnaqxSFfBEUIqOWXW745IBre/ZGnjQJyqzOXLj5pZCfdL1bRVfXtXnqcE1ShAiTW 1aYvLtQCSIHYIUwWslcdt2rpiqx9FyGo+xhxujrkO6anU9L7HKgMFheCePrZVV+JkMa8 SNXVdJg4za2n/v7SlR0vUizebkvv31lz9IOvgR5r22MMZtBdubNvx/UgvM845+ZkL3eB QWUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mPhQsaghE47HQCGroE40i78HIEahRfsscQDUXOWJ2r4=; b=oeK9p/fJJMLR0I4tjRuVW5XITBDZJQTpIN2mJ/SyEoC7STYYd04Ha3vGcivkzWFX7e Z1N4J2qtOHa9sz5rezjRwO1HKlhHIz9aqk/8LgryoWqqADbL4TRcmwHmo1HY3vAQQxEm v3LhhP1nMbqvy5YyndND1EZXsBsFf5h2h2Tb/jhKWuPmoSOn4tdztRBdbsxQBz2nnu55 O4XAUgBE7yz4c1PVviNyRmbXApoo8DEo/26I/qhY7BZvVcubHPipm8twTX4PoqTBZ8Ov R4dQDq0wO+JdSIz9zNd6neHedS6bhb8xu4YDxsWkjH9VD+tv0LKsuwXUeFhpxjSQ+dtB 1jDQ==
X-Gm-Message-State: AMke39mOJLs7MrjzTrLWyaBMLL+DqmdGskRfcysDd06w22eM/yjQjVRuOf6GY2nqezPhSuODWlb7DxxoatfSCA==
X-Received: by with SMTP id 14mr4794107qkd.86.1485984612408; Wed, 01 Feb 2017 13:30:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 1 Feb 2017 13:30:12 -0800 (PST)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Wed, 1 Feb 2017 13:30:12 -0800
X-Google-Sender-Auth: GqadlOJ6swVnIf0SBs1gL0CpOog
Message-ID: <>
Subject: Re: Route Information Options in Redirect Messages (updated)
To: "Templin, Fred L" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: james woodyatt <>, IPv6 List <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Feb 2017 21:30:15 -0000

At Tue, 31 Jan 2017 23:14:59 +0000,
"Templin, Fred L" <> wrote:

> An updated version of "Route Information Options in Redirect Messages" is now
> available (see below). This version addresses 6man list comments posted in the
> 1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man.
> It also expands on several aspects of the proposal that were not covered in the
> intarea draft. Please (re-)review and post comments to the list.

I've read the 01 version.  Here are my comments.

- general

  I'd like to understand why we need this extension.  And I'd like
  this document to explain it.  At least from the current content of
  the draft it's not clear to me.

- Section 1

   "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861][RFC2460]
   provides a Redirect function allowing routers to inform recipients of
   a better next hop on the link toward the destination.

  A minor point, but I don't understand why [RFC2460] is referenced
  here.  I actually don't see the need for it in this context.

- Section 3.2

   These Redirect messages may
   be either "solicited" (i.e., an ordinary Redirect) or "unsolicited"
   (i.e., a Redirect generated without waiting for a packet to arrive).

  If I understand RFC4861 correctly, the concept of "unsolicited
  redirect" (whether it contains RIO or not) didn't originally exist
  and is a new update in this document.  Am I right?  If so, I think
  it should clearly state this update in addition to the allowance of
  the use of RIO in redirects somewhere (probably in Section 1).  And,
  perhaps more important, I don't understand why this concept has been
  introduced.  Some background motivation/justification would be

- Section 3.2

   An unsolicited Redirect message includes a Destination Address and
   Redirected Header option that are either fabricated or derived from a
   remembered packet that was processed at an earlier time.
   Alternatively, the message could omit the Redirected Header option
   and/or set the Destination Address field to "::" (the IPv6
   unspecified address).  Such a message would still satisfy the message
   validation checks in Section 8.1 of [RFC4861].

  I suspect a fabricated or '::' Destination Address doesn't always
  work like a remembered one, since in that case the sending router is
  (at least relatively) less likely to be the first-hop router for the
  Destination Address for the receiving host.

- Section 3.3

   [...] Type "D" hosts
   process Redirect messages with RIO elements by updating
   [...] and 3) their routing tables per any RIO
   elements present.

  Does this mean prefixes in the RIO will be updated even if they
  don't match the Redirect's Destination Address?  If so, I think it's
  better to clarify that explicitly.  I also think that behavior may
  be debatable (it's probably related to the general comment of
  understanding why we need this extension).

- Section 3.3.1

  The discussion in this subsection is confusing to me.  Since a
  "router MUST NOT update its routing table upon receipt of a
  Redirect" (Section 8.2. of RFC4861), a straightforward
  interpretation of the following text would be that it violates or
  updates RFC4861:

   Such Type "D" hosts act like a host in
   terms of processing received Redirects and act like a router in terms
   of sending Redirects.

  But I guess it's actually talking about a hybrid host-router node,
  acting as a host and DHCPv6 PD client on an "external interface"
  while acting as a router for "an entourage of backend hosts" on
  internal interface(s).  I see the existence of such a hybrid node at
  least in practice (even if it's not officially defined in IETF
  documents), but I don't understand why we have to bother to mention
  it in this specification, since it doesn't seem to be specific to
  the "type D" host.

- Section 4

   The Redirect function and RIOs are widely deployed in IPv6

  This sentence could read as if the proposed extension is already
  widely deployed in implementations.  If the intent is to say that
  - the redirect function is widely deployed, and
  - RIOs are (also) widely deployed (which I'm not so sure about, but
    is probably true given Windows has implemented it).
  then I'd suggest making it clearer.  I don't have a specific
  suggestion, but perhaps stating these separately in separate
  sentences is an easy way to do it.

- Section 6

   "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a
   layer-2 filtering technique intended for network operators to use in

  I don't understand the purpose of this paragraph, especially in the
  context of the Security Considerations section.  Does this sentence
  try to say that we could use the proposed extension in an
  environment where a legitimate router can't send an RA due to
  (perhaps misconfigured) RA guard?  That's probably true, but in that
  case we should solve this problem operationally, i.e., fix the
  configuration of RA guard rather than tweaking the protocol.  And
  that doesn't seem to be a topic of security considerations anyway.
  Or does this paragraph try to say something else?  In that case I
  totally misunderstand it, and I guess it will have to be fully
  rewritten unless I'm the only dumb person to understand it...

JINMEI, Tatuya