[Gen-art] Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt

[Mohan Parthasarathy <[e-mail]>]

>On Sun, 10 Dec 2006, Fred Baker wrote:
>> On Dec 9, 2006, at 5:55 PM, [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art