I wanted to mention a few points regarding this document, given that the matter has been the subject of some controversy. There was clear consensus in the WG for picking this approach, but it was also a rough consensus, with a number of differing opinions. One of the concerns was that the discussed vulnerabilities do not justify changing the specifications. First, this is not the first or the last time we find security issues or other bugs in our protocols. This particular issue has gotten more interest than it probably deserves; as bugs and changes go, its a very small one. But this does not imply that we can forget it and do nothing. The IETF is responsible for its specifications much the same way as vendors are responsible for their products. When there's a bug or a security vulnerability in our specifications, it is our duty to take notice and take appropriate action. Perhaps we can debate what that action should be, but it most certainly should include documentation of the issue, and in some cases modification of the spec in question. I personally want to ensure that IETF specifications and the real world are in sync, both in terms of describing what implementations actually do, and in the specifications being complete descriptions of the issues that one must think about. No one should have to hunt list discussions and operational folklore to find out how to implement key parts of our protocol stacks. A similar concern was why IPv6 is being treated differently from IPv4, which has similar source routing features. But there is a fairly big difference between the features when looking at the details. Specifically, IPv6 allows a much larger number of addresses to be used in the routing list, resulting in a greater potential for amplification. (But frankly, I suspect that even in IPv4 we have a difference between what our RFCs say and what the true implementation and operational practice is. Maybe the by-default-on rule from RFC 1812 should be revisited. Once we are done with this document we need to look at the IPv4 situation as well.) Another concern is that if Type 0 Route Header is deprecated, it is hard to bring back, if we later find out that we need it. However, new Types can be defined with relative ease -- in fact, I have personal experience of this in RFC 3775, and the process was smooth, I can recommend it. Finally, a process note required by our downref process: The document Updates both RFC 2460 (core IPv6 spec, DS) by removing functionality and RFC 4294 (IPv6 node requirements, Informational) while itself being destined for PS. Jari Arkko AD for IPv6 WG _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf