Protocol

The---------------------------------------------------------------------------------------------
Internet Protocoljournal March 2011 Volume 14, Number 1 A Quarterly Technical Publication for Internet and Intranet Professionals In This Issue
You can download IPJ back issues and find subscription information at: www.cisco.com/ipj F R ! T " # # $ I T R %
In &'(( we ha)e alread* seen some important Internet anni)ersaries and milestones. +e ha)e celebrated &, *ears of I#TF meetin-s and .' *ears of the FTP protocol/ but the most si-nificant milestone took place in Februar* when I010 handed out its final blocks of IP). addresses to the RIRs 2see pa-e &(3. It seems like a -ood time to publish an edition of IPJ de)oted entirel* to IP)./IP)4 transition/ and to help me with this task I ha)e in)ited 5eoff "uston as co6 editor and author for this issue/ so let me hand it o)er to him:
There is a 7hinese pro)erb that states: 8It9s better to
The I#TF desi-ned IP)4 in the (=='s for this )er* reason. Its (&;6 bit address field is easil* capable of accommodatin- the output of a prolific silicon manufacturin- industr* for man* decades to come. >ut when we look at toda*9s Internet/ )er* little IP)4 can be seen. #stimates of the number of clients with functional IP)4 ser)ices ho)er at around '.& to '.. percent of the total.
be a doin a peaceful time than be a man in a chaotic period.: For the Internet/ this *ear is shapin- up to be a time that looks more like de)elopin- chaos than serenit* and peace. The I010 has -i)en out the last /;9s/ and demand has alread* depleted the IP). address stocks in the 0sia Pacific. !eanwhile/ the industr* has disco)ered the mass marketin- potential of mobile de)ices/ and e<pects to sell and connect more than &,' million of them in &'(( alone.
The stor* about IP)4 transition technolo-ies is comple</ and there are man* wa*s to undertake this effort. In this issue we will e<amine the )arious approaches and their relati)e stren-ths and weaknesses.
In order to send out a broad messa-e about the need to shift online content from e<clusi)el* usin- IP). into a dual6stack world of both IP). and IP)4/ I% 7 is supportin- World IPv6 Day on June ;. Phil Roberts e<plains this initiati)e and its role in helpin- the o)erall transition effort.
This transition is -oin- to be difficult. It in)ol)es all parts of this THE INTERNET PROTOCOL JOURNAL
2
di)erse industr*/ and means combinin- some well6 understood and widel*6 .
deplo*ed technolo-ies in some surprisin- and challen-in- wa*s. There is much to do/ and we hope that this issue of IPJ pro)ides an insi-ht into just what the transition to IP)4 will entail
I%%1 (=..6((?. Geoff Huston, -ih@apnic.net Ole J. Jacobsen, ole@cisco.com
Ch ef !c ent st, "P#IC $d tor and Publ sher, IP
THE INTERNET PROTOCOL JOURNAL

3
J0 Rou-h 5uide to 0ddress #<haustion by Geoff Huston, "P#IC
he le)el of interest in IP). address e<haustion seems to be increasin-/ so I thou-ht I would share some answers to the most common Auestions I ha)e been asked on this topic in recent times. +hat is the most si-nificant challen-e to the Internet toda*B
+hat a wonderfull* open6ended AuestionC There are so man* chal6 len-es that I could identif*: impro)in- the le)el of securit* on the network/ eradicatin- spam and )iruses/ impro)in- capacit* of the network infrastructure/ impro)in- the efficienc* of hi-h6speed data transfer/ impro)in- the accurac* of search en-ines/ buildin- more efficient and hi-h6capacit* data centers/ and reducin- the unit cost of Internet ser)ices/ to name but a few.
If there is a common factor in man* of these challen-es/ it is scal n% the network to meet an e)er6e<pandin- a-enda of more
users/ more de)ices/ more traffic/ more ser)ices/ and more policies. 0nd with more users and more forms of use come hi-her le)els of di)ersit* of use and -reater need to replace implicit mechanisms of trust with e<plicit forms of trust ne-otiation and -reater le)els of demonstrable inte-rit* of operation.
>ut these topics are all tactical in nature. The* reflect the 8how: of makin- the network work tomorrow b* stud*in- how to undertake mar-inal impro)ements on the network of toda*. "owe)er/ it is not clear that the networks not just of tomorrow or ne<t *ear/ but a decade or more hence should reflect the usa-e patterns and user population of toda*. Perhaps a more fundamental challen-e is to understand what is missin- in toda*9s network that we will need in the future.
This discussion leads to a prett* ob)ious challen-e/ at least for me. The basic currenc* of an* network is dent f ers. Identifiers allow the network to distin-uish between clients and ensure that con)ersations occur between those parties who intended to communicate. In the world of packet6switched networkin-/ such as
IP/ these endpoint identifiers are s*non*mous with the concept of an address. +hat is missin- in toda*9s network is an abundant suppl* of new addresses that will allow the network to scale up in siDe b* a further factor of at least ( million/ and hopefull* more than a billion6fold.
In fact/ the suppl* of addresses is not just inadeAuate for future needs for a decade hence. The stock of addresses is facin- imminent depletion/ and the Auestion of a)ailabilit* of addresses is best phrased in terms of months rather than *ears.Perhaps the term 8address: is somewhat of a misnomer in this conte<t/ but it ma* well be too late to chan-e that now. The primar* role of an IP address is not to uniAuel* identif* the location of an endpoint of a network in relation to some positional or topo-raphical coordinate set/ but to simpl* uniAuel* identif* an endpoint to distin-uish it from all other endpoints. Its location is not an intrinsic propert* of this so6called address. >ut common con)ention is to call these endpoint identifiers 8addresses/: so I will stick with the same con)ention here.
%o m* candidate 8most si-nificant challen-e for the Internet toda*: is that we are runnin- out of further suppl* of IP addresses.

7
Address Exhaustion: cont nued +hat is an IP address/ and wh* is it so importantB
ne of the re)olutionar* chan-es introduced b* the so6called &ac'et( s) tched network architecture of the InternetEas compared to its telephone predecessor that used c rcu t s) tch n%Ewas that a massi)e amount of 8intelli-ence: was ripped out of the network and placed into the de)ices that connect at the ed-e.
IP networks are incredibl* simple/ and at their most basic le)el the* do )er* little. The* are built of routers and interconnectin- conduits. The function of a router is Auite simple. 0s a packet arri)es at the router from the connected circuitr* 2or from a wireless interface3/ it is di)ided into a common IP header and a pa*load. The IP header of the packet contains/ amon- other components/ two fi<ed6len-th fields: the address of the intended dest nat on of the packet/ and/ like a postal en)elope/ the address of the packet creator/ or the source. The router uses the destination address of the packet to make a routin- decision as to how to dispose of the packet. For each incomin- packet/ THE INTERNET PROTOCOL JOURNAL
8
the router inspects the destination address in the packet and either passes it to a connected computer if there is an address match or otherwise passes it down the default path to the ne<t router. 0nd that is a workin- description of the entiret* of toda*9s Internet. The important aspect here is that e)er* connected de)ice must ha)e a uniAue address. 0s lon- as this condition is satisfied/ e)er*thin- else can be made to work.
In the current )ersion of the Internet Protocol/ an 8address: is a ?&6bit field/ which can encompass some ... billion uniAue )alues. +h* are we runnin- out of addressesB
>lame silicon. )er the past ,' *ears/ the silicon chip industr* has -raduated from the humble transistor of the (=,'s to an astonishin- industr* in its own ri-ht/ and the ke* to this silicon industr* is )olume.

9
Address Exhaustion: cont nued Indi)idual processor chips ma* take hundreds of millions of dollars to desi-n/ but if fabricated in sufficient )olume/ each processor chip ma* take as little as a few dollars to manufacture and distribute. The lar-er the production run of the silicon die/ the lower the unit price of the resultant chip. +e currentl* produce a hu-e )olume of computers e)er* *ear. In &''; alone around (' billion computer processors were manufactured. 0lthou-h most of these microprocessors are simple ;6bit processors that are used to open doors or run ele)ators/ a siDable proportion are used in de)ices that support communications/ whether it is in laptop computers/ smartphones/ or e)en more basic communication applications. T*picall* we do not in)ent a new communications protocol for each new application. +e rec*cle. 0nd these da*s if we want a communications protocol for a particular application/ it is easiest to simpl* embed the IP protocol en-ine onto the chip. The protocol is cheap/ well tested/ and it works across almost an* scale we can ima-ine from a couple of bits per second to a couple of billion bits per second.
%o it is not just the entire human population of the planet who ma* well ha)e a desire to access the Internet in the future/ but eAuall* important is the emer-in- world of 8thin-s: that communicate. +hether it is the latest fashion in mobile phones or more mundane consumer electronics de)ices such as tele)isions or -ames consoles/ all these de)ices want to communicate/ and to communicate the* need to ha)e a uniAue identification code to present to the network/ or/ an 8address.:

10
+e are presentl* turninon more than &'' million new Internet ser)ices e)er* *ear/ and toda* we ha)e used up most of the ... billion addresses that are encompassed b* the IP protocol. +hen will we run outB
0s of %eptember &'('/ some (,( million addresses were left in the -eneral6use pool of unallocated addresses that are mana-ed b* the central pool administration/ the Internet "ss %ned #u*bers "uthor ty 2I0103. The world9s IP address consumption rate peaked earlier this *ear at a new all6time hi-h of an eAui)alent rate of &.? million addresses per *ear.
>* earl* Februar* &'(( I010 handed out its last address blocks to the RIRs.

11
Address Exhaustion: cont nued The fi)e +e% onal Internet +e% str es 2RIRs3F(G still had pools of addresses a)ailable for -eneral use at that time/ but from that point/ as the* further run down their local pools/ the I010 is now unable to pro)ide an* more addresses to replenish them. The 0sia Pacific Re-ional Re-istr*/ 0P1I7/ has been e<periencin- the hi-hest le)el of demand in the world/ accountin- for some two6thirds of all addresses consumed in earl* &'((. 0P1I7 e<hausted its -eneral use IP). address pool in 0pril &'((.
0lthou-h the current models of address consumption show that the other re-ions will be able to mana-e a)ailable address pools for a few more months/ this prediction does not account for the multinational nature of man* of the lar-est of the ser)ice pro)iders/ and at this sta-e it is not known how much address6consumption pressure will shift outward from 0P1I7 to the other RIRs now that 0P1I79s a)ailable address pool is effecti)el* drained. %o it ma* well be that &'(( will see IP). addresses cease to be -enerall* a)ailable in man* parts of the world/ and b* earl* &'(& there will be no further -enerall* a)ailable IP). addresses in #urope/ 1orth 0merica and 0sia.

12
+hat is the planB
This news of imminent e<haustion of the suppl* of addresses is not a surprise. 0lthou-h the e<act date of predicted address e<haustion has )aried o)er time/ the prospect of address e<haustion was first raised in technical circles in 0u-ust (=='/ and work has been undertaken since that time to understand what mi-ht be possible and how that could be achie)ed.
The (=='s saw an intense burst of en-ineerin- acti)it* that was intended to pro)ide a solution for this forthcomin- address problem. The most si-nificant outcome of this effort was the specification of a successor IP protocol to that of IP)./ called IP Hersion 4 or IPv6.

13
Address Exhaustion: cont nued +h* IP)4 and not IP),B
It would be reasonable to e<pect the successor protocol of IP Hersion . to be called IP Hersion ,/ but as it turned out Hersion , of the Internet Protocol Famil* was alread* taken. In the late (=;'s the Internet Protocol itself was the topic of a considerable le)el of research/ as researchers e<perimented with different forms of network beha)ior. Hersion , of the Internet Protocol was reser)ed for use with an e<perimental IP protocol/ the Internet !trea* Protocol, ,ers on - 2%T6II3/ written up as RF7 ((=' in (=='. +hen it came time to assi-n a protocol number of the 8ne<t -eneration: of IP)./ the ne<t a)ailable )ersion number was 4/ hence IP)4.
The outcome of this process was a relati)el* conser)ati)e chan-e to the IP protocol. The major shift was to enlar-e the address fields from ?& bits to (&; bits in len-th. ther chan-es were made that were thou-ht to be minor impro)ements at the time/ althou-h hindsi-ht has mana-ed to raise some doubts about thatC THE INTERNET PROTOCOL JOURNAL
14
The desi-n intent of IP)4 is a usable lifetime of more than ,' *ears/ as compared with a 8mainstream: deplo*ment lifetime of IP). of (, *ears/ assumin- that *ou are prepared to draw a line at around (==, and claim that at that time the protocol mo)ed from an interestin- academic and research project to a mainstream pillar of the -lobal communications industr*.
That ,' *ears of usable life for IP)4 is admittedl* )er* ambitious/ because it is intended to encompass a -rowth of the ubiAuit* of silicon from the current industr* )olumes of hundreds of millions of new connected de)ices e)er* *ear to a future le)el of acti)it* that ma* encompass in the order of hundreds of billions to possibl* some trillions of new connected de)ices e)er* *ear.
%o the technical plan to address the address6e<haustion problem was to perform an up-rade of the Internet and con)ert the Internet from IP Hersion . to IP Hersion 4.

15
Address Exhaustion: cont nued 1othin- else needs to be chan-ed. This chan-e is not intended to be radical or re)olutionar*. The chan-e from circuit switchin- to packet switchin- was a re)olutionar* chan-e for both the communications industr* itself and for *ou and me as enthusiastic communicators. The chan-e from IP). to IP)4 is intended to be a polar opposite/ and at best it is intended to be a transparent and lar-el* in)isible transition. #6mail will still be e6mail. The web should still look just as it alwa*s did/ and an*thin- that works on IP). is e<pected to work on IP)4. IP)4 is not inherentl* an* faster/ nor an* cheaper/ nor is it e)en all that much better. The major chan-e in IP)4 is that it supports a much lar-er address field. "ow man* addresses are in IP)4B
In theor*/ there are & to the power (&; uniAue addresses in IP)4Ea )er* lar-e number. If each IP)4 address were a sin-le -rain of sand/ the entire IP)4 address space would construct ?'' million planets/ each the siDe of the earthC

