Subject: Re: Route Information Options in Redirect Messages (updated)

From: 神明達哉 <[email-masked]>
Date: Wed, 1 Feb 2017 13:30:12 -0800

At Tue, 31 Jan 2017 23:14:59 +0000,
"Templin, Fred L" <[email-masked]> 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
  helpful.

- 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
   implementations.

  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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 3 Feb 2017 00:02:10 +0000

Jinmei-san,

Thank you for these comments. See below for follow-up:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, February 01, 2017 1:30 PM
> To: Templin, Fred L <[email-masked]>
> Cc: IPv6 List <[email-masked]>; james woodyatt <[email-masked]>
> Subject: Re: Route Information Options in Redirect Messages (updated)
> 

Perhaps this could be addressed through the addition of a "motivation"
section. Here is a first-pass proposal:

"3.  Motivation

   One common usage scenario for RIOs is the LAN segment on residential
   networks with a single default gateway that conforms minimally to
   "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084], where
   hosts that receive DHCP prefix delegations (PD) can elect to add
   routing capability to provide hosts on the LAN segment with
   reachability to addresses numbered from the delegated prefix.

   Because common host operating systems do not, in their default
   configuration, accept RIOs in RA messages per the Type "C" behavior
   defined in [RFC4191], packets sent by such hosts to destinations on
   delegated prefixes are always forwarded via the customer edge router.
   This adds costs for retransmission on the shared LAN segment, usually
   also adding latency and jitter with queuing delay and delay
   variability.  This scenario is not materially different under the
   usage scenarios described in "IPv6 Home Networking Architecture
   Principles" [RFC7368] except that the use of an interior dynamic
   routing protocol allows for routers to coordinate when and how to
   send RIOs to hosts on home network links.

   On other link types, nodes that receive prefix delegations may
   connect an entourage of "Internet of Things" backend devices.  The
   node may therefore appear as a router from the perspective of the
   backend devices but behave as a host on the link from the perspective
   of receiving Redirects and without participating in a dynamic routing
   protocol.  Instead, the node sends initial packets with a source
   address taken from one of the node's delegated prefixes via a default
   or more-specific route with a router on the link as the next-hop.

   The router may return a Redirect message with RIOs if there is
   another node on the link that would be a better next-hop for the
   destination.  This better next-hop may itself be a holder of prefix
   delegations that behaves in a similar fashion as the source node.
   Examples of where such relationships apply include peer-to-peer
   communications in civil aviation networks, unmanned aerial vehicle
   networks and enterprise networks that host mobile user devices (e.g.,
   cell phones, tablets, laptops, etc.)."

>   here.  I actually don't see the need for it in this context.

We will remove this citation.

>   and is a new update in this document.  Am I right?

RFC4861 is silent on whether Redirects are only sent in response to
data packet arrivals, or if they may be sent independently of any data
packet arrivals. We therefore assume that both options are permissible,
and we are providing a clarifying update that names the concept and
provides additional clarifying requirements

>   If so, I think

We want to clarify how a target router uses "unsolicited" Redirect
messages to update or cancel a redirection on its own initiative, i.e.,
without having to wait for packet reception. For example, the redirection
target may wish to change the Prefix Length, Preference, and/or Route
Lifetimes that were reported for the Prefix in the initial redirection event.
(The redirection target could also set Route Lifetime to 0 to cancel an
existing route.)

>   Destination Address for the receiving host.

We would like to seriously consider the use of '::' as the Destination Address
for all Redirects that include RIOs (more on that below). We would
therefore need to say that this document updates Section 8.1 of
RFC4861 by allowing Redirects that include RIOs to include a Destination
Address of "::".

>   don't match the Redirect's Destination Address?

As above, we would like to consider using '::' as the Destination Address
for all Redirects that include RIOs. This would avoid the ambiguity
you are describing.

>   If so, I think it's

Some of this may already be addressed by the "Motivation" section text
proposed near the beginning of this message, but we feel it is important
to establish that common node types that would use this extension would
act as a host for the purpose of receiving and processing Redirects but act
as a router for the purpose of generating Redirects. This is necessary to
satisfy the "MUST NOT" conditions at the bottom of Sections 8.2 and
8.3 of [RFC4861].

>   sentences is an easy way to do it.

Here is a proposal:

