IPv6

©Peter R. Egli 2011
2
Rev. 2.62
IPv6
indigoo
.
com
•Relevant IPv6 RFCs
RFC2460
„Internet Protocol, Version 6 (IPv6) Specification“
RFC4291
„IP Version 6 AddressingArchitecture“
RFC3587
„IPv6 Global UnicastAddress Format“
RFC4213
„Transition Mechanisms for IPv6 Hosts and Routers„
RFC3056
„Connection of IPv6 Domains via IPv4 Clouds„
RFC2529
„Transmission of IPv6 over IPv4 Domains without Explicit Tunnels„(„6over4“)
RFC4862
„IPv6 StatelessAddressAutoconfiguration“
RFC3177
„IAB/IESG Recommendationson IPv6 Addresses“
RFC3484
„Default AddressSelectionforInternet Protocolversion6 (IPv6)“
RFC2765
„StatelessIP/ICMP TranslationAlgorithm“(SIIT)
RFC4861
„Neighbordiscoveryprotocol“
RFC3879
"DeprecatingSite LocalAddresses"
RFC4147
"IANA IPv6 Registry"
RFC3849
"IPv6 AddressPrefixReservedforDocumentation"
DeprecatedIPV6 concepts:
Someconceptsin IPv6 havealreadybeendeprecated(e.g. site-localunicastaddresses).
These aremarkedin light greytext in thisdocumentation.
©Peter R. Egli 2011
3
Rev. 2.62
IPv6
indigoo
.
com
•WhyIPv6?






Motivation forIPv6:
1. ExhaustedIPv4 addressspace:
V4 addressspaceisbecomingexhausted(only4.3G addresses) despiteNAPT and CIDR.
Around2008 till2015 itisexpectedthatIPv4 addressspacewill beexhausted(oraround2022
accordingto othersources;-) orevenaround2045 to yetothersources). Itisactuallyunclear
whenexactlyIPv4 addresseswill runout, buteventuallytheywill.
2. IPv4 addressesarenon-hierarchical:
V4 addressesarenon-hierarchicaland assignedirrespectiveof geographicaltopology.
Thisleadsto fragmentationand thusbigroutingtables(as of 2010 over320k route prefixesto
beexchangedbetweenbackbonerouters).
See
http://bgp.potaroo.net/
or
http://www.cidr-report.org/
.
3. DisproportionateIPv4 addressassignment:
IPv4 addressesareassigneddisproportionately(2005: USA 75%, Asiaonly~10%, China < 1%).
4. IPv4 addressmanagementisdifficult:
IPv4 doesnot reallysupportautomaticaddressassignment(exceptAPIPA). Usageof DHCP
meanshigh administrative effort.
Morestatisticson IPv4:
http://www.potaroo.net/tools/ipv4/index.html
©Peter R. Egli 2011
4
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 –theholygrail?
IPv6 solvestheaddressscarcityproblem(fornow).
IPv6 shouldsolvetheroute tablesizeproblemin backbonerouters.
IPv6 comeswithimprovedQoSsupportforreal-timeapplications.
IPv6 will beoneof thedriversof mobility(always-onmobile devices).
Securitywas an integral partof IPv6 fromitsinception(IPSec).
IPv6 has a simplifiedheaderthusgreatlyreducingroutingprocessingload.
IPv6 isdesignedto scalealmostindefinitely(to verylarge networks); theprotocolshould
supportroutingspeedsforOC-12+ (622Mbps) lines.
IPv6 isplug-and-play: automaticIP addressassigment(no DHCP), routersolicitationfor
gettingtheSLA and routeradvertismentformakingownIP addressknownto neighbors.
IPv6 isnot somethingrevolutionarynew. Itisdesignedto beas transparent to
applicationsas possiblewhilesolvingthebiggestproblemsand deficienciesof IPv4.
©Peter R. Egli 2011
5
Rev. 2.62
IPv6
indigoo
.
com
•Main differenciesbetweenIPv4 and IPv6
1. Headerissimplified, has fixedsize(40bytes); IPv6 introducesconceptof (optional)
extensionheadersforfragmentation, headeroptionsetc.
2. Headerchecksumremoved; thisfunctionisalreadycoveredbylayer2 protocols(e.g.
Ethernet and Frame Relay) and anywaytheIPv4 checksumdoesnot provideForward Error
Correction(possibilityto correcterrorsbasedon thechecksum) thusitisbasicallyuseless
(routershaveto drop erroredpacket anyway).
3. Biggeraddresses.
Total length
TOS
IHL
Ver.
Identification
Frag.
Fragment offset
TTL
Protocol
Headerchecksum
IP sourceaddress
IP destinationaddress
Optional IP options
Flowlabel
T. class
Ver.
Payloadlength
IP sourceaddress
NextH.
Hoplimit
IP destinationaddress
IPv4 header:
IPv6 header:
Fieldretainedin IPv6.
Function/ fieldretainedin IPv6, butused/encodeddifferently.
Fielddiscardedin IPv6.
Optional extensionheaders
©Peter R. Egli 2011
6
Rev. 2.62
IPv6
indigoo
.
com
•Thepast, thepresentand thefutureof IPv6?

IPv6 effortsbeganin theearly90ies.

WhereisIPv5?
IP protocolversion5 was alreadyassignedto anotherprotocol(ST: Streamingprotocolfor
real-timetrafficovertheInternet). InitiallyIPv6 effortsran underthenameIPng(next
generation IP). One of thepredecessorsof IPv6 was calledSIPP (Simple IP Plus).

IPngwas thepredecessorof IPv6 and consistedof 3 proposals:
CATNIP: „Common ArchitectureforNextGen. Internet Protocol“, createdcommonality
betweenInternet (IPv4, TCP, UDP), OSI (CLNP) and Novell(IPX).
TUBA: „TCP and UDP UsingBiggerAddresses“usingOSI‘sCLNP.
SIPP: „Simple IP Plus“, removedIPv4 functionsthatdidnot work, increasedaddresssizeto
64bit.
A revisedversionof SIPP (128bit addresses, auto-configuration) was chosenas thebasisfor
IPngwhicheventuallybecameIPv6. See
RFC1752
.

IPv6 didnot reallycatch on muchso far (as of 2010). IPv6 adoptionrate isstill verylow. But
mobility(mobile devices) maybea real driverfortheadoptionof IPv6 (killerapplication).

6Bone: IPv6 testbedfor thedeployment of IPv6.
©Peter R. Egli 2011
7
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 extensionheaders

Optional functionshavebeenmovedto (optional) extensionheaders(nextheader
mechanism). Thustheheaderhas beenstreamlinedforthecommoncase(commoncasemust
befast, lessoftenusedfunctionslikefragmentationmovedto optional headers).
Nextheaderscanbestackedin a pre-definedorder:






Possibleextensionheaders(mustbestackedin theorder given):
1. Hop-by-hopoptions(optionsareevaluatedat eachhop)
2. Routingheader(likeloosesourceroutingand recordroute in IPv4)
3. Fragmentationheader(onlytransmittingnodecanfragment, not routersalongthepath)
4. Destination options(optionsevaluatedbyreceiver)
5. AH header(IPSec)
6. ESP header(IPSec)
7. Upper layerheader(TCP)
IPV6 header
Nextheader= TCP
TCP header+ data
IPV6 header
Nextheader= IPSecAH
TCP header+ data
IPSecAH
Nextheader= TCP
IPV6 header
Nextheader= IPSecAH
TCP header+ data
IPSecAH
Nextheader= Fragm.
Fragm. header
Nextheader= TCP
Normal IPv6
TCP packet IPv6 TCP
encapsulatedin
IPSecAH
FragmentedIPv6
TCP packet
withIPSecAH
©Peter R. Egli 2011
8
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(1)

IPv6 addresstypes:
1. Unicastaddress:
Same as IPv4 unicastaddress.
2. Multicastaddress:
In IPv4 thereweremulticastaddressesbutonly
forexperimental use. Multicastaddresses
arean integral partof IPv6.
Multicastaddresses: ff0x::<group ID>
x=1 = interfacelocal
x=2 = link local
x=5 = sitelocal
x=E= global
3. Anycastaddress:
Anycastaddressesarenewin IPv6.
Anycastpacketsareroutedto nearesthost.
Thenearesthostisascertainedbyroutingprotocols.
Anycastaddressesaresyntacticallyindistinguishablefromunicastaddresses.
Unicastaddress= configurationof sameunicastaddresson multiple interfacesand configurationof
routingsuch thatitroutesa packet to thisaddressto thenearestinterfacehavingthisaddress.
N.B.: Thereareno broadcastaddressesin IPv6 (multicastreplacesbroadcast).
©Peter R. Egli 2011
9
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(2)

