/
IPv6 Addressing of IPv6 Addressing of

IPv6 Addressing of - PowerPoint Presentation

pamella-moone
pamella-moone . @pamella-moone
Follow
389 views
Uploaded On 2016-07-30

IPv6 Addressing of - PPT Presentation

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

ipv6 ipv4 address prefix ipv4 ipv6 prefix address translatable addresses translation 102 converted suffix 2001 202 network stateful checksum

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

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.