Internet DRAFT - draft-janog-softwire-report
draft-janog-softwire-report
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
"", <http://technet.microsoft.com/en-us/security/advisory/
2743314>.
[ENOG] ""Echigo Network Operators' Group"", <http://enog.jp/>.
[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"",
<http://www.janog.gr.jp/en>.
[NAT-Analyzer]
""Network Measurement Activites at TUM"",
<http://nattest.net.in.tum.de/>.
[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] <http://6lab.cisco.com/map/
MAP.php?W1siUnVsZSAwIiwiMjQwMzo5MjAwOjA6MC8zMiIsIjIwMy44Ni4yMjUu
MC8yOCIsMTYsNCwxXV0=>
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]