IPv6 addresseshavescope(validityin a specificarea): link, site, global.
Link localscope: IP addressisvalidonlywithina specificlink (e.g. Ethernet link).
Site localscope: IP addressisvalidonlywithina specificsite(e.g. enterprise, university).
Global scope: IP addressisgloballyunique.






In IPv6 thereareno addressclasses(likeA, B, C in classfulIPv4).

General structureof IPv6 address(as proposedby
RFC3177
):
Net part(networkprefix)
Interface part/ Interface ID („host“part)
64 bits
64 bits
Networkprefix: „Whereareyouconnectedto“.
Interface ID: „Whoareyou“. CreatedfromMAC addressorfromIPv4 address
(IPv6 compatibleaddresses). See
RFC4291
2.5.
UnlikeIPv4, IPv6 addressesarehierarcical
to allowroute aggregation(prefix). Theprefix
boundarycanfall anywherewhithintheaddress(„classlessness“).
N.B.: In IPv6 thereareno hostsanymore. Everyaddressspecifiesan interfaceand not
a host.
A hostisexpectedto havemultiple interfaces(„multi-homed“host).
©Peter R. Egli 2011
10
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(3)

IPv6 addressnotation(
RFC4291
):
Dueto muchhighernumberof bitstherepresentationwas changedfromdecimalto hex (colon-
hexadecimalnotation).
x:x:x:x:x:x:x:x
(x = 16 bithex), e.g.
1080:0000:0000:0000:0008:0800:200C:417A
.
Prefixlength(„mask“length):
Theprefixlengthissuffixedwith„/x“(nodeaddressand prefixlength).
E.g.
1080::8:800:200C:417A/48 or2002::/16
IPv4 style masksdo not existin IPv6.
Shorthandwriting:
In order to easewritingsomeshorthandshavebeendefined:
1. Removeleading0 in 16 bitgroups(l
eading0 in each16 bithex-blockcanbeomitted):

Theremustbeat least onedigitin each16 bitgroup.
E.g.
1080:0:0:0:8:800:200C:417A
2. Collapse0000 (
Multiple groupsof 16 bit0 (0000 in hex) canbecollapsedinto„::“):

Onlycompleteand adjacent0000 groupscanbecollapsed.

„::“mayoccuronlyoncein theaddress.
E.g.
1080::8:800:200C:417A
Mixed IPv4/IPv6 format:
x:x:x:x:x:x:d.d.d.d
wherex = hex-16-bit Repräsentation of high order bitsand d = IPv4 notation.
E.g.
0:0:0:0:0:FFFF:129.144.52.38
=
::FFFF:129.144.52.38
(IPv4-mapped address).
©Peter R. Egli 2011
11
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(4)

IPv6 AddressingArchitecture
RFC4291
:
RFC4291
definestheaddressingarchitectureof theIPv6 addressspace.
Link-local
unicastaddress(p. 11)
Site-localunicast
address(p. 11)
Global
unicastaddress (p. 15)
Global routingprefix
Subnet ID
Interface ID
48 Bits64Bit
FEC0::/10
SLA ID
Interface ID
FE80::/10
Interface ID
::/96
IPv4
address
::FFFF/96
IPv4
address
Unassigned
FF
Flags
Scope
Group ID
8Bit4Bit4Bit112Bit
X
Global
Site
local
Link
local
(X)
X
(X)
(X)
X
IPv4 compatible
address(p. 13)
IPv4-mapped
address(p. 13)
Multicast
address(p. 18)
Validity(scope)
16 Bits
©Peter R. Egli 2011
12
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(5)

Special IPv6 addresses(1/2):
A. LocalLoopbackaddress(only1 singleaddressas opposedto IPv4):
0000:0000:0000:0000:0000:0000:0000:0001
=
::1/128
B. Unspecifiedaddress(similarto 0.0.0.0 in IPv4):
0000:0000:0000:0000:0000:0000:0000:0000
=
::/128
Meaning: Absence of address or invalid address.
C. IPv6 multicast:
FF00::/8
D. Link-local unicast:
FE80::/10
Link-local addresses are used on a link for automatic address configuration, neighbor
discovery or when no routers are present on the link.

These addresses are not routed (valid only on a link such as Ethernet).
E. Site-local unicast(deprecated, see
RFC3879
):
FEC0::/10
Originally intended to be used within a site (similar to link-local, but valid within a site).
Definition of a "site" was too fuzzy (organization, company) so the concept of link-local
addresses was abandoned.
©Peter R. Egli 2011
13
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(6)

Special IPv6 addresses(2/2):
F: UniqueLocalAddress(ULA):
FD00::/8
RFC4193
definesuniquelocaladdressesanalogousto IPv4 private addresses(10.0.0.0/8,
172.16.0.0/12 and 192.168.0.0/16, see
RFC1918
).

Uniquelocaladdressescontaina randomlygeneratedpartto maketheaddressunique.

Uniquelocaladdressesavoidaddressconflicts(e.g. whenestablishinga tunnelbetween2
sitesthatareindependentlyconfiguredsites).

Easyfilteringat siteboundaries(avoidleakingof packetsto theInternet).
G: IPv6 AddressPrefixforDocumentation:
2001:0DB8::/32
In order to avoid confusion IETF set aside a special range of IPv6 addresses to be used
in documentation (and not to be used in real deployments). See
RFC3849
.
©Peter R. Egli 2011
14
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(7)

IPv4/IPv6 compatibilityaddresses(1/2):
A. IPv4 compatibleaddress(deprecated):
0:0:0:0:0:0:w.x.y.z
Used by IPv6/IPv4 nodes that are communicating with IPv6 over an IPv4 infrastructure. When
the IPv4-compatible address is used as an IPv6 destination, the IPv6 traffic is automatically
encapsulated with an IPv4 header and sent to the destination using the IPv4 infrastructure.
IPv4 compatible addresses are deprecated as transition mechanismdo not use it anymore.
B. IPv4-mapped address:
0:0:0:0:0:FFFF:w.x.y.z
or
::FFFF:w.x.y.z
,
Used to represent an IPv4-only node to an IPv6 node (SIIT). It is used only for internal
representation. The IPv4-mapped address is never used as a source or destination address of
an IPv6 packet. The IPv4-mapped address is used by some IPv6 implementations when acting
as a translator between IPv4-only and IPv6-only nodes (e.g. used by
RFC2765
SIIT = stateless
IPv4 to IPv6 address translation).
C. IPv4-translated address(usedby
RFC2765
SIIT = statelessIPv4 to IPv6 address
translation):
0::FFFF:0:a.b.c.d
Usedto representan IPv6-enabled node.
©Peter R. Egli 2011
15
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(8)

IPv4/IPv6 compatibilityaddresses(2/2):
D. 6to4 addresses:
2002::WWXX:YYZZ::[subnet-ID]:[InterfaceID]/48
(colon-hexadecimalnotation)
Usedby
RFC3056
6to4 tunneling.
E. 6over4 addresses:
FE80::WWXX:YYZZ
(colon-hexadecimalnotation)
Example: IPv4 131.107.4.92





6over4 IPv6 address
FE80::836B:45C
F. ISATAP addresses:
Valid64-bit unicastprefixand interfaceidentifier
0:5EFE:w.x.y.z
.
Example:
FE80::5EFE:131.107.4.92
(link local)
G. Teredoaddresses(NAPT traversal):
Useprefix
3FFE:831F::/32
.
Example:
3FFE:831F:CE49:7601:8000:EFFF:62C3:FFFE
©Peter R. Egli 2011
16
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(9)






"IPv6 global unicastaddress" = mainaddresstypein IPv6 (see
RFC3587
) (1/2):
Aggregationisusedforof reducingroutingtables(maingoalof IPv6).
Format (see
RFC3587
):
Theglobal routingprefix, usually48 bits, identifiesa site(organization, company), i.e. a
clusterof subnets/ links. In specialcasesISPsmayusesmallerprefixes(forverylarge
organizations) or64 bitprefixes(customeronlyneedsexactly1 address).
ThesubnetID identifiesa subnetwithina site.
Subnet
LAN
WLAN
Internet
Site (e.g. HSZ-T)
2001:0DB8:ABCD::
/48
2001:0DB8:ABCD:
C
000::
/52
2001:0DB8:ABCD:
C
6
00::
/56
2001:0DB8:ABCD:
C
7
00::
/56
Public topology
n bits64 -n bits64 bits
Site topology
Interface identifier
Global routingprefix
Subnet ID
Interface ID
©Peter R. Egli 2011
17
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(10)






