Re: Route Information Options in Redirect Messages (updated)

james woodyatt <> Mon, 06 February 2017 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03AD8129621 for <>; Mon, 6 Feb 2017 12:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 9nn1Rlf7ho7M for <>; Mon, 6 Feb 2017 12:07:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70FAC1295EE for <>; Mon, 6 Feb 2017 12:07:06 -0800 (PST)
Received: by with SMTP id e4so26310733pfg.1 for <>; Mon, 06 Feb 2017 12:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=x1byxq9evry+LbtgppibCDEV7d/mvZJSAQQqhd9JBPE=; b=Hp+e87ZFu+3LlU4SCCJcy0MS/1Raid2WP+Puwi6d+qHjrEJlZZboKMgXto12G/sHW4 MjgkYekyyHw+DPGh0CjJBFil62f9d82NwbLqUzae46y+ZLlzkB3LUCK8LCE3PNE/lO6Y noX90ZOwaEKnKm3NCYGRB5vqx0ywXfnM6rR7GrSh0/6C36JDh0GpDAHdaUXjekDAkvM2 eNNYkp45BhcU+pO57PhOO8PXSmU7E7zfsFgM7fWZK9WcpeZKxPNstCfZnDRtNGzuSMw8 ql7kEY/W3dAedkPay3viJbpV6KaWx4WltK1D8Wyo8dFLgvMvsV/Y/UuM/82MVcyP1iM4 TWLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x1byxq9evry+LbtgppibCDEV7d/mvZJSAQQqhd9JBPE=; b=ocodh3l7XcFf7+4E3+A+m6KMkM1a6X4yV0Iez8tTntM1R1bkk1b0Esdj5a78ECNcih YD6ePU0AhwEWKABYKxJZ4M7SCsXWQ9Tx/PW2gLHax5g3uP8X5jOO7Tl7ggeafOohwPfu r8qjZdVT36IXN7OwITex9oSnmta4sIeGHEbb1UaNQ1bMeHg4gWggk+Yb2akkKwl0ooPC qb64kv9vJRIc7Q8RPEU97pd9aEvITfHQRuqAnzfYEA1pM5VGdp7IjuZpkzQ+4aqjaAFa Dhan6zWlUVPaCjW5IeVEhI9X6+sLjE4pIw+aVHUeXDUbFGq6ATxGlUGsyKVITfCef1RU W2bw==
X-Gm-Message-State: AIkVDXJe/ndDr/7LDbYHFsXHZ9EjjuXP0EmI/5fzlj8dK6oof6/xIy5AsOZDXrVzXzgjKeZd
X-Received: by with SMTP id 86mr14949621pfs.90.1486411625664; Mon, 06 Feb 2017 12:07:05 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id i10sm4706319pgd.37.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 12:07:05 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E85D3CE5-5AC0-4073-8DA4-EA2837FA3FAC"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Route Information Options in Redirect Messages (updated)
From: james woodyatt <>
In-Reply-To: <>
Date: Mon, 6 Feb 2017 12:07:32 -0800
Message-Id: <>
References: <> <> <> <>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <>
X-Mailer: Apple Mail (2.3124)
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: Mon, 06 Feb 2017 20:07:08 -0000

Hi Jinmei,

I’m writing here to concur explicitly with everything Fred wrote in a his recent reply to this, and also to add my response to this particular point.

On Feb 3, 2017, at 11:51, 神明達哉 <> wrote:
>>> - 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...
>> An earlier comment on the list asked us to investigate interactions with
>> RFC6105 under Security Considerations. We have analyzed the potential
>> interactions and documented them here to the best of our understanding.
>> But, we would be happy to consider any text change suggestions.
> I can't suggest anything at this moment as I don't understand what it
> actually tries to state...for example, I don't know whether it tries
> to say "the RA Guard function defined in [RFC6105] does not filter ND
> Redirect messages" is considered an issue to be resolved/mitigated or
> a good effect of this proposal.

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.

--james woodyatt < <>>