IPv6 Addressing of IPv4/IPv6 Translators v01 prepared by X. Li, C. Bao v02 updated by Med v03 updated by X. LI, C. Bao v04 insert slides provided by M. Bagnulo v05 updated by Med v06 add some questions from the mailing-list

2 Outline Introduction Recommendations (Excerpt) Address Format Choice of Prefix for Stateless Translation Deployments Choice of Suffix Choice of Prefix for Stateful Translation Deployments Choice of the Well Known Prefix

3 Introduction Main Objective –Specifies how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is used Applicability Scope –Translation –Encapsulation? On the Need of Adequate Terminology –The IPv6 addresses assigned to IPv6 hosts are referred to as "IPv4-translatable" IPv6 addresses Used for the stateless translation only These addresses are used to reach IPv6 hosts "IPv4-translatable" IPv6 prefixes are assigned to IPv6 hosts –The IPv6 addresses used to represent IPv4 hosts are referred to as "IPv4-converted" IPv6 addresses Used for both stateless translation as well as stateful translation

4 Recommendations (Excerpt) Impact on Inter-Domain Routing –The Well Known Prefix SHOULD NOT be used to construct IPv4- translatable addresses –The Well Known Prefix MUST NOT be used to represent non global IPv4 addresses –Advertisement of the Well Known Prefix SHOULD be controlled –When NSP is used, the global IPv6 routing policy guideline MUST be followed Referral support and optimal routing –IPv4-converted and IPv4-translatable SHOULD use the same prefix IPv6 address availability and consumption –Suggest to use 1/256 of allocated IPv6 address space Security –ACL and uRPF may only be used for /64 or shorter in some routers IPv6 address architecture –U-bit MUST be set to zero. The IPv6 hosts MUST not use subnet-router anycast address Support for multiple translators –Stateless translation can support multiple translators –Stateful translation needs special considerations

5 Address Format The IPv4-converted and IPv4-translatable IPv6 addresses are composed of a variable length prefix U-bit (bit 70) defined in the IPv6 architecture MUST be 0. U-octet (bit range 64-71) is recommended to set to zero Prefix shall be –"Well Known Prefix" defined in the addressing architecture to represent IPv4-converted addresses for the stateful translation –"Network Specific Prefix" unique to the organization deploying the address translation, to represent IPv4-translatable and IPv4-converted addresses

6 Choice of Prefix for Stateless Translation Deployments Prefix recommendations –IPv4-converted and IPv4-translatable addresses MUST be constructed based on the specified address format –IPv4-translatable addresses MUST use NSP –IPv4-converted and IPv4-translatable addresses SHOULD use the same prefix Prefix length recommendations –For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 prefix for an ISP holding a /32 allocation, and a /56 prefix for a site holding a /40 allocation –For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 (an IPv4 network to an IPv6 network), we recommend using a /64 prefix

7 Choice of Suffix Options –Null suffix (default) Does null Identifier induce errors/problems? We need feedback from the WG –Neutrality checksum (not selected) Should we consider the neutrality checksum? –Encoding of a port range (defined later)

8 Some open questions Could the address format defined in this document be used for both encapsulation and translation? –We think that the same issues apply for both modes Variable length approach of the address format –Should we recommend a default address format? –Should it be let to the SPs to decide? –Do we allow other prefix lengths? On the need of decimal representation –IPv4 translatable prefixes may be assigned for both native IPv6 communications and IPv6/IPv4 interworking purposes: this should be transparent for end users…and then decimal representation should be avoided –Having decimal representation may ease troubleshooting?

9 Choice of Prefix for Stateful Translation Deployments Organizations MAY use NSP or WKP WKP SHOULD be used when no NSP is available The Well Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to an IPv4 network)

10 Well-Known Prefix Candidate solutions: –Reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 2765 Section 2.1 –Request IANA to allocate a /32 prefix –Request allocation of a new /96 prefix

11 WKP: Reuse ::FFFF:0:0/96 We tried presenting AAAA RR containing addresses formed with ::FFFF:0:0/96 to current hosts (MacOS, Windows, Linux) Current implementations do not send IPv6 packets to that addresses They do send IPv4 packets, if they have IPv4 enabled Using this prefix would require updating the hosts, so this is NOT RECCOMENDED

12 WKP: Request a new /32 Implies that the WKP+IPv4 address fit in the 64 bits of the prefix We could route based on parts of the IPv4 address (just like the argument for the NSP) In case of multiple stateful translators, this may imply that the same IPv6 host is presented with different IPv4 addresses In order to use decimal notation for the IPv4 address, we need to update RFC4281

13 WKP: Request a new /96 It would make more difficult to route on the IPv4 address part –So if the WG thinks that we should not do this, this is good! It would allow to use decimal notation without updating RFC4291

14 An Intermediate Approach Ask for a /32 Define two algorithms –WKP:a.b.c.d:: –WKP::a.b.c.d Define a default one

15 Appendixes

16 Appendix 1 IPv4-converted and IPv4-translatable address examples The IPv4 Internet Stateless xlate An IPv6 network :250:ffca:2672:0100::0 Algorithm PREFIX:( ):SUFFIX IPv4-converted PREFIX:( ):SUFFIX IPv4-translatable The IPv4 Internet Stateful xlate An IPv6 network # :da8::100# # :da8::101# # :da8::200#3000 State database PREFIX:( ):SUFFIX IPv4-converted

17 Appendix 2 Null suffix considerations When a /32 prefix is used, the null suffix results in a null identifier. We understand the conflict with Section of RFC4291, which specifies that all zeros are used for the subnet-router anycast address. However, in our specification, there would be only one IPv4 translatable host in the /64 subnet, and the anycast semantic would not create confusion. We thus decided to keep the null suffix, rather than invent a more complex scheme.

18 Appendix 2 Null suffix example If we have –PREFIX 2001:db8::/32 –IPv4 address /32 Then the IPv4-translatable will be – :db8:ca26:6601::/64 It seems that we has a subnet-router anycast address problem, since –2001:db8:ca26:6601::/64 is the subnet-router anycast address However, we dont have this problem, since we will never use /32, the minimum IPv4 block which we will use is /30, except loopback interface. Therefore, the IPv4 block should be /30, the IPv4- translatable addresses are – :db8:ca26:6600::/62 IPv4 net-id IPv6subnet-router anycast address which will not be used – :db8:ca26:6601::/62can be used for physical interface – :db8:ca26:6602::/62can be used for physical interface – :db8:ca26:6603::/62IPv4 broadcast address which will not be used

19 Appendix 3: checksum neutral Neutrality checksum –Give a chosen value to 16 of the suffix bits to ensure that the IPv4-translatable and IPv4-converted IPv6 addresses have the same 16 bit complement to 1 checksum as the original IPv4 address. –Stateful translation Only one of the two addresses (IPv4-converted address) would be checksum neutral –Stateless translation Translators may want to recomputed the checksum to verify the validity of the translated datagrams. However, for the fragmented packets, this will introduce states.