IPv4IPv6 Translators 20091103 v01 prepared by X Li C Bao 20091103 v02 updated by Med 20091104 v03 updated by X LI C Bao 20091105 v04 insert slides provided by M Bagnulo 20091106 v05 updated by Med ID: 425401
Download Presentation The PPT/PDF document "IPv6 Addressing of" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
IPv6 Addressing of IPv4/IPv6 Translators
2009-11-03 v01 prepared by X. Li, C. Bao2009-11-03 v02 updated by Med2009-11-04 v03 updated by X. LI, C. Bao2009-11-05 v04 insert slides provided by M. Bagnulo2009-11-06 v05 updated by Med2009-11-08 v06 add some questions from the mailing-listSlide2
2
OutlineIntroductionRecommendations (Excerpt)Address FormatChoice of Prefix for Stateless Translation DeploymentsChoice of Suffix Choice of Prefix for Stateful Translation DeploymentsChoice of the Well Known PrefixSlide3
3
IntroductionMain ObjectiveSpecifies how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is usedApplicability Scope TranslationEncapsulation?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 translationSlide4
4
Recommendations (Excerpt)Impact on Inter-Domain RoutingThe Well Known Prefix SHOULD NOT be used to construct IPv4-translatable addressesThe Well Known Prefix MUST NOT be used to represent non global IPv4 addressesAdvertisement of the Well Known Prefix SHOULD be controlledWhen NSP is used, the global IPv6 routing policy guideline MUST be followedReferral support and optimal routingIPv4-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 translatorsStateful translation needs special considerationsSlide5
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 Slide6
6
Choice of Prefix for Stateless Translation Deployments Prefix recommendationsIPv4-converted and IPv4-translatable addresses MUST be constructed based on the specified address formatIPv4-translatable addresses MUST use NSPIPv4-converted and IPv4-translatable addresses SHOULD use the same prefixPrefix length recommendationsFor 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 Slide7
7
Choice of SuffixOptionsNull 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)Slide8
8
Some open questionsCould the address format defined in this document be used for both encapsulation and translation?We think that the same issues apply for both modesVariable length approach of the address formatShould 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 avoidedHaving decimal representation may ease troubleshooting? Slide9
9
Choice of Prefix for Stateful Translation Deployments Organizations MAY use NSP or WKP WKP SHOULD be used when no NSP is availableThe Well Known Prefix MUST NOT be used for scenario 3 (the IPv6 Internet to an IPv4 network)Slide10
10
Well-Known PrefixCandidate solutions:Reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 2765 Section 2.1Request IANA to allocate a /32 prefixRequest allocation of a new /96 prefix Slide11
11
WKP: Reuse ::FFFF:0:0/96We 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 addressesThey do send IPv4 packets, if they have IPv4 enabledUsing this prefix would require updating the hosts, so this is NOT RECCOMENDEDSlide12
12
WKP: Request a new /32Implies that the WKP+IPv4 address fit in the 64 bits of the prefixWe 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 addressesIn order to use decimal notation for the IPv4 address, we need to update RFC4281Slide13
13
WKP: Request a new /96It 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 RFC4291Slide14
14
An Intermediate Approach Ask for a /32Define two algorithmsWKP:a.b.c.d::WKP::a.b.c.dDefine a default oneSlide15
15
Appendixes Slide16
16
Appendix 1IPv4-converted and IPv4-translatable address examples
The IPv4
Internet
Stateless
xlate
An IPv6
network
202.38.114.1
2001:250:ffca:2672:0100::0
Algorithm
PREFIX:(18.9.22.169):SUFFIX
IPv4-converted
PREFIX:(202.38.114.1):SUFFIX
18.9.22.169
202.38.114.1
IPv4-translatable
The IPv4
Internet
Stateful
xlate
An IPv6
network
202.38.102.1#2000
2001:da8::100#3000
202.38.102.1#2001
2001:da8::101#3000
202.38.102.1#2002
2001:da8::200#3000
State database
PREFIX:(18.9.22.169):SUFFIX
IPv4-converted
18.9.22.169
202.38.102.1Slide17
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. Slide18
18
Appendix 2 Null suffix exampleIf we have PREFIX 2001:db8::/32 IPv4 address 202.38.102.1/32Then the IPv4-translatable will be202.38.102.1 2001:db8:ca26:6601::/64It 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 usedSlide19
19
Appendix 3: checksum neutralNeutrality checksumGive 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 translationOnly one of the two addresses (IPv4-converted address) would be checksum neutralStateless translationTranslators may want to recomputed the checksum to verify the validity of the translated datagrams.However, for the fragmented packets, this will introduce states.