"IPv6 global unicastaddress" = main address type in IPv6 (see
RFC3587
) (2/2):






Hierarchicaladdressesallowassigningaddressesaccordingto geographicaltopologythus
reducingroutingtables(prefixescanbeaggregated).






Theproposedaggregatableunicastaddressformatisa tradeoffbetweenminimizing
routingtablesand flexibilityin IP addressallocation.
2001:0DB8::/32
2001:DB8:
1
000::/36
All 2001:DB8:1
2
traffic
goeshere
All 2001:DB8:1
1
traffic
goeshere
All 2001:DB8 traffic
goeshere
2001:DB8:1
1
00::/40
2001:DB8:1
2
00::/40
2001:DB8:1
3
00::/40
2001:DB8:12
1
0::/44
2001:DB8:12
2
0::/44
2001:DB8:12
3
0::/44
2001:DB8:13
1
0::/44
©Peter R. Egli 2011
19
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(12)

IPv6 zoneidentifier(2/2):
Problem:
Addresseswithoutglobal scope(interface, local, site) areonlyuniquewithintheirscope.
These addressesmaybereusedoutsidetheirscope, e.g. an addresswithlink scopemaybe
reusedon anotherlink.
Thezoneto whicha particularIP addresspertainsisnot encodedin theIP address. Itmustbe
ratherdeterminedfromthecontext, i.e. fromthelink overwhicha packet was received.







