(full disclosure - I am one of the editors of the DoD IPv6 Profiles document - but comments are my own as an individual)
1. Can we discuss the normative level of the revised Node Requirements document? My preference would be that it is a standards track or BCP ultimately, to give firm definition of what an IPv6 node MUST do. Another INFORMATIONAL document like RFC4294 is merely a helpful annotated bibliography, but that may be all we can accomplish in a reasonable timeframe, all in all it doesn't make a big difference. 2. I don't expect (nor believe it appropriate) that this revision will satisfy all the needs of either NIST or DoD for defining "IPv6 Capable" for our client organizations. That being said, several folks are already reviewing the three drafts side by side, to help ensure that the Node Requirements accurately defines the requirements that apply to ALL IPv6 nodes for ALL deployments. The editors of the DoD and NIST documents should concentrate on the delta from that baseline for specific US Government and DoD requirements and deployments. 3. Specifically with respect to IPsec and IKEv2, regardless of the "settlement" of that debate years ago, there are still valid questions about which requirements apply to ALL IPv6 nodes. I hope this revision of the Node Requirements can reiterate the commitment to IPsec, but if it does not, DoD (and NIST) can certainly state stronger and more specific requirements in our documents. DoD in particular answers to a higher authority on security and cryptographic requirements, and will probably require things that a small office or home user would never need. A prior message in this thread (from Jeremy Duncan) included pointers to the NIST and DoD profiles drafts, feel free to send any questions/comments to the editors off-list. Some of the differences are worth discussing on this list to see if there is consensus for changes to the Node Requirements draft. Additional work will need to be done by the editors of both the DoD and NIST drafts to address the specific needs of our clients that don't apply to everyone. Hemant Singh (shemant) wrote: > Brian, > > Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because I > see the new node-req-bis draft URL snipped below to be on Standards > Track. > > http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.txt > > Sorry, if I am missing some IETF process. I was expecting the bis draft > above to be INFORMATIONAL as well. > > Thanks. > > Best Regards. > > Hemant > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Brian Haberman > Sent: Tuesday, February 26, 2008 9:27 AM > To: [email protected] > Subject: Re: the role of the node "requirements" document > > Hemant, > Take a look at the category for RFC 4294 at > http://tools.ietf.org/html/rfc4294. It is Informational and no > discussion has occurred to change that classification for this update. > > Regards, > Brian > > > Hemant Singh (shemant) wrote: > >> Pekka, >> >> The node requirement draft as I read it from >> >> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.tx >> t >> >> is on Standards Track. Did I miss anything because you think this node >> > > >> requirement doc is an INFORMATIONAL draft? >> >> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for >> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is >> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security >> Architecture for the Internet Protocol). Snipped from the RFC's is >> section 10 shown below between square brackets. >> >> [10. Conformance Requirements >> >> All IPv4 systems that claim to implement IPsec MUST comply with all >> requirements of the Security Architecture document. All IPv6 >> > systems > >> MUST comply with all requirements of the Security Architecture >> document.] >> >> I totally appreciate Alain's concern for cable modem devices with >> limited memory for IPv6 but the problem is that IPv6 community decided >> > > >> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >> Cable IPv6 standards came much later. We will have to see what common >> ground can be met to address Alain's concern. >> >> Hemant >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >> Of Pekka Savola >> Sent: Tuesday, February 26, 2008 5:05 AM >> To: Alain Durand >> Cc: [EMAIL PROTECTED]; [email protected]; Fred Baker (fred) >> Subject: the role of the node "requirements" document >> >> On Tue, 26 Feb 2008, Alain Durand wrote: >> >>> The problem is that some of those devices have really limited memory >>> and they already do (too?) many things, so there is no room left... >>> Some vendors had to go back at their code and spend a lot of time and >>> > > >>> effort to clean things up to make room for the very basic IPv6 code, >>> >> so every kb count. >> >>> The whole idea of asking them to do extra efforts to implement a >>> functionality that is not needed and that will introduce bugs & >>> instability is not very appealing. >>> >>> Again, this last argument applies also to devices that do not have >>> memory >>> problems: if I do not need functionality X, I'd rather like not to >>> have it implemented as it will lower the operational risks. >>> >> I think this discussion somewhat misses the point because some folks >> feel informational roadmap documents have more weight than they >> actually do (according to IETF procedures, or even in practice in >> > vendors' > >> feature planning). (E.g., there was similar discussion about >> RFC4614.) >> >> The node requirements document, despite its misleading title, is >> INFORMATIONAL. It does not represent IETF consensus, so even if the >> document would say every IPv6 node MUST implement IPsec, it would mean >> > > >> basically nothing. >> >> Where is a Standards Track or BCP document that says IPsec is >> > mandatory? > >> If vendors need to make tradeoffs of what they implement or don't >> implement, that's their call. They can't call that product to be >> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, or >> claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC >> number which mandates IPsec). That's all. >> >> The product also might not get IPv6 ready logo certifications and >> such, but that's not IETF's business anyway. >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
