Stateless IPv4 over IPv6 report
Cisco SystemsMidtown Tower, 9-7-1,AkasakaMinato-KuTokyo107-6227Japan+81 3 6434 6543shtsuchi@cisco.comSakura Internet33F Sumitomo fudosan Nishi shinjuku Bldg.,7-20-1 Nishi shinjukuShinjuku-KuTokyo160-0023Japan+81 3 5332 7070ohkubo@sakura.ad.jpINTERNET MULTIFEED CO.OTEMACHI 1st.SQUARE EAST TOWER,3F 1-5-1,Otemachi,Chiyoda-kuTokyo100-0004Japan+81 3 3282 1040kawakami@mfeed.ad.jpInternet Engineering Task ForcetemplateStateless 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. 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.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. VendorOS/EquipmentIP InfusionLinux 2.6.18IP InfusionNetBSD 4.0.1Furukawa Network Solution Corp.FX5000ASAMAPVyattaInternet Initiative Japan Inc.SEIL/X1Cisco SystemsIOS-XR/ASR9000VendorOS/EquipmentIP InfusionLinux 2.6.18IP InfusionNetBSD 4.0.1Furukawa Network Solution Corp.F60WASAMAPVyattaCERNETOpenWRTInternet Initiative Japan Inc.SEIL/X1Yamaha CorporationRTX1200We took a survey to participant about security considerations which is described on Section 13 of [I-D.ietf-softwire-map]. 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?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 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.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.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. MAP-E ParameterParameterValueRule IPv6 prefix2403:9200::/32Rule IPv4 prefix203.86.225.0/28End-user IPv6 prefix2403:9200:fff1::/48 - 2403:9200:fff7::/48EA bits16bit(48-32)Port-Set ID12bitPSID offset4BR IPv6 address2403:9200:fff0:0::2TopologyMeshEach of MAP-E has only 15 TCP/UDP ports,1 IP address is shared by 4096 users.MAP Simulation Tool shows this rule.MTU ParameterParameterIPv6 MTUTCP MSS clampTunnel IF IPv4 MTUValue1500byteEnable1460byteMAP-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. Section 9 of [I-D.ietf-softwire-map] describes about ICMP handling in MAP domain.T-1-1: echo request/echo replyConfirmed 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.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 UnreachableConfirmed 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 transitConfirmed 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.IPSec VPN [RFC2401] uses ESP packets, therefore MAP-E CE should support NAT traversal [RFC3948]. T-2-1:IPSecAll of CE failed.This result is expected behavior. T-2-2:IPSec VPN(UDP:NAT Traversal)All of CE succeeded.It should be no problem, because SSL VPN[RFC4347] uses TCP sockets.All of CE succeeded.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) modeAll of CE succeeded.T-4-2:Active(PORT) modeOnly 2 vendor's CE succeeded.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.L2TP/IPsec[RFC3193] should support on MAP-E using with NAT Traversal[RFC3948]. All of CE succeeded.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. All of combination basically succeeded. Tested both chat and video. All of combination succeeded. Not testedAll of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination basically succeeded. Tested chat,voice and video. All of combination succeeded. Tested chat,voice and video in the meeting.Not testedAll of combination succeeded. 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.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 MappingREQ-8: Filtering BehaviorREQ-9: HairpinningREQ-3: Port overloading[NAT-Analyzer] is JAVA applet in the browser to verify NAT functionality.The test result will be update.Even DNS queries could occupy to MAP-E CE NAT table in this port restricted (only 15 ports) environments.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.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).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.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.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
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. This document has no actions for IANA. There is no additional security requirement.
&RFC2119;
&RFC4787;
&RFC3489;
&RFC4347;
&RFC2401;
&RFC3948;
&RFC5508;
&RFC2408;
&RFC6586;
&RFC0959;
&RFC2637;
&RFC3193;
&RFC5780;
&RFC5569;
&RFC5952;
&RFC5737;
&RFC3849;
&RFC6104;
&RFC6587;
&RFC6145;
&RFC6052;
&RFC6346;
&RFC4443;
&RFC5387;
"Microsoft Security Advisory (2743314) Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure
""JApan Network Operators Group""Network Measurement Activites at TUM""Echigo Network Operators' Group"
.--.
_(. `)
_( 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
+---------------+
| | |
---- 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
---- 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
!
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
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
}
}
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
!
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
-- 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
---- 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
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
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
}
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
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
# 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