RFC4007
definesa zoneID thatidentifiesthezoneto whichan IP addressbelongs.
Example:
FE80::1%1
Configurationof zoneindex:
Theconfigurationof thezoneindexshouldbeautomatic(avoidmanualconfiguration).
Eachlink to whichan interfaceisattachedhas itsown
link index(evenwhenmultiple interfacesare
Interface x link x
Host
Host
FE80::1
%1
FE80::1
%2
FE80::2
%1
FE80::1
%3
Ethernet
©Peter R. Egli 2011
20
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(13)






Multicastaddresses
Multicastaddressallowto reachmultiple destinations. Multicastaddressesreplacebroadcast
addresses.
Structureof IPv6 multicastaddress(as per
RFC4291
):
8
4
4
112
Multicast
prefix
0 = Permanentlyassigned(=well-knownmulticastaddress, assignedbyIANA)
1 = Transientordynamicallyassigned
IANA: Internet AssignedNumbersAuthority
0 = Multicastaddressthatisnot assignedbasedon thenetworkprefix
1 = Multicastaddressthatisassignedbasedon thenetworkprefix
Definition see
RFC3956
Scope limits the scope to:
0 reserved
1 Interface-Local scope
2 Link-Local scope
3 reserved
4 Admin-Local scope
5 Site-Local scope
6, 7 (unassigned)
8 Organization-Local scope
9...D (unassigned)
E Global scope
F reserved
Multicastgroup ID
E.g. FF0E:0:0:0:0:0:0:101 = NTP multicastwith
global scope.
FF
Group ID
0
R
P
T
Scope
©Peter R. Egli 2011
21
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 addresses(14)
LiteralIP addressesin URLs (useof IP addressesin URLs):
URLs maycontainnumericalIP addressesas follows(thoughitisnot recommendedto use
thisfeature!):
IPv4:
http://193.5.54.123:80
IPv6 (see
RFC3986
):
http://[2001:DB8::7]/index.html
©Peter R. Egli 2011
22
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 route aggregationversusIPv6 multihoming(1/3)
Route aggregation is very important in IPv6 in order to reduce the number of routing entries
in IPv6 routers (remember: IPv4 @ Y2010 ~320k route prefixes).
RIRsassign Provider Aggregatable(PA) address blocks to providers. These blocks can be
aggregated into a single route advertisment.
AS2100
2001:DB8:2100::/40
AS2110
2001:DB8:2110::/44
AS2120
2001:DB8:2120::/44
AS2130
2001:DB8:2130::/44
AS2000
2001:DB8::2000/36
Advertiseaggr. prefix
2001:DB8:2100/40
AS: AutonomousSystem (=IP networkadministered
byoneorganization)
RIR: Regional Internet Registry
AS numberssee
http://bgp.potaroo.net/cidr/autnums.html
AS2131
2001:DB8:2131::/48
Advertiseprefix
2001:DB8:2131/48
Advertiseaggr. prefix
2001:DB8:2130/44
AS1000
2001:DB8::1000/36
Advertiseaggr. prefix
2001:DB8:2110/44
AS1100
2001:DB8:1100::/40
Advertiseaggr. prefix
2001:DB8:1100/40
Advertiseaggr. prefix
2001:DB8:1000/36
Advertiseaggr. prefix
2001:DB8:2000/36
AS1110
2001:DB8:1110::/44
Advertiseaggr. prefix
2001:DB8:1110/44
Advertiseaggr. prefix
2001:DB8:2000/36
©Peter R. Egli 2011
23
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 route aggregationversusIPv6 multihoming(2/3)
Problem: How to minimize routing table size and
provide redundancy?
Redundanycan be achieved through multihoming, i.e. connecta site to multiple providers.
When using Provider Independent address space (PI) the same address range can be advertised
to multiple providers (2001:DB8:2110/44 in picture below).
But: PI addresses "punch holes" into the routing tables (increases the number of
routing entries).
R2
AS2100
2001:DB8:2100::/40
AS2110
2001:DB8:2110::/44
AS2120
2001:DB8:2120::/44
AS2000
2001:DB8::2000/36
AS1000
2001:DB8::1000/36
AS1100
2001:DB8:1100::/40
AS1110
2001:DB8:1110::/44
2001:DB8:2000/36 via R0
2001:DB8:1110/44 via R1
R0
2001:DB8:2000/36 via R0
2001:DB8:1110/44 via R1
2001:DB8:2110/44 via R2
R1
2001:DB8:2000/36
2001:DB8:2FFF/36
2001:DB8:2110/44
AS1100 interiorroutingtables
before
"punchinghole":
AS1100 interiorroutingtables
after
"punchinghole":
AdvertisePI prefix
2001:DB8:2110/44
Addressspace:
©Peter R. Egli 2011
24
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 route aggregationversusIPv6 multihoming(3/3)
As of 2010 multihomingwith PI addresses is seen as an acceptable intermediate
approach until a final solution is available. See also RIPE'spolicy on PI addresses
(
http://www.ripe.net/ripe/policies/proposals/2006-01.html
).
©Peter R. Egli 2011
25
Rev. 2.62
IPv6
indigoo
.
com
•IP addressassignmentwithIPv6 (1)
1. IPv6 Stateless Address Autoconfiguration
RFC4862
1
Router solicitation RS
(ICMPv6)
2
Router Advertisement (RA)
(ICMPv6)
4
DAD
1. Host sendsICMPv6 routersolicitationpacket (on Ethernet and IPv6 multicastaddress).
2. Routersendsback a RA messagewiththeglobal prefix(networkpartof IP address).
3. Thehostcreateshis IPv6 addressfromtheglobal prefix(networkpart) and theEUI-64 hostpartgenerated
fromtheMAC address.
4. Thehostsendsan ICMPv6 neighborsolicitationpacket withitsownIPv6 address(Duplicate
AddressDetection-DAD). Ifno neighborrespondsthentheIP addressstateischangedto „assigned“.
Option:
Theroutermaysend RA messageswith2 flags:
ManagedFlag1 
Thehostshouldusestatefulautoconfiguration(DHCPv6).
OtherConfigFlag1 
Thehostshouldqueryotherinformationfroma DHCPv6 server(e.g. DNS server).
ManagedFlagseebelow.
3
©Peter R. Egli 2011
26
Rev. 2.62
IPv6
indigoo
.
com
•IP addressassignmentwithIPv6 (2)
2. IPv6 StatefulAddress Autoconfiguration
RFC3315
1
Router solicitation RS
(ICMPv6)
2
Router Advertisement (RA, ICMPv6)
with
ManagedFlag
4
DAD
DHCPv6 solicitation
DHCPv6 advertisement
DHCPv6 request
DHCPv6 confirm
6
5
7
8
DHCP server
Routersolicitationisthestandardmechanismto getan IP address, to besupportedbyall hosts.
TheManagedFlagtellsthehostto proceedwithDHCPv6 to geta centrallyadministeredIP address.
3
©Peter R. Egli 2011
27
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 fragmentation

Thedefinitionof fragmentationin IPv4 isnon-optimalforrouters(routersshouldforward
packet, not fragmentpackets).
WithIPv6 onlythetransmittingnodecanfragment. Intermediateroutersdo not fragment
They‘resupposedto route packetsas fast as possible. Fragmentationisnot theirjob.

Ifan intermediaterouterreceivesa packet thatwouldneedfragmentationitsendsback an
ICMP6 „Packet toobig“messageback to thesender(similarto IPv4 „Fragmentationneeded
butDF set“).
Packet (4000 Bytes)
MTU: 4382
MTU: 1500
Packet (4000 Bytes)
ICMPv6 Error Msg:
Messagetoobig
MTU=1500
ICMPv6 Error Msg:
Messagetoobig
MTU=1500
Packet (1500 Bytes)
Packet (1500 Bytes)
Packet (1500 Bytes)
MTU 5000
MTU 5000MTU 1500
©Peter R. Egli 2011
28
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 neighbordiscovery(ND) protocol–
RFC4861
(1/2)

Purpose:
ReplacementforIPv4 ARP, ICMP routerdiscoveryand ICMP redirectmessagesand IPv4 DHCP.






IPv6 neighbordiscovery
RFC4861
functions(1):
Router Discovery(replacesIPv4 routerdiscovery):
How hosts locate routers that reside on an attached link.
Prefix Discovery:
How hosts discover the set of address prefixes that define whichdestinations are on-link
for an attached link.
Parameter Discovery:
How a node learns such link parameters as the link MTU or such Internet parameters as the
hop limit value to place in outgoing packets.
Address Autoconfiguration:
How nodes automatically configure an address for an interface.
Address resolution:
How nodes determine the link-layer address of an on-link destination (e.g., a neighbor) given
only the destination's IP address(replacesIPv4 ARP).
©Peter R. Egli 2011
29
Rev. 2.62
IPv6
indigoo
.
com
•IPv6 neighbor discovery (ND) protocol –
RFC4861
(2/2)

IPv6 neighbordiscovery
RFC4861
functions(2):
Next-hop determination:
The algorithm for mapping an IP destination address into the IP
address of the neighborto which traffic for the destination should be sent. The next-hop can
be a router or the destination itself.
NeighborUnreachabilityDetection:
How nodes determine that a neighboris no longer reachable. For neighborsused as routers,
alternate default routers can be tried. For both routers and hosts, address resolution can be
performed again.
Duplicate Address Detection DAD:
How a node determines that an address it wishes to use is not already in use by another node.
Redirect(replacesIPv4 redirectmessages):
How a router informs a host of a better first-hop node to reach a particular destination.
©Peter R. Egli 2011
30
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (1/44)
IPv6 was designedwithmigrationin mind(no „D-day“whereeverythingismovedto IPv6
on thedot of twelveo‘clock!).
ThusIPv4 and IPv6 will coexistfora longtime to come, possiblyforever!
Therearemanydifferent migrationprotocols. Itisunclearwhichonewill beused.
IPv4
Experimental IPv6
(e.g. 6Bone)
Phase 1
IPv4
ocean
Phase 2
IPv6
ocean
Phase 3
IPv6
only
Phase 4
IPv6
island
IPv4
island
IPv4 IPv6 translation
©Peter R. Egli 2011
31
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (2/44)
Nodeclassificationfortransition(
RFC4213
):
1. IPv4-only node:
A hostorrouterthatimplementsonlyIPv4.
2. IPv6/IPv4 node:
A hostorrouterthatimplementsbothIPv4 and IPv6.
3. IPv6-only node:
A hostorrouterthatimplementsIPv6, and doesnot implementIPv4.
4. IPv6 node:
AnyhostorrouterthatimplementsIPv6. IPv6/IPv4 and IPv6-only nodesarebothIPv6 nodes.
5. IPv4 node:
AnyhostorrouterthatimplementsIPv4. IPv6/IPv4 and IPv4-only nodesarebothIPv4 nodes.
N.B.:
Thetermshostand nodeareusuallyusedsynonymously. Thetermhostdenotesthephysical
machinethatrunsIPv4 and/orIPv6 whilethetermnodeisusedto denotea logical
entitythatimplementsIPv4 and/orIPv6.
©Peter R. Egli 2011
32
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (3/44)

Overviewof transitionmechanisms(1):
Thetransitiontechnologiescanbedividedinto:
1. Dual-stack
1.1. Simple IPv4 and IPv6 dual stackdeployment
1.2. VLAN basedIPv4-IPv6 coexistence(
RFC4554
)
2. Tunneling
2.1. Automatic tunneling
2.1.1. 6in4 (
RFC4213
, basictransitionmechanism)
2.1.2. 6over4 (
RFC2529
, "VirtualEthernet")
2.1.3. 6to4 (
RFC3056
, connectionof IPv6 domainsvia IPv4 clouds)
2.1.4. ISATAP (
RFC5214
)
2.1.5. Teredo(
RFC4380
)
2.1.6. IPv6 automatictunneling(
RFC2893
, deprecatedbyRFC4213)
2.1.7. Tunnel broker(
RFC3053
, IPv6 tunnelbroker)
2.1.8. DSTM (IETF draft)
2.2. Configuredtunneling(=explicittunnel)
3. Translation
3.1. NAT-PT (
RFC2766
, deprecatedby
RFC4966
)
3.2. SIIT (
RFC2765
, StatelessIP/ICMP translationalgorithm)
3.3. BIS (
RFC2767
, Bumpin thestack)
3.4. BIA (
RFC3338
, Bumpin theAPI)
3.5. ALG
3.7. SOCKS64 (
RFC3089
)
3.7. TRT (
RFC3142
)
©Peter R. Egli 2011
33
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (4/44)

Applicabilityof transitionmechanisms(seealso
http://ipv6int.net
):
4 over66 over46 over46 over46 over46 over46 over4
Tunnel
type
ExpiredIETF draft.
IPv4 overIPv6 tunneling.
H2R
No
Yes
(RH)
NoNo
DSTM
Automatic setupof tunnel.
Doesnot definespecifictunnelprotocol.
H2R
(No)(No)(No)(No)
Tunnel
broker
RFC3053
H2H
H2RH2RR2RH2H
H2RH2H
H2R
R2R
H2H/
H2R/
R2R
NoNoNoNo
Yes
OS X
Last resortwhenothertunnelingmechanismcannot
beused.
Yes
(Miredo)
YesYes
Teredo
RFC4380
Proto-41 tunneling
Alternative for6over4 whenIPv4 multicastisnot
supported.
YesYesYes
ISATAP
RFC5214
Yes
No
Yes
(SUSE,
RH)
Linux
Yes
No
Yes
MS
Proto-41 tunneling.
Standard way of v6 to v4 interworking.
Yes
6to4
RFC3056
Proto-41 tunneling.
Not usedmuch/ at all dueto needformulticast.
No
6over4
RFC2529
Proto-41 tunneling.
Basic tunnelingmechanism.
Yes
6in4
RFC4213
Comment
Cisco
Key:
H2H Host to hosttunnel
H2R Host to routertunnel
R2R Routerto routertunnel
©Peter R. Egli 2011
34
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (5/44)

Applicabilityof transitionmechanisms(seealso
http://ipv6int.net
):
May beusedin conjunctionwithother
tunnelmechanisms.
Usedto separate IPv6 and IPv4 trafficon a LAN.
NoNoNo
Yes
IPv4/IPv6
VLAN
RFC4554
NoNo
Yes
NoNoNo
OS X
ConnectIPv6 applicationsto IPv4-only servers.
No changeson IPv6 orIPv4 hostsnecessary.
NoNoNo
TRT
RFC3142
ConnectIPv6 applicationsto IPv4-only servers.
Hosts needto "talk" SOCKS protocol
NoNoNo
SOCKS64
RFC1928
RFC3089
Yes
NoNoNo
Linux
Yes
NoNoNo
MS
Simple applicationlevelproxy.
InherentlysupportedbyOSes, butneedsa proxyapplicationto be
developed.
No
ALG
LikeBIS, buttranslationof API callsinsteadof
packet headers.
No
BIA
RFC3338
ConnectIPv4 applicationsoverIPv6 infrastructure.
No
BIS
RFC2767
ConnectIPv6 applicationsoverIPv4 infrastructure.
Yes
SIIT
RFC2765
Comment
Cisco
©Peter R. Egli 2011
35
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (6/44):
1.1. Simple IPv4 and IPv6 dual stackdeployment
Applicationseitherusev4 orv6-sockets. BothIPv4 and IPv6 runon thesameEthernet.
1.2. VLAN basedIPv4-IPv6 coexistence(
RFC4554
)
Problem withapproachabove(1.1.): All routersin LAN mustsupportbothIPv4 and IPv6.
RFC4554
proposesto mapall IPv6 trafficintoa specificVLAN tag.
All switchesin thenetworkforwardthisVLAN trafficto a dedicatedIPv6 router.
IPv4
Internet
IPv6
Internet
IPv6 in
VLAN6
VLAN trunk
IPv6 in VLAN6
IPv4 in VLAN4
VLAN
Switch
VLAN
Switch
IPv6-only
node
IPv6/IPv4
node
IPv4-only
node
IPv4 in
VLAN4
IPv4
router
IPv6
router
IPv4 in
VLAN4
IPv4 in
VLAN6
V6
appl.
V4
appl.
TCPv4
IPv4
Ethernet
TCPv6
IPv6
IPv4/IPv6
router
IPv4-only
node
IPv6-only
node
Dual
stack
Physicalview:
IPv4/IPv6
router
IPv4-only
node
IPv6-only
node
Dual
stack
Logicalview:
IPv4 traffic
IPv6 traffic
©Peter R. Egli 2011
40
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (11/44):
2.1.2. 6over4 tunneling(
RFC2529
, „virtualEthernet“) (3/3):
6over4 maybeusedto connectisolatedIPv6 nodesto an IPv6 network.
6over4 isa host-to-hostand host-to-routertunnelingmechanism.
6over4 usesIPv4 forthetransmissionof encapsulatedIPv6 packet, thusittreatsthe
IPv4 Internet as a giantEthernet segment.
Everynodeneedsa uniqueIPv4 addressand IPv6 prefix.
6over4 usesunicastand multicast(forneighborand routerdiscovery).
6over4 usessimple protocol=41 encapsulation(IPv6 in IPv4):
Structureof 6over4 IPv6 address(sameas in 6in4):
6over mapstheIPv4 addressto theleast order bitsof theIPv6 address.
Criticismof 6over4:
6over4 requiresv4 multicast. Multicastisnot widelyavailablein IPv4, thus6over4
isof limiteduse(somesaythat6over4 isdeprecated).
FE80
0
IPv4 address
10 bits54 bits32 bits
0
32 bits
IPv4 header
Prot. = 41
Payload
IPv6
header
TCP/UDP
header
©Peter R. Egli 2011
42
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (13/44):
2.1.3. 6to4 tunneling(
RFC3056
) (2/3):
6to4 mapstheIPv4 addressspaceintotheIPv6 space:
6to4 usessimple protocol=41 encapsulation(IPv6 in IPv4):
Structureof the6to4 IPv6 address:
TheIPv4 addressusedfortunnelingtheIPv6 packetsispartof theIPv6 address.
Thepositionof theIPv4 addressin theIPv6 addressallowsprefixaggregation.
Theprefixlenghtwithoutsubnetis48 bits.
IPv4 address
space
16.32.1.1
48.64.1.2
6to4 space
Prefix2002::/16
IPv6 address
space
2002
IPv4 addr.
Subn.
Interface ID
16 bits32 bits16 bits64 bits
IPv4 header
Prot. = 41
Payload
IPv6
header
TCP/UDP
header
©Peter R. Egli 2011
43
Rev. 2.62
IPv6
indigoo
.
com
IPv4
network
•Migration stepsfortransitionfromIPv4 to IPv6 (14/44):
2.1.3. 6to4 tunneling(
RFC3056
) (3/3):
6to4 relayroutermaybeaddedto connectisolated6to4 hoststo IPv6-only hosts(IPv6 Internet):
6to4
router
IPv6
subnet
DNSv6
server
6to4 relay
router
Automatic 6to4 tunnel
IPv6
subnet
DNS AAAA request:
host.indigoo.com
v4A: 16.32.1.1v4A: 48.64.1.2
6to4A: 2002:3040:0102:1::1
v6A: X
IPv6-only node:
v6A: 2001:0DB8:B:1::1
DNS: host.indigoo.com
IPv6/IPv4 node:
v6A: 2001:0DB8:A:1::1
6to4A: 2002:1020:0101:1::1
DNS AAAA response:
2001:0DB8:B:1::1
6to4 packet:
V6 src. IP: 2002:1020:0101:1::1
V6 dst. IP: 2001:0DB8:B:1::1
Encapsulated6to4 packet:
V4 src. IP: 16.32.1.1
V4 dst. IP: 48.64.1.2
V6 src. IP: 2002:1020:0101:1::1
V6 dst. IP: 2001:0DB8:B:1::1
6to4 packet:
V6 src. IP: 2002:1020:0101:1::1
V6 dst. IP:2001:0DB8:B:1::1
Routingtableentry:
Dst: 2001:0DB8:B:1::1
Nexthop: 2002:3040:0102:1::1
Routingtableentry:
Dst: 2001:0DB8:B:1::1
Nexthop: 2002:3040:0102:1::1
©Peter R. Egli 2011
46
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (17/44):
2.1.4. ISATAP –Intra-SiteAutomatic TunnelingAddressingProtocol(
RFC5214
) (3/4):
Step bystepexplanationof ISATAP interactionbetweenISATAP nodeand IPv6-only node:
1./2. ISATAP nodeascertainsISATAP router:
TheISATAP node'A' makesa normal IPv4 DNS queryforisatap.example.comin order to find an ISATAP router.
Insteadof DNS (v4) theISATAP nodecouldusesomeothermeanssuch as DHCP optionsto find an ISATAP router.
TheIPv4 DNS serverrespondswiththeroutersIPv4 address48.64.1.1.
3. AddISATAP routerIPv4 addressto PRL:
TheISATAP node'A' addstheroutersIPv4 addressto itsPotential RouterList (PRL). Thislist containstheIPv4 addressof
availableISATAP routerinterfacesalongwitha time-to-liveof thisaddress(forredundancyreasonsmultiple ISATAP router
interfacesmaybeavailable, so itisimportantthateachISATAP nodeknowsavailableand validISATAP interfaces).
4./5. Routersolicitationto receiveISATAP supportinformation:
TheISATAP node'A' sendsan ISATAP-encapsulated(link-localIPv6 addresses) routersolicitationmessage(ICMPv6)
to receiveadditional information, namelytheglobal prefixto beusedfortheISATAP addresses.
Therouterrespondswitha routeradvertisementcontainingtheglobal IPv6 prefixto beusedforISATAP addresses(needed
so thatthedestinationnode'B' cansend back packetsto theISATAP node'A').
6./7. DNS queryforindigoo.comto obtaintargetIpv6 address:
TheISATAP node'A' receivestheIPv6 addressof thenode'B' througha DNS query(DNSv4, oneof theanswerscontains
an AAAA entry).
8. ISATAP-encapsulationof packet:
Node'A' encapsulatestheIPv6 packet in an IPv4 packet (tunnel) usingtherouter'sIPv4 as destinationaddress. TheIPv6 source
addressisnow2001:0DB8:A::5EFE.16.32.1.1 so thatthedestinationhas a reachableIPv6 addresswhereto send back packets.
9. RouterdecapsulatestheISATAP packet:
TheISATAP routerdecapsulatesthepacket (tunneltermination) and forwardsittowardsthedestinationusingstandardIPv6
routing.
©Peter R. Egli 2011
47
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (18/44):
2.1.4. ISATAP –Intra-SiteAutomatic TunnelingAddressingProtocol(
RFC5214
) (4/4):
ISATAP workssimilarto 6over4 butdoesnot requireIPv4 multicastsupport.
InsteadISATAP usesIPv4 as a non-broadcastmultiple access(NBMA) link layer.
To compensateforthemissingmulticastISATAP-nodesusetables(PRL) withISATAP-router
interfacesthatserveas ISATAP-tunnelendpoints.
Whenusingglobal addresses(obtainedthroughDNS + routersolicitation) insteadof link local
addressesISATAP evenallowsto connecthostswithprivate IPv4 addressesto theIPv6 Internet.
ISATAP uses simple protocol=41 encapsulation (IPv6 in IPv4):
Structureof ISATAP IPv6 address:
ISATAP mapstheIPv4 addressto least order bitsand prefixingtheIPv4 addresswith0x5EFE.
ISATAP addressesmayhavelink-localorglobal prefixes.
Criticismof ISATAP:
ISATAP requiresseveralnetworkresourcesto workin concert (DNS server, maybeDHCP server,
ISATAP router). Configuringtheseconsistentlymaynot beeasy.
FE80
0
IPv4 address
10 bits54 bits32 bits16 bits
0
5EFE
16 bits
2001
IPv4 address
10 bits54 bits32 bits16 bits
0
5EFE
16 bits
ISATAP addresswithlink-localprefix ISATAP addresswithglobal prefix
0DB8:B:1
IPv4 header
Prot. = 41
Payload
IPv6
header
TCP/UDP
header
©Peter R. Egli 2011
48
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (19/44):
2.1.5. Teredo(
RFC4380
) (1/6):
Teredowas developedmainlybyMicrosoft as tunnelingtransitionmechanismto pass throughNATs.
Simple 6in4 encapsulation as in 6to4, 6over4, 6in4 or ISATAP makes it difficult or impossible to
traverse NAT-firewalls.
Teredois a transition mechanism that will be replaced when more and more NATssupport 6to4
Tunneling (translate addresses also for proto=41 encapsulated packets).
Teredorequires an understanding of NAT-types as defined in
RFC3489
(STUN).
Before communication with a peer starts, a Teredoclient must determine the type of NAT it is behind
(qualification procedure).
Teredois a host to host (H2H) or host to router (H2R) tunneling protocol (using a Teredorelay).
Teredoencapsulates IPv6 packets in an additional UDP header for NAT-traversal:
Structure of Teredoaddress:
Teredoaddresses are constructed from IPv4 addresses. They may be registered with DNS.
IPv4 header
Prot= 41
Payload
IPv6
header
TCP/UDP
header
UDP
header
Client IPv4
32 bits32 bits32 bits
T. serverIPv4
16 bits
Routerprefix
Flags
16 bits
Port
©Peter R. Egli 2011
52
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (23/44):
2.1.5. Teredo(RFC4380) (5/6):
Step by step explanation of initial client configuration of a Teredosession:
Scenario 1: Cone NAT
1. Client sends an RS probe with cone flag=1:
The client sends an ICMPv6 router solicitation (RS) message to the Teredoserver. The cone flag in the probe is set to 1.
2. Teredoserver RA response:
The Teredoserver responds with a router advertismentmessage (RA). Because the cone flag in the RS message was set to 1,
the server uses a different IPv4 address as source address (48.64.1.2 instead of 48.64.1.1).
If the client receives the RA message it knows that it is behinda cone NAT (different destination addresses use the same
mapped address). The client now constructs its TeredoIPv6 address (structure see above).
Scenario 2: Restricted cone NAT:
1. Client sends an RS probe with cone flag=1:
As in scenario 1 the client sends an RS probe packet.
2. Teredoserver RA response:
As in scenario 1 the server responds with an RA packet. The restricted cone NAT, however, blocks the packet.
3. Client sends RS probe with cone flag=0:
Because the client has not received the RA packet it re-sends the RS probe, but sets the cone flag to 0.
4. Teredoserver RA response:
Because the cone flag in the probe packet was set to 0, the server sends the RA packet from the IPv4 address on which it
received the RS probe packet (48.64.1.1).
5. Additional RS+RA to a different Teredoserver:
The client sends RS probe to second Teredoserver to check if it is behind a symmetric NAT.
If the client determines that it is behind a symmetric NAT communication stops. The client constructs its TeredoIPv6 address.
©Peter R. Egli 2011
53
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (24/44):
2.1.5. Teredo(RFC4380) (6/6):
Step by step explanation of punching holes into NATs:
1. Host A sends bubble packet:
Host A sends a bubble packet directly to host B. Host A’s NAT will add an address mapping into its NAT table to allow
packets from any outside host addressed to A’s IPv4 address and port number to pass.
Host B’s NAT blocks the bubble packet because there is no mapping in its table.
2. Host A sends a bubble packet to host B’s Teredoserver:
Host A determines host B’s Teredoserver (see address structure above) and sends a bubble packet to it.
3. Host B’s Teredoserver forwards bubble packet:
Host B’s Teredoserver determines that the packet is a Teredopacket and forwards it to host B. Host B’s NAT lets the
Packet pass because it contains an address mapping for packets from Teredoserver B (from the qualification procedure at the
Beginning).
4. Host B sends bubble packet to host A:
Host B sends a bubble packet back directly to host A. This adds a NAT entry for packets from host A in host B’s NAT.
5. Tunneled application packet:
Host A now sends an application IPv6 packet encapsulated in an IPv4 packet to host B.
©Peter R. Egli 2011
55
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (26/44):
2.1.7. Tunnel broker/ tunnelserver(
RFC3053
) (2/3):
Step by step explanation of a tunnel broker session:
1. Clients request:
The client sends a request to the tunnel broker (TB) to setup a tunnel. It is recommended to use HTTP as underlying protocol.
2. Access control:
The tunnel server may perform some access control functions suchas authentication, authorization and possibly accounting
through a protocol like RADIUS. This function is particularly interesting for ISPs to control who accesses their network.
3. IPv6 address allocation:
Based on the information given by the client (role: single node or router) the TB assigns and reserves an IPv6 address
(range).
4. Client DNS name registration:
The TB registers the client's DNS name under the assigned IPv6 address in the global DNSv6 space.
5. Tunnel setup:
The TB sets up the tunnel on the tunnel server.
6. Tunnel parameters to client:
The TB informs the client about the tunnel parameters.
7. User packet sent by client:
The client application sends an IPv6 packet to the destination. The tunnel function in the client encapsulates the packet
in an IPv4 packet.
8. Decapsulation+ forward:
The tunnel server decapsulatesthe tunnel packet and forwards it to the next hop in the IPv6 network. The packet is forwarded
based on standard IPv6 routing.
©Peter R. Egli 2011
56
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (27/44):
2.1.7. Tunnel broker/ tunnelserver(
RFC3053
) (3/3):
Withdynamic(on-demand) tunnelcreationno configurationon theclientisrequired.
Tunnel setupissimilarto settingup a VPN connection(tunnelbroker+server= VPN server).
As such a tunnelbrokertogetherwiththetunnelserveractslikea virtualIPv6 ISP.
Tunnel brokerisnot a protocolbuta generalarchitectureforconnectingdual stackhoststo
an IPv6 network.
Tunnel brokermodelcanbeusede.g. with6to4 to automaticallysetuptunnels.
Tunnel brokerisbest suitedto connectisolatednodesto an IPv6 network.
Themaintunnelbrokerfunctionsare:
1. Access control(e.g. throughRADIUS)
2. Register clientDNS namein theIPv6 DNS space
3. Assignoneormultiple IPv6 prefixesto theclient(default: 48 prefix)
Thereexistcommercialtunnelbrokers.
List of tunnelbrokerssee
http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
.
©Peter R. Egli 2011
57
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (28/44):
2.1.8. DSTM –Dual StackTransitionMechanism(Internet draft) (1/3):
DSTM isintendedforbeingusedwhenIPv4 and IPv6 arein balance(communicationbetweenexisting
IPv4 and IPv6 hosts).
DSTM isverysimilarto thetunnelbrokertransitionmechanism. Unliketunnelbroker, DSTM tunnels
IPv4 packetsoveran IPv6 network(tunnelbroker: IPv6 tunneledoverIPv4).
DSTM isa componentof theOS of a hostand interceptsand tunnelspacketsas per theDSTM
protocol. IPv6 applicationsareunawareof thepresenceof DSTM and workjust likenormal IPv6
applicationsusingv6 sockets.
©Peter R. Egli 2011
59
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (30/44):
2.1.8. DSTM –Dual Stack Transition Mechanism (Internet draft) (3/3):
Step by step explanation of DSTM scenario IPv6
IPv4:
1. DNSv6 request:
The DSTM component on host A intercepts a request by the DNS resolver. DSTM translates the request for host.indigoo.com
into an A and AAAA DNS request for host.indigoo.com(v6 request).
2. DNS response:
As host B is an IPv4-only node, the DNS server only has an A record for host B and returns this to host A.
3.+4. Host A obtainstemporaryIPv4 address:
As DSTM onlyreceivesan A record, itcontactstheDSTM serverto obtaina temporaryIPv4 address. Thisstepmayuse
existingprotocolslikeDHCPv6. AlongwiththetemporaryIPv4 addressDSTM also obtainstheIPv6 addressof theDSTM
gateway.
5. Tunnelingtheapplicationpacket to theDSTM gateway:
Theapplicationsendsa packet to theIPv4 hostB. DSTM interceptsthepacket, encapsulatesitintoan IPv6 packet and
forwardsitto theDSTM gateway.
6. Packet decapsulation:
TheDSTM gatewaydecapsulatesthepacket and forwardsitto theIPv4 destinationhostB.
©Peter R. Egli 2011
60
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (31/44):
3.1. NAT-PT –NetworkAddressTranslation, Port Transl. (
RFC2766
, deprecatedby
RFC4966
):
NAT-PT combinesaddresstranslationtogetherwithprotocoltranslationas definedin
RFC2765
.
NAT-PT maintainsa poolof uniqeIPv4 addressesthataredynamicallyassignedto IPv6 hosts(stateful
translationas themappingof IPv6 to IPv4 mustbemaintainedin tables).
NAT-PT comesin 2 flavors:
a. Basic NAT-PT:
Translationof IP addressesonly.
Maps1 IPv6 addressto 1 IPv4 address(1:1 mapping). Problem: IPv4 addressdepletion.
b. NAPT-PT:
Address(IP) and porttranslation.
Multiple IPv6 addressaremappedto 1 commonIPv4 address(conservesIPv4 addresses).
1 IPv6 addressismappedto a TCP/UDP portnumber.
NAT-PT isdeprecatedby
RFC4966
dueto varioustechnicalproblemsthathamperthedeployment
of IPv6.
IPv6/IPv4 dual-stackrouter
Operations:
a. Addresstranslations
b. Protocoltranslations
IPv4
network
IPv6
network
IPv6 host
IPv6
addr.
pool
IPv4
addr.
pool
Port map:
IPv6 addr. UDP port
IPv6 host
©Peter R. Egli 2011
61
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (32/44):
3.2. SIIT -StatelessIP/ICMP Translation(
RFC2765
) (1/3):
SIIT is similar to NAT-PT but does not translate port numbers. The translation is stateless (no address
pools with stored mappings between IPv4 and IPv6 addresses).
IPv4
network
SIIT
IPv6 layer and SIIT may be on the
same host (dual stack with SIIT,
see below)
V6 src. IP:
::FFFF:0:16.32.1.1
V6 dst. IP:
::FFFF:48.64.1.1
IP4-only nodeB:
v4A: 48.64.1.1
DNS: host.indigoo.com
DNSv6 server
DNS AAAA request:
host.indigoo.com
DNS AAAA response:
::FFFF:0:48.64.1.1
V4 src. IP:
16.32.1.1
V4 dst. IP:
48.64.1.1
1
2
3
4
IPv6/IPv4 nodeA:
v4A: 16.32.1.1
©Peter R. Egli 2011
62
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (33/44):
3.2. SIIT -StatelessIP/ICMP Translation(
RFC2765
) (2/3):
Step by step explanation of SIIT transaction:
1.+2. DNSv4 request:
SIIT does not define how a SIIT host obtains a SIIT destination IPv6 address. This may be through standard IPv6 DNS lookup
or some other mechanism.
The obtained destination address is the IPv4-mapped address.
3. IPv6 packet:
The IPv6 IP layer constructs a packet where the IPv6 dst. address is the destination's IPv4-mapped address and the IPv6
source address is the source's IPv4-translated address.
4. SIIT packet interception and header translation:
The SIIT layer in the stack intercepts the packet. Because the IPv6 dst. address is an IPv4-mapped address (=trigger), SIIT
translates the IP header from V6 to V4 with the following mappings (6
4 direction):
Protocol= IPv6 next header field value
Src. IP addr.= Low order 32 bits of IPv6 src. addr.
Dst. IP addr.= Low order 32 bits of IPv6 dst. addr.
In the reverse direction (4
6) the mappings are:
Next header = IPv4 protocol field value
Src. IP addr. = ::FFFF:0:A.B.C.D (IPv4-translated addr.)
Dst. IP addr. = ::FFFF:A.B.C.D (IPv-mapped addr.)
©Peter R. Egli 2011
63
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (34/44):
3.2. SIIT -StatelessIP/ICMP Translation(
RFC2765
) (3/3):
Structureof SIIT IPv6 addresses:
SIIT usesan IPv4-translated addressas sourceIPv6 addressto allowtunnelsbetweentheIPv6 layer
and theSIIT layer(SIIT layermayresidein a separate box oron thesamemachineas theIPv6 layer).
SIIT stack:
WhencolocatedwiththeIPv6 layertheSIIT layerinterceptsIPv6 packetsand translatesthem.
0
IPv4 address
80 bits32 bits
FFFF
16 bits
Ethernet
TCP/UDP
IPv6
IPv6 Application
SIIT
IPv4
0
IPv4 address
64 bits32 bits
0
16 bits
FFFF
IPv4-mapped address(SIIT sourceaddress) IPv4-translated address
(SIIT destinationaddress)
©Peter R. Egli 2011
64
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (35/44):
3.3. BIS -Bumpin theStack(
RFC2767
) (1/4):
BIS issimilarto SIIT, butthepurposeisto provideconnectivityforIPv4 hostsoveran IPv6 network.
BasicallyBIS isNAT-PT and SIIT functionalitycombinedand movedintothehostOS betweentheIPv4
and IPv6 stack.
Possiblescenarios:
1. Remotehostisan IPv4/IPv6 host. DNS providesan A and AAAA DNS mapping.
2. Remotehostisan IPv6-only host. DNS onlyprovidesan AAAA mapping.
3. Remotehostisan IPv4-only host. DNS onlyprovidesan A mapping.
BIS stack:
TheextensionnameresolverinterceptsIPv4 DNS queries(A queries) and createsan additional query
forA (IPv4) and AAAA (IPv6) queries.
ThetranslatorcomponenttranslatestheIPv4 headerintoan IPv6 headeraccordingto SIIT (seeabove).
Theaddressmapperisresponsibleforthestoringof IPv4 to IPv6 addresspairs.
Ethernet
TCP/UDP
IPv4
IPv4 Application
Translator
IPv6
Addr.
mapper
Ext. name
resolver
©Peter R. Egli 2011
65
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (36/44):
3.3. BIS -Bumpin theStack(
RFC2767
) (2/3):
BIS scenario1: RemotehostB isan IPv4/IPv6 node.
IPv6
network
IPv4 appl.
IPv6/IPv4 nodeB:
v6A: ::FFFF.48.64.1.1
v4A: 48.64.1.1
DNS: host.indigoo.com
DNSv6 server
DNSv4 request:
host.indigoo.com
DNS AAAA response:
AAAA ::FFFF.48.64.1.1
A 48.64.1.1
1
2
3
IPv6/IPv4 nodeA:
v4A: 16.32.1.1
Ext. name
resolver
Addr. mapper
+ translator
IPv6
InterceptA request, convertto
A and AAAA request:
host.indigoo.com
Addressmap:
IPv6 addr. IPv4 addr.
::FFFF.48.64.1.1 48.64.1.1
::FFFF:0.16.32.1.1 
16.32.1.1
Addmappingto addressmap:
::FFFF.48.64.1.1 
48.64.1.1
IPv4
4
DNS A response:
48.64.1.1
5
Appl. packet
V4 src. IP:
16.32.1.1
V4 dst. IP:
48.16.1.1
IPv4
addr.
pool
6
7
V6 src. IP:
::FFFF:0:16.32.1.1
V6 dst. IP:
::FFFF:48.64.1.1
©Peter R. Egli 2011
66
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (37/44):
3.3. BIS -Bumpin theStack(
RFC2767
) (3/4):
Step by step explanation of BIS scenarios 1-3 (1/2):
1. DNSv4 request:
The v4 application makes a DNS A request for indigoo.com(v4 request).
2. Extension nameresolverDNS requestinterception:
Theextensionnameresolver(partof theBIS stack) interceptstheDNSv4 requestand convertsitintoa V4/v6 request(A and
AAAA request). TheDNS servermaybean IPv4 orIPv6 host.
3. DNS AAAA response:
Scenario1 (IPv4/IPv6):
TheDNS serverrespondswithan A and AAAA response.
Scenario2 (IPv6-only):
TheDNS serverrespondswithan AAAA responseonly.
Scenario3 (IPv4-only):
TheDNS serverrespondswithan A responseonly.
4. AddmappingbetweenIPv4 and IPv6 address:
Scenario1 (IPv4/IPv6):
Theextensionnameresolverinstructstheaddressmapperand translatorto adda mappingbetweenthereceivedIPv4 and
IPv6 addressesto themappingtable(::FFFF.48.64.1.1 48.64.1.1).
Scenario2 (IPv6-only):
The extension name resolver instructs the address mapperand translator to allocate a free IPv4 address from the addresspool
and to add the mapping between the IPv4 and IPv6 address to the mapping table (2001:0DB8:B:1::1 
48.64.1.1).
Scenario 3 (IPv4-only):
As thereisno IPv6 addressthereisno mappingbetweenIPv4 and IPv6. ThetransactioncontinueswithIPv4 only.
©Peter R. Egli 2011
67
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (38/44):
3.3. BIS -Bumpin theStack(
RFC2767
) (4/4):
Step by step explanation of BIS scenarios 1-3 (2/2):
5. Report IPv4 addressto theIPv4 application:
TheextensionnameresolverreportsthequeriedIPv4 addressto thecallingapplication.
6. Send packet withIPv4 addresses:
TheIPv4 applicationsendsa packet withIPv4 addresses.
7. Packet interceptionand headertranslation:
Theaddressmapperand translatorinterceptstheIPv4 packet, translatestheheaderto IPv6 and insertstheIPv6 addresses
as definedin theaddressmap. Thisstepsisidenticalto whatSIIT does. Finallythepacket isforwardedtowardstheIPv6
destination.
©Peter R. Egli 2011
68
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (39/44):
3.4. BIA -BumpIn theAPI (
RFC3338
):
Similarto BIS, butthepurposeof BIA isto allowIPv4 applicationsto communicateoveran IPv6
network.
UnlikeBIS, BIA translatesbetweenIPv4 and IPv6 APIs(socketlayer). BIA isimplementedas a layer
betweentheapplicationand thetransportlayer(TCP, UDP).
TheBIA scenariosareverysimilarto BIS (also seescenariosabove). Insteadof translatingIPv4
headers(translator) BIA translatesthesocketAPI calls, so thereisno needto translateIPv4 headers.
BIA stack:
The extension name resolver intercepts IPv4 DNS queries (A queries) and creates an additional query
for A (IPv4) and AAAA (IPv6) queries.
The function mappercomponent translates the IPv4 socket calls into corresponding IPv6 socket calls.
The address mapperis responsible for the storing of IPv4 to IPv6 address pairs (allocates IPv4
addresses from the unassigned range 0.0.0.0/24).
Ethernet
SocketAPI (IPv4, IPv6)
BIA: API translator
IPv4 Application
Function
mapper
Addr.
mapper
Name
resolver
TCP/IPv6
TCP/IPv4
©Peter R. Egli 2011
69
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (40/44):
3.5. ALG -ApplicationLayerGateway:
ALGsaresimple dual-stackapplicationlayerproxiesthatperformtranslationon applicationlayer.
UnlikeSOCKS64 (seebelow) thetranslationincludestheapplicationlayerprotocol(e.g. HTTP),
e.g. thetranslationof URLs (IPv4 addressesto IPv6 address).
ALGscaneitherconnectexistingIPv4 serversto theIPv6 Internet (picturebelow) ormakenew
IPv6 serversavailableon theexistingIPv4 Internet.
ALG stack:
IPv4
network
IPv6-only nodeA:
v6A: 2001:0DB8:B:1::1
IPv4
Ethernet
IPv6
Proxy
application
IPv6
network
ALG / (e.g. web proxy):
IPv4/IPv6 node:
V6A: 2001:0DB8:B:2::1
v4A: 16.32.1.1
IPv4-only nodeB (e.g. web server):
v4A: 48.32.1.1
TCPv4
TCPv6
©Peter R. Egli 2011
70
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (41/44):
3.6. SOCKS64 (
RFC1928
/
RFC3089
):
RFC1928
definestheSOCKS protocolforIPv4 and IPv6. Itallowshoststo traverse firewalls
similarto ALG. UnlikeALGs, SOCKS gatewaysperformonlyTCP / UDP protocolterminationand
addresstranslation.
RFC3089
makesuseof theSOCKS protocolto providecircuitlayertranslationbetweenIPv4 and IPv6.
UnlikeALG theSOCKS64 translationisapplication-protocolagnostic(e.g. not URL translationfor
HTTP).
In SOCKS64, DNS nameresolutionisdelegatedto theSOCKS gateway.
SOCKS64 protocolstack:
SOCKS64
TCP4
TCP6
IPv4
IPv6
TCP4
IPv4
TCP6
IPv6
IPv6
network
IPv4
network
©Peter R. Egli 2011
71
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (42/44):
3.7. TRT –Transport RelayTranslator(
RFC3142
) (1/3):
TRT allowsto connectIPv6 hostswithIPv4 servers(e.g. web servers).
TRT isverysimilarto SOCKS64. ButunlikeSOCKS64, TRT doesnot requiremodificationson theIPv6
orIPv4 hosts.
LikeSOCKS64 TRT terminatestransportprotocols(TCP, UDP) butdoesnot filterormanipulate
theapplicationPDU (APDU).
Similarto BIS/BIA TRT isbasedon "spoofing" DNS responses. ButunlikeBIS/BIA TRT usesan
applicationlayerDNS proxyon a separate machine. Comparedto BIS/BIA thishas theadvantage
thattheIPv6 orIPv4 hostsdo not needto bemodified.
Possible scenarios:
1. Remote host is an IPv4-only host. DNS only provides an A mapping.
2. Remote host is an IPv4/IPv6 host. DNS provides an A and AAAA DNS mapping.
3. Remote host is an IPv6-only host. DNS only provides an AAAA mapping.
TRT stack:
IPv4
Ethernet
IPv6
Proxy
application
TCPv4
TCPv6
©Peter R. Egli 2011
72
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (43/44):
3.7. TRT –Transport RelayTranslator(
RFC3142
) (2/3):
TRT scenario 1: Remote host B is an IPv4-only node.
IPv4
network
IP4-only nodeB:
v4A: 48.64.1.1
DNS: host.indigoo.com
DNSALG
(DNS proxy)
IPv6 node:
v6A: 2001:0DB8:B:1::1
IPv6
network
DNS
server
TRT
DNSv6 request:
host.indigoo.com
DNS A and
AAAA request:
host.indigoo.com
DNS A response:
48.64.1.1
FakeDNS AAAA
response:
C6::48.64.1.1
V6 src. IP:
2001:0DB8:B::1:1
V6 dst. IP:
C6::48.64.1.1
v4A: 16.32.1.1
V4 src. IP:
16.32.1.1
V4 dst. IP:
48.64.1.1
1
2
3
4
5
6
©Peter R. Egli 2011
73
Rev. 2.62
IPv6
indigoo
.
com
•Migration stepsfortransitionfromIPv4 to IPv6 (44/44):
3.7. TRT –Transport RelayTranslator(
RFC3142
) (3/3):
Step by step explanation of TRT scenarios:
1. DNSv6 request:
The v6 application on host A makes a DNS AAAA request for indigoo.com(v6 request). Host A sends the DNS request
to the DNS proxy (DNSALG).
2. DNS request:
TheDNS proxysendsan A and AAAA queryto theactualDNS server.
3. DNS response:
Scenario1 (remotehostB isIPv4-only):
TheDNS serverrespondswithan A response.
Scenario2 (remotehostB isIPv4/IPv6):
TheDNS serverrespondswithan A and AAAA response.
Scenario3 (remotehostisan IPv6-only node):
TheDNS serverrespondswithan AAAA responseonly.
4. AddmappingbetweenIPv4 and IPv6 address:
Scenario1 (IPv4-only):
TheDNS proxyconstructsa TRT addressfromthereceivedIPv4 addresswiththeprefixC6::/8.
Scenario2+3 (IPv4/IPv6 and IPv6-only):
Obviously the remote host B is connected to IPv6 as well. Thus the DNS proxy returns the IPv6 address to host A. The
communication continues with IPv6.
5.+6. Packet translation by TRT:
TheTRT conversttheIPv6 packet intoan IPv4 packet (terminatesTCP orUDP v6, createsa newpacket). Itusestheloworder
4 bytesof thedestinationIPv6 addressas destinationIPv4 address.
TheTRT usesitsownIPv4 addressas sourceaddress.