Subject: In consideration of I-D.templin-6man-rio-redirect

From: james woodyatt <[email-masked]>
Date: Tue, 18 Jul 2017 23:12:21 +0200

Dear 6MAN,

We exhausted our available time discussing <https://tools.ietf.org/html/draft-templin-6man-rio-redirect <https://tools.ietf.org/html/draft-templin-6man-rio-redirect>> in the session yesterday, and since this draft seems to both Fred and me to be ready for working group adoption, I’d like to prompt further discussion on the list toward that end. Some participants would like further clarifications about the reasoning behind the technical choices we made in this draft, and I hope we can do that here on the list. I’m going to use a Q&A format to present various paraphrased versions of the questions we’ve noted in talking without other participants, and try to provide more satisfying answers here.

Question: What is this draft *really* about? I’m just all confused about its basic problem statement.

Answer: Most popular host IPv6 implementations, e.g. Linux, Darwin, Windows, et cetera, have host route tables capable of representing routes more specific than a simple default route, but RFC 4191 hasn’t been widely adopted in default configurations— so, the "Type C” hosts it defines, which process RIO options in RA messages, are not commonly deployed in general purpose hosts. I mean, yes, you can turn it on with a sysctl variable or some such advanced configuration parameter, but out of the box? No, it’s not enabled. This draft is *really* all about revising RFC 4191— in a completely backward compatible way— to make automatically and dynamically updating host route tables with information from the network more appropriate for widespread deployment in general purpose hosts. In other words, we hope Linux, FreeBSD, Windows and the like will adopt this, and turn it on by default out of the box.

Question: So why isn’t RFC 4191 good enough as it is? Why do we need to revise it?

Answer: One reason host implementations are not Type C in default configurations is the concern about “rogue advertisers” poisoning host route tables then using that as a platform to mount attacks on the security associations in various kinds of cryptographic protocols. The perception (arguably a misperception, but let’s leave that aside) is that it’s not always safe in general purpose hosts to process RIO options in RA messages. Our draft introduces new features to the existing protocol to narrow the attack surface on hosts that process RIO options so that simple RA guards can be deployed on links to block rogue advertisers and hosts will still optimize transmission for sending to the best router for specific destinations.

Question: Why even do this with ICMPv6 neighbor discovery at all? Couldn’t you just provision host route tables with stateful DHCPv6 options?

Answer: That’s an *excellent* question, because it illustrates the situation very well! The simple answer is “for all the same reasons we don’t configure hosts with Default Router addresses using DHCPv6,” while the complete answer is that host routing tables often need to be dynamically updated in response to dynamic routing protocol events, and that would mean a tight coupling between the DHCPv6 server and the dynamic routing protocol agent so that DHCPv6 Reconfigure messages can be sent to prompt hosts to make Information-request messages for route table updates in a timely manner. And there is the whole fate-sharing thing. Plus, a couple other points: a) the ICMPv6 neighbor and router discovery protocols are the natural place in the IPv6 architecture for doing this stuff; and b) it has some attractive qualities in typical host implementations, which handle ICMPv6 entirely inside the kernel, whereas DHCPv6 and various dynamic routing protocols are usually implemented as daemons.

Question: In the draft, Figure 1: "Classical Redirection Scenario” is confusing. Is the Target a router too? What kind of node is the Source?

Answer: The draft uses Source and Target here because it’s talking about the names of the fields in the ND Redirect packet where the IPv6 address of the relevant interface on the corresponding nodes shown in the diagram. The node labeled Target is a gateway— with one interface on the link with the Router (which sends the ND Redirect to Source for Target), and another interface on the link with the hosts H1, H2, H3, et cetera. The gateway need not be a dynamic router, i.e. a gateway that uses a routing protocol like RIP, OSPF, IS-IS or Babel. It could be a simple gateway that obtains its prefix delegation from Router with DHCPv6-PD, and it’s an important point that the Source that processes RIO elements doesn’t have any need to know how the gateway obtained the prefix to which it forwards packets, or how the routing domain is controlled and managed. In the simple case, the Source node is just a host, and it neither needs nor “wants” to participate in the dynamic routing protocol used by the Router and the Target nodes.

Question: Why are you using NS/NA for the RIO confirmation lockstep? Why not use RS/RA instead?

Answer: In fact, the draft has a whole section about that, §4.2.6 “Why NS/NA?” and paraphrasing here: mainly because, to send RA messages entails delay and rate limiting that do not apply when sending NA messages. Also, RA messages are typically multicast, which is less reliable on many wireless link types, but these interactions are better done with unicast from Target directly to Source without any delays. Finally, if simple RA guards are deployed without whitelisting all the potential targets that may receive DHCPv6-PD delegations, then those RA messages will be filtered out and the system won’t work. Better to use NS/NA interchanges here, and keep the system simple.

Question: Okay, this makes a lot more sense now that you’ve explained things more clearly! Can you update the draft with all this?

Answer: Yes! Let’s adopt the draft as a working group item, then we can debate the best way to clarify the text so that it conveys all this as clearly as possible! Can we please adopt the draft as a working group item? That would be excellent. Let’s do that right away.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Jul 2017 08:50:35 +0000

Hi James,

To what you said very well in your message, I will add that this draft complements
the notion of giving a /64 to each host as has been discussed widely in recent list
messages. There needs to be some way for neighbors to discover the /64s of
peers on the link, and shipping the /64s around in RIOs in IPv6 ND messages is
IMHO the right way to go when running a dynamic routing protocol is impractical.

