📄 rfc2473.txt
字号:
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
Fig.3 Encapsulating a Packet
Conta & Deering Standards Track [Page 6]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Tunnel extension headers should appear in the order recommended by
the specifications that define the extension headers, such as [IPv6-
Spec].
A source of original packets and a tunnel entry-point that
encapsulates those packets can be the same node.
3.2 Packet Processing in Tunnels
The intermediate nodes in the tunnel process the IPv6 tunnel packets
according to the IPv6 protocol. For example, a tunnel Hop by Hop
Options extension header is processed by each receiving node in the
tunnel; a tunnel Routing extension header identifies the intermediate
processing nodes, and controls at a finer granularity the forwarding
path of the tunnel packet through the tunnel; a tunnel Destination
Options extension header is processed at the tunnel exit-point node.
3.3 IPv6 Decapsulation
Decapsulation is graphically shown in Fig.4:
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
v
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
Fig.4 Decapsulating a Packet
Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
exit-point node, its IPv6 protocol layer processes the tunnel
headers. The strict left-to-right processing rules for extension
headers is applied. When processing is complete, control is handed to
the next protocol engine, which is identified by the Next Header
field value in the last header processed. If this is set to a tunnel
protocol value, the tunnel protocol engine discards the tunnel
headers and passes the resulting original packet to the Internet or
lower layer protocol identified by that value for further processing.
Conta & Deering Standards Track [Page 7]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
For example, in the case the Next Header field has the IPv6 Tunnel
Protocol value, the resulting original packet is passed to the IPv6
protocol layer.
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.
3.4 IPv6 Tunnel Protocol Engine
Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a
node is graphically shown in Fig.5:
Note:
In Fig.5, the Upper-Layer Protocols box represents transport
protocols such as TCP, UDP, control protocols such as ICMP, routing
protocols such as OSPF, and internet or lower-layer protocol being
"tunneled" over IPv6, such as IPv4, IPX, etc. The Link-Layer
Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame
Relay, ATM, etc..., as well as internet layer "tunnels" such as IPv4
tunnels.
The IPv6 tunnel protocol engine acts as both an "upper-layer" and a
"link-layer", each with a specific input and output as follows:
(u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets
that are going to be decapsulated. The tunnel packets are
incoming through the IPv6 layer from:
(u.i.1) a link-layer - (path #1, Fig.5)
These are tunnel packets destined to this node and will
undergo decapsulation.
(u.i.2) a tunnel link-layer - (path #7, Fig.5)
These are tunnel packets that underwent one or more
decapsulations on this node, that is, the packets had
one or more nested tunnel headers and one nested tunnel
header was just discarded. This node is the exit-point
of both an outer tunnel and one or more of its inner
tunnels.
For both above cases the resulting original packets are passed
back to the IPv6 layer as "tunnel link-layer" output for
further processing (see b.2).
Conta & Deering Standards Track [Page 8]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
+-----------------------+ +-----------------------------------+
| Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer |
| | | |
| | | ---<-------------------<------- |
| | | | ---->---|------>--------- | |
| | | | | | | | | |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | v ^ |
v ^ v ^ v ^ v ^ Tunnel | | | |
| | | | | | | | Packets| | | |
+---------------------------------------------+ | | | |
| | | | | / / | | | | D E |
| v ^ IPv6 | --<-3--/-/--<---- | | | | E N |
| | | Layer ---->-4-/-/--->-- | | | | | C C |
| v ^ / / | | | | | | A A |
| | | 2 1 | | | | | | P P |
| v ^ -----<---5---/-/-<---- v ^ v ^ | | S S |
| | | | -->---6---/-/-->-- | | | | | | | U U |
| v ^ | | / / 6 5 4 3 8 7 | | L L |
| | | | | / / | | | | | | | | A A |
| v ^ v ^ / / v ^ | | | | | | T T |
+---------------------------------------------+ | E E |
| | | | | | | | | | | | | | | |
v ^ v ^ v ^ v ^ v ^ v ^ Original| | | |
| | | | | | | | | | | | Packets | v ^ |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | | | |
| | | | ---|----|-------<-------- | |
| | | --->--------------->------>---- |
| | | |
| Link-Layer Protocols | | IPv6 Tunnel Link-Layer |
+-----------------------+ +-----------------------------------+
Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node
(u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets
that are passed through the IPv6 layer down to:
(u.o.1) a link-layer - (path #2, Fig.5)
These packets underwent encapsulation and are sent
towards the tunnel exit-point
(u.o.2) a tunnel link-layer - (path #8, Fig.5)
These tunnel packets undergo nested encapsulation.
This node is the entry-point node of both an outer
tunnel and one or more of its inner tunnel.
Conta & Deering Standards Track [Page 9]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Implementation Note:
The tunnel upper-layer input and output can be implemented similar
to the input and output of the other upper-layer protocols.
The tunnel link-layer input and output are as follows:
(l.i) "tunnel link-layer input" - consists of original IPv6 packets
that are going to be encapsulated.
The original packets are incoming through the IPv6 layer from:
(l.i.1) an upper-layer - (path #4, Fig.5)
These are original packets originating on this node
that undergo encapsulation. The original packet source
and tunnel entry-point are the same node.
(l.i.2) a link-layer - (path #6, Fig.5)
These are original packets incoming from a different
node that undergo encapsulation on this tunnel entry-
point node.
(l.i.3) a tunnel upper-layer - (path #8, Fig.5)
These packets are tunnel packets that undergo nested
encapsulation. This node is the entry-point node of
both an outer tunnel and one or more of its inner
tunnels.
The resulting tunnel packets are passed as tunnel upper-layer
output packets through the IPv6 layer (see u.o) down to:
(l.o) "tunnel link-layer output" - consists of original IPv6 packets
resulting from decapsulation. These packets are passed through the
IPv6 layer to:
(l.o.1) an upper-layer - (path #3, Fig.5)
These original packets are destined to this node.
(l.o.2) a link-layer - (path #5, Fig.5)
These original packets are destined to another node;
they are transmitted on a link towards their
destination.
Conta & Deering Standards Track [Page 10]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(l.o.3) a tunnel upper-layer - (path #7, Fig.5)
These packets undergo another decapsulation; they were
nested tunnel packets. This node is both the exit-
point node of an outer tunnel and one or more inner
tunnels.
Implementation Note:
The tunnel link-layer input and output can be implemented similar
to the input and output of other link-layer protocols, for
instance, associating an interface or pseudo-interface with the
IPv6 tunnel.
The selection of the "IPv6 tunnel link" over other links results
from the packet forwarding decision taken based on the content of
the node's routing table.
4. Nested Encapsulation
Nested IPv6 encapsulation is the encapsulation of a tunnel packet.
It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel
containing a tunnel is called an outer tunnel. The tunnel contained
in the outer tunnel is called an inner tunnel - see Fig.6. Inner
tunnels and their outer tunnels are nested tunnels.
The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6
packets encapsulated by the "outer IPv6 tunnel" entry-point node. The
"inner tunnel entry-point node" treats the receiving tunnel packets
as original packets and performs encapsulation. The resulting
packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested
tunnel packets" for the "outer IPv6 tunnel".
Conta & Deering Standards Track [Page 11]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Outer Tunnel
<------------------------------------->
<--links--><-virtual link-><--links--->
Inner Tunnel
Outer Tunnel Outer Tunnel
Entry-Point Exit-Point
Node Node
+-+ +-+ +-+ +-+ +-+ +-+
| | | | | | | | | | | |
| |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| |
| | | | | | | | | | | |
+-+ +-+ +-+ +-+ +-+ +-+
Original Inner Tunnel Inner Tunnel Original
Packet Entry-Point Exit-Point Packet
Source Node Node Destination
Node Node
Fig.6. Nested Encapsulation
4.1 Limiting Nested Encapsulation
A tunnel IPv6 packet is limited to the maximum IPv6 packet size
[IPv6-Spec]. Each encapsulation adds to the size of an encapsulated
packet the size of the tunnel IPv6 headers. Consequently, the number
of tunnel headers, and therefore, the number of nested encapsulations
is limited by the maximum packet size. However this limit is so
large (more than 1600 encapsulations for an original packet of
minimum size) that it is not an effective limit in most cases.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -