Subject: Re: I-D ACTION:draft-ietf-ipv6-tunnel-v02-00.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 7 Sep 2002 22:17:23 +0300 (EEST)

A few comments.

On Wed, 24 Jul 2002 [email-masked] 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-masked]
--------------------------------------------------------------------

---

From: Mukesh Gupta <[email-masked]>
Date: Mon, 09 Sep 2002 15:06:11 -0700

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

--
******************************************************************
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
******************************************************************