16
>ut theor* and practice ali-n onl* in theor*. In practice the IP)4 address plan creates a usable span of addresses that encompasses between & to the power ,' and & to the power 4' de)ices. 0lthou-h this number is nowhere near & to the power (&;/ it is still a ran-e of numbers that are between ( million to ( billion times the siDe of the IP). address space. "ow do we transition to IP)4B
Infortunatel* IP)4 is not 8backward6compatible: with IP).. >ackward compatibilit* would allow for a piecemeal transition/ where IP)4 could be re-arded as a full* functional substitute for IP)./ so that the e<istin- network base would keep usin- IP). fore)er/ while the most recent de)ices would use IP)4 and all de)ices could com6 municate with each other. The lack of such backward compatibilit* implies that this communication is simpl* not possible. IP). and IP)4 are distinct and different communications protocols/ in the same wa* that #n-lish and/ sa*/ 5erman are distinct and different lan-ua-es.
0ttempts ha)e been made to desi-n )arious forms of automated protocol translator units THE INTERNET PROTOCOL JOURNAL
17
Address Exhaustion: cont nued that can take an incomin- IP). packet and emit a correspondin- IP)4 packet in the same manner as a lan-ua-e interpreter. "owe)er/ this approach also has some major limitations/ so it is usable onl* in )er* carefull* constrained conte<ts.
The implication of this lack of backward compatibilit* and inabilit* to perform automated translation within the network is that if we want to preser)e comprehensi)e an*6to6an* connecti)it* durin- the transition/ we ha)e to eAuip each de)ice that is performin- a transition with both protocol stacks/ or/ in effect/ allow the de)ice to become 8bilin-ual/: and conduct a con)ersation in either IP). or IP)4/ as reAuired. This transition has been termed a dual(stac' transition. +hen m* computer supports IP)4/ can I return m* IP). addressB
#ach de)ice needs to maintain its capabilit* to con)erse usin- IP). while there are still other de)ices out there that remain IP).6onl*. %o a de)ice that becomes IP)46capable cannot immediatel* -i)e up its IP). address. It will need to keep this IP). capabilit* and THE INTERNET PROTOCOL JOURNAL
18
operate in dual6stack mode for as lon- as there are other de)ices and ser)ices out there that are reachable onl* usin- IP)..
The implication of this constraint is that we will need to add dualstack de)ices to the Internet and consume both IP). and IP)4 addresses durin- this transition.
%o/ no/ *ou will need to keep *our IP). address for as lon- as there are folk out there with whom *ou want to communicate who ha)e not also mi-rated to be a dual6stack IP).6 and IP)46capable entit*.

19
Address Exhaustion: cont nued +hat needs to be done to transition the network to IP)4B
+hat is encompassed in 8transitionB: $o all Internet !erv ce Prov ders 2I%Ps3 ha)e to decide when and how to repro-ram their s*stems and reconfi-ure their routers/ switches/ and middlewareB +ill the* need to replace all their customers9 modems with ones that support IP)4B +hat is the a-endaB
This le)el of uncertaint* about the transition to IP)4 is e)identl* widespread in toda*9s Internet. !ost of the actors in the Internet are unsure about what needs to be done/ from the lar-est of the ser)ice pro)iders down to indi)idual end users. Yes/ it appears to be a simple matter of repro-rammin- de)ices from bein- just IP).6capable to bein- capable of supportin- both IP). and IP)4/ but it is not Auite so simple. $ual6stack operation is not eas*/ nor will it just happen without an* form of applied impetus. Ima-ine that this transition is from e)er*one on the planet speakin- Jatin to each other to e)er*one speakin- #speranto. If this situation were a simple matter of e)er*one stoppin- usin- one THE INTERNET PROTOCOL JOURNAL
20
lan-ua-e and bein- rebooted to use the other lan-ua-e one b* one/ then ima-ine the pli-ht of the first people to undertake this transitionEfrom bein- connected and beinable to communicate with e)er*one else usin- Jatin/ these first users would find themsel)es speakin- e<clusi)el* #speranto to ... nobod*C The* would in effect ha)e been disconnected from the network.
%o the transition is a little trickier than just turnin- a bi- switch from IP). to IP)4. >ecause this transition is a piecemeal and fra-mentar* one/ each de)ice/ each router/ each firewall/ each load ser)er/ and all those other components of the network ser)ice platform need to be pro-rammed with an additional protocol/ and become/ in effect/ bilin-ual. 0nd in this case there are no ma-ic interpreters that can 8translate: between IP). and IP)4. %o it is onl* when the entire network is bilin-ual in a dual6stack mode that we can turn off IP). and consider the transition to be complete.
For an e<tended period of time the Internet is -oin- to ha)e to operate as two Internets. +e ha)e ne)er tried that t*pe of operation before/ at least not on a -rand scale as this oneK in fact/ it has often been likened to replacin- the jet en-ines of an airplane while the THE INTERNET PROTOCOL JOURNAL
21
Address Exhaustion: cont nued plane is in fli-ht. %omehow we now ha)e to not onl* sustain a -rowth rate of at least some &,' million new connections per *ear/ but at the same time retrofit IP)4 to the e<istin- installed base while continuin- to support IP).. The comple<it* of this operation is si-nificant/ and there is considerable confusion about what to do/ when to do it/ how much it will all cost/ and who will pa*. %o *es/ we are all unsure about what needs to be done. "ow lon- do we e<pect this dual6stack transition to takeB
If onl* we knewC The Internet toda* encompasses some (.L billion users/ and hundreds of millions of de)ices out there are confi-ured to 8talk: onl* IP).. %ome of these de)ices will surel* die in the comin- *ears/ and others ma* be up-raded or repro-rammed/ but others will persist in operation for man* *ears to come while continuin- to speak onl* IP).. #)en lookin- at what is bein- sold toda*/ althou-h man* -eneral6purpose computers 2or at least their operatin- s*stems3 are now confi-ured to operate in dual6 stack mode/ when *ou look at embedded de)ices such as D % tal !ubscr ber . ne 2$%J3 or cable modems/ or firewalls/ or a m*riad of other de)ices that are inte-ral to the operation of toda*9s Internet/ man* of these de)ices are still confi-ured in firmware to operate e<clusi)el* usin- IP)..

22
%ome modelin- of the transition process has projected an ;'6*ear transition process. That projection is headin- into the realms of the absurd/ -i)en that our e<pectations for the operational lifespan of IP)4 ha)e a lower bound of just ,' *ears or so. "owe)er/ -i)en the sheer scope of the con)ersion task and the current le)el of penetration of IP)4 to le)els of between & and , percent of toda*9s Internet/ and -i)en that a deadline of & *ears from now implies a con)ersion rate of in e<cess of ( million de)ices e)er* da* in that &6 *ear span. It seems that an e<pectation that this transition could be substantiall* completed in as little as & *ears also strikes an unrealistic note.
%o a more realistic assumption is that we will probabl* take around , *ears to complete this transition/ and we will need to operate the Internet in dual6stack mode with both IP). and IP)4 across this entire period.
>ut at the current le)el of Internet -rowth/ the IP). address pool cannot sustain a further , *ears of -rowthEat least not with the current amount of unallocated addresses remainin- in the allocation pools. The current address6consumption rate is some &,' million addresses per *ear. The depleted IP). address pool simpl* cannot withstand the THE INTERNET PROTOCOL JOURNAL
23
Address Exhaustion: cont nued pressures of a ,6*ear transition without a radical chan-e to the model of the IP). network. 0nd if we need to rework the model of the IP). network simpl* to sustain a transition to IP)4/ then can9t we simpl* -et -oin- with IP)4 a little more Auickl* insteadB
"owe)er/ 8full* depleted: or e)en 8run out: is perhaps not the most appropriate wa* to describe what will happen to IP). addresses in the comin- months. It is probabl* more accurate to sa* 8unobtainable at the current prices.: +hen the current orderl* process of allocation of IP). addresses comes to an end/ that does not mean that IP). addresses will be completel* unobtainable. In this world man* thin-s that are scarce are still obtainable Efor a price. It is Auite reasonable to anticipate that for as lon- as there is still a demand for IP). addresses there will be some form of 8aftermarket: where addresses are traded for mone*. "owe)er/ as with man* markets/ what is not possible to predict is the price for addresses that will be established b* such a market6based address6tradin- re-ime.
+hat about Maddress sharin-M in IP).B THE INTERNET PROTOCOL JOURNAL

