Nanogers- Specifically Enterprise nogers. Not sure if you are aware of this IETF draft on RH0. Its in last call. So if you want to voice your opinion on whether you feel everyone should stop the traffic "that has RH0 headers" from moving on or just ignore it and let it on by, you will need to make your voice heard now. For the most part everyone is ok with this draft because it doesnt effect them and it helps address a security issue. I havnt heard a large voice from the Enterprise arena who might actually need the traffic to be passed on and not stopped. Thus, my posting this on nanog. -Cheers! Marla Official last call notice:
The IESG has received a request from the IP Version 6 Working Group WG (ipv6) to consider the following document:
- 'Deprecation of Type 0 Routing Headers in IPv6 ' <draft-ietf-ipv6-deprecate-rh0-01.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-09-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt
AD's follow-up:
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