"The Redirect function as specified in Section 8 of RFC4861 is widely deployed
in all standard-compliant IPv6 implementations. The Route Information
Option specified in Section 3 of RFC4191 is widely deployed in some major
vendor and open system implementations."

>   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.

Fred and James

---

From: 神明達哉 <[email-masked]>
Date: Fri, 3 Feb 2017 11:51:48 -0800

At Fri, 3 Feb 2017 00:02:10 +0000,

>    delegations that behaves in a similar fashion as the source node.

So, an intended use case is something like this?

           Customer Edge Router
                |
                |
    ----+-------+--------+---   <=== same single LAN
            |                |
          Node-A           Node-B
          ||||||           ||||||
         IoT devs          IoT devs

where both Node-A and Node-B get prefixes via DHCP-PD, act as a host
on the LAN-facing interfaces while acting as a router for the "IoT
devices" behind it.  When an IoT device behind Node-A ('IoT-A') sends
a packet to an IoT device behind Node-B ('IoT-B'), Node-A first
forwards the packet to the customer edge router.  The router knows the
prefix for Node-B can be directly reachable from Node-A, so it sends a
Redirect with RIO for that prefix.  Subsequent packets from IoT
devices behind Node-A to devices behind Node-B will be directly
forwarded to Node-B.

> packet arrivals.

Hmm...although RFC4861 doesn't explicitly ban "unsolicited" redirects,
the following text of Section 8.2

   A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself (i.e., a packet that is not source routed through the router)

looks to me that it pretty clearly assumes sending that redirects are
only "reactive".

> We therefore assume that both options are permissible,

If we want to be sure about the original intent we might ask the very
original authors of RFC1970, but in any case it would be clearer to
at least say this something not explicitly documented in the original
ND spec.

> (The redirection target could also set Route Lifetime to 0 to cancel an

Hmm...so the intent is to allow 'Node-B' in the above example to send
redirects?  That sounds like 'Node-B' is actually a "router" that just
doesn't speak routing protocols (note also that a "host" MUST NOT send
redirect per RFC48610.)  So, to this end, it rather seems to make
sense to allow it to send an RA with RIO instead of tweaking the
redirect spec further.  Then we won't have to worry about the tricky
questions on Sections 3.2 and 3.3 (but see also below).

> > - Section 3.3.1
> >
> >   The discussion in this subsection is confusing to me.
>

Okay, now I think I'm getting what you're trying to do.  IMO this will
lead to a more profound discussion of the definition of router and
host, rather than a mere extension to the redirect message.  I'd
consider revising this proposal as such, i.e, first redefining hosts
and routers as an update to prior IPv6 protocol specs and then
proposing the redirect extension on top of the update.

> vendor and open system implementations."

Yes, this one is much better.

> 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.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Sun, 5 Feb 2017 12:40:54 +1100

Hi Fred, James,

> intarea draft. Please (re-)review and post comments to the list.

I had an idea for this sort for thing a few years ago, and have
another couple of use cases. I'd be interested in being a co-author.

Firstly, I think a more user friendly name for it could be a "Prefix Redirect".

The first use case is the Next Hop Resolution Protocol scenario, where
there are a set of routers on a mutli-access link, however they're not
running a dynamic routing protocol between themselves. There is a
primary router that has knowledge of all other routers and the
prefixes behind them in the link, and secondary routers that only have
knowledge of the primary router to which they default route. When the
primary router knows that secondary router is sending traffic to
another secondary router on the same link, it sends a "prefix
redirect" to the first secondary router, establishing a more direct
path over the multi-access layer 2 link.

The more specific example of this use case I was thinking of was an
ADSL broadband scenario common here in .au, where in the telephone
exchanges (C.O.s in US terminology), customer ADSL traffic is
aggregated at layer 2 (Ethernet), and then switched between
subscribers attached to the same exchange by an off-site BRAS, with
that inter-subscriber traffic having to traverse the backhaul link to
the BRAS twice.

In this scenario a "prefix redirect" sent to the customer RGs would
allow the intra-exchange traffic to stay local rather than traversing
the backhaul link. This could also be more useful if there is a CDN
subnet present in the exchange, allowing the RGs to send and receive
traffic directly to/from the CDN over the intra-exchange network,
further keeping traffic local to the exchange. There are some security
issues here, however if they are overcome, it could be very beneficial
to keep intra-exchange traffic local, as backhaul and BRAS resources
are comparatively quite expensive compared to intra-exchange layer 2
aggregation resources.

