Internet DRAFT - draft-liu-6man-ident-tunnel-packet-addr
draft-liu-6man-ident-tunnel-packet-addr
Network Working Group J. Wu
Internet-Draft C. Liu
Intended status: Standards Track Y. Cui
Expires: April 24, 2014 Tsinghua University
October 21, 2013
Identifying Addresses of IPv6 Tunnel Packets at Tunnel Exit-point
draft-liu-6man-ident-tunnel-packet-addr-00
Abstract
In the networks where IPv6 tunneling is used, it is not specific
about how a tunnel end-node identifies the received tunnel packets by
checking the destination and source addresses. when the tunnel end-
node is configured with multiple IPv6 addresses or multiple IPv6
tunnel instances, such identification is necessary. This document
describes the problem and defines the behavior of IPv6 tunnel end-
nodes about identifying tunnel packets.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Wu, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
5. Tunnel End-node Behavior . . . . . . . . . . . . . . . . . . 4
5.1. Acceptable Local/Remote Address Set Maintenance . . . . . 4
5.2. Inbound Tunnel Packet Identification . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
IPv6 tunneling mechanism [RFC2473] provides support for various
protocols to work in IPv6-only network. But when a tunnel end-node
receives a tunnel packet, it is not specific about whether or not the
tunnel end-node should identify the tunnel packet by checking the
destination and source addresses in the packet. When the tunnel end-
node is configured with multiple IPv6 tunnel instance, it is also
undefined how to dispatch the received tunnel packet to each tunnel
instance. This document provides a solution to this problem by
defining the behavior of tunnel end-node on how to identify received
tunnel packets.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
This document makes use of the following terms:
Acceptable Local Address Set: A set of one or more IPv6 addresses or
prefixes maintained by a tunnel
instance. It represents the set of
acceptable IPv6 destination addresses
in the received IPv6 tunnel packets.
Wu, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013
Usually it consists of one or more
IPv6 addresses on local interfaces of
the tunnel end-node.
Acceptable Remote Address Set: A set of one or more IPv6 addresses or
prefixes maintained by a tunnel
instance. It represents the set of
acceptable IPv6 source addresses in
the received IPv6 tunnel packets.
Terminology defined in [RFC2473] is used extensively in this
document.
4. Problem Statement
Consider an IPv6 tunnel end-node with multiple IPv6 addresses
configured on its interface. One of the IPv6 addresses is chosen as
the tunnel entry-point node address [RFC2473]. When the tunnel end-
node receives an IPv6 tunnel packet with its destination address
other than the tunnel entry-point node address, the tunnel end-node
either discards it or accepts it. Section 3.3 of [RFC2473] states
that:
"Upon receiving an IPv6 packet destined to an IPv6 address of a
tunnel exit-point node, its IPv6 protocol layer processes the
tunnel headers."
According to this statement, the tunnel end-node ought to accept the
tunnel packet. However, when the destination IPv6 address is used to
distinguish among multiple tunnel instances running in the same
tunnel end-node, one tunnel packet may be passed to multiple tunnel
instances, and it may not be the expected result.
When there are multiple tunnel instances in a tunnel end-node and
each instance with a separated process engine, it must be decided
about which tunnel instance(s) to be chosen to process a received
IPv6 tunnel packet. As the payload of a IPv6 tunnel packet may be
various protocols, only 3 items may be used to identify a tunnel
packet: IPv6 destination address, IPv6 source address, and the
payload protocol type (the Next Header field in IPv6 tunnel packet).
The payload protocol type can be used to distinguish between an IPv4
-in-IPv6 tunnel and an IPv6-in-IPv6 tunnel. The IPv6 source and
destination address can be used to distinguish among tunnels of the
same protocol type.
There are several IPv6 transition mechanisms relies on point-to-
multipoint IPv6 tunnel, such as DS-Lite [RFC6333], Lightweight 4over6
[I-D.ietf-softwire-lw4over6], MAP-E [I-D.ietf-softwire-map], etc. In
Wu, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013
these mechanisms, one tunnel instance may have multiple remote
tunnel-ends, each with different IPv6 unicast addresses. Thus, the
acceptable destination / source address of a inbound tunnel packet
could be multiple address.
5. Tunnel End-node Behavior
5.1. Acceptable Local/Remote Address Set Maintenance
An IPv6 tunnel end-node maintains an Acceptable Local Address Set in
each of its tunnel instance. An Acceptable Local Address Set
contains one or more IPv6 addresses or prefixes. The destination
address of an inbound IPv6 tunnel packet to be passed to a tunnel
instance MUST match a record in the Acceptable Local Address Set of
the tunnel instance.
An IPv6 tunnel end-node maintains an Acceptable Remote Address Set in
each of its tunnel instance. An Acceptable Remote Address Set
contains one or more IPv6 addresses or prefixes. The source address
of an inbound IPv6 tunnel packet to be passed to a tunnel instance
MUST match a record in the Acceptable Remote Address Set of the
tunnel instance.
For example, in a point-to-point IPv6 tunnel, the Acceptable Local
Address Set contains one IPv6 address(tunnel entry-point node address
[RFC2473]), and the Acceptable Remote Address Set contains one IPv6
address(tunnel exit-point node address [RFC2473]). In the tunnel
model of DS-Lite AFTR [RFC6333], the Acceptable Remote Address Set
may contains a IPv6 prefix ::/0, to represent that the tunnel accepts
tunnel packets from any B4s.
5.2. Inbound Tunnel Packet Identification
When an IPv6 tunnel end-node receives an IPv6 tunnel packet, the
tunnel end-node identifies the packet by comparing its IPv6 source
address, IPv6 destination address and protocol type (Next Header)
with the Acceptable Remote Address Set, Acceptable Local Address Set,
and protocol type of each tunnel instance running on the node. If
all the 3 fields match, the IPv6 tunnel packet is passed to the
tunnel instance.
If a tunnel packet matches more than one tunnel instance, it is
passed to each of the tunnel instances. If a tunnel packet matches
no tunnel instance, the tunnel end-node MUST discard the packet, and
SHOULD send a ICMPv6 error message to the source address of the
tunnel packet. ICMPv6 type is TBD.
6. Security Considerations
Wu, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013
TBD
7. IANA Considerations
This document does not include an IANA request.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
8.2. Informative References
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-01 (work
in progress), July 2013.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-08
(work in progress), August 2013.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
Authors' Addresses
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Wu, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Identify Address of IPv6 Tunnel Packets October 2013
Cong Liu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Wu, et al. Expires April 24, 2014 [Page 6]
