[99393] in North American Network Operators' Group
RH0 and Enterprise Input
daemon@ATHENA.MIT.EDU (Azinger, Marla)
Thu Sep 20 00:44:51 2007
Date: Thu, 20 Sep 2007 00:43:08 -0400
From: "Azinger, Marla" <marla.azinger@frontiercorp.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
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
=09
"that has RH0 headers"
=09
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,=20
> comments may be sent to iesg@ietf.org instead. In either case, please=20
> 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=20
> 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=20
> 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
