james woodyatt
2017-07-18 21:12:21 UTC
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 <***@google.com <mailto:***@google.com>>
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 <***@google.com <mailto:***@google.com>>