Internet Engineering Task Force S. Tsuchiya, Ed. Internet-Draft Cisco Systems Intended status: Informational S. Ohkubo Expires: May 5, 2013 Sakura Internet Y. Kawakami INTERNET MULTIFEED CO. Nov 2012 Stateless IPv4 over IPv6 report draft-janog-softwire-report-01 Abstract Stateless IPv4 over IPv6 tunnel such as MAP(Mapping of Address and Port) designs to support IPv4 over IPv6 island and resolve IPv4 shortage problem by Address and Port Mapping technique. This document describes supported vendor's implementation, ipv4 functionality over IPv6 and interoperability report. 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 May 5, 2013. Copyright Notice Copyright (c) 2012 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 Tsuchiya, et al. Expires May 5, 2013 [Page 1] Internet-Draft IPv4 over IPv6 report Nov 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Implementation Report . . . . . . . . . . . . . . . . . . . . 4 2.1. Participant List . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. MAP-E Border Relay (BR) . . . . . . . . . . . . . . . 4 2.1.2. MAP-E Customer Edge (CE) . . . . . . . . . . . . . . . 5 2.2. Security mechanism . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Question . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Typical implementation . . . . . . . . . . . . . . . . 5 2.3. Provisioning method . . . . . . . . . . . . . . . . . . . 6 2.4. Reachability to BR address . . . . . . . . . . . . . . . . 6 3. Test Parameter . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IPv4 functionality over IPv6 . . . . . . . . . . . . . . . . . 7 4.1. T-1:ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. T-2:IPSec VPN . . . . . . . . . . . . . . . . . . . . . . 9 4.3. T-3:SSL VPN . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. T-4:FTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. T-5:PPTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6. T-6:L2TP . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.7. T-7:Instant Messaging and VoIP . . . . . . . . . . . . . . 10 4.7.1. Facebook on the web (http) . . . . . . . . . . . . . . 10 4.7.2. Facebook via a client (xmpp) . . . . . . . . . . . . . 10 4.7.3. Jabber.org chat service (xmpp) . . . . . . . . . . . . 10 4.7.4. Gmail chat on the web (http) . . . . . . . . . . . . . 10 4.7.5. Gmail chat via a client (xmpp) . . . . . . . . . . . . 10 4.7.6. Google Talk client . . . . . . . . . . . . . . . . . . 10 4.7.7. AIM (AOL) . . . . . . . . . . . . . . . . . . . . . . 10 4.7.8. ICQ (AOL) . . . . . . . . . . . . . . . . . . . . . . 10 4.7.9. Skype . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7.10. MSN . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7.11. Webex . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7.12. Sametime . . . . . . . . . . . . . . . . . . . . . . . 11 4.7.13. facetime . . . . . . . . . . . . . . . . . . . . . . . 11 4.8. T-8:NAT verification tool . . . . . . . . . . . . . . . . 11 4.8.1. T-8-1:RFC4787 . . . . . . . . . . . . . . . . . . . . 11 4.8.2. T-8-2:NAT-Analyzer . . . . . . . . . . . . . . . . . . 11 4.9. Result summary . . . . . . . . . . . . . . . . . . . . . . 11 5. BR redundancy . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 12 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 13 Tsuchiya, et al. Expires May 5, 2013 [Page 2] Internet-Draft IPv4 over IPv6 report Nov 2012 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 A.1. test network toplogy and parameters . . . . . . . . . . . 17 A.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 17 A.2.1. IP Infusion NetBSD 4.0.1:BR . . . . . . . . . . . . . 17 A.2.2. IP Infusion Linux 2.6.18:BR . . . . . . . . . . . . . 18 A.2.3. Furukawa Network Solution Corp.:BR . . . . . . . . . . 18 A.2.4. Vyatta ASAMAP:BR . . . . . . . . . . . . . . . . . . . 18 A.2.5. Internet Initiative Japan Inc. SEIL:BR . . . . . . . . 19 A.2.6. Cisco IOS-XR:BR . . . . . . . . . . . . . . . . . . . 19 A.2.7. IP Infusion NetBSD 4.0.1:CE . . . . . . . . . . . . . 19 A.2.8. IP Infusion Linux 2.6.18:CE . . . . . . . . . . . . . 20 A.2.9. Furukawa Network Solution Corp.:CE . . . . . . . . . . 20 A.2.10. Vyatta ASAMAP:CE . . . . . . . . . . . . . . . . . . . 21 A.2.11. Internet Initiative Japan Inc. SEIL:CE . . . . . . . . 21 A.2.12. Yamaha :CE . . . . . . . . . . . . . . . . . . . . . . 21 A.2.13. CERNET OpenWRT :CE . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Tsuchiya, et al. Expires May 5, 2013 [Page 3] Internet-Draft IPv4 over IPv6 report Nov 2012 1. Introduction Stateless IPv4 over IPv6 tunnel such as MAP(Mapping of Address and Port) designs to support IPv4 over IPv6 island and resolve IPv4 shortage problem by Address and Port Mapping technique. JApan Network Operators Group [JANOG] made a Working Group to evaluate this feature. 7 vendors and 9 implementations attended to the interop events which hold at Nagaoka city of Niigata, Japan. This document describes MAP-E [I-D.ietf-softwire-map] supported vendor's implementation, ipv4 functionality over IPv6 and interoperability report. 2. Implementation Report MAP-E [I-D.ietf-softwire-map] is already supported by a lot of vendors. The total number was 7 vendors and 9 implementations at this point. In this section, describes about interop event participant list, security mechanism and provisioning method and reachability to BR address. 2.1. Participant List 2.1.1. MAP-E Border Relay (BR) +---------------------------------+----------------+ | Vendor | OS/Equipment | +---------------------------------+----------------+ | IP Infusion | Linux 2.6.18 | | IP Infusion | NetBSD 4.0.1 | | Furukawa Network Solution Corp. | FX5000 | | ASAMAP | Vyatta | | Internet Initiative Japan Inc. | SEIL/X1 | | Cisco Systems | IOS-XR/ASR9000 | +---------------------------------+----------------+ Tsuchiya, et al. Expires May 5, 2013 [Page 4] Internet-Draft IPv4 over IPv6 report Nov 2012 2.1.2. MAP-E Customer Edge (CE) +---------------------------------+--------------+ | Vendor | OS/Equipment | +---------------------------------+--------------+ | IP Infusion | Linux 2.6.18 | | IP Infusion | NetBSD 4.0.1 | | Furukawa Network Solution Corp. | F60W | | ASAMAP | Vyatta | | CERNET | OpenWRT | | Internet Initiative Japan Inc. | SEIL/X1 | | Yamaha Corporation | RTX1200 | +---------------------------------+--------------+ 2.2. Security mechanism We took a survey to participant about security considerations which is described on Section 13 of [I-D.ietf-softwire-map]. 2.2.1. Question Q1. How to behave when CE/BR receives IPv4 packets which does not match MAP cpe domain? Q2. How to behave when CE/BR receives IPv6 packets which has inconsistency between IPv6 src address and IPv4 src address? Q3. How to behave when CE/BR receives IPv6 packets which has inconsistency between IPv6 dst address and IPv4 dst address? Q4. How to behave when CE receives IPv6 packets which is not from BR address? 2.2.2. Typical implementation A1. Most of vendor look up IP routing table, then routing to next hop or drops. But some vendors check routing table at first, then check consistency between the Rule IPv4 prefix and IPv4 destination packets. As the result, routing to next hop or drops. A2. All of BRs checks inconsistency between IPv6 src address and IPv4 src address. Most of CE checks inconsistency between IPv6 src address and IPv4 src address. If IPv6 src address is included in the Rule IPv6 prefix then validates IPv4 src address. If the src address is BR address, then it does not validate. A3. Most of BR only checks whether the IPv6 dst address is BR address. Most of CE validates inconsistency between IPv6 dst address Tsuchiya, et al. Expires May 5, 2013 [Page 5] Internet-Draft IPv4 over IPv6 report Nov 2012 and IPv4 dst address before NAT process. A4. Depends on configuration. If CE is configured as "Hub and Spoke mode" or permit only from BR address, then the packets will be dropped. If CE is configured as "Mesh mode" or no filter, then packets will transit. 2.3. Provisioning method Section 7 of [I-D.ietf-softwire-map] describes configuration of MAP-E. All of CE and BR who attended the event are supported manual configuration only at this time. Most of vendors directly configures "Length of EA bits", but some vendors configures "sharing ratio" and "contiguous-ports", "length of EA bits" would be calculated as the result. The former configuration type would be useful for operation and trouble shooting, because "rule in the packets" is visible on configurations. On the other hand, latter type configuration would be easy to understand design such as how many user will be shared one address. 2.4. Reachability to BR address 3 BR implementations are required to configure BR address as interface address. The rest of 2 BR implementations must not configure BR address as interface address. The former implementation, can confirm reachability of BR address from IPv6 network. But latter implementation, can not confirm reachability to BR address but of course can confirm reachability to BR themselves. 3. Test Parameter MAP-E Parameter Tsuchiya, et al. Expires May 5, 2013 [Page 6] Internet-Draft IPv4 over IPv6 report Nov 2012 +----------------------+-------------------------------------------+ | Parameter | Value | +----------------------+-------------------------------------------+ | Rule IPv6 prefix | 2403:9200::/32 | | Rule IPv4 prefix | 203.86.225.0/28 | | End-user IPv6 prefix | 2403:9200:fff1::/48 - 2403:9200:fff7::/48 | | EA bits | 16bit(48-32) | | Port-Set ID | 12bit | | PSID offset | 4 | | BR IPv6 address | 2403:9200:fff0:0::2 | | Topology | Mesh | +----------------------+-------------------------------------------+ Each of MAP-E has only 15 TCP/UDP ports,1 IP address is shared by 4096 users. MAP Simulation Tool shows this rule. [1] MTU Parameter +-----------+----------+---------------+--------------------+ | Parameter | IPv6 MTU | TCP MSS clamp | Tunnel IF IPv4 MTU | +-----------+----------+---------------+--------------------+ | Value | 1500byte | Enable | 1460byte | +-----------+----------+---------------+--------------------+ 4. IPv4 functionality over IPv6 MAP-E [I-D.ietf-softwire-map] uses A+P technologies with NAT44. Basic NAT requirement is defined as [RFC4787], [RFC5508] and [RFC5382]. But there is difference of implementation among vendors. ALG support also depends on vendors implementations. 4.1. T-1:ICMP Section 9 of [I-D.ietf-softwire-map] describes about ICMP handling in MAP domain. T-1-1: echo request/echo reply Confirmed from MAP-E CE network to global internet. Echo request (ICMP type 8 code 0) has identifier, so MAP-E CE has to rewrite this field from ports-set value. Echo reply(ICMP type 0 code 0) has same identifier as echo request. MAP-BR must handle from this identifier field. Tsuchiya, et al. Expires May 5, 2013 [Page 7] Internet-Draft IPv4 over IPv6 report Nov 2012 Therefore the test could confirm capability of ICMP both CE and BR. All of CE and BR are supported this feature. T-1-2: Host Unreachable Confirmed from MAP-E CE network to global internet. Layer3 switch reply "Host unreachable" (ICMP type 3 code 1) message, the message does not has identifier field. So MAP-BR has to inspect ICMP payload. The test could confirm capability to handling for null identifier ICMP of MAP-BR. 3 BR already supported this feature.2 BR does not support this feature at this time. T-1-3: TTL equals 0 during transit Confirmed traceroute from MAP-E CE network to global internet. Layer3 switch reply "TTL equals 0 during transit" (ICMP type 11 code 0) message, the message does not has identifier field. So MAP-BR has to inspect ICMP payload. The test could confirm capability to handling for null identifier ICMP of MAP-BR. 3 BR already supported this feature.2 BR does not support this feature at this time. T-1-4: Fragmentation needed but no frag. bit set Confirmed Echo with DF-bit from MAP-E CE network to global internet. Layer3 switch reply "Fragmentation needed but no frag. bit set" (ICMP type 3 code 4) message, the message does not has identifier field. So MAP-BR has to inspect ICMP payload. The test could confirm capability to handling for null identifier ICMP of MAP-BR. 3 BR already supported this feature.2 BR does not support this feature at this time. Tsuchiya, et al. Expires May 5, 2013 [Page 8] Internet-Draft IPv4 over IPv6 report Nov 2012 4.2. T-2:IPSec VPN IPSec VPN [RFC2401] uses ESP packets, therefore MAP-E CE should support NAT traversal [RFC3948]. T-2-1:IPSec All of CE failed.This result is expected behavior. T-2-2:IPSec VPN(UDP:NAT Traversal) All of CE succeeded. 4.3. T-3:SSL VPN It should be no problem, because SSL VPN[RFC4347] uses TCP sockets. All of CE succeeded. 4.4. T-4:FTP FTP[RFC0959] PORT(Active) and PASV(Passive) mode had sometimes problem in NAT44. [RFC2428] is enhancement FTP for IPv6/NAT. MAP-E devices may need support FTP ALG if the customer required FTP Active mode. T-4-1:Passive(PASV) mode All of CE succeeded. T-4-2:Active(PORT) mode Only 2 vendor's CE succeeded. 4.5. T-5:PPTP PPTP[RFC2637] uses GRE and TCP port 1723. Unless configuring to pass GRE and TCP port 1723, can not use PPTP on MAP-E .NOTE:Microsoft is warning use of PPTP due to security reason. [2743314] All of CE failed.This result is expected behavior. 4.6. T-6:L2TP L2TP/IPsec[RFC3193] should support on MAP-E using with NAT Traversal[RFC3948]. All of CE succeeded. Tsuchiya, et al. Expires May 5, 2013 [Page 9] Internet-Draft IPv4 over IPv6 report Nov 2012 4.7. T-7:Instant Messaging and VoIP Verified functionality of Instant Messaging and VoIP tool that described on section 5.3 of [RFC6586] and facetime within same MAP-E CE, different MAP-E CEs and between MAP-E BR and CE. 4.7.1. Facebook on the web (http) All of combination basically succeeded. Tested both chat and video. 4.7.2. Facebook via a client (xmpp) All of combination succeeded. 4.7.3. Jabber.org chat service (xmpp) Not tested 4.7.4. Gmail chat on the web (http) All of combination basically succeeded. Tested chat,voice and video. 4.7.5. Gmail chat via a client (xmpp) All of combination basically succeeded. Tested chat,voice and video. 4.7.6. Google Talk client All of combination basically succeeded. Tested chat,voice and video. 4.7.7. AIM (AOL) All of combination basically succeeded. Tested chat,voice and video. 4.7.8. ICQ (AOL) All of combination basically succeeded. Tested chat,voice and video. 4.7.9. Skype All of combination basically succeeded. Tested chat,voice and video. 4.7.10. MSN All of combination basically succeeded. Tested chat,voice and video. Tsuchiya, et al. Expires May 5, 2013 [Page 10] Internet-Draft IPv4 over IPv6 report Nov 2012 4.7.11. Webex All of combination succeeded. Tested chat,voice and video in the meeting. 4.7.12. Sametime Not tested 4.7.13. facetime All of combination succeeded. 4.8. T-8:NAT verification tool Acording to Section-11 of [I-D.ietf-softwire-map], MAP CE should support [RFC4787], [RFC5508] and [RFC5382] . This section describes the result of MAP CEs which were verified by test tool. 4.8.1. T-8-1:RFC4787 STUN [RFC5389], NAT Behavior Discovery [RFC5780] and UDP hole punching are used for online game. [RFC4787] is Best Current Practise of NAT behavior requirement for UDP. Konami Digital Entertainment Co., Ltd. provided [RFC4787] verification tool. The test result will be update. REQ-1: Endpoint-Independent Mapping REQ-8: Filtering Behavior REQ-9: Hairpinning REQ-3: Port overloading 4.8.2. T-8-2:NAT-Analyzer [NAT-Analyzer] is JAVA applet in the browser to verify NAT functionality. The test result will be update. 4.9. Result summary Even DNS queries could occupy to MAP-E CE NAT table in this port restricted (only 15 ports) environments. Tsuchiya, et al. Expires May 5, 2013 [Page 11] Internet-Draft IPv4 over IPv6 report Nov 2012 There is two solution; one is specific short timer for DNS or UDP. Another is configured DNS transport proxy on MAP-E CE. As section-3 of [I-D.draft-dec-stateless-4v6] describes, MAP-E CE expected to act as a DNS resolver proxy, using native DNS over IPv6 to the SP network. IPv6 MTU expected as 1500byte, but some vendors had the implicit limitation which does not configured over 1280byte. It could not see a lot of site if the vendor which had limitation works as BR. Also there was complex issue even if the vendor works as CE. As section 10.1 of [I-D.ietf-softwire-map], IPv6 MTU in the MAP domain should configured well managed value. Most of modern applications and VPN protocols could use in multi vendor MAP-E[I-D.ietf-softwire-map]. But there is the difference of test result of [RFC4787] and FTP Active mode. It's depends on vendor's NAT implementation. 5. BR redundancy As MAP-E is stateless,so specific technic is not required for redundancy. Tested BR redundancy between 2 BRs by routing convergence. Skype session had been kept and could communicate after route convergence(about 2 sec). 6. Interoperability MAP-E stateless technology that means does not need maintenance of state machine. So there are no problem of interoperability. But there was one issue about "ipv6 interface identifier" from misunderstanding of section-6 of [I-D.ietf-softwire-map]. If it could add example to explain format in this section, then it would be more understandable. The issue is already fixed. Tsuchiya, et al. Expires May 5, 2013 [Page 12] Internet-Draft IPv4 over IPv6 report Nov 2012 7. Conclusion A lot of vendors already implemented MAP-E. There is no critical issue about interoperability between different vendor's CE and CE, CE and BR, BR and BR. Most of issue were already discussed on IETF. MAP-E [I-D.ietf-softwire-map] is mature. 8. Contributor Test netork Contributors Chisato Kashiwagi Chisato.Kashiwagi@ipinfusion.com Shuuichi Saito shuu@fnsc.co.jp Takuya Iimura tiimura@cisco.com Tomoki Murai murai@fnsc.co.jp Tomoyuki Sahara tsahara@iij.ad.jp Ryo Sato sr.10005@konami.com Motohiko Sato sm.64846@konami.com Congxiao Bao congxiao@cernet.edu.cn Guoliang Han bupthgl@gmail.com Kohei Ono Kohei.Ono@ipinfusion.com Naohide Kamitani kamitani@fnsc.co.jp Masakazu Asama m-asama@ginzado.ne.jp Kazuhiko Satoyoshi satoyoshi@soundnet.yamaha.co.jp Takehiro Sukizaki sukizaki@soundnet.yamaha.co.jp Tetsuya Innami tinnami@cisco.com Satoshi Kubota sa-kubota@jpne.co.jp Yuji Yamazaki yuji.yamazaki@g.softbank.co.jp Satoru Matsushima satoru.matsushima@gmail.com Kaoru Oka kaoru.oka@g.softbank.co.jp Miki Takata miki@baking.jp Takayuki Osabe osabet@nscs.jp Satoshi Ebe satoshie@nscs.jp Yasuyuki Kaneko yasuyuki.kaneko@global-netcore.jp Maoke Chen fibrib@gmail.com 9. Acknowledgements The author would like to thanks NS Comuputer Service, ENOG and JANOG committee. The authors would like to thank you Satoru Matsushima, Seiichi Kawamura for their thorough review and comments. Tsuchiya, et al. Expires May 5, 2013 [Page 13] Internet-Draft IPv4 over IPv6 report Nov 2012 10. IANA Considerations This document has no actions for IANA. 11. Security Considerations There is no additional security requirement. 12. References 12.1. Normative References [I-D.dec-stateless-4v6] Dec, W., "Stateless 4via6 Address Sharing", draft-dec-stateless-4v6-00 (work in progress), March 2011. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, S., and T. Murakami, "Mapping of Address and Port (MAP)", draft-ietf-softwire-map-00 (work in progress), June 2012. [I-D.murakami-softwire-4rd] Murakami, T. and O. Troan, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-00 (work in progress), July 2011. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. Tsuchiya, et al. Expires May 5, 2013 [Page 14] Internet-Draft IPv4 over IPv6 report Nov 2012 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009. [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010. [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. 12.2. Informative References [2743314] ""Microsoft Security Advisory (2743314) Unencapsulated MS- CHAP v2 Authentication Could Allow Information Disclosure "", . [ENOG] ""Echigo Network Operators' Group"", . [I-D.ietf-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-ietf-softwire-stateless-4v6-motivation-00 (work in progress), September 2011. [JANOG] ""JApan Network Operators Group"", . [NAT-Analyzer] ""Network Measurement Activites at TUM"", . [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. Tsuchiya, et al. Expires May 5, 2013 [Page 15] Internet-Draft IPv4 over IPv6 report Nov 2012 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011. URIs [1] Appendix A. Additional Stuff Tsuchiya, et al. Expires May 5, 2013 [Page 16] Internet-Draft IPv4 over IPv6 report Nov 2012 A.1. test network toplogy and parameters .--. _(. `) _( IPv4 `)_ ( Internet `) ( ` . ) ) `--(_______)---' | +----------+ | MAP-E BR | +----------+ MAP-E BR IPv6 address | 2403:9200:fff0:0::2 .--. _(. `) _( IPv6 `)_ ( Backbone `) Rule IPv6 prefix:2403:9200::/32 ( ` . ) ) Rule IPv4 prefix:203.86.225.0/28 `--(_______)---' CE IPv6 prefix: | 2403:9200:fff1::/48 - 2403:9200:fff7::/48 | EA bits:16bit(48-32) | Port-Set ID:12bit +---------------+ PSID offset:4 | IPv6 Switch | Tunnel Interface IPv4 MTU: 1460 +---------------+ | | | Figure 1 A.2. Configuration A.2.1. IP Infusion NetBSD 4.0.1:BR ---- MAP tunnel I/F ---- # cat /etc/ifconfig.map0 up mtu 1460 inet 10.99.99.1/24 rule_ipv6_prefix 2403:9200::/32 rule_ipv4_prefix 203.86.225.0/28 rule_eabits_length 16 psid_offset 4 encap_src_check 0 fmr 1 Tsuchiya, et al. Expires May 5, 2013 [Page 17] Internet-Draft IPv4 over IPv6 report Nov 2012 A.2.2. IP Infusion Linux 2.6.18:BR ---- MAP tunnel I/F ---- ip -6 tunnel change map1 rule_ipv6_prefix 2403:9200::/32 ip -6 tunnel change map1 rule_ipv4_prefix 203.86.225.0/28 ip -6 tunnel change map1 rule_eabits_length 16 ip -6 tunnel change map1 psid_offset 4 ip -6 tunnel change map1 fmr 1 ip -6 tunnel change map1 map_autosetaddr 1 ip -6 tunnel change map1 map_autosetgw 1 ip -4 addr add 203.86.225.18/30 dev map1 A.2.3. Furukawa Network Solution Corp.:BR ! interface tunnel 1 tunnel mode ipinip ipv4 ipv6-tunnel-profile 1 exit ! ipv4 ipv6-tunnel-profile 1 profile-mode map-encap rule-ipv4-prefix 203.86.225.0/28 rule-ipv6-prefix 2403:9200::/32 user-len 16 source-address 2403:9200:fff0::2 exit A.2.4. Vyatta ASAMAP:BR interfaces { loopback lo { } map map0 { br-address 2403:9200:fff0::2/64 default-forwarding-mode encapsulation default-forwarding-rule true role br rule 1 { ea-length 16 ipv4-prefix 203.86.225.0/28 ipv6-prefix 2403:9200::/32 } } Tsuchiya, et al. Expires May 5, 2013 [Page 18] Internet-Draft IPv4 over IPv6 report Nov 2012 A.2.5. Internet Initiative Japan Inc. SEIL:BR interface frd0 mtu 1460 frd mode br frd br-address 2403:9200:fff0::2 frd rule add R0 external-ipv4-prefix 203.86.225.0/28 internal-ipv6-prefix 2403:9200::/32 index-length 16 psid-offset 4 A.2.6. Cisco IOS-XR:BR ! interface ServiceApp5 ipv4 address 203.0.113.5 255.255.255.252 load-interval 30 service cgn JANOG service-type map-e logging events link-status ! interface ServiceApp6 ipv6 address 2001:db8:1:1::1/64 load-interval 30 service cgn JANOG service-type map-e logging events link-status ! interface ServiceInfra1 ipv4 address 203.0.113.1 255.255.255.252 service-location 0/0/CPU0 ! service cgn JANOG service-location preferred-active 0/0/CPU0 service-type map-e Softwire cpe-domain ipv4 prefix 203.86.225.0/28 cpe-domain ipv6 prefix 2403:9200::/32 sharing-ratio 12 aftr-endpoint-address 2403:9200:fff0::2 contiguous-ports 0 address-family ipv4 interface ServiceApp5 ! address-family ipv6 interface ServiceApp6 ! end A.2.7. IP Infusion NetBSD 4.0.1:CE Tsuchiya, et al. Expires May 5, 2013 [Page 19] Internet-Draft IPv4 over IPv6 report Nov 2012 -- ifconfig.map0 -- actual MAP-E parameter up mtu 1460 rule_ipv6_prefix 2403:9200::/32 rule_ipv4_prefix 203.86.225.0/28 lan_if_name any wan_if_name lo1 map_autosetaddr 1 map_autosetgw 1 rule_eabits_length 16 psid_offset 4 map_border_router 2403:9200:fff0:0::2 map_mss auto fmr 1 A.2.8. IP Infusion Linux 2.6.18:CE ---- MAP tunnel I/F ---- ip -6 tunnel change map1 rule_ipv6_prefix 2403:9200::/32 ip -6 tunnel change map1 rule_ipv4_prefix 203.86.225.0/28 ip -6 tunnel change map1 rule_eabits_length 16 ip -6 tunnel change map1 psid_offset 4 ip -6 tunnel change map1 map_border_router 2403:9200:fff0:0::2 ip -6 tunnel change map1 fmr 1 ip -6 tunnel change map1 map_autosetaddr 1 ip -6 tunnel change map1 map_autosetgw 1 A.2.9. Furukawa Network Solution Corp.:CE ip nat ap_pool ADDR-POOL1 ipv6-mape-profile 1 exit ip ipv6-mape-profile 1 user-len 16 br-address 2403:9200:fff0:0::2 rule-ipv6-prefix reference-interface loopback 1 rule-ipv6-prefix-len 32 rule-ipv4-prefix 203.86.225.0 255.255.255.240 exit interface tunnel 1 tunnel mode ipip ipv6-mape-profile 1 tunnel source reference-interface ipv6 loopback 1 ip mtu 1460 ip nat inside source list 10 ap_pool ADDR-POOL1 exit Tsuchiya, et al. Expires May 5, 2013 [Page 20] Internet-Draft IPv4 over IPv6 report Nov 2012 A.2.10. Vyatta ASAMAP:CE interfaces { map map0 { br-address 2403:9200:fff0::2/64 default-forwarding-mode encapsulation default-forwarding-rule true role ce rule 1 { ea-length 16 ipv4-prefix 203.86.225.0/28 ipv6-prefix 2403:9200::/32 } tunnel-source eth1 } A.2.11. Internet Initiative Japan Inc. SEIL:CE interface frd0 mtu 1460 interface frd0 tcp-mss 1420 nat napt add private 192.168.1.0-192.168.1.255 interface frd0 nat option port-assignment random frd mode ce frd ce-address 2403:9200:fff6:0:cb:56e1:f0f:f600 frd br-address 2403:9200:fff0::2 frd rule add R0 external-ipv4-prefix 203.86.225.0/28 internal-ipv6-prefix 2403:9200::/32 index-length 16 psid-offset 4 A.2.12. Yamaha :CE tunnel select 1 tunnel encapsulation ipip tunnel endpoint address 2403:9200:fff7:0:cb:56e1:f0f:f700 2403:9200:fff0::2 tunnel map-e 203.86.225.0/28 2403:9200::/32 16 4 ::2 ip tunnel mtu 1460 ip tunnel nat descriptor 1000 tunnel enable 1 nat descriptor type 1000 masquerade nat descriptor timer 1000 30 nat descriptor timer 1000 tcpfin 5 nat descriptor address outer 1000 map-e A.2.13. CERNET OpenWRT :CE Tsuchiya, et al. Expires May 5, 2013 [Page 21] Internet-Draft IPv4 over IPv6 report Nov 2012 # configure eth1 -- IPv4 interface ifconfig br-lan 192.168.1.1/24 ./control start #janog softwire interop event utils/ivictl -r -d -P 2403:9200:fff0:0::2/128 utils/ivictr -r -p 203.86.225.0/28 -P 2403:9200::/32 -R 4096 - M 1 -f -E utils/ivictr -s -i br-lan -I eth0.1 -H -N -a 192.168.1.0/24 -A 203.86.225.1/28 -P 2403:9200::/32 -R 4096 - M 1 -o 4 -f -c 1400 -E service iptables stop service ip6tables stop Authors' Addresses Shishio Tsuchiya (editor) Cisco Systems Midtown Tower, 9-7-1,Akasaka Minato-Ku, Tokyo 107-6227 Japan Phone: +81 3 6434 6543 Email: shtsuchi@cisco.com Shuichi Ohkubo Sakura Internet 33F Sumitomo fudosan Nishi shinjuku Bldg.,7-20-1 Nishi shinjuku Shinjuku-Ku, Tokyo 160-0023 Japan Phone: +81 3 5332 7070 Email: ohkubo@sakura.ad.jp Yuya Kawakami INTERNET MULTIFEED CO. OTEMACHI 1st.SQUARE EAST TOWER,3F 1-5-1,Otemachi, Chiyoda-ku, Tokyo 100-0004 Japan Phone: +81 3 3282 1040 Email: kawakami@mfeed.ad.jp Tsuchiya, et al. Expires May 5, 2013 [Page 22]