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

["Templin, Fred L" <[e-mail]>]

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:[e-mail]] On Behalf Of james woodyatt
Sent: Tuesday, July 18, 2017 2:12 PM
To: 6MAN Working Group <[e-mail]>
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.

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 <[e-mail]<mailto:[e-mail]>>