Intcrnct. Within tlic IETt', several efforts \\?ere undertakento both study and i~npro\*e the i~sc of the 32-bitIntcrnct Protocol (IPv4) addresses, as \\,ell as to idcntieand replace protocols and services that \\!auld limitgro\\.th. The 32-bit ,tddrcssing architecture jn the nct-\\,ark la!rcr \\,as cll~ickl!. detczrmi~~ed to be the crux ottlic problem, \\,it11 both hard\\,arc nncl li~~man limitsnpproxlli~~g f~ndamental boiu~darics.' 1h.4 addrcsscs3rc ~~ncvcnly allocated in blocks that arc oficn toolarge or too small; they are also difficult to change\vithin any csisting network.When the IETF called for replaccmcnt proposals,Digital participated in this industry-\vide cffort bysubmitting \\!l~itc papers outlining issues and by dcvclopingand c\laluating prototT\ipes of the \w-ious proposals,Digital also participated in the IE'l'F \\forltinggro~~psaand in the IPng directorate, \\~Iiich liati tlicrcsrx)nsibility for making the ultimate decision. In July1994, the IPng directorate selected the InternetProtocol \.enion 6 (1116) as the replaccmcnt nenvorklayer protocol, and IETE \\,orking groups began tob~~ild spccificatio~ls. "The Recornnlendatio~l for rlicIP Nest Generation Protocol" summarizes the candidatesand explains the selection of this protocol.'Digital UNlX PrototypeThe current Digital UNIS IPv6 prototype pmjcct isDigital's most recent acidition to an ongoing effort todc~lclop and evaluate the competing Il'r~g proposals.This began with the Si~nplc Internet Protocol (SIP),\\,liich ~ ~sed eight octet addresses. SIP was latcr mcldcd\vith another early proposal and bcca~nc known asSi~nplc Internet Protocol Plus (SIPP), the directantecedent of 11'\,6.' The prirnary goal of Digital'sefforts h:~s been to e\,aluate the technical feasibility oftlic proposcti arcliitect~~rc ancl pro\ridc fccdbaclc to theIF,TF \\,orking groups. This is critical to the stantlardsclc\clopment process in the IETF, \\.llich rccl~~ircs n1~1ltiplcjndcpclldcnt ancl intczroperable jn~plc~ilc~itntio~isof 3 spcciticatiorl before it may become an Intcrnctst;tndnrcl. An additional goal has been to cvaluatc systemdesign altcrnati\,cs to gain the cspcricncc nccdcdto allo\v Digital to incorporate this nc\\. architccti~rcinto existing products. Digital has niadc thc protohpcavailable to researchers within the company as a sourcccode distribution and Inore reccntl!. has begun to supplybinary kits for early adopters and evaluators in theIntcrnct con~munity. As the IR.6 protocol ,~nd architecturemdturcs, use have begun to focus on ho\v toOcst i~ltegr~itc tlie code illto thc D~gital UNIS prodilct.IPv6 OverviewTo underst:~nd the s!rstem-\vide impact of IPv6, \\.crc\*ic\\*somc ofits ~ic\\.fcatures and contrast them \\.it11the IPv4 model. IPv6 is both a complctcly nc\vnct\vork layer protocol and a major revision of theIntcrnct architecture. At both le\~els, it builds uponand incorporates csperiences gained wit11 ll'v4.Figure 1 sho\\!s the evolution of the packet formatinto the ne\v TPv6 Iieader. It retains sonic fields (vcrsion,source, and destination address), clarifies the roleofot11c1.s (for csample, the Time -To Li\,c [TTL,] fcldis rcnamcd the Hop Li~i~it), and introduces new ones(such as Flo\\, 11)) with as yet untapped potential. Thencrt header fi cld allo\\.s for modirlar construction ofcomplex packcts: difkrcnt 1leadt.1- npcs can he chnincdtogether to provide specialized functionality, includingsccurin and source routing. Findl!; all licadcrs arcstructured to allo\v 64-bit alignmcnt, \\.hich shouldallo\v optimal processing both at sourcc and dcstinationsystc~ns, ;IS \\.ell as in transit.'Tlic most striking departure fro~ii I1'\,4 is theaddress size: it has increased horn 32 bits to 128 bits.- >1 he 11'\,6 addressing architecti~re is rich, \\lit11 prcfiscsti)r ni~~lticast addresses and prcdcfincci scopes for bothunicast and multicast addresses. One special type ofunicast address is the link-local address, \\lhich permitscorn~n~~nications \\,ith only those s!fstems directly conncctcdon the same link. This allo\\!s a standard bootstrnppjngmechanism, so that systcnis can Icarn aboutneighbors and scr\-ices before a routablc atitlrcss is'lssig~ied to an intcrfacc. \Jarious addrcss assign~nclltoptions lin\,c bccn defined, including liicrarcliicalmodels bnsccl up011 rcgional rcgistrics and scr\,iccproviclcr identifiers."" In each casc, care has been takento ensure proper route aggregation, \\.liich \\.ill helpyiclcl Inore efficient bacltbonc routcr pcrfor~nancc.Multiple liicans of acquiring addrcsscs have bee11defined k,r 11'1.6 addrcssing, \\;it11 the goals of al lo\\,ingtlcsibility through different administrati\~c policiesVERSIONPRIORITYFLOW LABELPAYLOAD LENGTH NEXT HEADER HOP LIMITSOURCE ADDRESSDESTINATION ADDRESSFigure 11 I'j.6 Mcnticr6 1)i~inl 'lkcl~~iic.~l Joitrt~:~l Vol. S No. 3 I990
a~icl, pcrhaps Inorc important, ofdemanding that nct-\vork addrcss reassignment be supported throughoutthe arcl-~itccturc. Tlic two neu. addrcssing services areStatclcss Address Autoconfi g~rration and the stateful,transaction-based Dynamic Host Configuration Protocolversion 6 (1>H(:l'\~6).7Y~n the st.ltcless model,address prctiscs arc Icarncci by listcni~ig for routerad\fertiscrncnt packets. Addrcsscs ~ rc formed by combiningtlic prcf s \\.it11 linlc-specific token such as the48-bit Ethcrnct liard\\,are addrcss. In tlie statcfi~l proccclure,hosts Ilia!, rcqucst addrcsscs, configurationi~iformntion, and scr\.iccs from drdicatcd contigurationser\,crs, \\,it11 routers potcnti,~ll!r scr\'ing as relaystations cil~ring the initid pIi3sc. In botli cases, tlieresulting ;iddrcsscs have associated lifetimes, and systeltlsr~lust be prepared to both learn addrcsscsand rcleasc cspjred addrcsscs. Combined \vitli theability to rcgistcr updated addrcss information withDNS serlrers, these mcclianisms provide a path toward~ictc\lork rcnunibcring, a goal that has provcd difficultto achieve in the I l'v4 world.Finally, the Internet Control Mcssagc Protocol version6 (ICMPv6) was dcvclopcd.~This specificationaimed to merge the fi~nctions of two distinct Ih14 protocolsfor reporting errors and status, ICMP for unicastpackct trans~nission and tlic Internet Group~Mcssagc Protocol (IGMP) for multicast traffic.Tlic messages defined in this protocol arc catcgorizcdas either crror or inhr~national, ~4th a family ofIiiessages in the second gl-0~1~ LISC~ to provide theNeighbor Disco\rcry Protocol."' Nciglibor ciisco\,erysen8es mi~ltiplc purposes \\,it11 tlic o\,crall theme ofpro\,iding a systc~n \\,it11 ropologicnl and cn\,ironmcntalhints. For csnmplc, link-la\rcr addrcss resolution,router discovcr\l, destination addrcss redirection, 2ndaddrcss autoconfigurntio11 mechanisms arc a11 specifiedusing neighbor disco\,cry packct ~ pcs.Although thc ncn\,ork Inycr did experience the largestamount of change, Fig~~rc 2 sho\\,s tliat the effects ofthis \\fork touch nearly all aspects of the Digital UNISsystem. IiVc point out csamplcs ofdecisions made due toour fi~nda~~~c~lt;~l design pllilos~phy, \\,liicli is bascdupon integration \\lit11 tlic UNIX system framc\\,ork,modular and cstcnsiblc sohvarc, support for m~~ltipleoperational policies, and a dcsirc to take advantage ofthe Alpha platti)nn \vitliout compromising portabiliq.In the follo\ving sections, bvc study these topics indepth, beginning with tlic nct\vork laycr, then coveringthe transport laycr modifications and the newneighbor discovery algorithms. Aticr that, wc discussaddress autoconfiguratio~i mechanisms and theireffects upon tlic system. We concludc with servicestliat will be affcctcd by the transition ti-om IPv4 toIPv6 SLICII as thc socltct application progra~nrninginterface (API) nncl DNS.COMMANDSUSER....................KERNELFigure 2Base Platform ChangesNetwork LayerI LINK-LAYERMODULESIAND NEIGHBORIn this section, \ve review the processing rcquircmcntsof the IPv6 modules, including lli-st\.lc nctnlaslu,from Classless Inter-Do~iiain Routing), \\,liich ,11-cappropriate to botli Ih.4 and IP\,G.'? Wc ha\r alsotried to take rnasi~ni~m aditantage of the 64-bit Alphaarchitecture \\,hen i~nplementing 11'\.6, \\,liilc ~naltingcertain that this implementation \\,auld run on 32-bitCPUs as \veil. For csaniplc, the cliccksi~m routinesoperate on 32-bit quantities (~llo\ving the carry too\,erflo\\~ into the upper 32 bits of a 64-bit rcgistcr).The checlzsum routine is also designed to allo\\l it to bcissued to multiple Alpha csccution units, \\,hichremains a topic for fi~rther in\rcstigation.Adaptations to Existing IP and ICMP RoutinesThe IPv6 and ICMPv6 routines arc completelyindependent of the corresponding IPv4 and ICMPv4routines, and tlie processing styles have distinct differences.In IPv6, the incoming packet is treated as bci~lgread-only, \vhile the BSD Il'v4 code ~iianipulatcs f cldswithin the Ih4 heaclcr. We also avoici unnecessary useof the 111-pullup routine (\\~liicli co~isolidatcs chainedmemory b~rff2rs into a single large buffer) bccnl~sc thiscould cailsc the packet to bc nccdlcssl!. lost. Fin~ill!?,instead of passing nulmerous arguments \\,hen callingfro111 hnction to fi~nction, a comliion data structure isDigital Technical Journnl 1'01. 8 So 3 I996 7
- Page 1: IINTERNET PROTOCOL V.6DigitalTechni
- Page 6 and 7: lie! elements of the protocol,Digit
- Page 10 and 11: ~~scd to store Iicccssar!z ciata an
- Page 12 and 13: packets, \\,hilt the latter avoids
- Page 14 and 15: * Test address for IPv4 characteris
- Page 16 and 17: ROUTER SOLICITATIONTYPECODECHECKSUF
- Page 18 and 19: 7 .ncn\.orlt. The solution is to al
- Page 20 and 21: AUTOCONFIGURATIONPROCESSINGUSER SPA
- Page 22 and 23: pilssing tlic olx~i x)ckcts to them
- Page 24 and 25: James P. BoundJIII~ Bol~nd 15 ,I co
- Page 26 and 27: process of restoring a p;~rtic~~I~r
- Page 28 and 29: Table 2 (continued)Year Item Descri
- Page 30 and 31: Table 3Goals of the Australian Digi
- Page 32 and 33: fidelity, tlic tcst of \\~liicli is
- Page 34 and 35: An important consideration is that
- Page 36 and 37: Table 8Architectures Implemented by
- Page 38 and 39: ucoder~ novaNOVA simulator V2.2bsim
- Page 40 and 41: BiographiesMaxwell M. BurnetMax Bur
- Page 42 and 43: no\\. tli;it appropriate stantlards
- Page 44: High Perfor~nance Fortran V1.l is c
- Page 47 and 48: 5. For ca;i~i~l~lc scc /'I.OC.CY'L/
- Page 49 and 50: tllc s\,stcIn under test to use the
- Page 51 and 52: WAREHOUSEW.89,0.000089'WDISTRICTW'1
- Page 53 and 54: III 8-CPU. 8-GB 8-CPU, 8-GB II -II
- Page 55 and 56: ~ILI~LIC. In othcr \\.orcis, the gr
- Page 57 and 58: ~norc to ~ I ~ S L Ithe I . ~ ~.cj>
- Page 59 and 60:
13. 1)igital Eqi~ip~ncnt Corporatio
- Page 61 and 62:
TPC-C Benchmark7 -.I. lie TPC-C bcn
- Page 63 and 64:
Lock OptimizationL,ocl
- Page 65 and 66:
DATABASE CACHE SIZE IN GBFigure 2Ua
- Page 67 and 68:
Engineering Group); Marl< Davis and
- Page 69 and 70:
H\,pcrtc\-t Transfer I'rotocol (HTT
- Page 71 and 72:
Grc~pliical objccts such as definit
- Page 73 and 74:
select box part of the toollcit pro
- Page 75 and 76:
work on it was limited, \ve divided
- Page 77 and 78:
Further ReadingsThc Digital Technic
- Page 79 and 80:
J. Iroccssor," PI-ocec~di7rg.i ?/'l
- Page 81 and 82:
B. Lce, E. Atnkov, and J. ClementM.
- Page 83:
Printcd in U.S.A. EC-N7285-18/9612