24
+h* do we need IP)4/ -i)en that we could simpl* share addresses in IP).B
Yes/ of course address sharin-F&G is an option/ and we ha)e been doin- it for man* *ears alread* in IP).. >ut is it a )iable substitute for IP)4B
0s part of the en-ineerin- effort to de)elop a successor protocol to IP). in the mid (=='s/ the I#TF published a no)el approach of address shar n%, which we call toda* #et)or' "ddress /ranslat on, or 10T.F?G These da*s almost e)er* $%J modem/ and other forms of customer connection eAuipment/ comes eAuipped with 10T functions. Toda* most Internet %er)ice Pro)iders -i)e their subscribers a sin-le IP). address. 0t home I ha)e a sin-le IP). address/ and *ou probabl* do too. >ut in m* home I ha)e about &' connected de)ices of )arious sorts 2I am countin- TiHo units/ -ame consoles/ tele)isions/ printers/ and such/ because the* are all in essence Internet6connected de)ices/ and I belie)e that m* situation is not unusual3. 0ll these de)ices 8share: the sin-le e<ternal IP connection/ so all of them 8share: this sin-le IP). address. THE INTERNET PROTOCOL JOURNAL
25
Address Exhaustion: cont nued >ut address sharin- has its limitations. +hen a sin-le household shares a sin-le address/ nothin- unusual happens. >ut If I were to tr* to do the same address6sharin- trick of usin- a sin-le IP address to share across/ sa* &/''' customers/ I would cross o)er into a world of pain. !an* applications toda* -ain speed throu-h parallelism/ and the* support parallelism throu-h consumin- port addresses.
#ach IP address can support the parallel operation of 4,/,?, sessions/ usin- a (46bit &ort dent f er as the distin-uishin- identifier. >ut when address sharin- is used/ these ports are shared across the number of de)ices that are all sharin- this common address. +hen &/''' customers are sharin- a sin-le address and each customer has some &' or so de)ices/ then the a)era-e number of port addresses per de)ice is (.,. 7ommon applications that e<ploit parallel operation include such fa)orites as G*a l, Goo%le 0a&s, and /unes. +ith a sufficientl* constrained number of a)ailable ports to use/ these applications would cease to work. Indeed/ man* network applications would fail/ and at a le)el of a sin-le address shared across &/''' households/ I would -uess that up to half of these &/''' customers would not ha)e a workin- Internet at an* sin-le point in time.

26
ur e<perience su--ests that address sharin- works onl* up to a point/ and then it breaks e)er*thin- badl*. +e are alread* address sharin- at the le)el of sharin- a sin-le address per household/ and households are these da*s bu*in- more connected de)ices of )arious sorts/ not fe)er. %o attemptin- to share that sin-le address across more than one household is at best a temporar* solution/ and is not a sustainable option that is an alternati)e to IP)4.
%o we need to transition to IP)4/ and we need to do so within an impossibl* short time.
This discussion all sounds like a terrible problem.

27
Address Exhaustion: cont nued +as this -lobal Me<perimentM with the Internet all one bi- mistakeB
%hould we ha)e looked elsewhere for a networkin- technolo-* back in the (=='sB
The IP address problem isEfor me at an* rateEa fascinatin- one. 0t the time when researchers were workin- on the specifications for the Internet Protocol in the (=L's/ the* decided to use fi<ed6len-th ?&6bit fields of the interface identifier addresses in the protocol. This decision was a radical one at the time. 7ontemporar* network protocols/ such as D$Cnet Phase III, used (46bit address len-ths/ and ;6bit addresses were also )er* common at the time. 0fter all/ computers were so bi- and e<pensi)e/ who could possibl* afford more than &,4 uniAue de)ices in a sin-le networkB #i-ht bits for addresses was surel* enou-hC Isin- ?& bits in the address field was not an eas* decision to make/ because there was constant pressure to reduce the packet headers in order to lea)e more room for the data pa*load/ so to reser)e such a massi)e amount of space in the address fields of the protocol header to allow two ?&6bit address fields was a )er* bold decision. THE INTERNET PROTOCOL JOURNAL
28
"owe)er/ it was a decision that has pro)ed to be )er* robust. T7P/ IP has sustained the Internet from a mere handful of warehouse6siDed computers runnin- at mere kilobits per second to toda*/ where probabl* more than ? billion de)ices connect to the Internet in one wa* or another/ at speeds that ran-e from a few hundred bits per second to a massi)e ('' 5bpsEall talkin- one sin-le protocol that was in)ented more than ?' *ears a-o

29
.IP has demonstrated a scale factor ( billionC In m* mind that achie)ement demonstrates a le)el of en-ineerin- foresi-ht that is trul* phenomenal. %o in some sense the underl*in- obser)ation here is not that IP). is runnin- out of addresses toda*/ but that it has been able to -et to toda* at allC
5i)en that IP). has been able to scale b* a factor of ( billion/ then if we can make IP)4 scale b* a further factor of ( billion from toda* we will ha)e done well. $isclaimer
The )iews e<pressed in this article do not necessaril* represent the )iews or positions of the "s a Pac f c #et)or' Infor*at on Centre 20P1I73.

30
References
F(G
$aniel Narrenber-/ 5erard Ross/ Paul +ilson/ and Jeslie 1obile/ 8$e)elopment of the Re-ional Internet Re-istr* %*stem/: /he Internet Protocol Journal, Holume ./ 1o. ./ $ecember &''(.
F&G
5eoff "uston/ 810TOO: 0ddress %harin- in IP)./: /he Internet Protocol Journal, Holume (?/ 1o. &/ June &'('.

31
F?G
5eoff "uston/ 80natom*: 0 Jook inside 1etwork 0ddress Translators/: /he Internet Protocol Journal, Holume L/ 1o. ?/ %eptember &''..

32
5# FF "I%T 1/ >.%c./ !.%c./ is the 7hief %cientist at 0P1I7/ the Re-ional Internet Re-istr* ser)in- the 0sia Pacific re-ion. "e has been closel* in)ol)ed with the de)elopment of the Internet for man* *ears/ particularl* within 0ustralia/ where he was responsible for the initial build of the Internet within the 0ustralian academic and research sector. "e is author of numerous Internet6 related books/ and was a member of the Internet 0rchitecture >oard from (=== until &'',K he ser)ed on the >oard of Trustees of the Internet %ociet* from (==& until &''(. #6mail:
-ih@apnic.net
n June ;/ &'((/ websites includin- Goo%le, 1aceboo', 2ahoo3, and 4 n% will make their main webpa-es reachable o)er IP)4 for a &.6hour period from '':'' to &?:,= Coord nated 5n versal / *e 2IT73. This acti)it*/ World IPv6 Day, a 8test fli-ht: of IP)4/ is moti)atin- or-aniDations across the Internet industr* to prepare their ser)ices for IP)4/ the ne<t -eneration of the Internet Protocol. Internet %er)ice Pro)iders/ hardware makers/ operation s*stem and application )endors/ and other websites are indeed workin- to make this acti)it* of testin- IP)4 on an Internet scale successful. +orld IP)4 $a* by Ph l +oberts, I!OC
The Internet is a ne)er6endin- e<ercise in collaboration. !akin- a successful transition to IP)4 is one of the major challen-es facinthe Internet toda*. 0lthou-h IP)4 is used e<tensi)el* in man* lar-e networks toda*/ the +orld IP)4 $a* acti)it* is actin- as a focal

33
point to brin- to-ether all parts of the Internet industr* to accelerate deplo*ment of IP)4 in all parts of the Internet.
For some time the deplo*ment of IP)4 has faced a 8chicken6and6 e-- problem.: +ebsite owners ha)e been reluctant to deplo* IP)4 because there were not man* end users to )iew their webpa-es o)er IP)4. 1etwork operators ha)e been hesitant to deplo* IP)4 for man* end users because there were few places for those users to )iew content o)er IP)4. That the most popular websites in the world accordin- to 0le<a rankin-s are deplo*in- IP)4 on their main webpa-es is a clear indication that the Internet industr* is mo)in- be*ond this lon-6standin- impasse. 0lthou-h June ; is a &.6hour test/ it is clear that this is a mo)e toward re-ular operation of IP)4/ and network operators can confidentl* roll out IP)4 to end users knowin- that the Internet industr* is makin- a concerted effort to make IP)4 an operational realit*.
Toda*/ IP)4 connecti)it* concerns pro)ide another disincenti)e for a major website to enable IP)4 for re-ular operation. >adl* con6 fi-ured or poorl* beha)in- implementations ma* pre)ent end users from reachin- a major website that enables IP)4 on its main pa-e.

34
It is currentl* estimated that this problem will affect onl* a minor percenta-e of end usersEat the time of the announcement of +orld IP)4 $a*/ the estimate was that onl* '.', percent of end users would e<perience difficulties.
0lthou-h this percenta-e is small/ it is potentiall* a )er* lar-e number of end users for a website that has )isitors numberin- in the tens of millions 2or more3. It is simpl* impossible from a business point of )iew for a website of this ma-nitude to deplo* IP)4 alone when this man* users could be affected. The users who would not be able to -et to that website will simpl* -o to another website in search of similar ser)ices.

35
"owe)er/ because se)eral such websites ha)e a-reed to do this testin- at the same time/ and for the same duration/ indi)idual end users who e<perience disruption of their connecti)it* b* IP)4 ma* be able to determine that the problem the* are e<periencin- is indeed not a problem with a set of major websites but ma*/ in fact/ be a problem in their own host or network/ and will pro)ide an incenti)e for them to take steps to determine the source of the problem and repair it.
+ebsite owners/ network operators/ and hardware and software )endors are collaboratin- to minimiDe these effects leadin- up to +orld IP)4 $a*. 0ll of these or-aniDations are workin- to pro)ide tools to detect these problems and offer su--ested fi<es in ad)ance of June ;. The test site http://test6ip)4.com/ allows end users toda* to test their connecti)it* and determine whether their connecti)it* to websites will be affected when those websites enable IP)4.

36
%ome websites ha)e alread* performed a similar &.6hour test. Jast *ear/ the 5erman online news site "eise 2http://www.heise.de3 conducted a similar e<periment. The site enabled IP)4 on its main pa-e for &. hours/ turned it off/ e<amined the effects of the e<peri6 ment/ and then permanentl* enabled IP)4 on its main pa-e. Two major websites in 1orwa* did a similar test/ and the* also ha)e enabled IP)4 permanentl*. 0n acti)it* like this for man* websites is clearl* a step toward re-ular and normal IP)4 operations. +ebsite owners will/ of course/ determine when it makes sense for their business to make IP)4 operations a)ailable permanentl*.
%ince the announcement of +orld IP)4 $a*/ man* other websites from around the world ha)e indicated that the* are deplo*inIP)4/ and man* of those ha)e decided to join in the -lobal IP)4 test on June ;. The list of websites includes major websites such as Goo%le, 1aceboo', and 2ahoo3 and )er* small websites with small numbers of )isitors. It is e<citin- that websites from e)er* inhabited continent plan to participate. !ajor websites from the 7Dech Republic/ Portu-al/ >raDil/ and Japan/ for e<ample/ are joinin- this test/ with more websites joinin- e)er* da*.

37
For further information about +orld IP)4 $a*/ please )isit: http://www.isoc.or-/wp/worldip)4da*
There *ou will find details about the websites that will be turninon IP)4 on June ;/ how to join/ and information for networks and indi)iduals/ includin- an F0P.

38
P"IJ R >#RT% joined the Internet %ociet* 2I% 73 in &'';. Prior to that he spent se)eral *ears with !otorola in research and product de)elopment/ all in the area of mobile broadband s*stems. "e has been acti)e in the I#TF for more than a decade. "e can be reached at: roberts@isoc.or-Transition al !*ths by Geoff Huston, "P#IC
I found the session interestin-/ because it e<posed some commonl* held beliefs about the transition to IP)4/ so I will share them here/ and discuss a little about wh* I find them somewhat fanciful. Myth 1: We have many years for this transition.
ast ctober/ I attended the +6seau7 IP $uro&6ens 2RIP#3F(G meetin- in Rome/ andE not une<pectedl* for a -roup that has some interest in IP addressesE the topic of IP). address e<haustion/ and the related topic of the transition of the network to IP)4/ captured a lot of attention throu-hout the meetin-. ne session I found particularl* interestinwas on the transition to IP)4/ where people related their e<periences and perspecti)es on the forthcomin- transition to IP)4.
1o/ I don9t think we doC
The Internet is currentl* -rowin- at a rate that consumes some &'' million IP). addresses e)er* *ear/ or , percent of the entire address IP). pool. This -rowth rate reflects an underl*in- -rowth of ser)ice deplo*ment b* the same order of ma-nitude of some hundreds of millions of new ser)ices acti)ated per *ear. Throu-hout a dual6stack transition/ all e<istin- ser)ices will continue to reAuire IP). addresses/ and all new ser)ices will also reAuire access to IP). addresses. The pool of unallocated addresses was e<hausted in Februar* &'((/ and the +e% onal Internet +e% str es 2RIRs3F&G will e<haust their local pools commencin- earl* &'(( and throu-h &'(&. +hen those pools e<haust/ then all new Internet ser)ices will need access to IP). addresses as part of the IP). part of the dual6stack en)ironment/ but at that point there will be no more freel* a)ailable addresses from the re-istries. %er)ice pro)iders ha)e some local stocks of

39
IP). addresses/ but e)en those stocks will not last for lon-.
0s the network continues to -row/ the pressure to find the eAui)alent of a further &'' million or more IP). addresses each *ear will become acuteE and at some point will be unsustainable. #)en with the widespread use of #et)or' "ddress /ranslators 210Ts3F?G and further incenti)es to reco)er all unused public address space/ the ine<orable pressure of -rowth will cause unsustainable pressures on the suppl* of addresses.

40
It is unlikel* that we can sustain (' more *ears of network -rowth usin- dual stack/ so transition will need to happen faster than that. "ow about , *earsB #)en then/ at the hi-her le)el of -rowth forecasts/ we will still need to flush out the eAui)alent of (., billion IP). addresses from the e<istin- user base to sustain a ,6*ear transition/ and this number seems to be a stretch tar-et. 0 more realistic estimate of transition time/ in terms of accessible IP). addresses from reco)er* operations/ is in the ?6. *ear timeframe/ and no lon-er.%o no/ we do not ha)e man* *ears for this transition. If we are carefulEand a bit luck*Ewe will ha)e about . *ears. Myth 2: It is just a change of a protocol code. Users ill not see any difference in the transition.
If onl* that were trueC
In an open market en)ironment/ scarcit* is in)ariabl* reflected in price. For as lon- as this transition lasts/ this industr* is -oin- to ha)e to eAuip new networks and new ser)ices with IP). addresses/ and the -reater the scarcit* pressure on IP). addresses/ the -reater

41
Transitional Myths: cont nued
the scarcit* price of IP). addresses. %uch a price escalation of an essential -ood is ne)er a desirable outcome/ and althou-h numerous possible measures can be taken to miti-ate the problem/ to some e<tent or other/ the scarcit* pressure and the attendant price escalation su--est a reasonable e<pectation of some le)el of price pressure on IP). addresses.
In addition/ an Internet !erv ce Prov der 2I%P3 ma* not be able to rel* solel* on customer6owned and6operated 10Ts to locall* mask out some of the incremental costs of IP). address scarcit*. It is likel*E and increasin-l* so the lon-er the transition takesEthat the I%P will also ha)e to operate 10Ts. The attendant capital and operational costs of such additional network functions will ultimatel* be borne b* the ser)ice pro)ider9s customer base durin- the transition.
>ut it is not just price that is affected b* this transitionEnetwork performance ma* also be affected. Toda* a connection across the Internet is t*picall* made b* usin- the Do*a n #a*e !yste* 2$1%3 to translate a name to an eAui)alent IP address/ and then

42
launchin- a connection6establishment packet 2or the entire Auer* in the case of the Iser Data%ra* Protocol FI$PG3 to the address in Auestion. >ut such an operation assumes a uniform sin-le protocol. In a transition world *ou can no lon-er simpl* assume that e)er*thin- is contactable with a sin-le protocol/ and it is necessar* to e<tend the $1% Auer* to two Aueries/ one for IP). and one for IP)4. The client then needs to select which protocol to use if the $1% returns addresses in both protocols. Then there is the trick* problem of failo)er. If the initial packet fails to elicit a response within some parameter of retries and timeouts/ then the client will attempt to connect usin- the other protocol with the same set of retries and timeouts. In a dual6stack transitional world/ not onl* does failure take more time to reco-niDe/ but e)en partial failure ma* take time. %o users ma* see some chan-es in the Internet. The* ma* be e<posed to hi-her prices that reflect the hi-her costs of operatinthe ser)ice/ and the* ma* see some instances where the network simpl* starts to appear 8slu--ish: in response.Myth !: "#$ upon "#$ upon "#$ ill or%.
!a*be. >ut ma*be not all the time/ and ma*be not in wa*s that match what happens toda*.

43
The Internet has been operatin- for more than a decade now with a )er* pre)alent model of a sin-le le)el of address translation in the path. 0pplication desi-ners now assume its e<istence/ and also make some other rather critical assumptions/ notabl* that the 10T is close to the client in a client6ser)er world/ and that there is a sin-le 10T in the path/ and that its particular form of address translation beha)ior can be determined with numerous probe tests. There is e)en a client6to610T protocol to assist certain applications to communicate port6bindin- preferences to the local 10T. In a multile)el 10T world/ such assumptions do not directl* translate/ but it is not necessaril* the case that the application is aware of the added 10Ts in the end6to6end path.
"owe)er/ it is not just the added comple<it* of the multipart 10T that presents challen-es to applications. The 10T la*erin- is intended to create an en)ironment where a sin-le IP address is d*namicall* shared across multiple clients/ rather than beinassi-ned to a sin-le client at a time. 0pplications that use parallelism e<tensi)el* b* undertakin- concurrent sessions reAuire access to a lar-e pool of a)ailable port addresses. !odern web browsers are a classic e<ample of this form of beha)ior. The multiple 10T model effecti)el* shares a sin-le address across multiple clients b* usin- the port address/ effecti)el* placin- the pool of port addresses under contention. The hi-her the densit* of port contention/ the -reater the risk that this multiple la*erin- of 10Ts will ha)e a )isible effect on the operation of the application.

44
There is also a considerable in)estment in the area of lo--in- and accountabilit*/ where indi)idual users of the network are recorded in the )arious lo- functions throu-h their public6side address. %harin- these public addresses across multiple clients at the same timeEas is the intended outcome of a multila*er 10T en)ironmentEimplies that the lo- function is now forced to record operations at the le)el of port usa-e and indi)idual transactions. 1ot onl* does this realit* ha)e implications in terms of the load and )olume of lo--ed information/ there is also a tan-ible increase in the le)el of potential back tracin- of indi)idual users9 online acti)ities if full port usa-e lo--in- were to be instituted/ with the attendant concerns that this back tracin- represents an inappropriate balance between accountabilit* and traceabilit* and personal pri)ac*. It is also unclear whether there will be opportunit* to ha)e an* public debate on such a topic/ -i)en that the pressure to deplo* multile)el 10T is alread* )isible. Myth &: 'hanging the 'ustomer (remises )*uipment +'(), is easy.
1o/ not necessaril*.

45
I think we ha)e all seen man* transition plans/ includinmultile)el Hersion . 10Ts/ 10Ts that perform protocol translation between IP). and IP)4/ 10Ts plus tunnelin-/ as in Dual(!tac' . te, the I,I 4 (d rect on 0a&& n% Gate)ay, 6to8, 6+D, and /eredo, to call up but a few of the )arious transitional technolo-ies that ha)e been proposed in recent times. 2%ee the article 8Transitionin- Protocols: startin- on pa-e &&.3
0ll approaches to dual6stack transition necessaril* make chan-es to some part of the network fabric/ whether it is chan-es to the end s*stems to include an IP)4 protocol stack in addition to an IP). stack/ or the addition of more 10Ts/ or -atewa*s into the network infrastructure. f course/ within a particular transitional model there is a selecti)e choice as to what elements of the infrastructure are susceptible to chan-e and what elements are resistant to chan-e. %ome models of transition/ such as 4R$ and $ual6%tack Jite/ assume that chan-in- the 7P# is eas* and strai-htforward/ or at least that such a broad set of up-rades to customer eAuipment is lo-isticall* and economicall* feasible. 4R$ contains an implicit assumption that the network operator has no economic moti)ation to alter the network elements/ and wishes to retain a sin-le protocol infrastructure that uses IP)..

46
+here the 7P# is owned/ operated/ and remotel* maintained b* the ser)ice pro)ider/ up-radin- the ima-e on the 7P# mi-ht pres6 ent fewer obstacles than up-radin- other elements of the network infrastructure/ such as broadband remote6access ser)ers that oper6 ate in a sin-le protocol mode/ but sweepin- -eneraliDations in this industr* are unreliable. %er)ice pro)iders tend to operate customiDed cost models/ and appear to be operatin- with specialiDed mi<es of )endor eAuipment and operational support s*stems. For this reason operators tend to ha)e differinperspecti)es on what component of their network is more malleable/ and correspondin-l* ha)e differinperspecti)es on which particular transition technolo-* suits their particular en)ironment.
This industr* is )olume6based/ where an underl*in- homo-eneit* of the deplo*ed technolo-*Eand economies of scale and precision of processEare critical components of reliable and cost6efficient rollouts. It is somewhat une<pected to see this transition e<pose a relati)e hi-h de-ree of customiDation and di)ersit* in network ser)ice en)ironments. Myth -: My I.( has enough I(v& addresses to last for years/ so it does not have a pro0lem.

47
+ell/ not necessaril*.
The assumption behind this statement is that e)er*one else is also able to persist with IP)./ and e)er*one *ou wish to reach/ and e)er* ser)ice point *ou wish to access/ will maintain some form of connecti)it* in IP). indefinitel*.
>ut this assumption is not necessaril* )alid. 0t the point in time when a si-nificant number of clients or ser)ices cannot be adeAuatel* supported on IP)./ then irrespecti)e of how man* IP). addresses I%Ps ha)e/ the* will need to pro)ide their clients with IP)4 in order to reach these IP)46onl* ser)ices n a network/ the actions of others directl* affect *our own local actions. %o if *ou belie)e that *ou need do nothin-/ and *ou can use an IP). ser)ice for *ears into the future/ then this position will be inadeAuate at the point in time when a si-nificant number of others encounter critical le)els of scarcit* such that the* are incapable of sustaininthe IP). side of a dualstack deplo*ment/ and are forced to deplo* an IP)46onl* ser)ice. The -reater the le)el of address hoardin-/ the -reater the le)el of pressure to deplo* IP)46onl* ser)ices on the

48
part of those ser)ice pro)iders who are badl* placed in terms of access to IP). addresses. Myth 1: We ill al ays have to run I(v& protocols.
Probabl* not.
r at least not in terms and )olumes that are si-nificant to the industr* o)er the forthcomin- decades. Protocols do die. $#7net and !yste*s #et)or' "rch tecture 2%103 no lon-er e<ist as widel* deplo*ed networkin- protocols. In particular/ networkin- in the public space is all about an*6to6an* connecti)it*/ and to support this connecti)it* we need a common protocol foundation. In terms of the d*namics of transition/ this situation is more about tippin- points of the mass of the market than it is about sustained coe<istence of di)erse protocols. +hen a new technolo-*Eor in this case/ protocolEachie)es a critical le)el of adoption/ the momentum switches from resistin- the chan-e to embracin- it.

49
The aftermath of such transitions does not lea)e a le-ac* of endur6 in- demand for the superseded technolo-*. 0s difficult as it is to foresee toda*/ when the industr* acknowled-es that the new tech6 nolo-* achie)es this critical mass of adoption/ the d*namics of the networkin- effect propels the industr* into a tippin- point where the remainder of the transition is likel* to be both ine)itable and comprehensi)e. The likel* outcome of this situation is that there is no residual si-nificant le)el of demand for IP).. Myth 2: $here is a technology that ill translate 0et een I(v& to I(v1.
Yes/ but...
%uch a technolo-* effecti)el* maps between IP). and IP)4 addresses. ne approach/ the I,I 4 (d rect on 0a&& n% Gate)ay, pro)ides a (:( mappin- b* embeddin- fields of one address in the other. 0nother approach/ ori-inall* termed #et)or' "ddress /ranslator ( Protocol /ranslator 210T6 PT3/ uses a mappin- table in a fashion similar to a con)entional

50
10T unit. The common constraint here is that if there are no IP). addresses/ then such a bidirectional mappin- cannot be sustained in each approach. Iltimatel*/ if e)er* packet that tra)erses the public Internet reAuires public address )alues in the source and destination fields/ and the I%P must pro)ide a protocol brid-e between IP). and IP)4/ then public IP). addresses are reAuired.
>ut it is not just the reAuirement for continued access to addresses that is the critical concern here. 0 readin- of RF7 .=44F.G/ 8Reasons to !o)e the 1etwork 0ddress Translator 6 Protocol Translator 210T6PT3 to "istoric %tatus: should curb an* untoward enthusiasm that this approach is capable of sustainin- the entire load of this dual6stack transition without an* further implications or problems. Myth 3: We do not necessarily have to transition to I(v1. $here are su0stitutes.
1othin- is )isible from hereC

51
If we want to continue to operate a network at the price/ perfor6 mance/ and functional fle<ibilit* that is offered b* packet6switched networks/ then the search for alternati)es to IP)4 is necessaril* constrained to a set of technolo-ies that offer approaches that are Eat a suitabl* abstract le)elEisomorphic to IP. >ut -oin- from abstract obser)ations to a specific protocol desi-n is ne)er a fast or eas* process/ and the lessons from the -enesis of both IP). and IP)4 point to a period of man* *ears of desi-n and pro-ressi)e refinement to de)elop a )iable approach. In our current conte<t an* such redesi-n is not a )iable alternati)e to IP)4/ -i)en the timeframe of IP). address e<haustion. It is unlikel* that such an effort would elicit a substitute to IP)4/ and it is more likel* that such an effort ma* lead toward an ine)itable successor to IP)4/ if we dare to contemplate networkin- technolo-ies further into the future.
ther approaches e<ist/ based on application6le)el -atewa*s and similar forms of mappin- of ser)ices from one network domain. +e ha)e been there before in the chaotic jumble of networks and ser)ices that defined much of the (=;'s/ and it is a past that I for one find easier to for-etC %uch an outcome is of considerabl* hi-her comple<it*/ considerabl* less secure/ harder to use/ more e<pensi)e to operate/ and more resistant to scalin-.

52
Jike it or not/ the pra-matic obser)ation of toda*9s situation is that we do not ha)e a )iable choice here. 1o )iable substitutes e<ist. Myth 4: We %no hat is happening.
I am not sure that is uni)ersall* trueC The comments I ha)e heard about the current situation lead me to the obser)ation that there are man* different perspecti)es on the situation. Indi)iduals percei)e the transition in terms that relate to their own circumstances and their own limitations/ and a more encompassin- perspecti)e of the entire Internet and this transition is harder to assemble. %o/ from the perspecti)e of the Internet as a whole/ no/ we are not reall* aware of what is happenin-. Myth 15: We %no hat e are doing.
Indi)iduall* this statement is/ hopefull*/ true. >ut at the le)el of the entiret* of the Internet/ no/ we do not reall* ha)e a clear perspecti)e of this transition.

53
Myth 11: We have a plan6
%ee the comment for m*th ('. Myth 12: $he Internet ill 0e fine6
I am unsure about this one.

54
The worr*in- obser)ation is that the Internet has so far thri)ed on di)ersit* and competition. +e ha)e seen constant inno)ation and e)olution on the Internet/ and the entrance of new ser)ices and new ser)ice pro)iders.
>ut if we rel* solel* on IP). for the future Internet/ then this le)el of competition and di)ersit* will be e<tremel* challen-in- to sustain. If we lose that impetus of competiti)e pressure from inno)ation and creati)it*/ then the Internet will likel* sta-nate under the oppression of brutal )olume economics. The risks of monopol* formation under such conditions are relati)el* hi-h.
I hope one obser)ation I heard at the RIP# session will be a m*th as this transition -ets underwa*: $he incum0ents ill have all the I(v& space. $han%s for playing6

55
If that is not a m*th/ then we are -oin- to be in serious troubleC $isclaimer
The )iews e<pressed in this article do not necessaril* represent the )iews or positions of the "s a Pac f c #et)or' Infor*at on Centre 20P1I73.
References

56
F(G
http://www.ripe.net/ripe/meetin-s/ripe64(/
F&G
F?G

57
F.G
7edric 0oun and #lw*n $a)ies/ 8Reasons to !o)e the 1etwork 0ddress Translator 6 Protocol Translator 210T6PT3 to "istoric %tatus/: RF7 .=44/ Jul* &''L.
Pool of Inallocated IP). 0ddresses 1ow 7ompletel* #mptied
n Februar* ?/ &'(( a critical point in the histor* of the Internet was reached with the allocation of the last remainin- IP). Internet addresses from a central pool. It means the future e<pansion of the Internet is now dependant on the successful -lobal deplo*ment of the ne<t -eneration of Internet protocol/ called IP)4.

58
The announcement was made b* four international non6profit -roups/ which work collaborati)el* to coordinate the world9s Internet addressin- s*stem and its technical standards. 0t a news conference in !iami/ Florida/ the Internet Cor&orat on for "ss %ned #a*es and #u*bers 2I70113 joined the #u*ber +esources Or%an 9at on 21R 3/ the Internet "rch tecture 4oard 2I0>3 and the Internet !oc ety 2I% 73 in announcin- that the pool of first -eneration Internet addresses has now been completel* emptied. The final allocation of Internet addresses was administered b* the Internet "ss %ned #u*bers "uthor ty 2I0103/ which is a function of I7011.
8This is a major turnin- point in the on6-oin- de)elopment of the Internet/: said Rod >eckstrom/ I70119s President and 7hief #<ecuti)e fficer. 81o one was cau-ht off -uard b* this. The Internet technical communit* has been plannin- for IP). depletion for some time. >ut it means the adoption of IP)4 is now of paramount importance/ since it will allow the Internet to continue its amaDin- -rowth and foster the -lobal inno)ation we9)e all come to e<pect.:

59
Two 8blocks: of the dwindlin- number of IP). addressesEabout ?? million of themEwere allocated in late Januar* to 0P1I7/ the +e% onal Internet +e% stry 2RIR3 for the 0sia Pacific re-ion. +hen that happened/ it meant the pool of IP). addresses had been depleted to a point where a -lobal polic* was tri--ered to immediatel* allocate the remainin- small pool of addresses e:ually amon- the fi)e -lobal RIRs.
8It9s onl* a matter of time before the RIRs and Internet !erv ce Prov ders 2I%Ps3 must start den*in- reAuests for IP). address space/: said Raul #cheberria/ 7hairman of the 1R / the umbrella or-aniDation of the fi)e RIRs. 8$eplo*in- IP)4 is now a reAuirement/ not an option.

60
:Transitionin- Protocols by Geoff Huston, "P#IC
n the pre)ious article/ I looked at some common m*ths associated with the transition to IP)4. In this article I would like to look behind the )arious opinions and perspecti)es about this transition/ and e<amine in a little more detail the nature of the technolo-ies bein- proposed to support the transition to IP)4.
0fter some time of hearin- dire warnin-s about the imminent e<haustion of the stocks of a)ailable IP). address space/ we ha)e now achie)ed the first milestone of address e<haustion/ the depletion of the central pool of Internet "ss %ned #u*bers "uthor ty 2I01036 mana-ed address space. The last fi)e /;s were handed out from I010 to the +e% onal Internet +e% str es 2RIRs3 on Februar* ?/ &'((. 0fter some *ears of industr*wide -eneral inattention and inaction with IP)4/ perhaps it is not une<pected to now see a panicked response alon- the lines of 8!a*be we should do somethin- nowC:
>ut what e<actl* should be doneB It is one thin- to decide to 8support: IP)4 in a network/ but Auite another to de)elop a specific plan/ complete with specific technolo-ies/ timelines/ costs/ )endors/ and a realistic assessment of the incremental risks and opportunities. 0lthou-h workin- throu-h some of THE INTERNET PROTOCOL JOURNAL
61
this detail has the normal le)els of uncertaint* that *ou would e<pect to see in an* en)ironment that is under-oin- constant chan-e and e)olution/ an additional le)el of uncertaint* here is a b*6product of the technolo-* itself.
There is not just one approach to addin- support for IP)4 in *our network/ but *any. 0nd it is not just one major objecti)e *ou need to addressEincremental deplo*ment of IP)4 as a second protocol into *our operational network without causin- undue disruption to e<istin- ser)icesEbut two/ because the second challen-in- objecti)e is how to fuel continued -rowth in *our network ser)ice platform when the current suppl* lines of readil* a)ailable IP). addresses are effecti)el* e<hausted. +henB
The most common Auestion I ha)e heard recentl* is: 8"ow lon- do we ha)eB:

62
The remainin- pools of IP). address space continue to be drawn down. 0t the start of Februar* &'((/ the I010 pool was full* depleted/ with the final allocation to the RIRsF(G of IP). addresses.

63
Isin- a model based on monthl* address demands now predicts that the ne<t (; months or so will see the first three RIRs depleted of IP). addresses.The "s a Pac f c #et)or' Infor*at on Centre 20P1I73 was the first RIR to e<haust its a)ailable pool of IP). addresses in 0pril &'((/ with the +IP$ #et)or' Coord nat on Centre 2RIP# 1773 predicted to follow in late &'(( and the "*er can +e% stry for Internet #u*bers 20RI13 in earl* &'(&. The .at n "*er can and Car bbean Internet "ddresses +e% stry 2J071I73 is predicted to follow in &'(./ and the "fr can #et)or' Infor*at on Centre 20FRI1I73 in &'(4.
The -ood news is that man* people ha)e been bus* thinkin- about these intertwined objecti)es of e<tendin- the useful lifetime of IP). in the Internet and simultaneousl* undertakin- the IP)4 transition/ and there is a wealth of possible measures *ou can take/ and a broad collection of technolo-ies *ou can use. Fortunatel*/ we are indeed spoiled with choices hereC
The not6so6-ood news is that there is no simple sin-le path to

64
follow. #ach indi)idual network needs to carefull* consider the transition and select an approach that matches their particular circumstances. For an industr* used to pla*in- 8follow the leader: for man* *ears/ a )ariet* of choice is not alwa*s appreciated. 0nd/ unfortunatel*/ we are spoiled for choices here.
Jet9s look at each of the major transitional technolo-ies that are currentl* in )o-ue/ and e<amine their respecti)e stren-ths and weaknesses and their intended area of applicabilit*. +e will look at these technolo-ies first from the perspecti)e of the end user and then from the other side/ e<aminin- options for Internet !erv ce Prov ders 2I%Ps3. The $ual6%tack I%P 7lient
If *our ser)ice pro)ider pro)ides a dual6stack ser)ice with both IP)4 and IP)./ then *our task should be relati)el* strai-htforward. If *ou confi-ure *our modem or router with IP)4 in addition to IP)./ *ou are finished/ assumin- of course that *our local modem or router unit actuall* supports IP)4Ean assumption that ma* not be )alid in man* of the older and/ unfortunatel*/ man* of the currentl* a)ailable de)ices.

65
The con)entional approach in this form of en)ironment is to use IPv6 Pref 7 Dele%at on, where the I%P pro)ides the client with an IP)4 prefi</ usuall* a /.; or a /,4 IP)4 address prefi</ which is then passed into the client network throu-h an IPv6 +outer "dvert se*ent. Jocal hosts should be constructed to confi-ure their IP)4 stack automaticall*/ and *our s*stem should be connected as a dualprotocol s*stem. You probabl* do/ howe)er/ need to be aware of some ca)eats/ of which the most important is likel* to relate to the probable absence of a #et)or' "ddress /ranslat on 210T3F&G function in IP)4. 7urrentl* most commercial IP). Internet ser)ices assi-n a sin-le IP address to each client.To allow this address to be shared within the client9s network/ most IP). 8ed-e: de)ices autoconfi-ure themsel)es as 10T de)ices/ permittin- out-oin- connections usinthe /rans* ss on Control Protocol 2T7P3 or 5ser Data%ra* Protocol 2I$P3/ and allowin- some Internet Control 0essa%e Protocol 2I7!P3 messa-e t*pes to tra)erse the 10T/ but not much else. For man* clients this 10T confi-uration becomes the default local securit* framework/ because it permits outbound connections throu-h T7P and I$P to be made/ but not much else/ and permits initiation of no sessions as incomin- sessions. +ith IP)4 the local network is -enerall* confi-ured with an entire subnet/ and instead of a 10T/ this subnet is directl* connected to the Internet.
The local network is then in a mi<ed situation of bein- behind a 10T in IP)./ but directl* connected to the Internet usin- IP)4. This as*mmetric confi-uration with respect to IP). and IP)4 raises some Auestions about the effect on the securit* of *our local network. You need to think about addin- appropriate filter rules to the -atewa* IP)4 confi-uration that performs the same le)el of access control to *our local site that *ou ha)e alread* set up with IP). and the 10T. The best ad)ice here is to confi-ure some filter rules for IP)4 that limit the e<tent of e<posure of *our internal network to the broader Internet to be directl* comparable to the

66
confi-uration *ou are usin- with IP).. The IP).6 nl* I%P 7lient
#)en toda*/ when the IP). pools are rapidl* depletin-/ it is reall* not )er* common to ha)e an I%P offerin- dual6stack IP). and IP)4 ser)ices. Jet9s look at the more common situation/ when *our I%P is still offerin- onl* IP).. 0s an end user/ can *ou still set up some form of IP)4 accessB
The answer is 8Yes/: but *ou must use tunnels/ and the stor* can -et somewhat u-l*.

67
4to. Tunnels
If *ou ha)e public IP). addresses on *our local network/ *ou ma* elect to confi-ure *our local s*stem to use the 6to8 /unnel n% Protocol.
4to. is an autotunnelin- protocol coupled with an addressinstructure. The IP)4 address of a 4to.6reachable host be-ins with the IP)4 prefi< &''&::/(4. The address architecture embeds a ?&6 bit IP). address of the end host into the ne<t ?& bits. That wa* the IP)4 address carries the 8eAui)alent: IP). address within the IP)4 address.
To send an IP)4 packet/ the local host must first tunnel throu-h the local IP). network. To perform this tunnelin-/ the local host encapsulates the IP)4 packet in an outer IP). packet header. The IP protocol used is neither T7P nor I$P/ but protocol .(/ an IP protocol number reser)ed for tunnelin- IP)4 packets 2RF7 &.L?3 F?G

68
.The IP). packet is addressed to an IP).6to6IP)4 rela*. To a)oid manual confi-uration of each client/ all these rela*s share the same anycast address/ (=&.;;.==.(. These rela*s strip the outer IP). packet header off the packet and forward the IP)4 packet into the IP)4 network. The IP)4 destination treats the packet normall*/ and -enerates a packet in response without an* special processin-.
The re)erse path to a 4to. host uses an IP)46to6IP). rela*. The IP)4 address of the 4to. local host started with the IP)4 address prefi< &''&::/(4/ so the IP)4 packet that is bein- sent back to this host has a destination address that uses the &''&::/(4 4to. prefi<. This prefi< is interpreted as an an*cast rela* address. 0 route to the IP)4 &''&::/(4 prefi< is ad)ertised b* IP)46to6IP). rela*s. +hen a rela* recei)es a packet destined to a &''&::/(4 address/ it lifts the IP). address from inside the IP)4 address. It then wraps the IP)4 packet in an IP). packet header/ usin- as a destination address this e<tracted IP). address/ and usin- protocol .( as the IP protocol. The resultant IP). packet is then passed to the 4to. host in the IP). network 2Fi-ure (3.

69
If the local network has public IP). addresses on the local network/ then indi)idual hosts on the local network ma* use 4to. directl*. f course then the local -atewa* needs to be confi-ured to accept incomin- IP packets that use protocol .(.
0n alternati)e is to confi-ure the -atewa* de)ice of the local network as a 4to. -atewa*/ and use the IP). address on the I%P side of the -atewa* as a common 4to. address for the local network. The -atewa* then ad)ertises this s*nthetic .;6bit IP)4 prefi< to the interior network with a con)entional IP)4 Router 0d)ertisement. The -ate6 wa* can couple this ad)ertisement with a 10T function and pro)ide nati)e IP)4 to interior hosts that are confi-ured on RF7 (=(;F.G local IP). addresses.
In -eneral/ 4to. is a relati)el* poor approach to pro)isionin- IP)4/ and *ou reall* should a)oid it if at all possible. Indeed/ *our e<perience will probabl* be better o)erall if *ou continue runninIP). and a)oid accessin- IP)4 with 4to. CThe major concern here is that a successful connection relies on the assistance of both an outbound and an inbound 4to. third6part* rela*. n the IP). side a 4to. connection relies on the presence of a usable route to a IP).6to6IP)4 rela*/ and preferabl* one that is as close as possible to the IP). endpoint. n the IP)4 side a 4to. connection relies on a usable rela* ad)ertisin- a route to &''&::/(4.

70
0-ain/ to a)oid e<tended path o)erheads/ this rela* should be as close as possible to the IP)4 endpoint. This path as*mmetr* can cause connection 8black holes/: where one part* can deli)er packets to the other but not the re)erse.
0lso/ such confi-urations ha)e problems if the IP). host is confi-6 ured with stateful filters that insist that the IP). source address in incomin- packets match the destination address of out-oinpackets/ not necessaril* true in a 4to. connection.
Finall*/ it seems that man* sites operate with firewall filters that disallow incomin- packets other than T7P and I$P 2and possibl* some forms of I7!P3. The 4to. packets use protocol .(/ and there appears to be widespread use of filter rules that block such packets.

71
Tunnelin- also adds an additional packet header to a packet/ inflat6 in- the siDe of the packet. %uch an e<pansion of the packet on certain path elements of the network ma* cause path packet siDe problems/ increasin- the risk of encounterin- Path 0a7 *u* /rans* ss on 5n t 2!TI3 8black holes: due to the increase of the packet siDe b* &' b*tes when the IP). packet header is attached to the packet.
Teredo Tunnels
If the local network is behind an IP). 10T and the 10T -atewa* does not support 4to./ then all is not lost/ because another form of tunnelin- could possibl* be an answer. /eredo is described in RF7 .?;'F,G.

72
Teredo/ like 4to./ is an autotunnelin- protocol coupled with an addressinstructure. Jike 4to./ Teredo uses its own address prefi</ and all Teredo addresses share a common IP)4 /?& address prefi</ namel* &''(:''''::/?&. The ne<t ?& bits are the IP). address of the Teredo ser)er. The IP)4 interface identifier field is used to support 10T tra)ersal/ and it is encoded with the triplet of a field describin- the 10T t*pe/ the )iew of the rela* of the I$P port number used to reach the client 2the e<ternal I$P port number used b* the 10T bindin- for the client3/ and the )iew of the rela* of the IP). address used to reach the client 2the e<ternal IP). address used b* the 10T bindin- for the client3.
Teredo uses what has become a relati)el* con)entional approach to 10T tra)ersal/ usin- a simplified )ersion of the !ess on /raversal 5t l t es for #"/ 2%TI13F4G acti)e probinapproach to determine the t*pe of 10TK it uses concepts of 8clients/: 8ser)ers/: and 8rela*s. :0 Teredo cl ent is a dual6stack host that is located in the IP). world/ assumed to be located behind a 10T. 0 Teredo server is an address and reachabilit* broker that is located in the public IP). Internet/ and a Teredo relay is a Teredo tunnel endpoint that connects Teredo clients to the IP)4 network. The tunnelinprotocol used b* Teredo is not the simple IP)46in6IP). protocol .( used b* 4to.. 10T de)ices are sensiti)e to the transport protocol and -enerall* pass onl* T7P and I$P transport protocols. In the Teredo case the tunnelin- is I$P/ so all IP)4 Teredo packets are composed of an IP). packet header and a I$P transport header/ followed b* the IP)4 packet as the I$P pa*load. Teredo uses a combination of I7!P)4FLG messa-e e<chan-es to set up a connection and tunneled packets encapsulated usin- an outer IP). header and a I$P header/ and it contains the IP)4 packet as a I$P pa*load.

