|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RH0 and Enterprise Input
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 > [email protected] mailing lists by 2007-09-24. Exceptionally, > comments may be sent to [email protected] 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
|