One document matched: draft-boucadair-softwire-stateless-rfc6052-update-00.txt
Softwire Working Group M. Boucadair
Internet-Draft France Telecom
Updates: 6052 (if approved) C. Bao
Intended status: Standards Track CERNET Center/Tsinghua
Expires: March 10, 2012 University
N. Skoberne
Viris
X. Li
CERNET Center/Tsinghua
University
September 7, 2011
Embedding Port Information in IPv4-Translatable IPv6 Prefixes and IPv4-
Embedded IPv6 Addresses
draft-boucadair-softwire-stateless-rfc6052-update-00
Abstract
RFC6052 specifies the algorithmic translation of an IPv6 address to a
corresponding IPv4 address, and vice versa. In particular, RFC6052
specifies the address format to build IPv4-converted and IPv4-
translatable IPv6 addresses. In order to be deployed in the context
of stateless 4/6 solutions, RFC6052 should be updated so that IPv4-
embedded IPv6 addresses convey the port information. This document
identifies a set of requirements to be taken into account when
updating RFC6052 for that purpose.
A companion effort, document at
[I-D.bsd-softwire-stateless-port-index-analysis], is required to
converge on one or a set of algorithms to be used by all stateless
solutions.
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."
Boucadair, et al. Expires March 10, 2012 [Page 1]
Internet-Draft RFC6052 Update September 2011
This Internet-Draft will expire on March 10, 2012.
Copyright Notice
Copyright (c) 2011 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
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.
Boucadair, et al. Expires March 10, 2012 [Page 2]
Internet-Draft RFC6052 Update September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Scope . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Why Update RFC6052? . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Analysis of Port Indexing Algorithms . . . . . . . . . . . . . 7
5. Address and Prefix Format . . . . . . . . . . . . . . . . . . . 7
5.1. Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Address+Port Translation Algorithms . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Boucadair, et al. Expires March 10, 2012 [Page 3]
Internet-Draft RFC6052 Update September 2011
1. Introduction
Several solutions have been proposed in the past to embed the port
information in an IPv4-embedded IPv6 address or IPv4-translatable
IPv6 prefix (see [I-D.bsd-softwire-stateless-port-index-analysis]).
For interoperability purposes, the softwire WG should converge to one
address format to be used in the context of stateless 4/6 solutions.
This document specifies such address format based on the conclusions
of the analysis documented at
[I-D.bsd-softwire-stateless-port-index-analysis].
This document focuses exclusively on unicast; multicast-related
considerations are out of scope.
For further information about the motivations for stateless
solutions, the reader is invited to refer to
[I-D.operators-softwire-stateless-4v6-motivation].
1.1. Terminology
This document makes use of the following term:
o IPv4-translatable IPv6 address/prefix: denotes an IPv6 address/
prefix assigned to an IPv6 node for use with stateless IPv4-IPv6
translation [RFC6052].
1.2. Applicability Scope
The prefix and address format, defined in this document, can be used
by both encapsulation and translation solutions.
The usage of this format in an encapsulation or translation mode is
out of scope of this document.
1.3. 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 RFC 2119 [RFC2119].
2. Why Update RFC6052?
[RFC6052] specifies the algorithmic translation of an IPv6 address to
a corresponding IPv4 address, and vice versa. In particular,
[RFC6052] specifies the address format to build IPv4-converted and
IPv4-translatable IPv6 addresses. To be deployed in the context of
Boucadair, et al. Expires March 10, 2012 [Page 4]
Internet-Draft RFC6052 Update September 2011
stateless 4/6 solutions, [RFC6052] should be updated so that IPv4-
translatable IPv6 addresses convey the port information.
RFC6052 discusses the transport of the port range information in an
IPv4-embedded IPv6 address but the conclusion was the following
(excerpt from [RFC6052]):
"There have been proposals to complement stateless translation
with a port-range feature. Instead of mapping an IPv4 address to
exactly one IPv6 prefix, the options would allow several IPv6
nodes to share an IPv4 address, with each node managing a
different range of ports. If a port range extension is needed, it
could be defined later, using bits currently reserved as null in
the suffix."
This document identifies a set of requirements to be taken into
account when updating [RFC6052] for that purpose.
3. Requirements
In addition to the requirements discussed in [RFC6052], below are
listed additional requirements to be met when including the port
information in an IPv4-embedded IPv6 prefix/address:
REQ#1: The administrative entity operating the stateless solution
MUST be able to select the length of the prefix to be used to
build IPv4-translatable IPv6 addresses/prefixes.
REQ#2: When extending the IPv6 address with the port, the same
format MUST be used to build both IPv4-translatable IPv6
prefixes and IPv4-converted IPv6 addresses.
REQ#3: Some service providers may require the ability to
unambiguously distinguish IPv4 traffic from native IPv6
traffic (e.g., multi-topology contexts where IPv4 and IPv6
traffic may be conveyed over different paths).
This can be implemented using two distinct prefixes
or by having a dedicated flag in the address to
identify IPv4-translatable IPv6 addresses.
Boucadair, et al. Expires March 10, 2012 [Page 5]
Internet-Draft RFC6052 Update September 2011
REQ#4: When only one single IPv6 prefix is assigned for both native
IPv6 communications and the transport of IPv4 packets, the
IPv4-translatable IPv6 prefix MUST have a length < /64.
REQ#5: The algorithm that computes how port information is conveyed
in IPv4-embedded IPv6 addresses MUST be standardized for the
sake of interoperability.
Note: Do we allow the support of multiple algorithms?
REQ#6: The allocation policy of IPv4-translatable IPv6 prefixes
embedding the port information MUST preserve proper prefix
aggregation.
In particular, instantiating fragmented entries (due
to prefixes embedding the port information) into
routing and forwarding tables MUST be avoided. For
more information about the shrink of RIBs, the reader
is invited to refer to Section 4.8 of
[I-D.narten-radir-problem-statement].
REQ#7: Service Providers SHOULD be able to support different classes
of customers: i.e., be able to assign port ranges of
different sizes to customers without requiring any per-
customer state to be instantiated in network elements
involved in data transfer.
IPv4 port usage may not be homogeneous among all
customers. Therefore, differentiated classes may be
defined by Service Providers for that purpose. Each
of these classes can be characterized by given size
of port sets.
REQ#8: Applications requiring even/odd and port contiguity (e.g.,
RTP/RTCP) SHOULD NOT be broken due to the port set assignment
scheme.
Traditionally the voice/video applications that use
RTP and RTCP would specify only the RTP port that the
application would use for streaming the RTP data.
The inherent assumption is that the RTCP traffic will
be sent on the next higher port. Even though RFC3605
defines a new attribute for explicitly specifying the
RTCP attribute for the SDP-based applications, but
since it is not a MUST to use this attribute, there
are still applications that are not compliant with
Boucadair, et al. Expires March 10, 2012 [Page 6]
Internet-Draft RFC6052 Update September 2011
this RFC. There are also non-SDP based applications
that use RTP/RTCP like H323, that make the assumption
that RTCP streaming will happen on RTP+1 port.
Section 4.4 of [I-D.narten-radir-problem-statement] may inspire an
additional requirement for the stateless IPv4/IPv6 interconnection
function: loose interaction between the IPv4 address pool and the
stateless IPv4/IPv6 interconnection function.
4. Analysis of Port Indexing Algorithms
The conclusions of [I-D.bsd-softwire-stateless-port-index-analysis]
will be inserted here.
5. Address and Prefix Format
5.1. Prefix
Only Network-Specific Prefix (NSP) is allowed to be used to build
IPv4-translatable IPv6 addresses/prefixes.
5.2. Format
Below is provided the address format as defined in [RFC6052]:
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
This format is provided as a reminder. Appropriate modifications
will be documented in future version of this document.
/96 prefixes do not allow to embed the port information.
Boucadair, et al. Expires March 10, 2012 [Page 7]
Internet-Draft RFC6052 Update September 2011
5.3. Address+Port Translation Algorithms
This section specifies how to encode (resp. extract) an IPv4 address
and port number in (resp. from) an IPv4-embedded IPv6 address. This
section will be completed according to the conclusions of
[I-D.bsd-softwire-stateless-port-index-analysis].
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
Security considerations discussed in [RFC6052] should be taken into
account.
8. Acknowledgments
Many thanks to C. Jacquent for his review.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
9.2. Informative References
[I-D.bsd-softwire-stateless-port-index-analysis]
Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port
Indexing Algorithms", September 2011, <draft-boucadair-
softwire-stateless-port-indexing-analysis-00>.
Boucadair, et al. Expires March 10, 2012 [Page 8]
Internet-Draft RFC6052 Update September 2011
[I-D.narten-radir-problem-statement]
Narten, T., "On the Scalability of Internet Routing",
draft-narten-radir-problem-statement-05 (work in
progress), February 2010.
[I-D.operators-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-operators-softwire-stateless-4v6-motivation-02 (work
in progress), June 2011.
Authors' Addresses
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange-ftgroup.com
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing
China
Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Nejc Skoberne
Viris
Smartinska cesta 130
Ljubljana 1000
SI
Phone: +386 31 883 217
Email: nejc@viris.si
Boucadair, et al. Expires March 10, 2012 [Page 9]
Internet-Draft RFC6052 Update September 2011
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing
China
Phone: +86 10-62785983
Email: xing@cernet.edu.cn
Boucadair, et al. Expires March 10, 2012 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 06:06:35 |