73
It should be noted that this reliance on I7!P)4 to complete an initial protocol e<chan-e and confirm that the appropriate 10T bindin-s ha)e been set up is not a con)entional feature of IP). or e)en IP)4/ and IP)4 firewalls that routinel* discard I7!P messa-es will disrupt communications with Teredo clients. 1 %ure -; /eredo /unnel n% I !" #ost
Ter edo $lie nt
Teredo ICMPv6 Echo Request from Teredo Client to Server 2. Forw rded IMCPv6 Echo Request from Server to !ost ". IMCPv6 Echo Re#l$ from !ost to Rel $ %. Teredo &u&&le from Rel $ to Server '. Teredo &u&&le from Server to Client 6. Teredo &u&&le from Client to Rel $ (. Forw rded Teredo ICMPv6 Echo Re#l$ from Rel $ to Client ). Initi l # c*et Teredo-tunnelled from Client to Rel $ +. Forw rded initi l # c*et from Rel $ to !ost

74
The e<act nature of the packet e<chan-e in settin- up a Teredo connection depends on the nature of the 10T de)ice that sits in front of the Teredo client. Fi-ure & shows an e<ample packet e<chan-e that Teredo uses when the client is behind a Restricted 10T.
Teredo represents a different set of desi-n trade6offs as compared to 4to.. In its desire to be useful in an en)ironment that includes 10T functions in the IP). path/ Teredo is a per6host connecti)it* approach/ as compared to the 4to. approach/ which can support both indi)idual hosts and entire end sites within the same technolo-*. 0lso/ Teredo is a host6centric multipart* rendeD)ous application/ and Teredo clients reAuire the e<istence of dual6stack Teredo ser)ers and rela*s that e<ist in both the public IP). and IP)4 networks. Teredo is more of a connecti)it* tool than a ser)ice solution/ and one that is prone to man* forms of operational failure.
n the other hand/ if *ou are an isolated IP)4 host behind an IP). 10T and *ou want to access the IP)4 network/ then 4to. is not an option/ and *ou either ha)e to set up static tunnels across the 10T to make it all work or turn on Teredo in *our dual6stack hostK if e)er*thin- -oes accordin- to theor*/ *ou should be able to estab6

