Re: Route Information Options in Redirect Messages (updated)

Lorenzo Colitti <> Mon, 06 February 2017 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 099FF129983 for <>; Sun, 5 Feb 2017 17:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Status: No, score=-2.441 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, HTML_OBFUSCATE_05_10=0.26, 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 PgYYa-saCDYj for <>; Sun, 5 Feb 2017 17:27:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13C9D12957B for <>; Sun, 5 Feb 2017 17:27:07 -0800 (PST)
Received: by with SMTP id t8so46865167vke.3 for <>; Sun, 05 Feb 2017 17:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IaYcZOl/Ajq8/q1dHw1e87KzJH1DsaWyyx9K1NbN0hI=; b=sLfsdauubg376a2rsUj23NaQU52eNwaAEPhsa+FC/PQEAstmamk6u3nk1uz8J0NlKs bY1uOlj0SX7NLUND6l2shMCef6+PSP/KWD6R9nQPGRQhmhZoFBWl4dUzXkWSetO5oEjH BGP0jP+dQynX/eMGkhvuBEFDuC3Qzx2bgjiXo+Up5cD1KhVzlLt7TgsSTwPzJ5ZS6nzP x24IAirwXiSNUqzSyrKBLCcwlgw8uVsXSuhJRKGLwTSxccCMBlDNrP5ienE5M3cyrPAp WBPTcIMuDNKQ+DXyEmyEbmI9cYiTvj5mFKYoNdk4SHW5Q/X6TN2k6h6akyYTtchcnU1w zynQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IaYcZOl/Ajq8/q1dHw1e87KzJH1DsaWyyx9K1NbN0hI=; b=ZCJnKWdhmAa85FbxlZkrFtg8IfafF0PeJCZQKgo2QEM+kIr5/ZzRwWWTkDU8DLha0H brHROXfojq76CBfTBqLxTqRCi4pgLOgUo3wyRK+gwP03DfD89u3G1u83MI2OpBlaEkFQ +IipXYSvIJV87v0f7TE+EqrsCidHGhCQ/+h5/Ja9mjnU95kUWEz2awSf5Dy0DOUrmhmj T7u95s8lZq5n3EN3HK0aTs47vMn50G/t/C4/+AcNHd0d6O07BTggQDFn7VfoAoDlJWmU NFcatnsttN6mTfdP33iu2rqwqFFCIkUP/3uZWAE8GMSY8Bx+Q/mDdJ0tBgPgwplbzn3G JMIQ==
X-Gm-Message-State: AMke39kvlb3A+VK9kEEsJrZeD/4DJRaKpgjUDJTGjDFZbz0x5ogTmiqy4wwLwRbPGtpVdpJBOzV80pHiOXbv00F8
X-Received: by with SMTP id y128mr2999611vkd.102.1486344425902; Sun, 05 Feb 2017 17:27:05 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 5 Feb 2017 17:26:45 -0800 (PST)
In-Reply-To: <>
References: <>
From: Lorenzo Colitti <>
Date: Mon, 6 Feb 2017 10:26:45 +0900
Message-ID: <>
Subject: Re: Route Information Options in Redirect Messages (updated)
To: "Templin, Fred L" <>
Content-Type: multipart/alternative; boundary=001a1141d6008567dc0547d287e0
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: Mon, 06 Feb 2017 01:27:09 -0000

I'm not sure about the security reliability and reliability of this scheme.
The first things that come to mind are:

What happens if the whole network is renumbered? Fundamentally, the entity
that is authoritative for the larger prefix (i.e., the one sending the
prefix redirect) is the one that controls routing to that prefix. What
happens if that entity realizes that the prefix is no longer valid, and
that thus the sub-prefixes are also no longer redirected? How does it
withdraw those redirects?

Second: security. I get the feeling that a lot of work needs to be done
here to cover all the corner cases. One obvious example is: suppose I have
2001:db8:1:1:/64 on link, and then some host sends an unsolicited RIO
announcing that it is responsible for 2001:db8:1:1:/64, or for both
2001:db8:1:1::/65 and 2001:db8:1:1:8000::/65. What happens? Hopefully the
host doesn't get to MITM all the traffic on the link.

Even assuming that a router actually legitimately redirects a sub-prefix to
a given node for a certain lifetime, what's to stop that node claiming that
sub-prefix even after the original lifetime has expired? Should the host
receiving the prefix redirect enforce that the prefix lifetime can never

More in general it looks like this document is trying to reinvent a fair
amount of stuff that's already covered in detail, and more robustly, in
homenet. Why not use those solutions instead?

On Wed, Feb 1, 2017 at 8:14 AM, Templin, Fred L <>

> 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.
> Fred and James
> -----Original Message-----
> From: I-D-Announce [] On Behalf Of
> Sent: Monday, January 30, 2017 2:33 PM
> To:
> Subject: I-D Action: draft-templin-6man-rio-redirect-01.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>         Title           : Route Information Options in Redirect Messages
>         Authors         : Fred L. Templin
>                           James Woodyatt
>         Filename        : draft-templin-6man-rio-redirect-01.txt
>         Pages           : 7
>         Date            : 2017-01-30
> Abstract:
>    The IPv6 Neighbor Discovery protocol provides a Redirect function
>    allowing routers to inform recipients of a better next hop on the
>    link toward the destination.  This document specifies a backward-
>    compatible extension to the Redirect function to allow routers to
>    include routing information that the recipient can associate with the
>    next hop.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft
> <>
> directories:
> or
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------