Hi, Ran, thanks for the timely response.
On 2009-3-5, at 16:07, RJ Atkinson wrote:
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).
We have been considering and reviewing the proposal. But not all proposals end up getting approved.
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.
It would not set a precedent that the IETF is approving *all* such proposals, but it would set the precedent that the IETF has approved *one* such proposal. At that point, we're arguing about whether IPv6 options for one kind of walled garden vs. another kind of walled garden are OK.
My personal opinion is that "profiling" (to use an ITU-T term) of core Internet protocols is counterproductive. They are what makes the Internet universally interoperable, and creating non-interoperable flavors is something the IETF should attempt to prevent and not foster.
(I'd be fully OK with MLS IPv6 moving to a separate EtherType, but I don't think that's on the table for discussion.)
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.
The IETF is this standards body, and it has considered the proposal. The question now is whether it should approve it.
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.
If I got my history straight, the IPv4 sensitivity label dates back to DARPA days, i.e., to a time when the US government funded much of Internet research and deployment, and the resulting protocols reflect that to some degree. I question whether a 1:1 mapping of that technology into IPv6 is a good engineering choice today.
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.
This is a very valid argument, and so far it is one of the few reasons that I have down on the "pro" side of my personal MLS tally sheet. If the community thinks that this is the killer argument that trumps all other concerns, I may reconsider. Please send your thoughts.
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.
I didn't follow that process, but this decision did require and get IETF consensus, i.e., the IETF decided that the technology is obsolete for IPv4. You may disagree with this decision, but it was made. Because it was made, I question why it makes sense to resurrect obsolete technology in IPv6.
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. Newimplementations of RFC-1108 have been begun even after that IESG action.
The IETF can't stop anyone from implementing obsoleted protocols, or any technology that we find problematic for other reasons.
What we can do, however, is come to consensus now whether we want to allocate a new codepoint for an IPv6 version of a protocol mechanism we've made Historic for IPv4. We're having this discussion right now.
and in the meantime, the IETF has designed better protocol mechanismsthat 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.
OK, not being an MLS expert it is fully possible that I don't understand the requirements completely. But if none of the IETF's security solutions for the global Internet are applicable to these walled-garden deployments, that simply reinforces the point that these networks are in fact very different from the Internet.
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 labelledIPsec would be a sufficient substitute for these labels) was incorrect.
If this effort has failed and the plan now is to go back to IP-based MLS, I believe we should explicitly discuss whether the IETF community wants to go that way, rather than implicitly making it so by allocating a codepoint.
(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).
Thanks for summarizing your viewpoint. I believe I have made mine sufficiently clear, too, so hopefully the community now understands our disagreement and can share their thoughts.
Thanks, Lars
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 [email protected] 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 [email protected]
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