The other use case, which I think is likely the one the in mind when
the draft was written was delegation of prefixes to individual hosts,
so that inter-host traffic is direct between hosts rather than via the
hosts' default router. I think referring to RFC7934 would be useful
for this case.

Specific to sections of the draft:

1.  Introduction

I think describing these sorts of messages as a "hint" can be a good
way to convey the concept. e.g.,

'Routers sending these redirect messages are providing a "hint" to the
recipient about an alternate and more optimal forwarding path to the
destinations covered by the prefix. The recipient can ignore this
hint. Sending of traffic by the recipient should still be successful,
although less optimal."

3.1.  Validation of Redirect Messages

When thinking about the ADSL scenario above, I'd thought that the RGs
should only be accepting "prefix redirect" messages from known default
router(s), learned via RAs or static configuration. As long as bogus
RAs are prevented from being spoofed on the link, which is necessary
in an untrusted broadband environment, this would prevent unauthorised
traffic redirection.

RFC4861 does to a level of of this sort of validation for single
address redirects:

"The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address."

however I don't think it is enough validation for these "prefix redirects".

A scenario would be that the BRAS sends a "prefix redirect" to RG A
for RGB's /56. RG B would now be the next hop for the /56, and
therefore RG B could send a "prefix redirect" to RG A for a /57 (or
two "prefix redirects" for the two /57s covering the /56), causing RG
A to now send that traffic where ever RG B wanted it to be sent,
rather than to where the BRAS directed RG A to send it.

So I think the validations for a single address redirect in RFC4861
apply, except that "prefix redirects" should only be accepted from a
default router, learned via an RA or static configuration.

3.3.  Host Specification

I think it would be worth mentioning that in the ADSL/RG scenario
above (if included), the RGs are acting as a host on their WAN
interface and that processing of these "prefix redirects" is occurring
for the same reason that RGs process RAs, as per the W-3 requirement
in RFC7084.

I think that is it for the moment.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Feb 2017 10:26:45 +0900

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
increase?

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 <[email-masked]>
wrote:

> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, January 30, 2017 2:33 PM
> To: [email-masked]
> 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:
> https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-templin-6man-rio-redirect-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-templin-6man-rio-redirect-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Feb 2017 18:13:35 +0000

Jinmei-san - see below for responses:

> Sent: Friday, February 03, 2017 11:52 AM
> Cc: james woodyatt <[email-masked]>; IPv6 List <[email-masked]>

Yes. Although, instead of "LAN" we would prefer to see your figure
use the word "Link". Reason is that LANs are often understood to be
limited in expanse, where "Link" is a more generic term that could
apply to a facility that extends to vast connected network regions.

> looks to me that it pretty clearly assumes sending that redirects are

We could argue as to how to interpret RFC4861's silence on unsolicited
Redirects, but rather than argue can we simply agree that an update to
RFC4861 could allow them?

> at least say this something not explicitly documented in the original

OK.

> redirect spec further.

There are several considerations here. First RA with RIO might be blocked by
RA Guard. Second, RA message validation does not require a source address
check in the way that Redirects do, meaning that 'Node-A' would accept RAs
coming from any node on the link, and not just 'Node-B'. Third, Redirects
include a Target address whereas RA messages do not; for example, 'Node-B'
could send a Redirect with Target address of 'Node-C' for some other node
on the link that is now a better next hop.
 
> Then we won't have to worry about the tricky

This is not the first time documents have been published that talk
about nodes that act a little bit like a host and a little bit like a router.
See for example RFC7084 that speaks about CPE routers sending
RS messages; presumably to receive and process RAs.

> Yes, this one is much better.

OK.

> a good effect of this proposal.

Still not sure what if anything to do about this, but we are still open
to suggestions.

Fred and James

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Feb 2017 19:15:14 +0000

Hi Mark,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Saturday, February 04, 2017 5:41 PM
> I had an idea for this sort for thing a few years ago,

This idea is indeed not new, and has already been published in a string of
informational and experimental RFCs (RFC5558, RFC5720, RFC6179, RFC6706).
RFC6706 in particular shows the inclusion of RIOs in Redirects.

