draft-ietf-softwire-map-t-06.txt   draft-ietf-softwire-map-t-07.txt 
Network Working Group X. Li Network Working Group X. Li
Internet-Draft C. Bao Internet-Draft C. Bao
Intended status: Experimental CERNET Center/Tsinghua University Intended status: Experimental CERNET Center/Tsinghua University
Expires: April 17, 2015 W. Dec, Ed. Expires: May 31, 2015 W. Dec, Ed.
O. Troan O. Troan
Cisco Systems Cisco Systems
S. Matsushima S. Matsushima
SoftBank Telecom SoftBank Telecom
T. Murakami T. Murakami
IP Infusion IP Infusion
October 14, 2014 November 27, 2014
Mapping of Address and Port using Translation (MAP-T) Mapping of Address and Port using Translation (MAP-T)
draft-ietf-softwire-map-t-06 draft-ietf-softwire-map-t-07
Abstract Abstract
This document specifies the "Mapping of Address and Port" stateless This document specifies the "Mapping of Address and Port" stateless
IPv6-IPv4 Network Address Translation (NAT64) based solution IPv6-IPv4 Network Address Translation (NAT64) based solution
architecture for providing shared or non-shared IPv4 address architecture for providing shared or non-shared IPv4 address
connectivity to and across an IPv6 network. connectivity to and across an IPv6 network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2015. This Internet-Draft will expire on May 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. MAP-T Packet Forwarding . . . . . . . . . . . . . . . . . . . 9 8. MAP-T Packet Forwarding . . . . . . . . . . . . . . . . . . . 9
8.1. IPv4 to IPv6 at the CE . . . . . . . . . . . . . . . . . 9 8.1. IPv4 to IPv6 at the CE . . . . . . . . . . . . . . . . . 9
8.2. IPv6 to IPv4 at the CE . . . . . . . . . . . . . . . . . 10 8.2. IPv6 to IPv4 at the CE . . . . . . . . . . . . . . . . . 10
8.3. IPv6 to IPv4 at the BR . . . . . . . . . . . . . . . . . 11 8.3. IPv6 to IPv4 at the BR . . . . . . . . . . . . . . . . . 11
8.4. IPv4 to IPv6 at the BR . . . . . . . . . . . . . . . . . 11 8.4. IPv4 to IPv6 at the BR . . . . . . . . . . . . . . . . . 11
9. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 9. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Fragmentation and Path MTU Discovery . . . . . . . . . . . . 12 10. Fragmentation and Path MTU Discovery . . . . . . . . . . . . 12
10.1. Fragmentation in the MAP domain . . . . . . . . . . . . 12 10.1. Fragmentation in the MAP domain . . . . . . . . . . . . 12
10.2. Receiving IPv4 Fragments on the MAP domain borders . . . 12 10.2. Receiving IPv4 Fragments on the MAP domain borders . . . 12
10.3. Sending IPv4 fragments to the outside . . . . . . . . . 12 10.3. Sending IPv4 fragments to the outside . . . . . . . . . 13
11. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 13 11. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 13
12. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13 12. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13
12.1. EA-bit length 0 . . . . . . . . . . . . . . . . . . . . 13 12.1. EA-bit length 0 . . . . . . . . . . . . . . . . . . . . 13
12.2. Mesh and Hub and spoke modes . . . . . . . . . . . . . . 13 12.2. Mesh and Hub and spoke modes . . . . . . . . . . . . . . 13
12.3. Communication with IPv6 servers in the MAP-T domain . . 13 12.3. Communication with IPv6 servers in the MAP-T domain . . 14
12.4. Compatibility with other NAT64 solutions . . . . . . . . 14 12.4. Compatibility with other NAT64 solutions . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
17.1. Normative References . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . 16 17.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Examples of MAP-T translation . . . . . . . . . . . 18 Appendix A. Examples of MAP-T translation . . . . . . . . . . . 19
Appendix B. Port mapping algorithm . . . . . . . . . . . . . . . 22 Appendix B. Port mapping algorithm . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Experiences from initial service provider IPv6 network deployments, Experiences from initial service provider IPv6 network deployments,
such as [RFC6219], indicate that successful transition to IPv6 can such as [RFC6219], indicate that successful transition to IPv6 can
happen while supporting legacy IPv4 users without a full end-to-end happen while supporting legacy IPv4 users without a full end-to-end
dual IP stack deployment. However, due to public IPv4 address dual IP stack deployment. However, due to public IPv4 address
exhaustion this requires an IPv6 technology that supports IPv4 users exhaustion this requires an IPv6 technology that supports IPv4 users
skipping to change at page 9, line 5 skipping to change at page 9, line 5
across all CEs within that domain. These values may be conveyed and across all CEs within that domain. These values may be conveyed and
configured on the CEs using a variety of methods, including; DHCPv6, configured on the CEs using a variety of methods, including; DHCPv6,
Broadband Forum's "TR-69" Residential Gateway management interface, Broadband Forum's "TR-69" Residential Gateway management interface,
Netconf, or manual configuration. This document does not prescribe Netconf, or manual configuration. This document does not prescribe
any of these methods, but recommends that a MAP CE SHOULD implement any of these methods, but recommends that a MAP CE SHOULD implement
DHCPv6 options as per [I-D.ietf-softwire-map-dhcp]. Other DHCPv6 options as per [I-D.ietf-softwire-map-dhcp]. Other
configuration and management methods may use the data model described configuration and management methods may use the data model described
by this option for consistency and convenience of implementation on by this option for consistency and convenience of implementation on
CEs that support multiple configuration methods. CEs that support multiple configuration methods.
Besides the MAP configuration parameters, a CE requires an the IPv6 Besides the MAP configuration parameters, a CE requires an IPv6
prefix to be assigned to the CE. This End-user IPv6 prefix is prefix to be assigned to the CE. This End-user IPv6 prefix is
configured as part of obtaining IPv6 Internet access, and is acquired configured as part of obtaining IPv6 Internet access, and is acquired
using standard IPv6 means applicable in the network where the CE is using standard IPv6 means applicable in the network where the CE is
located. located.
The MAP provisioning parameters, and hence the IPv4 service itself, The MAP provisioning parameters, and hence the IPv4 service itself,
are tied to the End-user IPv6 prefix; thus, the MAP service is also are tied to the End-user IPv6 prefix; thus, the MAP service is also
tied to this in terms of authorization, accounting, etc. tied to this in terms of authorization, accounting, etc.
A single MAP CE MAY be connected to more than one MAP domain, just as A single MAP CE MAY be connected to more than one MAP domain, just as
skipping to change at page 9, line 32 skipping to change at page 9, line 32
7.2. MAP BR 7.2. MAP BR
The MAP BR MUST be configured with the same MAP elements as the MAP The MAP BR MUST be configured with the same MAP elements as the MAP
CEs operating within the same domain. CEs operating within the same domain.
For increased reliability and load balancing, the BR IPv6 prefix MAY For increased reliability and load balancing, the BR IPv6 prefix MAY
be shared across a given MAP domain. As MAP is stateless, any BR may be shared across a given MAP domain. As MAP is stateless, any BR may
be used for forwarding to/from the domain at any time. be used for forwarding to/from the domain at any time.
Since MAP uses provider address space, no specific routes need to be Since MAP uses provider address space, no specific IPv6 or IPv4
advertised externally for MAP to operate, neither in IPv6 nor IPv4 routes need to be advertised externally outside the service
BGP. However, the BR prefix needs to be advertised in the service provider's network for MAP to operate. However, the BR prefix needs
provider's IGP. to be advertised in the service provider's IGP.
8. MAP-T Packet Forwarding 8. MAP-T Packet Forwarding
The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet
being forwarded by a CE of BR in one of two directions for each such being forwarded by a CE of BR in one of two directions for each such
case. This section presents a conceptual view of the operations case. This section presents a conceptual view of the operations
involved in such forwarding. involved in such forwarding.
8.1. IPv4 to IPv6 at the CE 8.1. IPv4 to IPv6 at the CE
skipping to change at page 12, line 19 skipping to change at page 12, line 19
derive the destination IPv6 address by simply mapping the destination derive the destination IPv6 address by simply mapping the destination
IPv4 address without additional port info. IPv4 address without additional port info.
10. Fragmentation and Path MTU Discovery 10. Fragmentation and Path MTU Discovery
Due to the different sizes of the IPv4 and IPv6 header, handling the Due to the different sizes of the IPv4 and IPv6 header, handling the
maximum packet size is relevant for the operation of any system maximum packet size is relevant for the operation of any system
connecting the two address families. There are three mechanisms to connecting the two address families. There are three mechanisms to
handle this issue: Path MTU discovery (PMTUD), fragmentation, and handle this issue: Path MTU discovery (PMTUD), fragmentation, and
transport-layer negotiation such as the TCP Maximum Segment Size transport-layer negotiation such as the TCP Maximum Segment Size
(MSS) option [RFC0897]. MAP uses all three mechanisms to deal with (MSS) option [RFC0897]. MAP can use all three mechanisms to deal
different cases. with different cases.
Note: The NAT64 [RFC6145]mechanism is not entirely losseless and when
applied to IPv4 communication paths that traverse double NAT64
networks, IPv4 originated ICMP-independent PathMTU Discovery as
specified in [RFC 4821], ceases to be entirely reliable. This is
because the[RFC4821] defined DF=1/MF=1 combination, after NAT64
translation, becomes DF=0/MF=1.
10.1. Fragmentation in the MAP domain 10.1. Fragmentation in the MAP domain
Translating an IPv4 packet to carry it across the MAP domain will Translating an IPv4 packet to carry it across the MAP domain will
increase its size typically by 20 bytes. The MTU in the MAP domain increase its size typically by 20 bytes. The MTU in the MAP domain
should be well managed and the IPv6 MTU on the CE WAN side interface should be well managed and the IPv6 MTU on the CE WAN side interface
SHOULD be configured so that no fragmentation occurs within the SHOULD be configured so that no fragmentation occurs within the
boundary of the MAP domain. boundary of the MAP domain.
Fragmentation in MAP-T domain SHOULD be handled as described in Fragmentation in MAP-T domain SHOULD be handled as described in
skipping to change at page 16, line 24 skipping to change at page 16, line 30
Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta
Maglione and Hongyu Chen for their review and comments. Maglione and Hongyu Chen for their review and comments.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-softwire-map] [I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10 with Encapsulation (MAP)", draft-ietf-softwire-map-12
(work in progress), January 2014. (work in progress), November 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
skipping to change at page 16, line 51 skipping to change at page 17, line 9
[I-D.dec-stateless-4v6] [I-D.dec-stateless-4v6]
Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address
Sharing", draft-dec-stateless-4v6-04 (work in progress), Sharing", draft-dec-stateless-4v6-04 (work in progress),
October 2011. October 2011.
[I-D.ietf-softwire-map-dhcp] [I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
"DHCPv6 Options for configuration of Softwire Address and "DHCPv6 Options for configuration of Softwire Address and
Port Mapped Clients", draft-ietf-softwire-map-dhcp-09 Port Mapped Clients", draft-ietf-softwire-map-dhcp-11
(work in progress), October 2014. (work in progress), November 2014.
[I-D.ietf-softwire-stateless-4v6-motivation] [I-D.ietf-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
softwire-stateless-4v6-motivation-05 (work in progress), softwire-stateless-4v6-motivation-05 (work in progress),
November 2012. November 2012.
[I-D.maglione-softwire-map-t-scenarios] [I-D.maglione-softwire-map-t-scenarios]
Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use
cases for MAP-T", draft-maglione-softwire-map- cases for MAP-T", draft-maglione-softwire-map-
t-scenarios-04 (work in progress), April 2014. t-scenarios-05 (work in progress), October 2014.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC0897] Postel, J., "Domain name system implementation schedule", [RFC0897] Postel, J., "Domain name system implementation schedule",
RFC 897, February 1984. RFC 897, February 1984.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
skipping to change at page 17, line 43 skipping to change at page 17, line 50
December 2003. December 2003.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
4953, July 2007. 4953, July 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
 End of changes. 14 change blocks. 
19 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/