Subject: generic v6 tunneling

From: "IPSix Developer" <[email-masked]>
Date: 6 Feb 2002 09:33:50 -0000

1)With ref to section 3.3 of RFC 2473 :

"The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets can be the same node".

Does it mean tunnel exit-point IPv6 address and original packets destination IPv6 address are same? If they are
same, how do we configure the route for the destination V6 address at the tunnel entry point?

2)With ref to section 7.1(a) of RFC 2473:

When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6 pkt too big msg is sent with MTU as 
max(tunnel MTU, IPv6 min link MTU) . 

If the furthur received packets' size is larger than IPv6 min link MTU, again TOO BIG message will be sent and a looping will occur? how to avoid this? 

--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Wed, 06 Feb 2002 11:25:14 +0100

In your previous mail you wrote:

   "The tunnel exit-point node, which decapsulates the tunnel packets,
   and the destination node, which receives the resulting original
   packets can be the same node".
   
   Does it mean tunnel exit-point IPv6 address and original packets
   destination IPv6 address are same?

=> "can be" but usually they are configured to be different because:
 - this can too easily mess the routing system
 - there is no reason to encapsulate such packets (they can be sent
  directly).

   If they are same, how do we configure the route for the destination
   V6 address at the tunnel entry point?
   
=> there is already a route to the exit-point, not using the tunnel.

If you try to misconfigure a tunnel with a route to the exit-point
through the tunnel, good systems will detect the error and won't crash
trying infinite encapsulation. But this is harder if the loop is distributed
between different nodes so section 4 describes this kind of problems
and some solutions (note that 4.1.2 check detects your problem).

   When the IPv6 packet size is larger than IPv6 min link MTU, the
   ICMPv6 pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min
   link MTU) .
   
   If the furthur received packets' size is larger than IPv6 min link
   MTU, again TOO BIG message will be sent

=> yes, ICMPv6 are sent on errors but are rate limited.

   and a looping will occur?

=> I believe your loop is errors on errors. There are two counter-measures:
(draft-ietf-ipngwg-icmp-v3-02.txt section 2.4)
 - (c) Every ICMPv6 error message (type < 128) includes as much of the
   IPv6 offending (invoking) packet (the packet that caused the
   error) as will fit without making the error message packet
   exceed the minimum IPv6 MTU.
 - (e.1) An ICMPv6 error message MUST NOT be sent as a result of
   receiving an ICMPv6 error message.
(don't forget (f) aka rate limitation too).

   how to avoid this?
   
=> understand and implement carefully the specs (:-)!

Regards

[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Wed, 6 Feb 2002 10:49:45 -0800

>1)With ref to section 3.3 of RFC 2473 :
"The tunnel exit-point node, which decapsulates the tunnel packets, and
>the destination node, which receives the resulting original packets can
>be the same node".
>

Possibly, but not necessarily.  If the tunnel is treated as a separate
link, the exit endpoint of the tunnel will have its own IPv6 address(es),
distinct from those of the physical interface at which the tunnel
terminates.  But is also perfectly "legal" to send an IPv6 packet
encapsulated within another IPv6 packet, in which both the inner
and outer destination addresses are the same.
>
> If they are same, how do we configure
>the route for the destination V6 address at the tunnel entry point?

That is just an example of a router with more than one path to the same
destination.  That is handled as normal, either using routing protocols
to choose the "shortest" or "best" path, or by configuration (a "static
route").  

>When the IPv6 packet size is larger than IPv6 min link MTU, the ICMPv6
>pkt too big msg is sent with MTU as max(tunnel MTU, IPv6 min link MTU) .
>
>If the furthur received packets' size is larger than IPv6 min link MTU,
>again TOO BIG message will be sent and a looping will occur? how to
>avoid this?

If the source node ignores the Packet Too Big message and continues to
send packets that exceed max(tunnel MTU, IPv6 min link MTU), those
packets will be dropped and will trigger additional Packet Too Big
messages, subject to the general rate limiting requirement imposed
on transmitting ICMP error messages.

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 6 Feb 2002 10:54:37 -0800

> - there is no reason to encapsulate such packets (they can be sent

That's not the case if the tunnel entry point node is not the original
source node.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Feb 2002 20:51:05 +0100

=> this changes nothing: in both cases there is a route to the
destination and packets will follow it. The difference is they can be
encapsulated or not, the visible source address doesn't matter...

Regards

PS: differences can only be in source address based policies (QoS, IPsec,
policy routing, etc).

---

From: Steve Deering <[email-masked]>
Date: Wed, 6 Feb 2002 12:36:55 -0800

>PS: differences can only be in source address based policies (QoS, IPsec,

Francis,

Perhaps we are saying the same thing.  If the tunnel entry point is
other than the source node, that intermediate node has some reason
to perform the encapsulation (security, performance, policy, whatever).
Simply omitting the encapsulation -- which is what I thought you were
suggesting -- may fail to satisfy the reason for the tunnel.

Or in other words, encapsulation adds information to the packet
(additional address(es), possibly different traffic class or flow label
values, possibly extension headers).  Simply removing that information
changes the semantics of the packets, in possibly harmful ways.

Steve