> and have another couple of use cases.

That is good. We think there will be lots of additional use cases.

> I'd be interested in being a co-author.

Thanks for offering your services; James and I will discuss it.

> Firstly, I think a more user friendly name for it could be a "Prefix Redirect".

It sounds nice, but could morph into the term "Predirect" which is already
used for a different purpose in RFC6706. We could still consider it as
inline text in the draft, but I would not be in favor of its use in the title.

> path over the multi-access layer 2 link.

Yes. That is exactly the NBMA link model that has been established in
the RFCs I cited above and carries forward into 'draft-templin-aerolink'.
So, I agree with the scenario.

> that inter-subscriber traffic having to traverse the backhaul link to

Sounds good to me, and more use cases like this are welcome.

> are comparatively quite expensive compared to intra-exchange layer 2

Keeping the intra-exchange traffic local is the right idea, and not only
provides a more direct path but also reduces the load on critical network
infrastructure.

> hosts' default router. I think referring to RFC7934 would be useful

This idea has been around in 'draft-templin-aerolink' and its predecessor
RFCs (RFC5558, RFC5720, RFC6179, RFC6706) for many years. I mentioned
this to the RFC7934 authors before its publication but was rebuffed.

> hint. Sending of traffic by the recipient should still be successful,

While I agree with you, I wonder if anything needs to be said in the
draft since RFC4861 already says:

"  A router MUST limit the rate at which Redirect messages are sent, in
   order to limit the bandwidth and processing costs incurred by the
   Redirect messages when the source does not correctly respond to the
   Redirects, or the source chooses to ignore unauthenticated Redirect
   messages.  More details on the rate-limiting of ICMP error messages
   can be found in [ICMPv6]."

This (sort of) permits sources to ignore redirects, which could in
essence mean that the source can interpret redirects as a hint.
But, if you think our draft should say more we could consider it.

> in an untrusted broadband environment, this would prevent unauthorised

We talk about trust in security considerations. But, note that not only
the default router but also the "current first-hop router" could send
redirects.

> however I don't think it is enough validation for these "prefix redirects".

We say more about this in security considerations.

> rather than to where the BRAS directed RG A to send it.

RG B could certainly redirect RG A to RG C, that is true. And, if there
is a chance that RG B is being untruthful then RG A should ignore the
messages. Again, the place to discuss this is in security considerations.

> default router, learned via an RA or static configuration.

It depends on the security scenario. If routers on the link can truly trust
each other, then it should be OK for RG B to redirect A to C. If some other
form of trust enforcement is needed (e.g., SEND) then so be it.

But, the security considerations for a redirected prefix vs. a redirected
address are one and the same. If there is any chance of spoofing, then
accepting a spoofed redirect would lead to corruption in either case.
In other words, it is never OK to accept a spoofed redirect whether
it only includes a singleton destination address or an entire prefix.

> for the same reason that RGs process RAs, as per the W-3 requirement

I like this citation, and agree it would be worth adding.

> I think that is it for the moment.

Thanks for these very helpful comments!

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Feb 2017 19:51:31 +0000

Hi Lorenzo – see below for responses:

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Sunday, February 05, 2017 5:27 PM
To: Templin, Fred L <[email-masked]>
Cc: IPv6 List <[email-masked]>; james woodyatt <[email-masked]>
Subject: Re: Route Information Options in Redirect Messages (updated)

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?

FLT>>> The renumbering event itself would be no different than renumbering for
FLT>>> any DHCPv6 PD scenario – I guess it would entail a DHCPv6 “reconfigure”
FLT>>> exchange. But, once a prefix is renumbered, there are a couple of ways
FLT>>> that previous redirections could be cancelled. First, the redirection target
FLT>>> could send unsolicited Redirects with Route Lifetimes set to 0 for the
FLT>>> previous prefixes (in which case, the source will again allow future traffic
FLT>>> to flow through a default router). Second, the redirection target can
FLT>>> send “Destination Unreachable” messages to the source, which can then
FLT>>> infer that the redirected routes are no longer valid and delete the
FLT>>> redirected route. Our draft is currently silent on Destination Unreachables,
FLT>>> but ‘draft-templin-aerolink’ talks about them and we could adopt some
FLT>>> of that text.

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.

