Hi, I am planning to implement RFC2473 soon. Here are my comments.
-- I am not clear about the MUST requirements for being complaint with the RFC. Look at the following examples. ===== For Tunnel Encapsulation Limit Option (Is it required to implement this ????) Section 4.1: Last line of second paragraph says "Therefore limiting nested encapsulation is *recommended*" Section 4.1.1: first line says "A tunnel entry-point node *may be* configured ...." Section 4.1.1: Last sentence of second paragraph says "a limit value of zero means that a packet carrying that option *may not* enter another tunnel.." Page 15: Second line says "A tunnel entry-point node *is required* to execute...." Page 15: (c): Third line says ".... an additional Tunnel Encapsulation Limit option *must be* included ...." Page 15: (d): Third line says "....a Tunnel Encapsulation Limit option *must be* included...." ====== ====== Loopback protection (Is it required to implement this ????) Section 4.1.2: First line says "A particular case of encapsulation which *must be* avoided is the loopback encapsulation" Section 4.1.2: Second paragraph, first line says "To avoid such a case, it is *recommended* that an implementation have a mechanism..." Section 4.1.2: Second paragraph, fourth line says "It is also recommended that the encapsulating engine check for...." ===== -- I am with Pekka on his generic comments 2 (remove tunnel encapsulation limit option) and 3 (I wonder about it too :-)) and specific comment 2 (PMTU might not be available). regards Mukesh Pekka Savola wrote: > A few comments. > > On Wed, 24 Jul 2002 [EMAIL PROTECTED] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IP Version 6 Working Group Working Group of the >IETF. > > > > Title : Generic Packet Tunneling in IPv6 Specification > > Author(s) : A. Conta, S. Deering > > Filename : draft-ietf-ipv6-tunnel-v02-00.txt > > Pages : 37 > > Date : 23-Jul-02 > > > > This document defines the model and generic mechanisms for IPv6 > > encapsulation of Internet packets, such as IPv6 and IPv4. The model > > and mechanisms can be applied to other protocol packets as well, such > > as AppleTalk, IPX, CLNP, or others. > > Generic comments. > > 1) Compare a bit to transmech-v2/RFC1853 (IPIP) tunneling which seem to > be quite self-sufficient. This seems to be quite (overly?) verbose. But > I guess there's no use throwing out already written text.. > > 2) Tunnel Encapsulation Limit (e.g. 4.1, 4.1.3, 5.1 second paragraph, 7 > Note) is not implemented that I'm aware of --> remove? > > 3) What's the implementation status of relaying tunnel ICMP messages > (section 8.1), I wonder? > > 4) A couple of potential security considerations areas come to mind: > - threats due to processing of ICMP messages (e.g. attacker sends > uncalled-for unreachable/hop-limit exceeded/parameter problem messages). > This is new only for ICMP message relaying (sect 8.1), possibility to hide > the source of attacks? A pointer to general ICMP consideratins for this? > > - problems due to different trust models in tunnel endpoints. As tunnel > endpoint is can be reached with "link-local" messages, at least the other > end point has about the same security requirements as a node on a local > physical link. Especially in the case of tunnel crossing from one > organization to another, or "wildcard (no configured other endpoint) > decapsulator" (e.g. automatic tunneling kind-of open-ended tunnel). > > Specific comments. > > 1) > > 6.4 IPv6 Tunnel Packet Traffic Class > > The IPv6 Tunnel Packet Traffic Class indicates the value that a > tunnel entry-point node sets in the Traffic Class field of a tunnel > header. The default value is zero. The configured Packet Traffic > Class can also indicate whether the value of the Traffic Class field > in the tunnel header is copied from the original header, or it is set > to the pre-configured value. > > 6.5 IPv6 Tunnel Flow Label > > The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- > point node sets in the flow label of a tunnel header. The default > value is zero. > > ==> I think at least in the case traffic class, there's some new > specification for handling the bits (see similar thread for transmech-v2) > > 2) > > 6.7 IPv6 Tunnel MTU > > The tunnel MTU is set dynamically to the Path MTU between the tunnel > entry-point and the tunnel exit-point nodes, minus the size of the > tunnel headers: the maximum size of a tunnel packet payload that can > be sent through the tunnel without fragmentation [IPv6-Spec]. The > tunnel entry-point node performs Path MTU discovery on the path > between the tunnel entry-point and exit-point nodes [PMTU-Spec], > [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of > [...] > > ==> reword; PMTUD is not necessarily always performed. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -- ****************************************************************** A true friend is one who overlooks your failures and tolerates your successes ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
