1 / 19

IPv6 Addressing of IPv4/IPv6 Translators

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

cato
Download Presentation

IPv6 Addressing of IPv4/IPv6 Translators

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv6 Addressing of IPv4/IPv6 Translators 2009-11-03 v01 prepared by X. Li, C. Bao 2009-11-03 v02 updated by Med 2009-11-04 v03 updated by X. LI, C. Bao 2009-11-05 v04 insert slides provided by M. Bagnulo 2009-11-06 v05 updated by Med 2009-11-08 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, torepresent 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. 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? Some open questions

  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. IPv4-converted 18.9.22.169 PREFIX:(18.9.22.169):SUFFIX IPv4-translatable 202.38.114.1 PREFIX:(202.38.114.1):SUFFIX Algorithm The IPv4 Internet An IPv6 network Stateless xlate 202.38.114.1 2001:250:ffca:2672:0100::0 IPv4-converted 18.9.22.169 PREFIX:(18.9.22.169):SUFFIX State database 202.38.102.1 202.38.102.1#2000 2001:da8::100#3000 The IPv4 Internet An IPv6 network Stateful xlate 202.38.102.1#2001 2001:da8::101#3000 202.38.102.1#2002 2001:da8::200#3000 Appendix 1IPv4-converted and IPv4-translatable address examples

  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 2.6.1 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 202.38.102.1/32 • Then the IPv4-translatable will be • 202.38.102.1  2001: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 don’t have this problem, since we will never use 202.38.102.1/32, the minimum IPv4 block which we will use is /30, except loopback interface. • Therefore, the IPv4 block should be 202.38.102.0/30, the IPv4-translatable addresses are • 202.38.102.0  2001:db8:ca26:6600::/62 IPv4 net-id  IPv6 “subnet-router anycast address” which will not be used • 202.38.102.1  2001:db8:ca26:6601::/62 can be used for physical interface • 202.38.102.2  2001:db8:ca26:6602::/62 can be used for physical interface • 202.38.102.3  2001:db8:ca26:6603::/62 IPv4 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.

More Related