FLT>>> Please check the Security Considerations section and let us know if you
FLT>>> have any comments on what appears there. To your point, though, a
FLT>>> Node A having received a prefix redirect with next hop Node B will
FLT>>> never accept a redirect from Node C claiming to own the prefixes
FLT>>> that are legitimately owned by Node B.

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 increase?

FLT>>> RIOs include a Route Lifetime which gives a number of seconds before
FLT>>> the prefix expires. If the node that is the owner of the prefix wishes
FLT>>> to extend the Route Lifetimes, it can send unsolicited Redirects to its
FLT>>> (redirected) correspondents. But, once Route Lifetime expires the
FLT>>> correspondent discards the prefix and allows future packets to once
FLT>>> again flow through a default router.

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?

FLT>>> Please have a look at the use cases. The three that I have mentioned are
FLT>>> 1) enterprise mobile devices (e.g., cellphones, tablets, etc.), 2) Airplanes
FLT>>> in civil aviation networks, and 3) Unmanned Air Vehicles in unmanned
FLT>>> air traffic management networks. Others have mentioned other use
FLT>>> cases, and I think we will find that there are still many others. About
FLT>>> reinventing homenet, I think you would find that these concepts have
FLT>>> been around a lot longer than homenet.
FLT>>>
FLT>>> Thanks - Fred

On Wed, Feb 1, 2017 at 8:14 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Fred and James

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, January 30, 2017 2:33 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-templin-6man-rio-redirect-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Feb 2017 12:07:32 -0800

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.

> 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 <[email-masked] <mailto:[email-masked]>>

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Feb 2017 12:58:24 -0800

Hi Lorenzo,

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 a particular point.

On Feb 6, 2017, at 11:51, Templin, Fred L <[email-masked]> wrote:
> On Feb 5, 2017, at 17:26, Lorenzo Colitti <[email-masked]> wrote:

> […] About reinventing homenet, I think you would find that these concepts have been around a lot longer than home net.

Also, I’m not sure to what you’re referring here, Lorenzo. From my perspective, this draft is meant to address a problem that HOMENET has not yet addressed in its long history. In fact, I wrote to HOMENET on 19 Jan asking for review and comment on this draft. (Thanks for responding!)

The question I asked HOMENET is one this draft tries to answer: in the real world, how do routers inform *hosts* (not just other HOMENET routers) about optimal paths to more-specific routes?

The question is relevant, because in the real world, typical general-purpose home devices do not have RFC 4191 Type C behavior, and they will likely never have Type C behavior, for all the reasons that major operating systems vendors generally do not feature it in their factory default configuration, and most don’t even surface a reasonable human interface for motivated users to enable it. Because RA validation is difficult and RIO is a big big big rock to throw at a Type C host.

Clearly, relying on hosts to have RFC 4191 Type C behavior is insufficient. Hence the need for this draft. What in particular do you think HOMENET did here that is better? If I overlooked something, then I’d be grateful for any pointer you could provide.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 7 Feb 2017 10:18:20 -0800

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

> >>>  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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Feb 2017 18:43:12 +0000

Hi Jinmei-san,

One important clarification below:

> From: ipv6 [mailto:[email-masked]] On Behalf Of ????
> Sent: Tuesday, February 07, 2017 10:18 AM
> To: james woodyatt <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> destination,

No, that is not what we want to have happen. The document doesn't
say this currently, but we want to retain a revised version of the validity
check. The revised version of the check would say:

OLD:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address.

NEW:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address, or
        (when the ICMP Destination Address is '::') the same as the current
        first-hop router for the specified RIOs

Would welcome better wording than this, but we definitely do want
to retain the validity check. Comments?

Thanks - Fred
[email-masked]

> then I'd rather be more interested in a discussion of

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Feb 2017 06:37:48 +1100

On 8 Feb. 2017 05:43, "Templin, Fred L" <[email-masked]> wrote:

Hi Jinmei-san,

<snip>

OLD:

NEW:

I think you need to be careful of not effectively reinventing a dynamic
routing protocol that ends up missing the necessary capabilities required
of one to keep this method simple.

When I've thought about this sort of capability, I've thought of it as a
hint from the routing system to the users of the forwarding domain - hosts
and stub routers (default and connected route only routers, possibly with
other static routes) - of a better entry point for their packets into the
forwarding domain.

