Softwire Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Informational C. Bao
Expires: March 11, 2012 CERNET Center/Tsinghua
University
N. Skoberne
Viris
X. Li
CERNET Center/Tsinghua
University
September 8, 2011
Requirements for Extending IPv6 Addressing with Port Sets
draft-boucadair-softwire-stateless-requirements-00
Abstract
This document identifies a set of requirements to be taken into
consideration in the design of stateless 4/6 solutions. In
particular, these requirements cover the way IPv4-embedded IPv6
address and prefix are to be built when embedding the port
information.
A companion effort, documented 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."
This Internet-Draft will expire on March 11, 2012.
Copyright Notice
Boucadair, et al. Expires March 11, 2012 [Page 1]
Internet-Draft Stateless A+P Requirements September 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Boucadair, et al. Expires March 11, 2012 [Page 2]
Internet-Draft Stateless A+P Requirements 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 identifies a set of requirements to be taken into
account.
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. 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. 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.
Boucadair, et al. Expires March 11, 2012 [Page 3]
Internet-Draft Stateless A+P Requirements September 2011
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.
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.
Boucadair, et al. Expires March 11, 2012 [Page 4]
Internet-Draft Stateless A+P Requirements September 2011
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
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.
3. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
4. Security Considerations
Security considerations discussed in [RFC6052] should be taken into
account.
5. Acknowledgments
Many thanks to C. Jacquenet for his review.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Boucadair, et al. Expires March 11, 2012 [Page 5]
Internet-Draft Stateless A+P Requirements September 2011
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
6.2. Informative References
[I-D.bsd-softwire-stateless-port-index-analysis]
Boucadair, M., Skoberne, N., and W. Dec, "Analysis of Port
Indexing Algorithms",
draft-bsd-softwire-stateless-port-index-analysis-00 (work
in progress), 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
Boucadair, et al. Expires March 11, 2012 [Page 6]
Internet-Draft Stateless A+P Requirements September 2011
Nejc Skoberne
Viris
Smartinska cesta 130
Ljubljana 1000
SI
Phone: +386 31 883 217
Email: nejc@viris.si
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 11, 2012 [Page 7]