On 13 Mar 2009, at 20:08, JINMEI Tatuya / 神明達哉 wrote:
I have no strong opinion either for or against assigning a new IPv6 hop-by-hop option for some walled-garden, non-IETF protocol (except that HbH options are relatively scarce resource - but it doesn't matter much anyway, because we wouldn't expect so many options to be defined).
OK. Thanks.
However, I want that option to conform to the standard rules, especially when it's defined in an IETF document, i.e., RFC.
I think there might be a big confusion here. 1) No router is ever required to add or remove this or any IPv6 option. This document does NOT require that a router be capable of adding or removing this option in any situation. The document is quite clear on this. (Personally, I doubt that any commercial off-the-shelf router implementer will even consider doing this -- because there likely is no business case for them to implement it.) 2) The document does say that if a security gateway (which happens to be a device that forwards packets; this community calls any device that forwards packets a router, even if it is really a security box) chooses to include support for adding/removing this option (i.e. to let a bunch of MS Windows or Apple MacOS X systems connect at a single-level through a MLS network deployment), then that process must be done in a particular manner. The function is specified only to ensure that appropriate Mandatory Access Control rules get followed by such an implementation. MAC rules are the central fact of life in any MLS implementation or deployment, according to the applicable ISO standards. For ~2 decades now, in many IPv4 MLS networks, there are security gateways (the one I've heard about was custom-built on Trusted Solaris 8, and is not a commercial router nor is it commercially available) that will add/remove RFC-1108/FIPS-188 Sensitivity Label options to enable such single-level desktop systems to connect to a MLS server through a MLS network deployment. If someone wants to call that an Application Layer Gateway, I won't object to the words (because I don't really care what name we use for it :-), but functionally what the device does is apply Mandatory Access Controls and facilitate integration of single-level systems into a multi-level secure environment. If folks want me to edit the draft to rename that function an Application Layer Gateway, or Security Gateway, or use some different set of words, I'm certainly open to such edits. 3) I'll note that this document will NOT be an IETF RFC, will not be on the IETF standards-track, and is not an IPv6/6MAN WG document. This is in fact an individual submission that is proposed to be published as a non-IETF Informational RFC. It is being reviewed here because it proposes to allocate an IPv6 option number. 4) Separately, the RFC document series goes back to ~1970. The IETF was not even created until ~1985. Each year many non-IETF RFCs continue to be published. Most usually these are individual submissions with either Informational status or Experimental status. Not all RFCs are IETF documents; this one will not be an IETF document nor will it be an IPv6/6MAN WG document. Bob Hinden and some others here can likely provide more precise dates, but the years just above are at least pretty close. Yours, Ran Atkinson [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