In the case of a stub router, if it needs or would benefit from more
dynamic network information than just a prefix redirect hint, then I think
that is really saying that the stub router shouldn't be a stub router - it
needs to be a full and proper participant in the routing system (running
dynamic routing protocol, discovering and conveying network topology
information etc.), rather than a user of it via  default route to the
forwarding domain.

That's why I thought the validation should be that these prefix redirects
are only accepted from a default router learned via an RA or static default
router configuration, as a default router has the role of offering an entry
point into the forwarding domain. It would enforce the existing boundary
between the devices that are users of the forwarding domain, and the
devices that are participants in the routing system that decide the paths
through the forwarding domain.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Feb 2017 19:53:57 +0000

Hi Mark,

Ø  I think you need to be careful of not effectively reinventing a dynamic routing protocol

No, there is no reinvention going on here. The behavior parallels redirects
for singleton destination addresses, where Redirects are accepted from the
current first-hop router, be it a default or non-default.

Thanks - Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 11:38 AM
To: Templin, Fred L <[email-masked]>
Cc: 6man WG <[email-masked]>; james woodyatt <[email-masked]>; 神明達哉 <[email-masked]>
Subject: RE: Route Information Options in Redirect Messages (updated)

On 8 Feb. 2017 05:43, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jinmei-san,
<snip>

OLD:

I think you need to be careful of not effectively reinventing a dynamic routing protocol that ends up missing the necessary capabilities required of one to keep this method simple.

When I've thought about this sort of capability, I've thought of it as a hint from the routing system to the users of the forwarding domain - hosts and stub routers (default and connected route only routers, possibly with other static routes) - of a better entry point for their packets into the forwarding domain.

In the case of a stub router, if it needs or would benefit from more dynamic network information than just a prefix redirect hint, then I think that is really saying that the stub router shouldn't be a stub router - it needs to be a full and proper participant in the routing system (running dynamic routing protocol, discovering and conveying network topology information etc.), rather than a user of it via  default route to the forwarding domain.

That's why I thought the validation should be that these prefix redirects are only accepted from a default router learned via an RA or static default router configuration, as a default router has the role of offering an entry point into the forwarding domain. It would enforce the existing boundary between the devices that are users of the forwarding domain, and the devices that are participants in the routing system that decide the paths through the forwarding domain.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Feb 2017 12:40:20 -0800

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, 神明達哉 <[email-masked]> wrote:
> At Mon, 6 Feb 2017 12:07:32 -0800,james woodyatt <[email-masked]> wrote:
>> 

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?

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Feb 2017 07:06:18 +1100

Hi Fred,

On 8 Feb. 2017 06:54, "Templin, Fred L" <[email-masked]> wrote:

Hi Mark,

> current first-hop router, be it a default or non-default.

So in my proposed case of a stub router receiving and accepting a
prefix redirect, that is where there would be more of behaviour
change, as, per RFC4861,

A router MUST NOT update its routing tables upon receipt of aRedirect.

For these stub routers, accepting a prefix redirect from more than
just a default router is where I think it starts encroaching on the
functionality of a dynamic routing protocol. It starts being possible
to have all the stub routers in the set sending each other prefix
redirects (perhaps maliciously) and ending up with a variety of
different, possibly random paths across the link, with some of those
paths creating forwarding loops. Dynamic routing protocols would
resolve this situation to a single best path as well as eliminating
forwarding loops. That is the sort of functionality that would be (and
should be to keep it simple) missing from a simple prefix redirect
mechanism.

I think limiting the problem space to that of providing a better entry
point into the "proper" routing system/forwarding domain for stub
routers, by only accepting them from default routers learned via RAs
or static configuration, avoids the possibility of encountering and
having to mitigate these more complex issues.

Perhaps that means there needs to be two different validation rules
for the two different types of devices:

- for hosts, accept prefix redirects from current first-hop router for
a destination covered by the prefix

- for stub routers, only accept prefix redirects from default routers

with the fundamental distinguisher between the device types being
whether they forward non-local packets or not, and whether a stub
router accepts them or not being dependent on whether there is a
dynamic routing protocol enabled on the prefix redirect receiving
interface.

Regards,
Mark.

Thanks - Fred

To: Templin, Fred L <[email-masked]>
Cc: 6man WG <[email-masked]>; james woodyatt <[email-masked]>; 神明達哉
<[email-masked]>
Subject: RE: Route Information Options in Redirect Messages (updated)

