>On Sun, 10 Dec 2006, Fred Baker wrote: >> On Dec 9, 2006, at 5:55 PM, [EMAIL PROTECTED] wrote: >>> Section 4 has some wording problems: >>> >>> 1. [RFC2401] does not allow IP as the next layer protocol in traffic >>> selectors when an IPsec SA is negotiated. [RFC4301] also allows >>> IP as the next layer protocol (like TCP or UDP) in traffic >>> selectors. >>> >>> The "also" is susceptible to misreading. The second sentence should >>> be rephrased to: "In contrast, [RFC4301] does allow ..." > >Mohan or Richard, could you clarify this? I thought the idea was that >RFC2401 does not explicitly mention IP as the possible next layer >protocol, while many implementations do support it (and we aren't quite >sure whether such support is mandatory-to-implement)? On the other hand >RFC4301 explicitly requires support for all next layer protocol values. > >Maybe we forgot to to reword the text above since this become clearer >after earlier iterations. If so, suggestions to reword?
I think we should reword this. Though some implementations may support it, we are talking about RFC 2401 vs RFC 4301. In that sense, what David says make sense. >>> The three requirements in Section 5.2 are generally applicable, >>> and should not be buried in Section 5.2's discussion of IPsec >>> tunnel mode. The requirements also lack explanations of why >>> they are requirements. At a minimum, the statement of the >>> requirements should be moved into Section 5 (before 5.1), but >>> I would suggest moving them to the end of Section 3 and adding >>> a discussion of why these requirements are important (e.g., what >>> goes wrong if they're not met) with reference to the scenarios >>> described in Section 3. > >We could easily shuffle the text around a bit. Now that I read this, only >the first one seems to be clearly worded as a "requirement" rather than a >general observation. While the third one needs clarification (Mohan?), I used the word "requirement" more to mean that these should be supported for proper operation of passing IPv6 traffic through the IPv6-in-IPv4 tunnels. (3) is saying that IPsec needs to be modelled as an interface for proper source address selection to happen which is also discussed in rfc 3884. >only the first one (IMHO) can easily be expanded why that is so: > > 1. All of IPv6 traffic should be protected, including link-local > (e.g., Neighbor Discovery) and multicast traffic. > > 2. In router-to-router tunnels, the source and destination addresses > of the traffic could come from a wide range of prefixes that are > normally learned through routing. As routing can always learn a > new prefix, there is no way to know all the prefixes a priori > [RFC3884]. > > 3. Source address selection depends on the notions of routes and > interfaces. This affects scenarios (2) and (3). > >1) is required so that every form of traffic that is supported by RFC4213 >IPv6-in-IPv4 tunnels is supported. A more general explanation is >mentioned in 2nd paragraph of Section 6 (in effect, "we want link local, >e.g., routing protocols, multicast, etc.") but it doesn't mention why we >want them (explanation above). On the other hand Appendix A describes the >tunnel mode setup if this is not felt to be a requirement and Tunnel mode >is felt better in the particular scenario. > >As for 3), I'm not 100% sure what point it wants to convey and how it's >relevant here (does that refer to a multihomed endpoint with multiple >addresses?) Mohan? See above. -mohan Pekka _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