As to use cases, consider a large LAN with lots of hosts that have received /64s.
A specific example that comes to mind is the IETF conference SSIDs. So, I agree
that we should bring this in as a wg document so we can address these use cases.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, July 18, 2017 2:12 PM
To: 6MAN Working Group <[email-masked]>
Subject: In consideration of I-D.templin-6man-rio-redirect

Dear 6MAN,

We exhausted our available time discussing <https://tools.ietf.org/html/draft-templin-6man-rio-redirect> in the session yesterday, and since this draft seems to both Fred and me to be ready for working group adoption, I’d like to prompt further discussion on the list toward that end. Some participants would like further clarifications about the reasoning behind the technical choices we made in this draft, and I hope we can do that here on the list. I’m going to use a Q&A format to present various paraphrased versions of the questions we’ve noted in talking without other participants, and try to provide more satisfying answers here.

--james woodyatt <[email-masked]<mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 11:24:39 +0200

[...]
> Why not use RS/RA instead?

I subscribe to this question.  Especially if the 'Target' in the figure 
is a Router, and especially if we talk about Target-to-Target communication.

In IPWAVE WG we develop a problem statement about this, for vehicle to 
vehicle communications.

There are also some I-Ds with solutions doing this with RA extensions.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Jul 2017 09:36:52 +0000

Hi Alex,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, July 19, 2017 2:25 AM
> To: [email-masked]
> Subject: Re: In consideration of I-D.templin-6man-rio-redirect
> 
> 
> [...]

Target is a node that receives a Prefix Delegation. The node can then act
as either a host that uses the prefix for its own multi-addressing purposes
or as a router that forwards packets on behalf of nodes on its downstream
attached networks. Our draft refers to these nodes as "Type D" hosts.

> In IPWAVE WG we develop a problem statement about this, for vehicle to

This is for peer-to-peer communications so that two peer nodes on the link
can communicate directly without having to go through a default router. The
peer-to-peer communications are established through an NS/NA exchange
which may be initially triggered by a Redirect. 

> There are also some I-Ds with solutions doing this with RA extensions.

Our concept follows directly from RFC6706. But, we recognize the need
for involving RIOs in other IPv6 ND messages than just Redirects. We do
not see a need for any RA extensions.

Thanks - Fred

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Jul 2017 13:18:50 +0200

On Jul 19, 2017, at 11:05, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Couldn't the LAN case be solved by sending a PIO with shorter prefix length covering the address space with on-link set but SLAAC disabled?

That could work, but it would entail a NS/NS exchange and ND cache entries at the Source for every address in use that is delegated to the Target. Another similar method could work using the existing ND Redirect messages, which would have the same effect: inserting ND cache entries for each address.

You should think of our proposal as an optimization that lifts all those ND cache entries up into the host route table for whole prefixes at a time.

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Jul 2017 14:07:25 +0200

On Jul 19, 2017, at 13:18, james woodyatt <[email-masked]> wrote:
> On Jul 19, 2017, at 11:05, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
>> 

In fact, while this usage scenario isn’t the primary motivation of the authors, it probably warrants further discussion because adopting this proposal might make some desirable aspects of this kind of operating environment work better.

Consider a network where the routers advertise M=1 and no PIO option at all. In conformance with RFC 7934, a DHCPv6 service is provided that grants leases to clients making Prefix Delegation (PD) requests with delegated prefixes at least 64 bits in length, i.e. if a host asks for a prefix shorter than a /64, then it gets a /64, and if it asks for a longer one, then it gets a longer one. The DHCPv6 server is configured with a pool of prefix space for which the routers serve the link. Hosts use SLAAC (or some other method) to self-assign interface addresses in the prefixes they are delegated by the DHCPv6 server, and because there is no on-link prefix advertised, they send all their non-linklocal destination packets to their default router. (A reason you might want to do this is for scalability in networks with lots of hosts and terrible L2 multicast capability.)

Without our enhancements to RIO in this draft, optimizing the path from a source address to destination on the link so that it need not be forwarded by the default router entails the router sending ND Redirect to the source and destination hosts for each to directly target the other. This is kinda perilous, because redirection host route table entries are only removed by NUD and updated only by the target sending another ND Redirect. It’s also kinda tedious that you have to arrange ND Redirect exchanges for every source/destination pair.

Wouldn’t it be better if you could redirect an entire /64 prefix all at once with a single ND Redirect message? Well, that’s what our draft does.

With the enhancements to RIO in this draft, rather than update the neighbor cached with host redirect messages, we update the host route table with prefix redirect messages. Additionally, our draft makes some improvements to the operational semantics that allow for removing stale routes in a timely way.

In any case, we think this draft is in pretty good shape to be considered for working group adoption, and it seems to use that it provides a good solution to a variety of closely inter-related problems that have been in front of this group and others for a long time. Does anyone have further questions or comments to discuss?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Jul 2017 12:32:00 +0000

From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Thursday, July 20, 2017 5:07 AM
To: IPv6 List <[email-masked]>
Subject: Re: In consideration of I-D.templin-6man-rio-redirect

On Jul 19, 2017, at 13:18, james woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
On Jul 19, 2017, at 11:05, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

Ø    Only to say that it is simple, clean and solves real-world problems. Also fully

Ø    backward compatible without having to add more baggage to the already

Ø    overloaded RA message.