On 5 Mar 2009, at 06:30, Lars Eggert wrote:
Should the IETF allocate option numbers for extensions to our fundamental protocols (in this case, IPv6) that are targeted solely at private walled-garden networks? Note that in addition to draft- stjohns-sipso, we have been receiving liaison statements from the ITU-T, which would also like an IPv6 hop-by-hop option number for their walled garden, so our decision on draft-stjohns-sipso might set a precedent.
All, No. That concern is misplaced. The precedent that might be created is quite different, and ought not be controversial, namely: * As the standards body for IPv6, the IETF will consider and review proposals for IPv6 extensions (e.g. additional IPv6 options). Approving this as an Informational RFC would NOT set a precedent that the IETF would approve all such proposals for IPv6 extensions. As all IPv6 options necessarily have different semantics and syntax, the IETF community might well reach quite different (e.g. opposite) conclusions about one proposal versus some other proposal. If the IETF is the standards body for all IPv6 uses and extensions, as it claims to be, it would be quite odd to refuse to consider such IPv6-related proposals. Moreover, there is an existing IETF precedent for using and specifying explicit IP sensitivity labels; one that is over 20 years old. RFC-791 contains a Sensitivity Label option, which was subsequently evolved into RFC-1038 and then RFC-1108. Several commercial products (e.g. Solaris, Ultrix, HPUX, AIX, Linux, and Cisco IOS) supported at least RFC-1108 -- several of these are still shipping. RFC-1108 has always had limited deployment, and always will, but that deployment has grown over the past decade, not declined. Absence of an openly specified IPv6 Sensitivity Label is a serious barrier to governmental deployment of IPv6 -- and this affects a wide range of countries. Failure to have a open specification will have the undesirable result of forcing governments to continue to grow IPv4 deployments, by preventing IPv6 migration. One would imagine that both the IETF generally, and the IPv6/6MAN WG particularly, would want to facilitate and encourage IPv6 migration, rather than hinder/prevent it.
A secondary concern is that this document resurrects IPv4 technology that has been declared Historic for continued use with IPv6,
RFC-1108 was declared Historic over objections from the very few IETF participants who know MLS users. As the key issue operationally is having an open specification and an IANA-assigned option number, for interoperability reasons, moving RFC-1108 to Historic had little impact on anyone. New implementations of RFC-1108 have been begun even after that IESG action.
and in the meantime, the IETF has designed better protocol mechanisms that would arguably address the same set of requirements (for example, L3VPN).
One of the Routing ADs already has explained to you and to the other IESG members that L3VPNs *can not* meet the same set of requirements as this proposal. I have also discussed this at length in conversations with individual ADs and the entire IESG. So the claim above is simply not correct. L3VPNs simply cannot address or solve these MLS issues.
I understand the argument that the MLS architecture specifications require this sort of approach, but the ITU-T architecture has also in the past been used to argue for inferior technical solutions, and the IETF has chosen to not pursue those.
Frankly, there is no alternative MLS approach. Because we lack any concrete, and operationally viable, alternative for MLS networks, it seems odd to charaterise this MLS label as an "inferior" solution. Using labelled IPsec was the original plan for IPv6 MLS networks, as a check of the original IPsec RFCs (written by me) should reveal. Since then, over the past ~13 years, various efforts have been made to create/use a labelled IPsec approach for MLS environments. Both implementation experience and operational experience has shown that my (and the IPv6 WG's) earlier hope and belief (i.e. that labelled IPsec would be a sufficient substitute for these labels) was incorrect. (Much of this is already discussed in the I-D, as the result of review/feedback from a range of folks, including Lars.)
I'd like to ask for your thoughts on what the IETF should do here.
Just to be clear, the proposal to hand is that the draft-stjohns-sipso-* would be published as an Informational RFC. The MLS network user community simply wants to have an open specification for these labels, and to have an official IPv6 option number (so that interoperability is feasible and that use of this option would not interfere with other protential IPv6 options). There are ~3 MLS operating system suppliers who have told me that they plan to support this option if an RFC is published. (Some have already posted to the ipv6@ietf.org mailing list.) MLS systems are used on nearly all continents, and by a wide range of Asian, North American, South American, and European countries, by a range of different organisations/governments. So while the user base is small, it is geographically diverse. As of this minute, no IP router vendor has told me whether they plan to implement the ACL support for this IPv6 option or not. (The MLS user community clearly hopes that will happen.) Yours, Ran Atkinson r...@extremenetworks.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