75
lish IP)4 connecti)it*. It is hi-hl* likel* that the IP)4 Teredo con6 nection will fail in stran-e wa*s/ and/ like 4to./ this is a technolo-* best a)oidedC Tunnel >rokers
In contrast to these autotunnel approaches/ the simplest form of tunnelin- IP)4 packets o)er an IP). network is the manuall* confi-ured IP)46in6IP). tunnel.
"ere an IP)4 packet is simpl* prefi<ed b* a &'6octet IP). packet header. In the outer IP). packet header/ the source address is the IP). address of the tunnel in-ress/ the destination address is the IP). address of the tunnel e-ress/ and the IP protocol field uses )alue .(/ indicatin- that the pa*load is an IP)4 packet. The packet is passed across the IP). network from tunnel in-ress to e-ress usin- con)entional IP). packet forwardin-/ and at the e-ress point the IP). IP packet header is remo)ed and the inner IP)4 packet is routed in an IP)4 network as before. From the IP)4 perspecti)e the transit across the IP). network is a sin-le lo-ical hop.

76
0lternati)el*/ like , rtual Pr vate #et)or' 2HP13 tunnels/ the tunnel can be confi-ured usin- I$P or T7P/ and with some care/ the tunnel can be confi-ured throu-h 10T functions in the same wa* as HP1 tunnels can be confi-ured throu-h 10T functions.
The ad)anta-e of this approach is that the need to manuall* confi-ure the tunnel endpoints ensures that the tunnel rela* function is not pro)ided/ intentionall* or unintentionall*/ b* third parties throu-h some well6intentioned/ but ultimatel* random/ act of -oodwill. The need to perform a manual confi-uration also reduces the chances that the tunnel will be broken throu-h local firewall filters.
f course the need to perform a manual confi-uration does not lend itself to a 8plu-6and6pla*: en)ironment/ nor is this approach a )iable one for a lar-er mass market of consumer de)ices and ser)ices.

77
7lient 7onclusions
1one of these approaches to offer IP)4 connecti)it* to end hosts behind an IP).6onl* ser)ice pro)ider offers the same le)el of robustness and performance as nati)e IP). ser)ices. 0ll of these approaches reAuire a si-nificant de-ree of local e<pertise to set up and maintain/ and the* often reAuire a solid understandin- of other aspects of the local en)ironment/ such as firewall and filter conditions and Path !TI beha)ior to maintain. +ith the e<ception of the tunnel broker approach/ the* also reAuire third6 part* assistance to support the connection/ further addin- to the set of potential performance and reliabilit* concerns.
It appears that the most robust and reliable wa* to pro)ision IP)4 to end hosts is for the ser)ice pro)ider to pro)ision IP)4 as an inte-ral part of its ser)ice offerin-/ and offer clients a dual6stack ser)ice in both IP). and IP)4.

78
IP)4 for Internet %er)ice Pro)iders
0lthou-h the 8self6help: autotunnelin- approaches for clients out6 lined earlier in this article are a possible answer/ their utilit* is appropriatel* restricted to a )er* small number of end clients who ha)e the necessar* technical e<pertise and who are willin- to debu- some rather stran-e resultant potential problems relatin- to as*mmetric paths/ third6part* rela*s/ potential !TI mismatches/ and interactions with filters. This approach is not a reasonable one for the lar-er Internet.
From the perspecti)e of the mass market for Internet %er)ices/ we cannot assume that clients ha)e the moti)ation/ e<pertise/ and means to b*pass their I%P and set up IP)4 access on their own/ either throu-h autotunnelin- or manuall* confi-ured tunnels. The inference from this obser)ation is that for as lon- as the mass6 market I%Ps do not commit to IP)4 ser)ices/ and for as lon- as the* continue to stall in deplo*in- ser)ices supportin- dual access for their clients/ the entire IP)4 transition stor* remains effecti)el* stalled.

79
"ow can I%Ps support IP)4 access for their clientsB
The $ual6%tack %er)ice 1etwork
Perhaps it is ob)ious/ but the most direct response here is for the I%P to operate a Dual(!tac' #et)or'.
0nd the most direct wa* to achie)e this operation is for the I%P9s infrastructure to also support IP)4 where)er there is IP)./ so that

80
the deli)er* of ser)ices to the I%P9s clients in IP)4 faithfull* replicates the ser)ice offered in IP)..
This solution implies that the network needs to support IP)4 in the I%P9s routininfrastructure/ in the network data plane/ in the load6 mana-ement s*stems/ in the operational support infrastructure/ in access and accountin-/ and in peerin- and in transit. In short/ where)er there is IP). there needs to be IP)4.
The infrastructure elements that reAuire dual6stack ser)ice at the ne<t le)el include the routin- and switchin- elements/ includinthe internal and e<ternal routin- protocols. The task includes ne-otiatin- peerin- and transit ser)ices in IP)4 to complement those in IP).. 1etwork infrastructure also includes HP1 support and other forms of tunnels/ as well as data center front6end units/ includin- load balancers/ filters and firewalls/ and )arious )irtualiDed forms of ser)ice pro)ision. The task also includes inte-ration of IP)4 in the network mana-ement subs*stem and the related network measurement and reportin- s*stem. #)en a comprehensi)e audit of the supported 0ana%e*ent Infor*at on 4ases 2!I>s3 in the acti)e elements of the network to ensure that the rele)ant IP)4 !I>s are supported is an essential task. 0 similar task is associated with eAuippin- the

