I'm astonished that Path MTU is a MAY -- I had thought it was a MUST. I'd really like some more text explaining what some of the many exceptions are that are alluded to here.
It follows RFC 2460, which states:
It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery.
Given this, I'm not sure we can convert it to a MUST. But did you have some specific text issues about the Path MTU text as well?
For Section 8, RFCs 2401, 2402, and 2406 are currently being revised by the IPsec group; that should be mentioned.
Ok. I agree that it is good to alert the reader to the fact that some of the documents may have updated RFCs available. Thanks.
The crypto algorithm requirements should be better aligned with recommendations from the IPsec wg. There's a draft that lists 3DES as SHOULD, not MAY.
The problem is that the requirements have been aligned with the recommendations of the IPsec, as they exist in *RFCs*. Not drafts.
I personally think that we need to recommend and inform about better alternatives, even if such alternatives do not yet exist as RFCs or if they are not mandated by keywords. This is what we have done -- the document talks about 3DES, AES, etc.
However, there has been general resistance in the WG (maybe even the ADs) for us to mandate anything beyond the current normative RFCs. It was felt that the original RFCs should rather be updated than the node requirements document made to impose additional requirements. If the IESG thinks its okay for us to mandate stronger algorithms than what the current IPsec RFCs say, then I'm going to be *very* happy.
But if, not then I think its up to the IPsec WG to advance their documents and mandate the algorithms that they think are appropriate.
I think that IKEv? should be a SHOULD, not a MAY. While the IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will soon and it describes automated key management as a "strong SHOULD". That's certainly the consensus in the security area.
This is also related to the question of what the current RFCs say. In the case of IKE, I'm actually uncertain what the keyword is -- it is not immediately clear to me from the document. Perhaps it is to others, I would appreciate comments on this! I think we should use a keyword that the current RFCs have, whatever that is.
Anyway, I think the node requirements document is somewhat different than a usual IETF protocol document. In the RFC for for protocol FOO, there are some security issues and those are solved with the support of some security mechanisms.
But here, the specific security issues appear within the RFCs that we refer to, and the necessary security mechanisms are introduced there as well. So when talking about FOO and IKE, we know that IKE addresses FOO's issues. But in the case of the node requirements document, the security issues either have been addressed in the relevant RFCs, or those RFCs should be reissued and corrected.
Additional stuff can be extremely useful for the nodes, but it may not address any IPv6-specific issue. For instance, if we required IKE, TLS, and S/MIME, this would make sure that those are available to the IPv6 nodes, but none of them would help addressing the security issues in, say, IPv6 ND.
So I guess what I am looking for is some guidance on whether this document should focus on the IPv6 specific part, or give a more general requirements. I think we need to choose between
(1) "We, the IETF, think that in order to do IPv6, you
need <THIS>.", and
(2) "We, the IETF, think that in order to do IPv6, you
need <THIS> and the user on a node surely needs
also <THAT>."I'm fine doing it either way, but we need to agree what the scope is.
Set 2:
1. Section 10.1.1 talks about "IP Forwarding Table MIB" The revision of this MIB document (that you refer to) has a number of deprecated and obsoleted objects. I think what you want (intend) to say is that an agent must implement those objects that are required as per ipForwardFullCompliance or ipForwardReadOnlyCompliance.
I am also not sure that this is correct: Support for this MIB does not imply that IPv4 or IPv4 specific portions of this MIB be supported. Did you mean "IPv4 or IPv6 specific portions" ?
I think the intent was to say that if you implement IPv6 and as a result also the forwarding table MIB, it does not follow that you also have to implement all of IPv4.
But maybe the sentence is not needed at all. The two MODULE-COMPLIANCEs that I point you to above specify IP version neurtral objects!
I'm glad to hear that its IP version neutral.
So what happens if I create a new InetCidrRouteEntry and set inetCidrRouteDestType to "ipv4" on a box that supports only IPv6?
What I would like to happen is that this would fail, and doing so would not mean that the box violates 2096bis...
2. Similar comments/issue with Sect 10.1.2
I think you want to refer to CURRENT MODULE-COMPLIANCE, namely ipMIBCompliance2. Pls check and make sure you be specific as to what
needs to be supported.
Set 3:
One bigger issue, which may not be worth a Discuss, but something that IMHO should be discussed in some forum:
All nodes that need to resolve names SHOULD implement stub-
resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
support for:
- AAAA type Resource Records [RFC-3596];
- reverse addressing in ip6.arpa using PTR records [RFC-3152];
- EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
octets.
.. I'm operationally concerned about the last SHOULD. As far as I know, EDNS0 is not really implemented. It does not seem to include a SHOULD to something that hasn't seen practical, wide-spread deployment already. I'd recommend removing this or rewording it to a MAY.
This is very useful input. I'd go for a MAY if this is the case.
Question: is it the infrastructure part, the clients, or both that do not implement EDNS0?
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
