Re: Route Information Options in Redirect Messages (updated)

神明達哉 <> Tue, 07 February 2017 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A1C412943A for <>; Tue, 7 Feb 2017 10:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 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] 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 t3Cbk5WLBvXE for <>; Tue, 7 Feb 2017 10:18:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 820CA129E05 for <>; Tue, 7 Feb 2017 10:18:22 -0800 (PST)
Received: by with SMTP id u25so96649565qki.2 for <>; Tue, 07 Feb 2017 10:18:22 -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:content-transfer-encoding; bh=iryfVGqMjGXWF7pEP1XHuZ0vW3MC43deB/JPzivwVi0=; b=AU/gIYZxyJSmNcoIDL/W8hh62k889oqg5Vpkups3RUMk2vNiNwsF+UxG8rbnwyIlUc zvvYhbZCnI+mGQbN71faRC/dh4pEWUfcHvmrG08T1IEUiPjx41mICfn3W5swv1M5itAh GiufaWLDGEOry+2EIKEMdvrR8DGPiQLDJEt3DrHQ9G/5NJjpShYDvP+hvzb7k+4ja6UF /1BSKGhL0/CaFPTOImCbrVIU3tBsK50VhjhonaOy2IkxsTZX63dLl+kfuWUiT2R/q29P jNpX2iUGjZZ+hJYIirl6/xZcSXg2lXWusfVEBP0rxYiEhBVoyzDxJiG322dmQgsXvPsG ogxw==
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:content-transfer-encoding; bh=iryfVGqMjGXWF7pEP1XHuZ0vW3MC43deB/JPzivwVi0=; b=Bikct1u+kRzBmZdtx890QCzhqSCVqBO9ZVUeNP/1nHHdnkrnUCsAFpbQr0tIfDFSWd qWVnpCZtiyTJeEh6ejlXhGKg2L22UdFEmSHHJpfkRLc0vKpKi7YS0PJE7Q79M6CEMM+o MtqrPLxwiCtQdnez571R81NlxgDeuh1A6Kfgaeszxt3x+33+TnF/HUwwR5jG2yp+n9/W jcbuM/v/HH/vcyd6Nd0mtn3shpQN0lMuwRzRdZtC7NEsX/N7rFPttG7I+axw4SG0yKyO 9WyHk/sR9HSfKqANGLfGLh1AIp96oOluVGrVj2Rx2fxUvbr2AFVuSK8mrUZqSjsAMUQP ArDA==
X-Gm-Message-State: AMke39lGRxBMPmeoX+ymqzfTb249LlLs/MNe5BsZuEzBwvsXFy3K7SGIk/VwZ1GIFwB0wUW9M7Y9isRyQ71jmg==
X-Received: by with SMTP id w123mr15635015qkc.20.1486491501560; Tue, 07 Feb 2017 10:18:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Feb 2017 10:18:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 7 Feb 2017 10:18:20 -0800
X-Google-Sender-Auth: NvpOO6V9KBoy-9FYOd34QeyCU-M
Message-ID: <>
Subject: Re: Route Information Options in Redirect Messages (updated)
To: james woodyatt <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: 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: Tue, 07 Feb 2017 18:18:25 -0000

At Mon, 6 Feb 2017 12:07:32 -0800,
james woodyatt <> wrote:

> >>>   "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,[...]

> The idea I had in mind when I wrote this is that we are leaving
> aside entirely the question of whether or not RFC 6105 has any
> issues to be identified after reviewing our draft. It’s our view
> that this draft is applicable in networks where no RA Guard function
> is deployed. We include this note in section 6 because we are aware
> that RFC 6105 exists, and our draft is relevant to the
> considerations that drive operators to deploy RA Guard functions.

Hmm, maybe I'm so dumb but I'm afraid I still don't understand intent
clearly.  Do you mean an operational assumption of this proposal is to
use it in a link where RA guard isn't deployed?  If so, it's far
better (at least to me) to just say so.

BTW, if this proposal keeps the concept of "unsolicited redirect" and
also allows the destination address of '::' to bypass the host's
validity check of whether it's really the first hop router for the
destination, then I'd rather be more interested in a discussion of
whether we should extend RFC6105 so it will also cover redirects and
filter out "rogue redirects".  That's because such an unsolicited
redirect is quite powerful and allows almost any arbitrary on-link
attacker to exploit it at almost the same level of rogue RAs.  Aside
from specific conclusion from the discussion, a discussion like that
would look good content to me for the security considerations section
of this document.

JINMEI, Tatuya