81
ser)er infrastructure with IP)4 support/ and at the hi-her le)els of the protocol stack are the )arious applications/ includin- web ser)ices/ mail/ Do*a n #a*e !yste* 2$1%3/ authentication and accountin-/ ,o ce over IP 2HoIP3 ser)ers/ Joad >alancers/ 7loud %er)ers/ and similar applications.
0nd those are just the common elements of most I%Ps9 infrastructures. #)er* I%P also has more specialiDed elements in its ser)ice portfolio/ and each one of these elements also reAuires a comprehensi)e audit to ensure that there is an IP)4 solution for each of these elements that leads to a comprehensi)e dual6stack outcome.
0s ob)ious as this approach mi-ht appear/ it has two si-nificant problems. First/ it reAuires a comprehensi)e o)erhaul of e)er* element in the I%P9s ser)ice network. #)en for small6scale I%Ps this o)erhaul is not tri)ial/ and for lar-er ser)ice pro)ider platforms it is an e<ercise that ma* take months if not *ears and make considerable inroads into the operatin- bud-ets of the I%Ps. %econdl*/ it still does not account for the ine)itable fact that in the comin- months the current suppl* lines of IP). addresses will end and an* continued e<pansion of the ser)ice platform will reAuire some different approaches to the wa* in which IP). addresses are

82
deplo*ed in the ser)ice platform.
0lthou-h the approach of simpl* pro)isionin- IP)4 alon-side IP). in a simple dual6protocol ser)ice infrastructure ma* appear to be the most ob)ious response to the need to transition to IP)4/ it ma* not necessaril* be the most appropriate response for man* I%Ps to the dual factors of IP)4 transition and IP). address e<haustion.
0re there alternati)e approaches for I%PsB f course.

83
"*brid 0pproaches
%a*in- that an I%P must deplo* IP)4 across all of its infrastructure and actuall* doin- it are often Auite different. The cost of con)ertin- all parts of an I%P9s operation to run in dual6stack mode can be Auite hi-h/ and the benefit of runnin- e)er* aspect of an I%P9s ser)ice offerin- in dual6stack mode is dubious at best. 1 %ure <; Gener c I!P Pac'et /rans t "rch tecture

84
0re there middle positions hereB Is it possible for an I%P to deli)er robust IP)4 ser)ices to clients while still operatin- an IP).6onl* internal networkB ne wa* to look at an I%P9s network is as a transit conduit 2Fi-ure ?3. E%ress oints
The
I%P
needs to be able to accept packets from an e<ternal interface/ determine the appropriate e-ress point for the packet within the conte<t of the local network/ and then ensure that the packet is passed out this e-ress interface. The internal network need not operate in the same protocol conte<t as the protocol of the packets the network is handlin-. Hiewed at a le)el of the minimal essentials/ the network needs to be able to ha)e some protocol6 specific capabilit* at its in-ress points in order to determine the appropriate e-ress point of each incomin- packet/ and thereafter durin- the transit of the ser)ice pro)ider9s network/ the minimum necessar* association to maintain the identit* of this preselected e-ress point with the packet. 1ow if the network uniforml* supports the same protocol as the packet/ then the same e-ress decision can be made at each forwardin- point within the network

