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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf