One document matched: draft-vautrin-softwire-4rd-00.txt
Softwire O. Vautrin
Internet-Draft Juniper Networks
Intended status: Standards Track July 29, 2010
Expires: January 30, 2011
IPv4 Rapid Deployment on IPv6 Infrastructures (4rd)
draft-vautrin-softwire-4rd-00
Abstract
This document specifies an automatic tunneling mechanism tailored to
advance deployment of IPv4 to end users via an IPv6 network
infrastructure. This document aims at giving an alternative to
family translation to operate an Ipv6-only network.
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 January 30, 2011.
Copyright Notice
Copyright (c) 2010 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.
Vautrin Expires January 30, 2011 [Page 1]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 4rd Model and operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Traffic from CE to IPv4 Internet [CE Behavior] . . . . . . 5
4.2. Traffic from CE to IPv4 Internet [BR Behavior] . . . . . . 6
4.3. Traffic from IPv4 Internet to CE [CE Behavior] . . . . . . 6
4.4. Traffic from IPv4 Internet to CE [BR Behavior] . . . . . . 6
5. IPv6-only Deployment considerations . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Vautrin Expires January 30, 2011 [Page 2]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
1. Introduction
4rd specifies a protocol mechanism to deploy IPv4 to sites or Host
via an IPv6 network. It builds on [I-D.ietf-softwire-ipv6-6rd] and
[I-D.ietf-softwire-dual-stack-lite]. 4rd could be seen either as the
opposite of [I-D.ietf-softwire-ipv6-6rd] or as
[I-D.ietf-softwire-dual-stack-lite] without NAT (or leaving NAT as
optional).
IPv6-only network are not common. But Ipv6-only networks is the end
goal in the Ipv4 to IPv6 transition. Thus it is worthwhile to define
viable mechanism to ease the use of Ipv6-only network. The
alternatives to 4rd are defined in [I-D.ietf-behave-v6v4-framework]
and such mechanisms have well known limitation most of them described
in [RFC4966].
The 4rd mechanism relies upon a tunneling of IPv4 inside IPv6 to a
well known IPv6 address to allow automatic IPv4 operation in an IPv6-
only Network. The mechanism can be stateless or stateful depending
on the selection of the IPv6 address. If the Ipv6 address is using
the IPv4-Embedded IPv6 Address Format described in
[draft-ietf-behave-address-format] then the 4rd operation will be
stateless. If the algorithmic mapping is not used, 4rd will fall
back to a Standard DS-Lite operation. 4rd views the IPv6 network as a
link layer for IPv4 and supports an automatic tunneling abstraction
similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model.
A 4rd domain consists of 4rd Customer Edges (CE) and one or more 4rd
Border Relays (BRs). IPv4 packets encapsulated by 4rd follow the
IPv6 routing topology within the network among CEs and BRs. 4rd BRs
are traversed only for IPv4 packets that are destined to or are
arriving from outside the 4rd domain. The CE can be either a host
(which would need to have a 4rd client capability) or a router (On
the LAN side of the router, IPv4 is implemented as it would be for
any native IP service delivered by the network).
4rd relies on IPv6 and is designed to deliver production-quality IPv4
alongside IPv6 with as little change to IPv6 networking and
operations as possible. 4rd can be deployed and thus remove the need
for a Dual stack Network completely helping the transition to a full
IPv6 internet in the future.
4rd used with a short IPv4 DHCP lease time or in conjunction with
NAT44 (DS-Lite) can also be seen as an IPv4-depletion mitigation
solution.
Vautrin Expires January 30, 2011 [Page 3]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
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].
3. Terminology
4rd_IPv4_prefix - An IPv4 prefix selected for use by a 4rd domain.
There is exactly one 4rd IPv4-prefix for a given 4rd domain. A
network may deploy 4rd with a single 4rd domain or multiple 4rd
domains.
4rd Customer Edge - A 4rd CE is a device functioning as a Customer
Edge in a 4rd deployment. A 4rd CE may also be referred simply as a
"CE" within the context of 4rd.
4rd domain - A set of 4rd CEs and BRs connected to the same virtual
4rd link.
4rd Border Relay (BR) - A 4rd-enabled router managed at the edge of a
4rd domain. A border relay router has at least one of each of the
following: an IPv6-enabled interface, a 4rd virtual interface acting
as an endpoint for the 4rd IPv4 in IPv6 tunnel, and an IPv4 interface
connected to the native IPv4 network. A 4rd BR may also be referred
to simply as a "BR" within the context of 4rd.
BR_IPv6_address - The IPv6 address of the 4rd Border Relay for a
given 4rd domain. This IPv6 address is used by the CE to send
packets to a BR in order to reach IPv4 destinations outside of the
4rd domain.
CE_IPv6_address - The IPv6 address given to the CE through normal
means (i.e., configured via DHCP, or otherwise). With proper DHCP
and Network design planning, this address can match the
CE_IPv4_address that the CE will receive and thus use an IPv4-
Embedded IPv6 Address Format described in
[draft-ietf-behave-address-format]).
CE_IPv4_address - The IPv4 address given to the CE through the IPv6
tunnel (i.e., configured via DHCP, or otherwise). This means the CE
can only get its CE_IPv4_address when it already has an
CE_IPv6_address. This address may be global or private [RFC1918].
This address is used to send and receive IPv4 packets.
Vautrin Expires January 30, 2011 [Page 4]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
4. 4rd Model and operation
4rd-sites IPv6-Only Zone IPv4-Only Zone
__/\__ ________/\__________ __________/\_________
/ \ / \/ \
4rd-CEs
| 4rd-relays
|
V (IPv6 routing) |
_________________________ |
IPv4 | | V
& IPv6 | | ___
_|__ <= SiteV6Address(X) | | |
| | | | .----------------|---| |----
| X |--|-. / | |___|
|____| | \ / | (IPv4 routing)
Host-only | \ / |
CE | O BR_IPv6_address => <= 4rd_IPv4_prefix
___ | / \ (anycast) |
| | | | / \ | ___
|--| Y |--|-' \ | | |
| |___| | '----------------|---| |----
| Router <= SiteV6Address(Y) | |___|
| CE | |
| |_________________________|
IPv4 IPV4 ENCAPSULATED IN IPV6
& IPv6
THE 4RD MODEL
Figure 1
4.1. Traffic from CE to IPv4 Internet [CE Behavior]
the CE encapsulate the IPv4 packet into an IPv6 tunnel (aka
Softwire). The IPv4 source packet can be either private or public.
It can be learned through the IPv6 tunnel or by other means. The
Ipv6 source address can be either an IPv4-Embedded IPv6 Address or
not. The choice to use IPv4-Embedded IPv6 Address or not will have
an impact on the BR as this will switch between the stateless mode or
the stateful mode.
Vautrin Expires January 30, 2011 [Page 5]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
4.2. Traffic from CE to IPv4 Internet [BR Behavior]
If the IPv6 packet source address is using an IPv4-Embedded IPv6
Address, then in this direction the BR just decapsulate the IPv4
packets from the IPv6 tunnel and forward it to the IPv4 Internet.
This is what we call the Stateless 4rd mode. If the CE_IPv6_address
is *not* using an IPv4-Embedded IPv6 Address, then the BR need to
keep track of the relationship of this IP session and the Ipv6
tunnel. The IPv6 address becomes the ID of the session. This is
what we call the Stateful 4rd mode.
The BR is either doing NAT44 with the IPv6 address as the host
identifier if the CE_IPv4_address is a private address or the BR is
creating a mapping table between the softwire ID and the
CE_IPv4_address if this last one is public and should not be
modified. Note that 1:N NAPT can be used in parallel either on the
same device or on another one. This mechanism is then similar to DS-
Lite.
4.3. Traffic from IPv4 Internet to CE [CE Behavior]
The CE decapsulate the IPv4 packets from the IPv6 packets.
4.4. Traffic from IPv4 Internet to CE [BR Behavior]
If a session or a mapping information already exist in the system
that matches the IPv4 packets, the IPv6 packets will be created with
the information based on this session information. The session can
exist because of traffic that originated from the Ipv6 side or
because some Port or address forwarding have been configured on the
BR. If no sessions exist, the stateless mechanism will be used and
the IPv6 packets will be created using the IPv4 address as defined by
the IPv4 Mapped address mapping.
5. IPv6-only Deployment considerations
- Scenario 1: Service Provider with IPv6-only access would like to
give an IPv4 address to end subscribers.
4rd used with a short IPv4 DHCP lease time or in conjunction with
NAT44 (DS-Lite) can also be seen as an IPv4-depletion mitigation
solution. With more and more internet content accessible through
IPv6, An Ipv4 address could be needed in the future just to access
some legacy content. This means an Ipv4 address could be needed only
temporarily. This means temporary allocation of Ipv4 addresses with
short lease time can be a useful IPv4-depletion mitigation solution.
Vautrin Expires January 30, 2011 [Page 6]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
- Scenario 2: An IPv6-only Enterprise would like to give IPv4
connectivity.
In this case, operating systems would have to support 4rd the same
way current operating systems support 6to4, Teredo or ISATAP. An
alternative would be to deploy island of IPv4 with 4rd Clients
running on routers.
- Scenario 3: An IPv6-only Enterprise would like to restore their
servers connectivity from IPv4 Internet. In this case, the 4rd
client will be started either on the server itself or on the 1st hop
router.
6. Acknowledgements
None
7. IANA Considerations
None
8. Security Considerations
To be defined.
9. Normative References
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-09 (work in progress),
May 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion",
draft-ietf-softwire-dual-stack-lite-05 (work in progress),
July 2010.
[I-D.ietf-softwire-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10
(work in progress), May 2010.
Vautrin Expires January 30, 2011 [Page 7]
Internet-Draft 4rd (IPv4 Rapid Deployment) July 2010
[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Author's Address
Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: Olivier@juniper.net
Vautrin Expires January 30, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:52 |