85
.0lternati)el*/ the packet can be encapsulated with an outer wrapper that identifies the e-ress point usin- the same protocol conte<t as that used b* the ser)ice pro)ider9s internal switchin- elements/ and the packet can be passed throu-h the ser)ice pro)ider9s transit network usin- onl* this temporar* wrapper to determine the seAuence of forwardindecisions. 0ult &rotocol .abel !) tch n% 2!PJ%3 networks are an e<cellent e<ample of this form of approach/ as are other forms of IP6in6IP encapsulation. The ad)anta-e of this approach is that the internal infrastructure of the ser)ice pro)ider network need not be altered to support additional carria-e protocols: the chan-es to specificall* support IP)4 are reAuired onl* at the network in-ress elements/ and a basic encapsulation strippinfunction is used at all e-ress points.
+ith this information in mind/ let9s look at some of these h*brid approaches to supportin- IP)4 in a ser)ice pro)ider network.
4R$
4R$/ described in RF7 ,=4=F;G/ is an interestin- refinement of the 4to. approach. It shares the same basic encapsulation protocol and the same address structure of embeddin- of the IP). tunnel endpoint into the IP)4 address. "owe)er/ it has remo)ed the concept of third6part* rela*s and the use of the common &''&::/(4 IP)4 prefi</ and instead uses the pro)ider9s IP)4 prefi<. The effect of these chan-es is to limit the scope of the tunnelin- mechanism to that of tunnelin- across the network infrastructure of a sin-le pro)ider/ and the intended function is to tunnel from the Custo*er Pre* ses $:u &*ent 27P#3 to IP)4 4order +elays operated b* the customer9s I%P 2Fi-ure .3.
1 %ure 8; 6+D /unnel n%
If 4to. is not recommended for use because of hi-h failure rates of connections and suboptimal performance/ then wh* would 4R$ be an* betterB
The most compellin- reason to belie)e that 4R$ will perform more reliabl* than 4to. is that 4R$ remo)es the wild6card third6 part* rela* element from the picture. For outbound traffic the 7P# pro)ides the tunnel encapsulation/ which is/ hopefull*/ under the I%P9s operational control. The IP)46in6IP). tunnel is directed to the I%P9s own 4R$ >order Rela* rather than the 4to. rela* an*cast address. >ecause this process is also under the I%P9s direct operational control/ it eliminates the outbound third6part* rela* function. For the re)erse path/ the use of the pro)ider9s own IP)4 prefi< in 4R$/ instead of the -eneric &''&::/(4 prefi</ ensures that the inbound packets are sent throu-h IP)4 directl* to the I%P/ and the IP)46in6IP). tunnel is a-ain limited to a hop across the I%P9s own internal infrastructure.
0s lon- as the I%P effecti)el* mana-es all 7P# de)ices/ and as lon- as the 7P# itself is capable of supportin- the confi-uration of additional functional modules that can deli)er unicast IP)4 to the client and 4R$ tunnels inward to the I%P/ then 4R$ is a )iable option for the I%P. 0t the cost of up-radin- the 7P# set to include 4R$ support/ and the cost of deplo*ment of 4R$ >order Rela*s that terminate these 7P# tunnels/ to-ether with IP)4 transit from these >order Rela*s/ the I%P is in a position to pro)ide dual6stack support to its client base from an internal network platform that remains an IP). ser)ice platform/ thereb* deferrin- the process of con)ersion of its entire network infrastructure base to support IP)4.
For I%Ps seekin- to defra* the internal infrastructure IP)4 con)ersion costs o)er a number of *ears/ or for I%Ps seekin- an incremental path to IP)4 support that allows the e<istininfrastructure to remain in place temporaril*/ 4R$ can be an interestin- and cost6effecti)e alternati)e to a comprehensi)e dual6 stack deplo*ment/ as lon- as the I%P has some mechanism to load the 7P# with IP)4 support and 4R$ rela* functions.
!PJ% and 4P#
The 4R$ approach has man* similarities to !PJ%/ in that an addi6 tional header is added to incomin- packets at the network boundar*/ and the encapsulation effecti)el* directs the packet to the appropriate network e-ress point 2as identified b* in-ress3/ where the encapsulation is stripped and the ori-inal packet is passed out.
Rather than usin- an IP). header to direct a packet from in-ress to e-ress/ if the network is alread* usin- !PJ%/ wh* not simpl* support IP)4 on an e<istin- !PJ% network as a P#6to6P# !PJ% path set and b*pass the IP). stepB +h* not/ indeed/ and RF7 .4,=F=G describes how this b*pass can be achie)ed.If *ou are runnin- an !PJ% network/ then the role of the interior routin- protocol and label distribution function is to maintain )iable paths between all network in-ress and e-ress points. The protocol6 specific function in such networks is not the interior network topolo-* mana-ement function/ but the maintenance of the mappin- of e-ress to protocol6specific destination addresses 2Fi-ure ,3.
1 %ure =; 0P.! and 6P$
0s with 4R$/ if the local problem is some form of prohibiti)e barrier to the immediate deplo*ment of IP)4 in a dual6 stack confi-uration across the network infrastructure/ then this approach allows an IP). !PJ% network to set up paths across the network IP). !PJ% infrastructure from pro)ider ed-e to pro)ider ed-e. These paths ma* be used to tunnel IP)4 packets across the network b* associatin- the IP)4 destination address of the incomin- packet with the IP). address of the e-ress router/ usin- the nter or 4order Gate)ay Protocol 2i>5P3 #e7t(Ho& address/ for e<ample.
The incremental chan-es to support IP)4 are constrained to addin- IP)4 to the ser)ice pro)ider9s i>5P routininfrastructure/ and to the pro)ider6ed-e de)ices in the !PJ% network/ while all other parts of the ser)ice pro)ider9s ser)ice platform can continue to operate as an !PJ% IP). network for now.
IP). 0ddress 7ompression
It is not just the challen-e of addin- a new protocol to the e<istinIP). network infrastructure that confronts I%Ps. The entire reason for this acti)it* is the prospect of e<haustion of suppl* of IP). addresses. +hen this prospect was first aired/ in (=='/ it was assumed that the Internet would be supported b* industr* pla*ers that acted rationall* in terms of common interests . ne of the more critical assumptions made in the de)elopment of transitional tools was that transition acti)it* would be undertaken well in ad)ance of IP). address e<haustion. 7ompetiti)e interest would see each actor makin- the necessar* in)estments in new technolo-ies to miti-ate the risks of attemptin- to operate a network in an en)ironment of acute -eneral scarcit* of addresses. 0s much fun as the debate as to whom the 8last: IP). address should be -i)en mi-ht be/ it was assumed that this e)ent was/ in fact/ ne)er -oin- to happen. The assumption was that industr* actors would anticipate this situation and take the necessar* steps to a)oid it. The transition to IP)4 would be effecti)el* complete well before the stocks of IP). addresses had been e<hausted/ and IP). addresses would be an historical artefact well before we needed to use the last oneC
b)iousl*/ this scenario has not happened.
This industr* is -oin- to e<haust the a)ailable supplies of IP). addresses well before the transition to IP)4 is completeEand in some cases well before the transition process has e)en commencedC This situation creates an additional challen-e for I%Ps and the Internet/ and raises a further Auestion as well. The challen-e is to fold into this dual6stack transition the additional factor of ha)in- to work with fewer and fewer IP). addresses as the transition process continues. This situation implies that the necessar* steps that the I%P must take include ones that increase the intensit* of use of each IP). address/ and where)er possible substitute a pri)ate6use IP). address for public IP). addresses.
The Auestion that this scenario raises is one of -uessin- how lonthis h*brid model of an Internet where a si-nificant proportion of network ser)ices and network clients remains entrenched in an IP).6onl* world will persist. For as lon- as such IP).6onl* network domains persist/ and for as lon- as these IP).6onl* network domains encompass si-nificant ser)ice and customer populations/ all the other parts of the Internet are forced to maintain residual IP). capabilit* and cannot transition their customers and ser)ices to an IP)46onl* en)ironment. %tudents of economic -ame theor* ma* see some rich areas of stud* in this de)elopin- situation.
!ore practicall*/ for an I%P the Auestion becomes one of attemptin- to understand how lonthis h*brid period of attemptin- to operate a dual6stack network with continuinposte<haustion demand for further IP). addresses will last. +ill an after6market for the redistribution of addresses emer-eB "ow will the increasin- scarcit* pressure affect pricin- in such a marketB "ow lon- will demand persist for IP). addresses in the face of escalatin- pricesB +ill the industr* turn to IP)4 in a rapid sur-e in response to cost escalation for additional IP). addresses/ or will a dual6stack transition lumber on for man* *earsB In such a lar-e/ di)erse/ hetero-eneous en)ironment of toda*9s Internet/ the one constant factor is that the immediate future of the Internet is clouded with e<tremel* hi-h le)els of uncertaint*.
The cumulati)e effect of the indi)idual decisions made b* ser)ice pro)iders/ enterprises/ carriers/ )endors/ polic* makers/ and consumers has created a somewhat chaotic en)ironment that adds a si-nificant le)el of uncertaint* and associated in)estment risk into the current plannin- process for I%Ps. 7arrier65rade 10Ts
ha)e often heard it said that address scarcit* in IP). is nothinnew/ and it first occurred when the first 10T de)ice that supported port mappin- was deplo*ed. 0t this point the concept of address shar n% was introduced to the Internet/ and/ from the perspecti)e of the 10T industr*/ we ha)e not looked back since.
I
In toda*9s world 10Ts are e<tremel* commonplace. !ost clients are pro)isioned with a sin-le address from their I%P/ which the* then share across their local network usin- a 10T. +hether it is well ad)ised or not/ 10Ts t*picall* form part of a client9s network securit* framework/ and the* often are an inte-ral part of a customer9s multihomin- confi-uration if the client uses multiple pro)iders.
>ut in this model of 10Ts as the 7P#/ the I%P uses one IP). address for each client. If the I%P wants to achie)e -reater le)els of address compression/ then it is necessar* to share a sin-le IP). address across multiple customers. 1 %ure 6; Carr er(Grade #"/s $&N NAT $ E NAT I !4 Transit
I !4 'ocal Net(or) * ri!ate Address+
The most direct wa* to achie)e this scenario is for I%Ps to operate
their own 10T/ )ariousl* termed a Carr er(Grade #"/ 27513 or a .ar%e(!cale #"/ 2J%13/ or #"/888. This approach is the simplest/ and/ in essence/ is a case of 8more of the same: 2Fi-ure 43.
The 7arrier65rade 10T allows a sin-le public address to be shared across multiple clients/ who/ in turn/ further share this address across the end s*stems in their local networks.
From behind the 7P# in the client ed-e network not much has chan-ed with the addition of the 751 in terms of application beha)ior. It still reAuires an outbound packet to tri--er a bindinthat would allow a return packet throu-h to the internal destination/ so nothin- has chan-ed there. ther aspects of 10T beha)ior/ notabl* the 10T bindin- lifetime and the form of 10T 8cone beha)ior: for I$P/ take on the more restricti)e of the two 10T functions in seAuence. The bindin- times are potentiall* problematic in that the two 10Ts are not s*nchroniDed in terms of bindin- beha)ior. If the 751 has a shorter bindin- time/ it is possible for the 751 to misdirect packets and cause application6 le)el problems. "owe)er/ this situation is not o)erl* different from a sin-le6le)el 10T en)ironment where a--ressi)el* short 10T bindin- times also run the risk of causin- application6le)el problems when the 10T drops the bindin- for an acti)e session that has been Auiet for an e<tended period of time.
"owe)er/ one major assumption is broken in this structure/ namel* that an IP address is associated with a sin-le customer. In the 751 model a sin-le public IP address ma* be used simultaneousl* b* man* customers at once/ albeit on different port numbers. This scenario has ob)ious implications in terms of some current practices in filters/ firewalls/ 8black: and 8white: lists/ and some forms of application6le)el securit* and credentials where the application makes an inference about the identit* and associated le)el of trust in the remote part* based on the remote part*9s IP address.
This approach is not without its potential operational problems as well. For the ser)ice pro)ider/ ser)ice resilienc* becomes a critical concern in so far as mo)in- traffic from one 10T6connected e<ternal ser)ice to another will cause all the current sessions to be dropped. 0nother concern is one of resource mana-ement in the face of potentiall* hostile applications. For e<ample/ an end host infected with a )irus ma* -enerate a lar-e amount of probe packets to a lar-e ran-e of addresses. In the case of a sin-le ed-e 10T/ the lar-e )olumes of bindin-s -enerated b* this beha)ior become a local resource6mana-ement problem because the customer9s network is the onl* affected site. In the case where a 751 is deplo*ed/ the same beha)ior will consume port6bindin- space on the 751 and/ potentiall*/ can star)e the 751 of e<ternal address port bindin-s. If this problem is seen to be si-nificant/ the 751 would need to ha)e some form of e<ternal address rationin- per internal client in order to ensure that the entire e<ternal address pool is not consumed b* a sin-le errant customer application.
The other concern here is one of scalab l ty. +hereas the most effecti)e use of the 751 in terms of efficienc* of usa-e of e<ternal addresses occurs when the -reatest numbers of internal ed-e 10Ted clients are connected/ there are some real limitations in terms of 10T performance and address a)ailabilit* when a ser)ice pro)ider wants to appl* this approach to networks where the customer population is in the millions or lar-er. In this case the ser)ice pro)ider must use an IP). pri)ate address pool to number e)er* client. >ut if network (' is alread* used b* each customer as its 8internal: network/ then what address pool can be used for the ser)ice pro)ider9s pri)ate address spaceB ne of the few answers that come to mind is to deliberatel* partition the network into numerous discrete networks/ each of which can be pri)atel* numbered from (L&.(4.'.'/(&/ allowin- for some 4''/''' or so customers per network partition/ and then use a transit network to 8-lue: to-ether the partitioned elements.
The ad)anta-e of the 751 approach is that nothin- chan-es for the customer. There is no need for an* customers to up-rade their 10T eAuipment or chan-e it in an* wa*/ and for man* ser)ice pro)iders this moti)ation is probabl* sufficient to choose this path. The disad)anta-es of this approach lie in the scalin- properties when lookin- at )er* lar-e deplo*ments/ and the concerns of application6le)el translation/ where the 10T attempts to be 8helpful: b* performin- Dee& Pac'et Ins&ect on and rewritinwhat it thinks are IP addresses found in packet pa*loads. "a)inone 10T do this process is bad enou-h/ but loadin- them up in seAuence is a recipe for trouble.
0re there alternati)esB The 0ddress6plus6Port 0pproach
ne 10T in the path is certainl* worse than none from the perspecti)e of application a-ilit* and functions. 0nd two 10T functions do not make it an* betterC Ine)itabl*/ that second 10T de)ice adds some additional le)els of comple<it* and fra-ilit* into the process.
The Auestion is/ can these two 10T functions be collapsed back into a sin-le 10T/ *et still allow sharin- of public IP). addresses across multiple end clientsB 7P# 10T de)ices currentl* map connections into the (46bit &ort field of the sin-le e<ternal address. If the 7P# 10T could be coerced into performin- this mappin- into/ sa*/ (, bits of the port field/ then the e<ternal address could be shared between two ed-e 7P#s/ with the leadinbit of the port field denotin- which 7P#. b)iousl*/ mo)in- the bit marker further across the port field will allow more 7P# de)ices to share the one address/ but it will reduce the number of a)ailable ports for each 7P# in the process.
The theor* is a-ain Auite simple. The 7P# 10T is d*namicall* confi-ured with an e<ternal address/ as happens toda*/ and a port ran-e/ which is the additional constraint. The 7P# 10T performs the same function as before/ but it is now limited in terms of the ran-e of e<ternal port )alues it can use in its 10T bindin-s to those that lie within the pro)ided port ran-e. ther 7P# de)ices are concurrentl* usin- the same e<ternal IP address/ but with a different port ran-e.
For out-oinpackets this scenario implies onl* a minor chan-e to the network architecture/ in that the R0$II% e<chan-e to confi-ure the 7P# now must also pro)ide a port ran-e to the 7P# de)ice. The 7P# is then constrained such that as it maps pri)ate addresses and T7P or I$P port )alues to the e<ternal address and port )alues/ the mapped port )alue must fall within the confi-ured ran-e. 1 %ure >; "ddress(&lus(Port("&&roach orts: 0 , 1"-.- A/ $ E NAT I !4 'ocal Net(or) * ri!ate Address+ A/
&ate(ay I !4 Transit orts: 40112 , "11-1
orts: 1"-.4 , -22"2 orts: -22". , 40111
The handlin- of incomin- packets is more challen-in-. "ere the ser)ice pro)ider must forward the packet based not onl* on the destination IP address/ but also on the port )alue in the T7P or I$P header/ because there are now multiple 7P# e-ress points that share the same IP address. 0 con)enient wa* to perform forwardin- is to take the $ual6%tack Jite approach and use an IP).6in6IP)4 tunnel between the 7P# and the e<ternal address6 plus6port 20OP3 -atewa*. This address6plus6port -atewa* needs to be able to associate each address and port ran-e with the IP)4 address of a 7P# 2which it can learn d*namicall* as it decapsulates out-oinpackets that are similarl* tunneled from the 7P# to the address6plus6port -atewa*3. Incomin- packets are encapsulated in IP)4 usin- the IP)4 destination address that it has learned pre)iousl*. In this manner the 10T function is performed just once/ at the ed-e/ much as it is toda*/ and the interior de)ice is a more con)entional form of tunnel ser)er 2Fi-ure L3.
This approach relies on e)er* 7P# de)ice beinable to operate usin- a restricted port ran-e/ to perform IP).6in6IP)4 tunnel in-ress and e-ress functions/ and act as an IP)4 pro)isioned endpoint for the ser)ice pro)ider network. This set of constraints is perhaps unrealistic for man* ser)ice pro)ider networks. Further modifications to this model propose the use of an accompan*in751 operated b* the ser)ice pro)ider to handle those 7P# de)ices that cannot support this address6plus6port function.
This approach has some positi)e aspects. Pushin- the 10T function back to the network ed-e has some considerable ad)anta-e o)er the approach of mo)in- the 10T to the interior of the network. The packet rates are lower at the ed-e/ allowin- for commodit* computin- to process the 10T functions across the offered packet load without undue stress. The abilit* to control the 10T beha)ior with the Internet Gate)ay Dev ce protocol as part of the 5n versal Plu% and Play 2uPnP3 framework will still function in an en)ironment of restricted port ran-es. 0side from the initial pro)isionin- process to eAuip the 7P# 10T with a port ran-e/ the 7P# and the ed-e en)ironment are lar-el* the same as that of toda*9s 7P# 10T model.
That is not to sa* that this approach is without its ne-ati)e aspects/ and it is unclear as to whether the percei)ed benefits of a 8local: 10T function outwei-h the problems in this particular model of address sharin-. The concept of port 8rationin-: is a )er* suboptimal means of address sharin-/ -i)en that when a 7P# is assi-ned a port ran-e/ those port addresses are unusable b* an* other 7P#. The prudent ser)ice pro)ider would assi-n to each 7P# a port address pool eAual to some estimate of peak demand/ so that/ for e<ample/ each 7P# would be assi-ned some ('&. ports/ allowin- a sin-le e<ternal IP address to be shared across onl* some 4' such 7P# clients. The 7arrier65rade 10T and $ual6 %tack Jite approaches do not attempt this form of rationed allocation/ allowin- the port address pool to be treated as a common resource/ with far hi-her le)els of usa-e efficienc*. The le)era-e obtained in terms of efficientl* usin- these additional (4 bits of address space is reduced b* the imposition of a fi<ed boundar* between customer and ser)ice pro)ider use. The central 10T model effecti)el* pools the port address ran-e and would result in more efficient sharin- of this common pool across a lar-er client base.
The other consideration here is that this approach means a hi-her o)erhead for the ser)ice pro)ider/ in that the ser)ice pro)ider would ha)e to support both 8con)entional: 7P# eAuipment and address6 plus6port eAuipment. In other words/ the ser)ice pro)ider will ha)e to deplo* a 751 and support customer 7P# usin- a two6le)el 10T en)ironment in addition to operatin- the address6 plus6port infrastructure. Inless customers would be willin- to pa* a si-nificant price premium for such address6plus6port ser)ice/ it is unlikel* that this option would be attracti)e for the ser)ice pro)ider as an additional cost abo)e the 751 cost.
$ual6%tack Jite
The concept behind the Dual(!tac' . te approach is that the ser)ice pro)ider9s network infrastructure will need to support IP)4 runnin- in nati)e mode in an* case/ so is there a wa* in which the ser)ice pro)ider can continue to support IP). customers without runnin- IP). internall*B 1 %ure ?; Dual(!tac' . te
"ere the customer 10T is effecti)el* replaced b* a tunnel in-ress6 e-ress function in the $ual6%tack Jite home -atewa*. ut-oinIP). packets are not translated/ but are encapsulated in an IP)4 packet header/ which contains a source address of the carrier side of the home -atewa* unit/ and a destination address of the I%P9s -atewa* unit. From the ser)ice pro)ider9s perspecti)e/ each customer is no lon-er uniAuel* addressed with an IP). address/ but instead is addressed with a uniAue IP)4 address/ and pro)ided with the IP)4 address of the pro)ider9s combined IP)4 tunnel e-ress point and IP). 10T unit 2Fi-ure ;3.
3,4 'ite $& N I ! 4 Tra nsit
3,4 'ite $ E I !4 'ocal Net(or) The * ri!ate Address+ ser)ice pro)ider9s $ual6%tack Jite -atewa* unit will perform the IP)4 tunnel termination and a 10T translation usin- an e<tended local bindintable. The 10T 8interior: address is now a .6tuple of the IP). source address/ protocol I$/ and port/ plus the IP)4 address of the home -atewa* unit/ while the e<ternal address remains the triplet of the public IP). address/ protocol I$/ and port. In this wa* the 10T bindintable contains a mappin- between interior 8addresses: that consist of IP). address and port plus a tunnel identifier/ and public IP). e<terior addresses. This wa* the 10T can handle a multitude of net (' addresses/ because the* can be distin-uished b* different tunnel identifiers.
The resultant output packet followin- the strippin- of the IP)4 encapsulation and the application of the 10T function is an IP). packet with public source and destination addresses. IncominIP). packets are similarl* transformed/ where the IP). packet header is used to perform a lookup in the $ual6%tack Jite -atewa* unit/ and the resultant .6tuple is used to create the 10T6translated IP). packet header plus the destination address of the IP)4 encapsulation header.
The ad)anta-e of this approach is that there now needs to be onl* a sin-le 10T in the end6to6end path/ because the functions of the customer 10T are now subsumed b* the carrier 10T. This scenario has some ad)anta-es in terms of those mess* 8)alue6 added: 10T functions that attempt to perform deep packet inspection and rewrite IP addresses found in data pa*loads. There is also no need to pro)ide each customer with a uniAue IP). address/ public or pri)ate/ so the scalin- limitations of the dual6 10T approach are also eliminated. The disad)anta-es of this approach lie in the need to use a different 7P# de)iceEor at least one that is repro-rammed. The de)ice now reAuires an e<ternal IP)4 interface and at the minimum an IP)./IP)4 tunnel -atewa*
function. The de)ice can also include a 10T if so desired/ but it is not reAuired in terms of the basic $ual6%tack Jite architecture.
This approach pushes the translation into the interior of the network/ where the -reatest benefit can be deri)ed from port multiple<in-/ but it also creates a critical hotspot for the ser)ice itself. If the $ual6%tack Jite 10T fails in an* wa*/ the entire customer base is disrupted. It seems somewhat counterintuiti)e to create a resilient end6to6end network with stateless switchinen)ironments and then place a critical stateful unit ri-ht in the middleC Protocol Translation
%o far we ha)e looked at two -eneral forms of approach to h*brid networks that are intended to support both IP)4 transition and -reater le)els of address usa-e in IP)./ namel* address mappinand tunnelin-. 0 third approach lies in the area of protocol translation.
RF7 &L4,F('G contains the details of a relati)el* simple protocol6
translation mechanism. The approach relies on the basic obser)ation that IP)4 did not make an* radical chan-es to the basic IP architecture of IP)./ and that it was therefore possible to define a stateless mappin- al-orithm that could translate between certain IP). and IP)4 packets. f course the one major problem here is that there are far more addresses in IP)4 than in IP)./ so the approach used was to map IP). addresses into the trailin- ?& bits of the IP)4 address prefi< ::FFFF:':'/=4. The approach assumed that to the IP)46onl* end host the entire IP). network was )isible in this mapped IP)4 prefi</ and that when the IP)46onl* end host wished to communicate with a remote host who was addressed usin- this IP).6mapped prefi< it would use a source address also drawn from the same IP).6mapped prefi<. In other words/ it assumed that all IP)46onl* hosts were also assi-ned a uniAue IP). address
.The #"/(Protocol /ranslat on 210T6PT3 approach attempted to rela< this constraint/ allowin- IP)46onl* hosts to use a d*namic mappin- to a public IP). address throu-h the 10T6PT function/ in the same wa* as 10T functions work in an all6IP). domain 2Fi-ure =3. The proposed approach assumed that the local host was located behind a modified $1% en)ironment where the IP). 80: record of an IP).6onl* remote ser)ice is translated b* the $1% -atewa* into a local IP)4 address where the initial =4 bits of the IP)4 address identif* the internal address of the 10T6PT -atewa* and the trailin- ?& bits are the IP). address of the remote ser)ice. +hen the local host then uses this address as an IP)4 destination address/ the packet is directed b* the local routinen)ironment to the 10T6PT de)ice. This de)ice can construct an 8eAui)alent: IP). packet b* usin- the local IP). address as the source address and the last ?& bits of the IP)4 address as the destination address/ and bind the IP)4 source port to a free local port )alue. These sets of transforms can be locall* stored as an acti)e 10T bindin-. Return IP). packets can be mapped back into their 8eAui)alent: IP)4 form b* usin- the )alues in the bindin- to perform a re)erse set of transforms on the IP address and port fields of the packet.
This approach was published as RF7 &L44F((G in Februar* &'''. %ome L *ears later in Jul* &''L/ the I#TF published RF7 .=44F(&G/ deprecatin- 10T6PT to 8historic/: with an associated list of applications that would not operate correctl* throu-h such a de)ice. This ne-ati)e jud-ement of 10T6PT seems rather curious to me/ -i)en that con)entional 7P# 10T functions in IP). appear to share most/ if not all/ of the same shortfalls that are listed in RF7 .=44. 5i)en the e<tensi)e set of compromises that are reAuired in the en)ironment that is partiall* crippled b* IP). address e<haustion/ it seems rather contradictor* to insist upon e<tremel* hi-h le)els of functions and robustness from these h*brid translation approaches.
1 %ure @; #"/ Protocol /ranslat on ( #"/68 3N4"4
1ot unsurprisin-l*/ 10T6PT is under-oin- a re)i)al/ this time under the name 810T4..: 1ot much has chan-ed from the basic approach outlined in 10T6PT. The IP)46onl* client performs a $1% lookup throu-h a modified $1% ser)er that is confi-ured with $1%4.. If the Aueried name contains onl* an IP). address/ the $1%4. ser)er s*nthesises an IP)4 response b* mer-in- the prefi< address of the 10T4. -atewa* with the IP). address. +hen the client uses this address/ the IP)4 packet is directed to the 10T4. -atewa*/ and the same transform as described pre)iousl* for 10T6PT takes place.
This setup is similar to the 751 model/ in so far as the ser)ice pro)ider operates a common 10T that shares an IP). address pool across a set of end clients.
I%P 7onclusions
There reall* is no sin-le clear path forward from this point. $ifferent I%Ps will see some ad)anta-es in pursuin- different approaches to this dual problem of introducin- IP)4 into their ser)ice portfolio and at the same time introducin- additional measures that allow more efficient use of IP). addresses.
"owe)er/ one common theme is becomin- clear. %o far I%Ps ha)e been able to 8e<ternaliDe: man* of these problems b* pushinmuch of the comple<it* and fra-ilit* of 10T functions out to the customer and loadin- up the 7P# with these functions. This approach of e<ternaliDin- much of the comple<it* of address compression in 10T functions o)er to the customer9s network cannot be sustained with the IP)4 transition/ and no matter which approach is used/ whether it is a 751/ 10T4./ $ual6%tack Jite/ 4R$/ or !PJ% with 4P#/ the I%P now has to acti)el* participate in the deli)er* of IP)4 and in increasin- the efficienc* of the use of IP)..
%o for the I%P it is time to start makin- some technical choices as to how to address the combination of these two rather uniAue chal6 len-es of transition and e<haustion.
References
F(G
F&G
F?G
0le< 7onta and %tephen $eerin-/ 85eneric Packet Tunnelinin IP)4 %pecification/: RF7 &.L?/ $ecember (==;.
F.G
Yako) Rekhter/ >ob !oskowitD/ $aniel Narrenber-/ 5eert Jan de 5root/ and #liot Jear/ 80ddress 0llocation for Pri)ate Internets/: RF7 (=(;/ Februar* (==4.
F,G
7hristian "uitema/ 8Teredo: Tunnelin- IP)4 o)er I$P throu-h 1etwork 0ddress Translations 210Ts3/: RF7 .?;'/ Februar* &''4.
F4G
Jonathan Rosenber-/ Rohan !ah*/ Philip !atthews/ and $an +in-/ 8%ession Tra)ersal Itilities for 10T 2%TI13/: RF7 ,?;=/ ctober &'';.
FLG
0le< 7onta/ %tephen $eerin-/ and !ukesh 5upta/ 8Internet 7ontrol !essa-e Protocol 2I7!P)43 for the Internet Protocol Hersion 4 2IP)43 %pecification/: RF7 ...?/ !arch &''4.
F;G
!ark Townsle* and le Troan/ 8IP)4 Rapid $eplo*ment on IP). Infrastructures 24rd3 6 Protocol %pecification/: RF7 ,=4=/ 0u-ust &'('.
F=G
Jerem* $e 7lercA/ $irk oms/ !arco 7aru-i/ and Francois Je Faucheur/ 8>5P6!PJ% IP Hirtual Pri)ate 1etwork 2HP13 #<tension for IP)4 HP1/: RF7 .4,=/ %eptember &''4.
F('G
#rik 1ordmark/ 8%tateless IP/I7!P Translation 0l-orithm 2%IIT3/: RF7 &L4,/ Februar* &'''.
F((G
5eor-e Tsirtsis and P*da %risuresh/ 81etwork 0ddress Translation 6 Protocol Translation 210T6PT3/: RF7 &L44/ Februar* &'''.
F(&G
7edric 0oun and #lw*n $a)ies/ 8Reasons to !o)e the 1etwork 0ddress Translator 6 Protocol Translator 210T6PT3 to "istoric %tatus/: RF7 .=44/ Jul* &''L.
Further Readin-
The I#TF has been workin- on the issues related to the transition to IP)4 for the past (; *ears/ and in the inter)enin- period has -enerated man* hundreds of documents. In selectin- the followindocuments as a helpful readin- list/ I ha)e tried to select onl* from the more recent documents and those that are o)er)iews of transition technolo-ies rather than reference specifications for indi)idual technolo-ies.
F(G
Jari 0rkko and Fred >aker/ 85uidelines for Isin- IP)4 Transition !echanisms durin- IP)4 $eplo*ment/: Internet $raft/ +ork in Pro-ress/ $ecember &'('. /he docu*ent d scusses the IPv6 de&loy*ent *odels and * %rat on tools, and cons ders )hat a&&ears to be effect ve n net)or's to date. /h s Internet Draft, draft6arkko6ip)46 transition6-uidelines6 (..t<t/ s about to be &ubl shed as an Infor*at onal +1C.
F&G
>rian 7arpenter and %hen- Jian/ 8#mer-in- %er)ice Pro)ider %cenarios for IP)4 $eplo*ment/: RF7 4'?4/ ctober &'('.
Transitionin% rotocols: cont nued /h s docu*ent descr bes &ract ces and &lans that are e*er% n% a*on% Internet !erv ce Prov ders for the de&loy*ent of IPv6 serv ces, us n% data collected n a survey of nu*erous I!Ps carr ed out n early -ABA.Reinaldo Penno/ Tarun %a<ena/ !ohamed >oucadair/ and %enthil %i)akumar/ 80nal*sis of 4. Translation/: Internet $raft/ +ork in Pro-ress/ draft6ietf6beha)e64.6anal*sis6'(/ Januar* &'((. /h s &a&er s a )or' n% docu*ent of the I$/1Cs 4$H",$ Wor' n% Grou&. /he docu*ent notes that because of s&ec f c &roble*s, #"/(P/ )as de&recated by the I$/1 as a *echan s* to &erfor* IPv6(IPv8 translat on. ! nce then, ne) efforts have been underta'en ) th n I$/1 to standard 9e alternat ve *echan s*s to &erfor* IPv6(IPv8 translat on. /h s docu*ent evaluates ho) the ne) translat on *echan s*s avo d the &roble*s that caused the I$/1 to de&recate #"/(P/.
F?G
Fred >aker/ Qin- Ji/ and Ne)in Yin/ 8Framework for IP)./IP)4 Translation/: Internet $raft/ +ork in Pro-ress/ 0u-ust &'('. It s co**on n the I$/1 these days to %enerate a Dfra*e)or'E docu*ent as &art of the &rocess of develo& n% techn cal s&ec f cat ons. /h s draft s a fra*e)or' docu*ent for the %eneral IPv8FIPv6 translat on technolo%y. /h s Internet Draft, draft6 ietf6beha)e6)4).6framework6('.t<t/ ) ll soon be &ubl shed as an Infor*at onal +1C.

121
Transitionin% rotocols: cont nued

F.G
#lw*n $a)ies/ %uresh Nrishnan/ and Pekka %a)ola/ 8IP)4 Transition/7oe<istence %ecurit* 7onsiderations/: RF7 .=.&/ %eptember &''L. /he trans t on nto a dual(stac' env ron*ent, )h le atte*&t n% to &reserve the nte%r ty of a s n%le serv ce re% *e, &resents nu*erous secur ty concerns. /h s docu*ent s a %ood overv e) of such concerns.
F,G
$an +in- and 0ndrew Yourtchenko/ 8Impro)in- Iser #<pe6 rience with IP)4 and %7TP/: /he Internet Protocol Journal, Holume (?/ 1o. ?/ %eptember &'('. 4u ld n% eff c ent a&&l cat ons n a dual(stac' )orld can be very challen% n%. It s often the case that &oor *ana%e*ent of a dualstac' syste* can *a'e the user e7&er ence far slo)er than just cont nu n% n the IPv8 )orld. One )ay to redress th s &roble* s to e7chan%e se:uent al test n% of IPv6 and IPv8 connect v ty nto a &arallel o&erat onboth &rotocols at once. /h s art cle e7&la ns the conce&t.

122
Transitionin% rotocols: cont nued 5# FF "I%T 1/ >.%c./ !.%c./ is the 7hief %cientist at 0P1I7/ the Re-ional Internet Re-istr* ser)in- the 0sia Pacific re-ion. "e has been closel* in)ol)ed with the de)elopment of the Internet for man* *ears/ particularl* within 0ustralia/ where he was responsible for the initial build of the Internet within the 0ustralian academic and research sector. "e is author of numerous Internet6related books/ and was a member of the Internet 0rchitecture >oard from (=== until &'',K he ser)ed on the >oard of Trustees of the Internet %ociet* from (==& until &''(. #6mail: -ih@apnic.net

123
/he Internet Protocol Journal 2IPJ3 is published Auarterl* b* 7isco %*stems. The journal is not intended to promote an* specific products or ser)ices/ but rather is intended to ser)e as an informational and educational resource for en-ineerinprofessionals in)ol)ed in the desi-n/ de)elopment/ and operation of public and pri)ate internets and intranets. The journal carries tutorial articles 28+hat is...B:3/ as well as implementation/operation articles 28"ow to...:3. It pro)ides readers with technolo-* and standardiDation updates for all le)els of the protocol stack and ser)es as a forum for discussion of all aspects of internetworkin-. 7all for Papers
Topics include/ but are not limited to: THE INTERNET PROTOCOL JOURNAL
124

R
0ccess and infrastructure technolo-ies such as: I%$1/ 5i-abit #thernet/ % 1#T/ 0T!/ <$%J/ cable/ fiber optics/ satellite/ wireless/ and dial s*stems
Transport and interconnection functions such as: switchin-/ rout6 in-/ tunnelin-/ protocol transition/ multicast/ and performance
1etwork mana-ement/ administration/ and securit* issues/ includin-: authentication/ pri)ac*/ encr*ption/ monitorin-/ firewalls/ troubleshootin-/ and mappin-

125

R
Halue6added s*stems and ser)ices such as: Hirtual Pri)ate 1et6 works/ resource location/ cachin-/ client/ser)er s*stems/ distributed s*stems/ network computin-/ and Pualit* of %er)ice
0pplication and end6user issues such as: e6mail/ +eb authorin-/ ser)er technolo-ies and s*stems/ electronic commerce/ and application mana-ement
Je-al/ polic*/ and re-ulator* topics such as: cop*ri-ht/ content control/ content liabilit*/ settlement char-es/ 8modem ta</: and trademark disputes in the conte<t of internetworkin-

126
Transitionin% rotocols: cont nued In addition to feature6len-th articles/ IPJ contains standardiDation updates/ o)er)iews of leadin- and bleedin-6ed-e technolo-ies/ book re)iews/ announcements/ opinion columns/ and letters to the #ditor.
7isco will pa* a stipend of I%S(''' for published/ feature6len-th articles. 0uthor -uidelines are a)ailable from le Jacobsen/ the #ditor and Publisher of IPJ/ reachable )ia e6mail at ole@cisco.com

127
This #u&lic tion is distri&uted on n , s-is, & sis- without w rr nt$ of n$ *ind either e.#ress or im#lied- includin/ &ut not limited to the im#lied w rr nties of merch nt &ilit$fitness for # rticul r #ur#oseor non-infrin/ement. This #u&lic tion could cont in technic l in ccur cies or t$#o/r #hic l errors. 0 ter issues m $ modif$ or u#d te inform tion #rovided in this issue. 1either the #u&lisher nor n$ contri&utor sh ll h ve n$ li &ilit$ to n$ #erson for n$ loss or d m /e c used directl$ or indirectl$ &$ the inform tion cont ined herein.The Internet Protocol 2ourn l- Cisco S$stems 3(4 5est T sm n 6rive S n 2ose- C7 +'3"%3(46 8S7 11111111 7 I % 7 PRSRT ST6 8.S. Post /e AI3 E5MIT No6 11.2 4AN 784E, $A 766RESS SER9ICE RE:8ESTE6

128
"on- NonThe Internet Protocol Journal is published quarterly by the Chief Technology Office, Cisco Systems, Inc. www.cisco.com Tel !" #$% &'()#$$$ *)mail ip+,cisco.com Copyright - '$"" Cisco Systems, Inc. .ll rights reser/ed. Cisco, the Cisco logo, and Cisco Systems are trademar0s or registered trademar0s of Cisco Systems, Inc. and1or its affiliates in the 2nited States and certain other countries. .ll other trademar0s mentioned in this document or 3ebsite are the property of their respecti/e owners. Printed in the 2S. on recycled paper.
The Internet Protocol Journal le J. Jacobsen/ #ditor and Publisher
#ditorial 0d)isor* >oard $r. Hint 7erf/ HP and 7hief Internet #)an-elist 5oo-le Inc/ I%0 $r. Jon 7rowcroft/ !arconi Professor of 7ommunications %*stems Ini)ersit* of 7ambrid-e/ #n-land $a)id Farber $istin-uished 7areer Professor of 7omputer %cience and Public Polic* 7arne-ie !ellon Ini)ersit*/ I%0 Peter Jothber-/ 1etwork 0rchitect %tupi 0>/ %weden $r. Jun !urai/ 5eneral 7hair Person/ +I$# Project Hice6President/ Neio Ini)ersit* Professor/ Facult* of #n)ironmental Information Neio Ini)ersit*/ Japan $r. $eepinder %idhu/ Professor/ 7omputer %cience T #lectrical #n-ineerin-/ Ini)ersit* of !ar*land/ >altimore 7ount* $irector/ !ar*land 7enter for Telecommunications Research/ I%0 Pindar +on-/ 7hairman and President Herifi Jimited/

Protocol

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Protocol

Transféré par

Droits d'auteur :

Formats disponibles

The---------------------------------------------------------------------------------------------

There is a 7hinese pro)erb that states: 8It9s better to

I%%1 (=..6((?. Geoff Huston, -ih@apnic.net Ole J. Jacobsen, ole@cisco.com

Ch ef !c ent st, "P#IC $d tor and Publ sher, IP

THE INTERNET PROTOCOL JOURNAL

J0 Rou-h 5uide to 0ddress #<haustion by Geoff Huston, "P#IC

THE INTERNET PROTOCOL JOURNAL

Address Exhaustion: cont nued +hat is an IP address/ and wh* is it so importantB

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

+hat is the planB

THE INTERNET PROTOCOL JOURNAL

Address Exhaustion: cont nued +h* IP)4 and not IP),B

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

+hat about Maddress sharin-M in IP).B THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

%o we need to transition to IP)4/ and we need to do so within an impossibl* short time.

This discussion all sounds like a terrible problem.

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

1o/ I don9t think we doC

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

If onl* that were trueC

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

THE INTERNET PROTOCOL JOURNAL

1o/ not necessaril*.

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

+ell/ not necessaril*.

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

THE INTERNET PROTOCOL JOURNAL

1othin- is )isible from hereC

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

THE INTERNET PROTOCOL JOURNAL

THE INTERNET PROTOCOL JOURNAL

Transitional Myths: cont nued

Myth 11: We have a plan6

I am unsure about this one.