Hi Jinmei-san,

<snip>

OLD:

NEW:

I think you need to be careful of not effectively reinventing a
dynamic routing protocol that ends up missing the necessary
capabilities required of one to keep this method simple.

When I've thought about this sort of capability, I've thought of it as
a hint from the routing system to the users of the forwarding domain -
hosts and stub routers (default and connected route only routers,
possibly with other static routes) - of a better entry point for their
packets into the forwarding domain.

In the case of a stub router, if it needs or would benefit from more
dynamic network information than just a prefix redirect hint, then I
think that is really saying that the stub router shouldn't be a stub
router - it needs to be a full and proper participant in the routing
system (running dynamic routing protocol, discovering and conveying
network topology information etc.), rather than a user of it via
default route to the forwarding domain.

That's why I thought the validation should be that these prefix
redirects are only accepted from a default router learned via an RA or
static default router configuration, as a default router has the role
of offering an entry point into the forwarding domain. It would
enforce the existing boundary between the devices that are users of
the forwarding domain, and the devices that are participants in the
routing system that decide the paths through the forwarding domain.

Regards,

Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Feb 2017 20:33:14 +0000

Hi Mark,

What you are digging into here is out of scope for this document in the same
way that orchestrating redirects for singleton destinations is out of scope for
RFC4861. All it says in the validation checks is:

  - The IP source address of the Redirect is the same as the current first-hop
     router for the specified ICMP Destination Address.

It does not say anything about how all of the potential first-hop routers on
the link coordinate among themselves to make sure that the Redirects don't
steer hosts into a rat's nest of endless loops.

Yes, just the same as for redirects of singleton destinations, there is an
implied trust basis that routers that send Redirects will behave truthfully
and consistently. It is no different for Redirects that contain RIOs.

Thanks - Fred

