[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/