idnits 2.17.1 draft-janog-softwire-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 57 characters in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 14 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 547 has weird spacing: '... Sahara tsaha...' == Line 550 has weird spacing: '...iao Bao congx...' == Line 551 has weird spacing: '...ang Han bupth...' == Line 556 has weird spacing: '...ukizaki sukiz...' -- The document date (Nov 2012) is 4181 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5382' is mentioned on line 453, but not defined == Missing Reference: 'RFC2428' is mentioned on line 364, but not defined == Missing Reference: 'RFC5389' is mentioned on line 458, but not defined ** Obsolete undefined reference: RFC 5389 (Obsoleted by RFC 8489) == Missing Reference: 'I-D.draft-dec-stateless-4v6' is mentioned on line 488, but not defined == Unused Reference: 'I-D.dec-stateless-4v6' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.murakami-softwire-4rd' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'ENOG' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-stateless-4v6-motivation' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC3849' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC5387' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC5952' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC6104' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC6145' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 692, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-dec-stateless-4v6-00 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-00 == Outdated reference: A later version (-01) exists of draft-murakami-softwire-4rd-00 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-05) exists of draft-ietf-softwire-stateless-4v6-motivation-00 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 4 errors (**), 0 flaws (~~), 31 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Tsuchiya, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational S. Ohkubo 5 Expires: May 5, 2013 Sakura Internet 6 Y. Kawakami 7 INTERNET MULTIFEED CO. 8 Nov 2012 10 Stateless IPv4 over IPv6 report 11 draft-janog-softwire-report-01 13 Abstract 15 Stateless IPv4 over IPv6 tunnel such as MAP(Mapping of Address and 16 Port) designs to support IPv4 over IPv6 island and resolve IPv4 17 shortage problem by Address and Port Mapping technique. 19 This document describes supported vendor's implementation, ipv4 20 functionality over IPv6 and interoperability report. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 5, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Implementation Report . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Participant List . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.1. MAP-E Border Relay (BR) . . . . . . . . . . . . . . . 4 60 2.1.2. MAP-E Customer Edge (CE) . . . . . . . . . . . . . . . 5 61 2.2. Security mechanism . . . . . . . . . . . . . . . . . . . . 5 62 2.2.1. Question . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.2. Typical implementation . . . . . . . . . . . . . . . . 5 64 2.3. Provisioning method . . . . . . . . . . . . . . . . . . . 6 65 2.4. Reachability to BR address . . . . . . . . . . . . . . . . 6 66 3. Test Parameter . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. IPv4 functionality over IPv6 . . . . . . . . . . . . . . . . . 7 68 4.1. T-1:ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. T-2:IPSec VPN . . . . . . . . . . . . . . . . . . . . . . 9 70 4.3. T-3:SSL VPN . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4. T-4:FTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.5. T-5:PPTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.6. T-6:L2TP . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.7. T-7:Instant Messaging and VoIP . . . . . . . . . . . . . . 10 75 4.7.1. Facebook on the web (http) . . . . . . . . . . . . . . 10 76 4.7.2. Facebook via a client (xmpp) . . . . . . . . . . . . . 10 77 4.7.3. Jabber.org chat service (xmpp) . . . . . . . . . . . . 10 78 4.7.4. Gmail chat on the web (http) . . . . . . . . . . . . . 10 79 4.7.5. Gmail chat via a client (xmpp) . . . . . . . . . . . . 10 80 4.7.6. Google Talk client . . . . . . . . . . . . . . . . . . 10 81 4.7.7. AIM (AOL) . . . . . . . . . . . . . . . . . . . . . . 10 82 4.7.8. ICQ (AOL) . . . . . . . . . . . . . . . . . . . . . . 10 83 4.7.9. Skype . . . . . . . . . . . . . . . . . . . . . . . . 10 84 4.7.10. MSN . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.7.11. Webex . . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.7.12. Sametime . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.7.13. facetime . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.8. T-8:NAT verification tool . . . . . . . . . . . . . . . . 11 89 4.8.1. T-8-1:RFC4787 . . . . . . . . . . . . . . . . . . . . 11 90 4.8.2. T-8-2:NAT-Analyzer . . . . . . . . . . . . . . . . . . 11 91 4.9. Result summary . . . . . . . . . . . . . . . . . . . . . . 11 92 5. BR redundancy . . . . . . . . . . . . . . . . . . . . . . . . 12 93 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 12 94 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 102 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 103 A.1. test network toplogy and parameters . . . . . . . . . . . 17 104 A.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 17 105 A.2.1. IP Infusion NetBSD 4.0.1:BR . . . . . . . . . . . . . 17 106 A.2.2. IP Infusion Linux 2.6.18:BR . . . . . . . . . . . . . 18 107 A.2.3. Furukawa Network Solution Corp.:BR . . . . . . . . . . 18 108 A.2.4. Vyatta ASAMAP:BR . . . . . . . . . . . . . . . . . . . 18 109 A.2.5. Internet Initiative Japan Inc. SEIL:BR . . . . . . . . 19 110 A.2.6. Cisco IOS-XR:BR . . . . . . . . . . . . . . . . . . . 19 111 A.2.7. IP Infusion NetBSD 4.0.1:CE . . . . . . . . . . . . . 19 112 A.2.8. IP Infusion Linux 2.6.18:CE . . . . . . . . . . . . . 20 113 A.2.9. Furukawa Network Solution Corp.:CE . . . . . . . . . . 20 114 A.2.10. Vyatta ASAMAP:CE . . . . . . . . . . . . . . . . . . . 21 115 A.2.11. Internet Initiative Japan Inc. SEIL:CE . . . . . . . . 21 116 A.2.12. Yamaha :CE . . . . . . . . . . . . . . . . . . . . . . 21 117 A.2.13. CERNET OpenWRT :CE . . . . . . . . . . . . . . . . . . 21 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 120 1. Introduction 122 Stateless IPv4 over IPv6 tunnel such as MAP(Mapping of Address and 123 Port) designs to support IPv4 over IPv6 island and resolve IPv4 124 shortage problem by Address and Port Mapping technique. 126 JApan Network Operators Group [JANOG] made a Working Group to 127 evaluate this feature. 129 7 vendors and 9 implementations attended to the interop events which 130 hold at Nagaoka city of Niigata, Japan. 132 This document describes MAP-E [I-D.ietf-softwire-map] supported 133 vendor's implementation, ipv4 functionality over IPv6 and 134 interoperability report. 136 2. Implementation Report 138 MAP-E [I-D.ietf-softwire-map] is already supported by a lot of 139 vendors. The total number was 7 vendors and 9 implementations at 140 this point. 142 In this section, describes about interop event participant list, 143 security mechanism and provisioning method and reachability to BR 144 address. 146 2.1. Participant List 148 2.1.1. MAP-E Border Relay (BR) 150 +---------------------------------+----------------+ 151 | Vendor | OS/Equipment | 152 +---------------------------------+----------------+ 153 | IP Infusion | Linux 2.6.18 | 154 | IP Infusion | NetBSD 4.0.1 | 155 | Furukawa Network Solution Corp. | FX5000 | 156 | ASAMAP | Vyatta | 157 | Internet Initiative Japan Inc. | SEIL/X1 | 158 | Cisco Systems | IOS-XR/ASR9000 | 159 +---------------------------------+----------------+ 161 2.1.2. MAP-E Customer Edge (CE) 163 +---------------------------------+--------------+ 164 | Vendor | OS/Equipment | 165 +---------------------------------+--------------+ 166 | IP Infusion | Linux 2.6.18 | 167 | IP Infusion | NetBSD 4.0.1 | 168 | Furukawa Network Solution Corp. | F60W | 169 | ASAMAP | Vyatta | 170 | CERNET | OpenWRT | 171 | Internet Initiative Japan Inc. | SEIL/X1 | 172 | Yamaha Corporation | RTX1200 | 173 +---------------------------------+--------------+ 175 2.2. Security mechanism 177 We took a survey to participant about security considerations which 178 is described on Section 13 of [I-D.ietf-softwire-map]. 180 2.2.1. Question 182 Q1. How to behave when CE/BR receives IPv4 packets which does not 183 match MAP cpe domain? 185 Q2. How to behave when CE/BR receives IPv6 packets which has 186 inconsistency between IPv6 src address and IPv4 src address? 188 Q3. How to behave when CE/BR receives IPv6 packets which has 189 inconsistency between IPv6 dst address and IPv4 dst address? 191 Q4. How to behave when CE receives IPv6 packets which is not from BR 192 address? 194 2.2.2. Typical implementation 196 A1. Most of vendor look up IP routing table, then routing to next 197 hop or drops. But some vendors check routing table at first, then 198 check consistency between the Rule IPv4 prefix and IPv4 destination 199 packets. As the result, routing to next hop or drops. 201 A2. All of BRs checks inconsistency between IPv6 src address and 202 IPv4 src address. Most of CE checks inconsistency between IPv6 src 203 address and IPv4 src address. If IPv6 src address is included in the 204 Rule IPv6 prefix then validates IPv4 src address. If the src address 205 is BR address, then it does not validate. 207 A3. Most of BR only checks whether the IPv6 dst address is BR 208 address. Most of CE validates inconsistency between IPv6 dst address 209 and IPv4 dst address before NAT process. 211 A4. Depends on configuration. If CE is configured as "Hub and Spoke 212 mode" or permit only from BR address, then the packets will be 213 dropped. If CE is configured as "Mesh mode" or no filter, then 214 packets will transit. 216 2.3. Provisioning method 218 Section 7 of [I-D.ietf-softwire-map] describes configuration of 219 MAP-E. All of CE and BR who attended the event are supported manual 220 configuration only at this time. 222 Most of vendors directly configures "Length of EA bits", but some 223 vendors configures "sharing ratio" and "contiguous-ports", "length of 224 EA bits" would be calculated as the result. 226 The former configuration type would be useful for operation and 227 trouble shooting, because "rule in the packets" is visible on 228 configurations. 230 On the other hand, latter type configuration would be easy to 231 understand design such as how many user will be shared one address. 233 2.4. Reachability to BR address 235 3 BR implementations are required to configure BR address as 236 interface address. 238 The rest of 2 BR implementations must not configure BR address as 239 interface address. 241 The former implementation, can confirm reachability of BR address 242 from IPv6 network. But latter implementation, can not confirm 243 reachability to BR address but of course can confirm reachability to 244 BR themselves. 246 3. Test Parameter 248 MAP-E Parameter 249 +----------------------+-------------------------------------------+ 250 | Parameter | Value | 251 +----------------------+-------------------------------------------+ 252 | Rule IPv6 prefix | 2403:9200::/32 | 253 | Rule IPv4 prefix | 203.86.225.0/28 | 254 | End-user IPv6 prefix | 2403:9200:fff1::/48 - 2403:9200:fff7::/48 | 255 | EA bits | 16bit(48-32) | 256 | Port-Set ID | 12bit | 257 | PSID offset | 4 | 258 | BR IPv6 address | 2403:9200:fff0:0::2 | 259 | Topology | Mesh | 260 +----------------------+-------------------------------------------+ 262 Each of MAP-E has only 15 TCP/UDP ports,1 IP address is shared by 263 4096 users. 265 MAP Simulation Tool shows this rule. [1] 267 MTU Parameter 269 +-----------+----------+---------------+--------------------+ 270 | Parameter | IPv6 MTU | TCP MSS clamp | Tunnel IF IPv4 MTU | 271 +-----------+----------+---------------+--------------------+ 272 | Value | 1500byte | Enable | 1460byte | 273 +-----------+----------+---------------+--------------------+ 275 4. IPv4 functionality over IPv6 277 MAP-E [I-D.ietf-softwire-map] uses A+P technologies with NAT44. 278 Basic NAT requirement is defined as [RFC4787], [RFC5508] and 279 [RFC5382]. But there is difference of implementation among vendors. 280 ALG support also depends on vendors implementations. 282 4.1. T-1:ICMP 284 Section 9 of [I-D.ietf-softwire-map] describes about ICMP handling in 285 MAP domain. 287 T-1-1: echo request/echo reply 289 Confirmed from MAP-E CE network to global internet. 291 Echo request (ICMP type 8 code 0) has identifier, so MAP-E CE has to 292 rewrite this field from ports-set value. Echo reply(ICMP type 0 code 293 0) has same identifier as echo request. MAP-BR must handle from this 294 identifier field. 296 Therefore the test could confirm capability of ICMP both CE and BR. 298 All of CE and BR are supported this feature. 300 T-1-2: Host Unreachable 302 Confirmed from MAP-E CE network to global internet. 304 Layer3 switch reply "Host unreachable" (ICMP type 3 code 1) message, 305 the message does not has identifier field. So MAP-BR has to inspect 306 ICMP payload. 308 The test could confirm capability to handling for null identifier 309 ICMP of MAP-BR. 311 3 BR already supported this feature.2 BR does not support this 312 feature at this time. 314 T-1-3: TTL equals 0 during transit 316 Confirmed traceroute from MAP-E CE network to global internet. 318 Layer3 switch reply "TTL equals 0 during transit" (ICMP type 11 code 319 0) message, the message does not has identifier field. So MAP-BR has 320 to inspect ICMP payload. 322 The test could confirm capability to handling for null identifier 323 ICMP of MAP-BR. 325 3 BR already supported this feature.2 BR does not support this 326 feature at this time. 328 T-1-4: Fragmentation needed but no frag. bit set 330 Confirmed Echo with DF-bit from MAP-E CE network to global internet. 332 Layer3 switch reply "Fragmentation needed but no frag. bit set" (ICMP 333 type 3 code 4) message, the message does not has identifier field. 334 So MAP-BR has to inspect ICMP payload. 336 The test could confirm capability to handling for null identifier 337 ICMP of MAP-BR. 339 3 BR already supported this feature.2 BR does not support this 340 feature at this time. 342 4.2. T-2:IPSec VPN 344 IPSec VPN [RFC2401] uses ESP packets, therefore MAP-E CE should 345 support NAT traversal [RFC3948]. 347 T-2-1:IPSec 349 All of CE failed.This result is expected behavior. 351 T-2-2:IPSec VPN(UDP:NAT Traversal) 353 All of CE succeeded. 355 4.3. T-3:SSL VPN 357 It should be no problem, because SSL VPN[RFC4347] uses TCP sockets. 359 All of CE succeeded. 361 4.4. T-4:FTP 363 FTP[RFC0959] PORT(Active) and PASV(Passive) mode had sometimes 364 problem in NAT44. [RFC2428] is enhancement FTP for IPv6/NAT. MAP-E 365 devices may need support FTP ALG if the customer required FTP Active 366 mode. 368 T-4-1:Passive(PASV) mode 370 All of CE succeeded. 372 T-4-2:Active(PORT) mode 374 Only 2 vendor's CE succeeded. 376 4.5. T-5:PPTP 378 PPTP[RFC2637] uses GRE and TCP port 1723. Unless configuring to pass 379 GRE and TCP port 1723, can not use PPTP on MAP-E .NOTE:Microsoft is 380 warning use of PPTP due to security reason. [2743314] 382 All of CE failed.This result is expected behavior. 384 4.6. T-6:L2TP 386 L2TP/IPsec[RFC3193] should support on MAP-E using with NAT 387 Traversal[RFC3948]. 389 All of CE succeeded. 391 4.7. T-7:Instant Messaging and VoIP 393 Verified functionality of Instant Messaging and VoIP tool that 394 described on section 5.3 of [RFC6586] and facetime within same MAP-E 395 CE, different MAP-E CEs and between MAP-E BR and CE. 397 4.7.1. Facebook on the web (http) 399 All of combination basically succeeded. Tested both chat and video. 401 4.7.2. Facebook via a client (xmpp) 403 All of combination succeeded. 405 4.7.3. Jabber.org chat service (xmpp) 407 Not tested 409 4.7.4. Gmail chat on the web (http) 411 All of combination basically succeeded. Tested chat,voice and video. 413 4.7.5. Gmail chat via a client (xmpp) 415 All of combination basically succeeded. Tested chat,voice and video. 417 4.7.6. Google Talk client 419 All of combination basically succeeded. Tested chat,voice and video. 421 4.7.7. AIM (AOL) 423 All of combination basically succeeded. Tested chat,voice and video. 425 4.7.8. ICQ (AOL) 427 All of combination basically succeeded. Tested chat,voice and video. 429 4.7.9. Skype 431 All of combination basically succeeded. Tested chat,voice and video. 433 4.7.10. MSN 435 All of combination basically succeeded. Tested chat,voice and video. 437 4.7.11. Webex 439 All of combination succeeded. Tested chat,voice and video in the 440 meeting. 442 4.7.12. Sametime 444 Not tested 446 4.7.13. facetime 448 All of combination succeeded. 450 4.8. T-8:NAT verification tool 452 Acording to Section-11 of [I-D.ietf-softwire-map], MAP CE should 453 support [RFC4787], [RFC5508] and [RFC5382] . This section describes 454 the result of MAP CEs which were verified by test tool. 456 4.8.1. T-8-1:RFC4787 458 STUN [RFC5389], NAT Behavior Discovery [RFC5780] and UDP hole 459 punching are used for online game. [RFC4787] is Best Current 460 Practise of NAT behavior requirement for UDP. Konami Digital 461 Entertainment Co., Ltd. provided [RFC4787] verification tool. 463 The test result will be update. 465 REQ-1: Endpoint-Independent Mapping 467 REQ-8: Filtering Behavior 469 REQ-9: Hairpinning 471 REQ-3: Port overloading 473 4.8.2. T-8-2:NAT-Analyzer 475 [NAT-Analyzer] is JAVA applet in the browser to verify NAT 476 functionality. 478 The test result will be update. 480 4.9. Result summary 482 Even DNS queries could occupy to MAP-E CE NAT table in this port 483 restricted (only 15 ports) environments. 485 There is two solution; one is specific short timer for DNS or UDP. 486 Another is configured DNS transport proxy on MAP-E CE. 488 As section-3 of [I-D.draft-dec-stateless-4v6] describes, MAP-E CE 489 expected to act as a DNS resolver proxy, using native DNS over IPv6 490 to the SP network. 492 IPv6 MTU expected as 1500byte, but some vendors had the implicit 493 limitation which does not configured over 1280byte. It could not see 494 a lot of site if the vendor which had limitation works as BR. Also 495 there was complex issue even if the vendor works as CE. 497 As section 10.1 of [I-D.ietf-softwire-map], IPv6 MTU in the MAP 498 domain should configured well managed value. 500 Most of modern applications and VPN protocols could use in multi 501 vendor MAP-E[I-D.ietf-softwire-map]. 503 But there is the difference of test result of [RFC4787] and FTP 504 Active mode. It's depends on vendor's NAT implementation. 506 5. BR redundancy 508 As MAP-E is stateless,so specific technic is not required for 509 redundancy. 511 Tested BR redundancy between 2 BRs by routing convergence. Skype 512 session had been kept and could communicate after route 513 convergence(about 2 sec). 515 6. Interoperability 517 MAP-E stateless technology that means does not need maintenance of 518 state machine. So there are no problem of interoperability. 520 But there was one issue about "ipv6 interface identifier" from 521 misunderstanding of section-6 of [I-D.ietf-softwire-map]. 523 If it could add example to explain format in this section, then it 524 would be more understandable. 526 The issue is already fixed. 528 7. Conclusion 530 A lot of vendors already implemented MAP-E. 532 There is no critical issue about interoperability between different 533 vendor's CE and CE, CE and BR, BR and BR. 535 Most of issue were already discussed on IETF. 537 MAP-E [I-D.ietf-softwire-map] is mature. 539 8. Contributor 541 Test netork Contributors 543 Chisato Kashiwagi Chisato.Kashiwagi@ipinfusion.com 544 Shuuichi Saito shuu@fnsc.co.jp 545 Takuya Iimura tiimura@cisco.com 546 Tomoki Murai murai@fnsc.co.jp 547 Tomoyuki Sahara tsahara@iij.ad.jp 548 Ryo Sato sr.10005@konami.com 549 Motohiko Sato sm.64846@konami.com 550 Congxiao Bao congxiao@cernet.edu.cn 551 Guoliang Han bupthgl@gmail.com 552 Kohei Ono Kohei.Ono@ipinfusion.com 553 Naohide Kamitani kamitani@fnsc.co.jp 554 Masakazu Asama m-asama@ginzado.ne.jp 555 Kazuhiko Satoyoshi satoyoshi@soundnet.yamaha.co.jp 556 Takehiro Sukizaki sukizaki@soundnet.yamaha.co.jp 557 Tetsuya Innami tinnami@cisco.com 558 Satoshi Kubota sa-kubota@jpne.co.jp 559 Yuji Yamazaki yuji.yamazaki@g.softbank.co.jp 560 Satoru Matsushima satoru.matsushima@gmail.com 561 Kaoru Oka kaoru.oka@g.softbank.co.jp 562 Miki Takata miki@baking.jp 563 Takayuki Osabe osabet@nscs.jp 564 Satoshi Ebe satoshie@nscs.jp 565 Yasuyuki Kaneko yasuyuki.kaneko@global-netcore.jp 566 Maoke Chen fibrib@gmail.com 568 9. Acknowledgements 570 The author would like to thanks NS Comuputer Service, ENOG and JANOG 571 committee. The authors would like to thank you Satoru Matsushima, 572 Seiichi Kawamura for their thorough review and comments. 574 10. IANA Considerations 576 This document has no actions for IANA. 578 11. Security Considerations 580 There is no additional security requirement. 582 12. References 584 12.1. Normative References 586 [I-D.dec-stateless-4v6] 587 Dec, W., "Stateless 4via6 Address Sharing", 588 draft-dec-stateless-4v6-00 (work in progress), March 2011. 590 [I-D.ietf-softwire-map] 591 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 592 S., and T. Murakami, "Mapping of Address and Port (MAP)", 593 draft-ietf-softwire-map-00 (work in progress), June 2012. 595 [I-D.murakami-softwire-4rd] 596 Murakami, T. and O. Troan, "IPv4 Residual Deployment on 597 IPv6 infrastructure - protocol specification", 598 draft-murakami-softwire-4rd-00 (work in progress), 599 July 2011. 601 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 602 STD 9, RFC 959, October 1985. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 608 Internet Protocol", RFC 2401, November 1998. 610 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 611 W., and G. Zorn, "Point-to-Point Tunneling Protocol", 612 RFC 2637, July 1999. 614 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 615 "Securing L2TP using IPsec", RFC 3193, November 2001. 617 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 618 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 619 RFC 3948, January 2005. 621 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 622 Security", RFC 4347, April 2006. 624 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 625 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 626 RFC 4787, January 2007. 628 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 629 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 630 April 2009. 632 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 633 Using Session Traversal Utilities for NAT (STUN)", 634 RFC 5780, May 2010. 636 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 637 Network", RFC 6586, April 2012. 639 12.2. Informative References 641 [2743314] ""Microsoft Security Advisory (2743314) Unencapsulated MS- 642 CHAP v2 Authentication Could Allow Information Disclosure 643 "", . 646 [ENOG] ""Echigo Network Operators' Group"", . 648 [I-D.ietf-softwire-stateless-4v6-motivation] 649 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 650 Borges, I., and G. Chen, "Motivations for Stateless IPv4 651 over IPv6 Migration Solutions", 652 draft-ietf-softwire-stateless-4v6-motivation-00 (work in 653 progress), September 2011. 655 [JANOG] ""JApan Network Operators Group"", 656 . 658 [NAT-Analyzer] 659 ""Network Measurement Activites at TUM"", 660 . 662 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 663 Reserved for Documentation", RFC 3849, July 2004. 665 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 666 Message Protocol (ICMPv6) for the Internet Protocol 667 Version 6 (IPv6) Specification", RFC 4443, March 2006. 669 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 670 Applicability Statement for Better-Than-Nothing Security 671 (BTNS)", RFC 5387, November 2008. 673 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 674 Infrastructures (6rd)", RFC 5569, January 2010. 676 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 677 Reserved for Documentation", RFC 5737, January 2010. 679 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 680 Address Text Representation", RFC 5952, August 2010. 682 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 683 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 684 October 2010. 686 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 687 Problem Statement", RFC 6104, February 2011. 689 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 690 Algorithm", RFC 6145, April 2011. 692 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 693 IPv4 Address Shortage", RFC 6346, August 2011. 695 URIs 697 [1] 701 Appendix A. Additional Stuff 702 A.1. test network toplogy and parameters 704 .--. 705 _(. `) 706 _( IPv4 `)_ 707 ( Internet `) 708 ( ` . ) ) 709 `--(_______)---' 710 | 711 +----------+ 712 | MAP-E BR | 713 +----------+ MAP-E BR IPv6 address 714 | 2403:9200:fff0:0::2 715 .--. 716 _(. `) 717 _( IPv6 `)_ 718 ( Backbone `) Rule IPv6 prefix:2403:9200::/32 719 ( ` . ) ) Rule IPv4 prefix:203.86.225.0/28 720 `--(_______)---' CE IPv6 prefix: 721 | 2403:9200:fff1::/48 - 2403:9200:fff7::/48 722 | EA bits:16bit(48-32) 723 | Port-Set ID:12bit 724 +---------------+ PSID offset:4 725 | IPv6 Switch | Tunnel Interface IPv4 MTU: 1460 726 +---------------+ 727 | | | 729 Figure 1 731 A.2. Configuration 733 A.2.1. IP Infusion NetBSD 4.0.1:BR 735 ---- MAP tunnel I/F ---- 736 # cat /etc/ifconfig.map0 737 up 738 mtu 1460 739 inet 10.99.99.1/24 740 rule_ipv6_prefix 2403:9200::/32 741 rule_ipv4_prefix 203.86.225.0/28 742 rule_eabits_length 16 743 psid_offset 4 744 encap_src_check 0 745 fmr 1 747 A.2.2. IP Infusion Linux 2.6.18:BR 749 ---- MAP tunnel I/F ---- 750 ip -6 tunnel change map1 rule_ipv6_prefix 2403:9200::/32 751 ip -6 tunnel change map1 rule_ipv4_prefix 203.86.225.0/28 752 ip -6 tunnel change map1 rule_eabits_length 16 753 ip -6 tunnel change map1 psid_offset 4 754 ip -6 tunnel change map1 fmr 1 755 ip -6 tunnel change map1 map_autosetaddr 1 756 ip -6 tunnel change map1 map_autosetgw 1 757 ip -4 addr add 203.86.225.18/30 dev map1 759 A.2.3. Furukawa Network Solution Corp.:BR 761 ! 762 interface tunnel 1 763 tunnel mode ipinip ipv4 ipv6-tunnel-profile 1 764 exit 765 ! 766 ipv4 ipv6-tunnel-profile 1 767 profile-mode map-encap 768 rule-ipv4-prefix 203.86.225.0/28 769 rule-ipv6-prefix 2403:9200::/32 770 user-len 16 771 source-address 2403:9200:fff0::2 772 exit 774 A.2.4. Vyatta ASAMAP:BR 776 interfaces { 777 loopback lo { 778 } 779 map map0 { 780 br-address 2403:9200:fff0::2/64 781 default-forwarding-mode encapsulation 782 default-forwarding-rule true 783 role br 784 rule 1 { 785 ea-length 16 786 ipv4-prefix 203.86.225.0/28 787 ipv6-prefix 2403:9200::/32 788 } 789 } 791 A.2.5. Internet Initiative Japan Inc. SEIL:BR 793 interface frd0 mtu 1460 794 frd mode br 795 frd br-address 2403:9200:fff0::2 796 frd rule add R0 external-ipv4-prefix 203.86.225.0/28 internal-ipv6-prefix 2403:9200::/32 index-length 16 psid-offset 4 798 A.2.6. Cisco IOS-XR:BR 800 ! 801 interface ServiceApp5 802 ipv4 address 203.0.113.5 255.255.255.252 803 load-interval 30 804 service cgn JANOG service-type map-e 805 logging events link-status 806 ! 807 interface ServiceApp6 808 ipv6 address 2001:db8:1:1::1/64 809 load-interval 30 810 service cgn JANOG service-type map-e 811 logging events link-status 812 ! 813 interface ServiceInfra1 814 ipv4 address 203.0.113.1 255.255.255.252 815 service-location 0/0/CPU0 816 ! 817 service cgn JANOG 818 service-location preferred-active 0/0/CPU0 819 service-type map-e Softwire 820 cpe-domain ipv4 prefix 203.86.225.0/28 821 cpe-domain ipv6 prefix 2403:9200::/32 822 sharing-ratio 12 823 aftr-endpoint-address 2403:9200:fff0::2 824 contiguous-ports 0 825 address-family ipv4 826 interface ServiceApp5 827 ! 828 address-family ipv6 829 interface ServiceApp6 830 ! 831 end 833 A.2.7. IP Infusion NetBSD 4.0.1:CE 834 -- ifconfig.map0 -- actual MAP-E parameter 835 up 836 mtu 1460 837 rule_ipv6_prefix 2403:9200::/32 838 rule_ipv4_prefix 203.86.225.0/28 839 lan_if_name any 840 wan_if_name lo1 841 map_autosetaddr 1 842 map_autosetgw 1 843 rule_eabits_length 16 844 psid_offset 4 845 map_border_router 2403:9200:fff0:0::2 846 map_mss auto 847 fmr 1 849 A.2.8. IP Infusion Linux 2.6.18:CE 851 ---- MAP tunnel I/F ---- 853 ip -6 tunnel change map1 rule_ipv6_prefix 2403:9200::/32 854 ip -6 tunnel change map1 rule_ipv4_prefix 203.86.225.0/28 855 ip -6 tunnel change map1 rule_eabits_length 16 856 ip -6 tunnel change map1 psid_offset 4 857 ip -6 tunnel change map1 map_border_router 2403:9200:fff0:0::2 858 ip -6 tunnel change map1 fmr 1 859 ip -6 tunnel change map1 map_autosetaddr 1 860 ip -6 tunnel change map1 map_autosetgw 1 862 A.2.9. Furukawa Network Solution Corp.:CE 864 ip nat ap_pool ADDR-POOL1 865 ipv6-mape-profile 1 866 exit 867 ip ipv6-mape-profile 1 868 user-len 16 869 br-address 2403:9200:fff0:0::2 870 rule-ipv6-prefix reference-interface loopback 1 871 rule-ipv6-prefix-len 32 872 rule-ipv4-prefix 203.86.225.0 255.255.255.240 873 exit 874 interface tunnel 1 875 tunnel mode ipip ipv6-mape-profile 1 876 tunnel source reference-interface ipv6 loopback 1 877 ip mtu 1460 878 ip nat inside source list 10 ap_pool ADDR-POOL1 879 exit 881 A.2.10. Vyatta ASAMAP:CE 883 interfaces { 884 map map0 { 885 br-address 2403:9200:fff0::2/64 886 default-forwarding-mode encapsulation 887 default-forwarding-rule true 888 role ce 889 rule 1 { 890 ea-length 16 891 ipv4-prefix 203.86.225.0/28 892 ipv6-prefix 2403:9200::/32 893 } 894 tunnel-source eth1 895 } 897 A.2.11. Internet Initiative Japan Inc. SEIL:CE 899 interface frd0 mtu 1460 900 interface frd0 tcp-mss 1420 901 nat napt add private 192.168.1.0-192.168.1.255 interface frd0 902 nat option port-assignment random 903 frd mode ce 904 frd ce-address 2403:9200:fff6:0:cb:56e1:f0f:f600 905 frd br-address 2403:9200:fff0::2 906 frd rule add R0 external-ipv4-prefix 203.86.225.0/28 internal-ipv6-prefix 2403:9200::/32 index-length 16 psid-offset 4 908 A.2.12. Yamaha :CE 910 tunnel select 1 911 tunnel encapsulation ipip 912 tunnel endpoint address 2403:9200:fff7:0:cb:56e1:f0f:f700 2403:9200:fff0::2 913 tunnel map-e 203.86.225.0/28 2403:9200::/32 16 4 ::2 914 ip tunnel mtu 1460 915 ip tunnel nat descriptor 1000 916 tunnel enable 1 917 nat descriptor type 1000 masquerade 918 nat descriptor timer 1000 30 919 nat descriptor timer 1000 tcpfin 5 920 nat descriptor address outer 1000 map-e 922 A.2.13. CERNET OpenWRT :CE 923 # configure eth1 -- IPv4 interface 924 ifconfig br-lan 192.168.1.1/24 926 ./control start 928 #janog softwire interop event 929 utils/ivictl -r -d -P 2403:9200:fff0:0::2/128 930 utils/ivictr -r -p 203.86.225.0/28 -P 2403:9200::/32 -R 4096 - M 1 -f -E 931 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 932 service iptables stop 933 service ip6tables stop 935 Authors' Addresses 937 Shishio Tsuchiya (editor) 938 Cisco Systems 939 Midtown Tower, 9-7-1,Akasaka 940 Minato-Ku, Tokyo 107-6227 941 Japan 943 Phone: +81 3 6434 6543 944 Email: shtsuchi@cisco.com 946 Shuichi Ohkubo 947 Sakura Internet 948 33F Sumitomo fudosan Nishi shinjuku Bldg.,7-20-1 Nishi shinjuku 949 Shinjuku-Ku, Tokyo 160-0023 950 Japan 952 Phone: +81 3 5332 7070 953 Email: ohkubo@sakura.ad.jp 955 Yuya Kawakami 956 INTERNET MULTIFEED CO. 957 OTEMACHI 1st.SQUARE EAST TOWER,3F 1-5-1,Otemachi, 958 Chiyoda-ku, Tokyo 100-0004 959 Japan 961 Phone: +81 3 3282 1040 962 Email: kawakami@mfeed.ad.jp