> Sent: Wednesday, February 08, 2017 12:06 PM
> Cc: james woodyatt <[email-masked]>; 神明達哉 <[email-masked]>; 6man WG <[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Feb 2017 08:06:05 +1100

Hi Fred,

On 9 February 2017 at 07:33, Templin, Fred L <[email-masked]> wrote:
> RFC4861.

What RFC covers redirects? RFC4443 doesn't.

>  All it says in the validation checks is:
>

Then my use case is not a use case for this. I have to provide
services to stub routers, but cannot trust them to act entirely
benevolently, because I don't own, operate or even have much influence
over what brand they are. I want to provide a the best and possibly
better service to them because their owners are paying me to e.g.,
local layer 2 switching in the exchange, but I cannot let one customer
impact the service of any other customer.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Feb 2017 21:37:14 +0000

Hi Mark,

> Sent: Wednesday, February 08, 2017 1:06 PM

No, I am only talking about RFC4861.

> impact the service of any other customer.

OK, but then that sounds like either a different document or a Security
Considerations note for this document. But, the mainline validity check
needs to stay generic.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Feb 2017 09:10:55 +1100

Hi Fred,

On 9 Feb. 2017 08:37, "Templin, Fred L" <[email-masked]> wrote:

Hi Mark,

I'm afraid I don't still don't understand what you're saying.

This mechanism is, at face value, nothing more than a single message
carrying a redirect for a range of addresses.

However, because it can carry a range of addresses, it may be useful in
other contexts where single address redirects are either or nearly
worthless. For example, RFC4861 explicitly prohibits routers from
processing single address redirects, so there is no point sending them to
routers.

I think one of those scenarios where a prefix redirect would be useful (but
a single address redirect isn't) is a router control plane client/server
relationship, where this mechanism operates following the same model as the
Next Hop Resolution Protocol does - the server router instructs the client
routers to establish more direct paths between themselves across the shared
multi-access link, but the client routers do not make those shorter path
decisions. If they did, they would be control plane peers, not clients.

The validation rule you're describing allows the client routers to make
their own best path choices, which means the server router has lost its
ability to be the single decision maker and the single source of truth.

> >   - The IP source address of the Redirect is the same as the current
first-hop

It seems to me that the default validity check needs to be the one that
provides the most robustness, which usually means the default setting needs
to suit the likely deployment environment it will be deployed in.

In my scenario, if you trusted and operated all of the routers, you could
run a dynamic IGP on them to provide optimal path information to them. A
new mechanism like a prefix redirect is an alternative to existing
mechanisms in this scenario.

If you can't trust the routers, then you either provide them with a default
route (either they configure statically or you provide via RAs) or run BGP
with them, which has all the policy knobs necessary to provide and receive
routing information securely. BGP of course isn't scalable to residential
broadband.

The latter case is the most common, in the order of 100s of millions of
instances around the world. So I think the default validation for these
sorts of messages for stub routers should suit that scenario (requiring
non-technical users to switch on increased security features just doesn't
work.)

Regards,
Mark.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Feb 2017 22:34:03 +0000

Hi Mark,

I have always understood turning someone’s plaintext message into hypertext as
an unfriendly act in these list discussion. Effective inline-ing is no longer possible.
Top-posting is the only option.

That said, I will go back to what I was saying before – the scenario for a redirected
prefix is no different than for a redirected singleton address, where an untrustworthy
first-hop router could redirect a client to a victim target. This is a matter for discussion
in security considerations – it is not justification for instrumenting an overly-restrictive
validity check that would limit applicability in use cases where the threat does not apply.

Thanks - Fred

Sent: Wednesday, February 08, 2017 2:11 PM

Hi Fred,

On 9 Feb. 2017 08:37, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,

> From: Mark Smith [mailto:[email-masked]<mailto:[email-masked]>]
> To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
> Cc: james woodyatt <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
> On 9 February 2017 at 07:33, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
> > Hi Mark,
> >

This mechanism is, at face value, nothing more than a single message carrying a redirect for a range of addresses.

However, because it can carry a range of addresses, it may be useful in other contexts where single address redirects are either or nearly worthless. For example, RFC4861 explicitly prohibits routers from processing single address redirects, so there is no point sending them to routers.

I think one of those scenarios where a prefix redirect would be useful (but a single address redirect isn't) is a router control plane client/server relationship, where this mechanism operates following the same model as the Next Hop Resolution Protocol does - the server router instructs the client routers to establish more direct paths between themselves across the shared multi-access link, but the client routers do not make those shorter path decisions. If they did, they would be control plane peers, not clients.

The validation rule you're describing allows the client routers to make their own best path choices, which means the server router has lost its ability to be the single decision maker and the single source of truth.

It seems to me that the default validity check needs to be the one that provides the most robustness, which usually means the default setting needs to suit the likely deployment environment it will be deployed in.

In my scenario, if you trusted and operated all of the routers, you could run a dynamic IGP on them to provide optimal path information to them. A new mechanism like a prefix redirect is an alternative to existing mechanisms in this scenario.

If you can't trust the routers, then you either provide them with a default route (either they configure statically or you provide via RAs) or run BGP with them, which has all the policy knobs necessary to provide and receive routing information securely. BGP of course isn't scalable to residential broadband.

The latter case is the most common, in the order of 100s of millions of instances around the world. So I think the default validation for these sorts of messages for stub routers should suit that scenario (requiring non-technical users to switch on increased security features just doesn't work.)

Regards,
Mark.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Feb 2017 10:26:33 -0800

At Tue, 7 Feb 2017 18:43:12 +0000,

> to retain the validity check. Comments?

Okay, I now understand the intent.  In that case I think the
validation logic (currently described in Section 3.1) will have to be
more detailed.  It will also have to cover some corner cases such as
where some of RIOs contain pass the above validation but some others
don't.  Similarly, I guess it should specify which RIOs can be
accepted by the receiving host in general (e.g., when the destination
address is 2001:db8:a::1, should the host accept an RIO for
2001:db8:b::/48?).

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 9 Feb 2017 20:55:39 +0000

Hi Jinmei-san,

> Sent: Thursday, February 09, 2017 10:27 AM
> don't.

I would rather have the validation check say that, if any of the RIOs
(among possibly multiple) fail the check then the entire Redirect
message also fails the check.

> Similarly, I guess it should specify which RIOs can be

To avoid this ambiguity, I would prefer to require that the destination
address MUST be set to "::" IFF any RIOs are included. That way,
legacy implementations that don't understand RIOs will reject the
Redirect because it doesn't include a valid destination address, while
new implementations will process the Redirect by ignoring the
destination address and parsing all included RIOs.

Thanks - Fred