Re: Route Information Options in Redirect Messages (updated)

james woodyatt <> Tue, 07 February 2017 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42389129471 for <>; Tue, 7 Feb 2017 12:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, 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 4jYesz0vb8Rb for <>; Tue, 7 Feb 2017 12:40:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B12B12940C for <>; Tue, 7 Feb 2017 12:40:22 -0800 (PST)
Received: by with SMTP id f144so35707135pfa.2 for <>; Tue, 07 Feb 2017 12:40:22 -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=EThuAuZb9hBTBV6ThlrIgHZDAW66WXUuIk5QmDLEoJw=; b=BYZHyGj0wfCegmk21CtKi3M59purmRuxnXntQv/9raDmf0LFxcAGnpJMymgb9DulXF t391B+1MhMhRA3K/nZ8su3wgs1Lc++Nx8G0hHdO7bi7o09j1/M7L3H666g7DG8dzCZDO YT/w+jk5Jt0r0QJptmbsR7P4LEnZxAWANaV8UvBxCh3fDjjBcvZzMvPSt4sG7fpnIcV9 68qFMUqADaI8vQkbmNBjO0f9ePcixxvpabsuYNb3oherLe2ZCX3E6xbcgkDrAZ80HtYU 46uYMsOBXjtubbLCCGWP0WTrEfyXUyMvnyx3O/NgsEAjzPu38MIR0H7Ne25y2yQ03O7r USzw==
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=EThuAuZb9hBTBV6ThlrIgHZDAW66WXUuIk5QmDLEoJw=; b=ZnWM5GA8sqqRpP9hMVramalHosdM3cN7A1+K+o0vrq7QHhM8VEZsPE855cMkYdCn/G vd8XRdRx9CnWraWPX0/p8LHATT0biVqRm+/MOiPcmUs/R5iLfe0xIZbPJ8+Iz9DgdHu1 K8by18fR+pbMU77ACpJ2Crgng+J17MvtDwsY89ffr5cdugPFLYiPdQVvZ6jN6yptm3r9 0PVbCEpwA6qcTCNO2+F0c8ztJ78eNu0wk5uK6gQ2h88QTyyCrf0sDa/aRgB34JZPWfjw 10GlMPFq+x1aXDu3og41hfYngMN3+O605veiUdSsIpncu15mc8Fs52/l4EDxxKFQKzk1 iEuA==
X-Gm-Message-State: AIkVDXKHBeoWpkVVvlg0O3va91o6xbtupwa6gfzrpE+eMxpnnAawlMSZwn0++B0YPa7790XQ
X-Received: by with SMTP id b15mr28864808plm.114.1486500022096; Tue, 07 Feb 2017 12:40:22 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id s8sm13757092pfj.30.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Feb 2017 12:40:21 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_58FDFA9A-6E5C-4F19-990A-A53931C49A3A"
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: Tue, 7 Feb 2017 12:40:20 -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: Tue, 07 Feb 2017 20:40:24 -0000

Hi Jinmei,

First I want to echo what Fred wrote earlier in his response to you. I want to provide you here with a response to one particular question you brought.

On Feb 7, 2017, at 10:18, 神明達哉 <> wrote:
> At Mon, 6 Feb 2017 12:07:32 -0800,james woodyatt <> wrote:
>> 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.

Let me be clear, we don’t assume that this proposal will *only* be used in links where RA guard is not deployed.

We expect it to be useful in scenarios where operators take care to *not* deploy RA guard. We expect it to be useful in scenarios where operators *do* take care to deploy RA guard. Finally, we expect it to be useful in scenarios where networks are lightly managed or unmanaged and operators do not actually know or care whether RA guard is or is not deployed.

The intent of this passage is to inform the community that, in the subset of all applicable scenarios where operators take care to deploy RA guard, this proposal introduces a different method for hosts to receive and potentially process RIO from routers that RA guard currently allows operators to filter.

Maybe we should rather keep the community in the dark about things like this. Let them find out on their own. What could go wrong?

--james woodyatt < <>>