Sei sulla pagina 1di 498

IPAddressingFundamentals

ByMarkA.Sportack

IPAddressingFundamentals ByMarkA.Sportack Publisher: CiscoPress PubDate: October31,2002 ISBN: 1-58705-067-6 Pages: 368

Publisher:CiscoPress

PubDate:October31,2002

ISBN:1-58705-067-6

Pages:368

TableofContents |Index

ISBN: 1-58705-067-6 Pages: 368 TableofContents |Index

Thereader-friendlyexplanationofhowtheIPaddressspaceworksandhowitisused

Areader-friendlyintroductiontothecomplexandconfusingtopicofIPaddressing

ThoroughandunderstandableexplanationsofthebinarymathematicsbehindIPaddressing

CompletecoverageoftheIPv4addressspacewithoutdistractionsofroutingortransport

protocols

Detailedexplanationsofsubnettingandsupernetting,VariableLengthSubnetMasks(VLSMs),

CIDR,NAT,portableaddressspaces,andIPv6

StrategiesformanaginganaddressspaceforenterpriseWANs,datacenters,andISPs

Numerousexamplesandaneasy-to-readstyleofwritingthatimpartsaprofound

understandingofIPaddressing

TheInternetProtocol(IP)isthenativeprotocolsuiteoftheInternetandhasbecomepredominantinvirtuallyall

networksandinternetworks.ManaginganIPaddressspacerequiresasolidcommandofbinarymathematics,

particularlyasitisappliedwithintheIPaddressingarchitecture.ThemathematicsoftheIPaddressspace,however,

arenotintuitiveandcanbeverydifficulttograsp.Consequently,learningaboutIPaddressingcanbealotliketrying

topiecetogetherajigsawpuzzle-butwithoutknowingwhatthepuzzleissupposedtolooklike.

IPAddressingFundamentalsexplainssimplyandclearlyhowtheIPaddressspaceworksandhowitisused.Thisisa reader-friendlybookthatdetailsthefundamentalsoftheIPaddressspacefromthegroundup.IPAddressing Fundamentalsunravelsthemysteriesofsubnetting,supernetting,andCIDR;thoroughlyexplainsthebinary

mathematicsofIPv4'saddressingspace;anddemonstrateshowanIPaddressbecomesanactivecomponentinboth

networksandinternetworks.AuthorMarkSportackpreparesyouforreal-worldsuccessbywalkingyouthrough

someoftheissuesandtrapsthatlieinwaitforanyonewhoneedstoplanormanagetheuseofanIPaddress

space.Mostimportantly,thisbookdoesn'tpresumeyoualreadyknowwhattheentireIPaddressingpuzzlelooks

like.

IPAddressingFundamentalsimpartsaprofoundcommandofIPaddressingthroughaclearandconcisewritingstyle.

Basicsarereinforcedwithdetailedinformationandnumerousexamplesofhowtheconceptswork.Thisbookbuilds

uponconceptspresentedinearlierchaptersandconcludeswithfairlyadvancedtopicsthatwillbecomeincreasingly

usefultomidlevelnetworkengineers.

AfterreadingIPAddressingFundamentals,you'llfinallyunderstandIPaddressingandappreciatebothitsmechanics

andrelevance,andyou'llknowhowtoefficientlyapplyyournewknowledge.

IPAddressingFundamentals

ByMarkA.Sportack

IPAddressingFundamentals ByMarkA.Sportack Publisher: CiscoPress PubDate: October31,2002 ISBN: 1-58705-067-6 Pages: 368

Publisher:CiscoPress

PubDate:October31,2002

ISBN:1-58705-067-6

Pages:368

TableofContents |Index

Copyright AbouttheAuthor AbouttheTechnicalReviewers Acknowledgments Introduction IconsUsedinThisBook CommandSyntaxConventions PartI. IntroductiontoIPAddressing Chapter1. DevelopingtheInternet'sTechnologies TheInternet'sCaretakers TheInternetStandardsProcess TheBenefitsofOpenness Summary Chapter2. ClassicalIP:TheWayItWas EvolutionoftheAddressSpace TheAddressSpaceHierarchy Summary Chapter3. Fixed-LengthSubnetMasks IntroductiontoSubnetting

FormingSubnetsfrom24-BitNetworkAddresses

SourcesofInefficiencieswithFLSM Summary Chapter4. Variable-LengthSubnetMasks Variable-LengthSubnettingintheRFCs TheInefficienciesofFLSM APracticalApplication Summary PartII. TheEvolutionofIPv4 Chapter5. TheDateofDoom RespondingtotheCrisis InterimSolutions Summary Chapter6. ClasslessInterdomainRouting(CIDR)

CIDR:AnHistoricReview SymmetryofCIDRNotation Supernetting Summary Chapter7. PrivateAddressesandNAT PrivateAddressSpaces NAT ImplementationTopologies ProblemswithNAT Summary PartIII. AdvancedIPTopics Chapter8. InternetNames IntroductiontoInternetNames DNS:TheHierarchicalApproach NonstandardInternetNames Summary Chapter9. IPMulticasting TheConceptofMulticasting

IPv4MulticastingMechanisms

Summary PartIV. StrategiesforNetworkStability,Scalability,andPerformance Chapter10. NetworkingwithIP DissectingaTypicalCommunicationsSession DomainNameSystem TranslatingIPAddressesintoMACAddresses Summary Chapter11. InternetworkingwithIP TheMechanicsofRouting RoutingandtheInternet Summary Chapter12. NetworkStability TheProblemwith"Open"Networking

RFC2267,"SourceAddressAssurance"

AddressLendingforNetworkStability Summary Chapter13. PlanningandManaginganAddressSpace TheChallengeofManaginganAddressSpace AddressManagementIssuesforanEnterpriseWAN ISPAddressManagementIssues AddressManagementIssuesforanInternetHostingCenter Summary Chapter14. AddressManagementTactics TheChallengeofManaginganAddressSpace SequentialAssignment SequentialAssignmentwithGaps PredefiningwithSymmetricalGaps BalkanizinganAddressSpace

Summary

PartV. TheFutureoftheInternetProtocol Chapter15. IPv6:TheFutureofIPAddressing TheNeedforMore

OverviewofIPv6

AddressTypes

MoreMigrationTools

WhatAreWeWaitingFor?

Summary

Index

Copyright

Copyright©2003CiscoSystems,Inc.

CiscoPresslogoisatrademarkofCiscoSystems,Inc.

Publishedby:

CiscoPress

201West103rdStreet

Indianapolis,IN46290USA

Allrightsreserved.Nopartofthisbookmaybereproducedortransmittedinany

formorbyanymeans,electronicormechanical,includingphotocopyingand

recording,orbyanyinformationstorageandretrievalsystem,withoutwritten

permissionfromthepublisher,exceptfortheinclusionofbriefquotationsina

review.

PrintedintheUnitedStatesofAmerica1234567890

FirstprintingNovember2002

LibraryofCongressCataloging-in-PublicationNumber:2001093680

WarningandDisclaimer

Thisbookisdesignedtoprovideinformationaboutthefundamentalconceptsand

technologiesassociatedwithIPaddressing.Everyefforthasbeenmadetomake

thisbookascompleteandaccurateaspossible,butnowarrantyorfitnessis

implied.

Theinformationisprovidedonan"asis"basis.Theauthor,CiscoPress,andCisco

Systems,Inc.shallhaveneitherliabilitynorresponsibilitytoanypersonorentity

withrespecttoanylossordamagesarisingfromtheinformationcontainedinthis

bookorfromtheuseofthediscsorprogramsthatmayaccompanyit.

Theopinionsexpressedinthisbookbelongtotheauthorandarenotnecessarily

thoseofCiscoSystems,Inc.

TrademarkAcknowledgments

Alltermsmentionedinthisbookthatareknowntobetrademarksorservice

markshavebeenappropriatelycapitalized.CiscoPressorCiscoSystems,Inc.

cannotattesttotheaccuracyofthisinformation.Useofaterminthisbook

shouldnotberegardedasaffectingthevalidityofanytrademarkorservicemark.

FeedbackInformation

AtCiscoPress,ourgoalistocreatein-depthtechnicalbooksofthehighestquality

andvalue.Eachbookiscraftedwithcareandprecision,undergoingrigorous

developmentthatinvolvestheuniqueexpertiseofmembersoftheprofessional

technicalcommunity.

Readerfeedbackisanaturalcontinuationofthisprocess.Ifyouhaveany commentsregardinghowwecouldimprovethequalityofthisbook,orotherwise alterittobettersuityourneeds,youcancontactusthroughe-mailat feedback@ciscopress.com.PleasemakesuretoincludethebooktitleandISBN

(1-58705-067-6)inyourmessage.

Credits

Wegreatlyappreciateyourassistance.

Publisher

JohnWait

Editor-In-Chief

JohnKane

CiscoSystemsProgramManager

AnthonyWolfenden

ManagingEditor

PatrickKanouse

DevelopmentEditor

GrantMunroe

ProjectEditor

MarcFowler

CopyEditor

GayleJohnson

MarkGallo

TechnicalEditors

AlexKamantauskas

 

DaveKurtiak

MartinWalshaw

TeamCoordinator

TammiRoss

BookDesigner

GinaRexrode

CoverDesigner

LouisaKlucznik

ProductionTeam

Indexer

ProductionTeam Indexer CorporateHeadquarters CiscoSystems,Inc. 170WestTasmanDrive SanJose,CA95134-1706 USA

CorporateHeadquarters CiscoSystems,Inc.

170WestTasmanDrive

SanJose,CA95134-1706

Tel:408526-4000

800553-NETS(6387)

Fax:408526-4100

EuropeanHeadquarters CiscoSystemsEurope

11RueCamilleDesmoulins

OctalPublishing,Inc.

TimWright

92782Issy-les-MoulineauxCedex9

Tel:33158046000

Fax:33158046100

AmericasHeadquarters CiscoSystems,Inc.

170WestTasmanDrive

SanJose,CA95134-1706

Tel:408526-7660

Fax:408527-0883

AsiaPacificHeadquarters CiscoSystemsAustralia,Pty.,Ltd

Level17,99WalkerStreet

NorthSydney

NSW2059Australia

Tel:+61284487100

Fax:+61299574350

CiscoSystemshasmorethan200officesinthefollowingcountries.

Addresses,phonenumbers,andfaxnumbersarelistedontheCiscoWeb

Argentina•Australia•Austria•Belgium•Brazil•Bulgaria•Canada•Chile•

China•Colombia•CostaRica•Croatia•CzechRepublic•Denmark•Dubai,

UAE•Finland•France•Germany•Greece•HongKongHungary•India•

Indonesia•Ireland•Israel•Italy•Japan•Korea•Luxembourg•Malaysia•

MexicoTheNetherlands•NewZealand•Norway•Peru•Philippines•Poland•

Portugal•PuertoRico•RomaniaRussia•SaudiArabia•Scotland•Singapore•

Slovakia•Slovenia•SouthAfrica•Spain•SwedenSwitzerland•Taiwan•

Thailand•Turkey•Ukraine•UnitedKingdom•UnitedStates•Venezuela•

VietnamZimbabwe

Copyright©2000,CiscoSystems,Inc.Allrightsreserved.AccessRegistrar,

AccessPath,AreYouReady,ATMDirector,BrowsewithMe,CCDA,CCDE,CCDP,

CCIE,CCNA,CCNP,CCSI,CD-PAC,CiscoLink,theCiscoNetWorkslogo,theCisco

PoweredNetworklogo,CiscoSystemsNetworkingAcademy,FastStep,

FireRunner,FollowMeBrowsing,FormShare,GigaStack,IGX,Intelligenceinthe

OpticalCore,InternetQuotient,IP/VC,iQBreakthrough,iQExpertise,iQ

FastTrack,iQuickStudy,iQReadinessScorecard,TheiQLogo,KernelProxy,MGX,

NaturalNetworkViewer,NetworkRegistrar,theNetworkerslogo,Packet,PIX,

PointandClickInternetworking,PolicyBuilder,RateMUX,ReyMaster,ReyView,

ScriptShare,SecureScript,ShopwithMe,SlideCast,SMARTnet,SVX,

TrafficDirector,TransPath,VlanDirector,VoiceLAN,WavelengthRouter,Workgroup

Director,andWorkgroupStackaretrademarksofCiscoSystems,Inc.;Changing

theWayWeWork,Live,Play,andLearn,EmpoweringtheInternetGeneration,

areservicemarksofCiscoSystems,Inc.;andAironet,ASIST,BPX,Catalyst,

Cisco,theCiscoCertifiedInternetworkExpertLogo,CiscoIOS,theCiscoIOSlogo,

CiscoPress,CiscoSystems,CiscoSystemsCapital,theCiscoSystemslogo,

CollisionFree,Enterprise/Solver,EtherChannel,EtherSwitch,FastHub,FastLink,

FastPAD,IOS,IP/TV,IPX,LightStream,LightSwitch,MICA,NetRanger,Post-

Routing,Pre-Routing,Registrar,StrataViewPlus,Stratm,SwitchProbe,TeleRouter,

areregisteredtrademarksofCiscoSystems,Inc.oritsaffiliatesintheU.S.and

certainothercountries.

Allotherbrands,names,ortrademarksmentionedinthisdocumentorWebsite arethepropertyoftheirrespectiveowners.Theuseofthewordpartnerdoesnot

implyapartnershiprelationshipbetweenCiscoandanyothercompany.(0010R)

Dedications

Idedicatethisbooktomypreciouswife,Karen,forherunflaggingloveand

supportthroughoutthearduousprocessofdevelopingthisbook.I'llneverknow

whyyoutoleratemyeccentricitiesandavocationaldistractions,butI'm

perpetuallygrateful.

Ialsodedicatethisbooktomytwochildren,AdamandJennifer.Youhavebrought

joyandmeaningintomylifeinwaysIcan'texplain.

Ialsodedicatethisbooktomytwochildren,AdamandJennifer.Youhavebrought joyandmeaningintomylifeinwaysIcan'texplain.

AbouttheAuthor

Byday,MarkA.SportackistheDirectorofNetworkEngineeringforClearBlue Technologies.Bynight,heisanadjunctprofessorwithSyracuseUniversity's SchoolofInformationStudiesandTechnology,whereheteachesapairof graduatecoursesondatanetworking.Hisdaytimeresponsibilitiesinclude strategicplanningforthenetworksthatsupportthecompany'sInternetdata centers,researchandevaluationofemergingnetworktechnologies,specification ofthetechnologybaseforthenetworksthatthecompany'sInternet-based

managedhostingservices.Duringthecourseofthelast20years,Sportackhas

workedinvirtuallyeveryaspectofinformationtechnology,fromadministering

networksandserverstomanagingtechnologyandtechnicalpersonnel.Healso

haswrittenavarietyofbooks,includingIPRoutingFundamentals,publishedby

CiscoPress,NetworkingEssentialsUnleashed,andmanyothers.

IPRoutingFundamentals ,publishedby CiscoPress, NetworkingEssentialsUnleashed ,andmanyothers.

AbouttheTechnicalReviewers

MarkGalloisatechnicalmanagerwithAmericaOnline.Hisnetworkcertifications

includeCiscoCCNPandCiscoCCDP.Hehasledseveralengineeringgroups

responsiblefordesigningandimplementingenterpriseLANsandinternationalIP

networks.HehasaBSinelectricalengineeringfromtheUniversityofPittsburgh.

HeresidesinnorthernVirginiawithhiswife,Betsy,andson,Paul.

AlexKamantauskasisthehostmasterforClearBlueTechnologies,Inc.Hehas

workedinawidevarietyofpositionsintheInternetsectorsince1993,including

systemandnetworkengineering,networksecurity,andIPallocationservices.In

hissparetimehecomposeselectronicmusic.

DaveKurtiakisaprincipalengineerandDirectorofNetworkComputingServices forLoralSkynet,whereheleadsateamoftechnicalprofessionalsresponsiblefor

managingthecompany'sITanddatanetworkinfrastructure.Hehasmorethan14

yearsofexperienceintheITandtelecommunicationsindustries.Beforejoining

LoralSkynet,hewasaseniordatacommunicationsspecialistforAT&T.He

specializesinend-to-endnetworkanalysis,planning,andtroubleshooting.Kurtiak

isexperiencedinmanytelecommunicationstechnologies,includingEthernet,

switches,routers,VPN,point-to-pointdigitalfacilities,FrameRelay,andpremise

wiringtopologies.HeisalsorecognizedastheresidentexpertinTCP/IP

networking.Hehasamaster'sdegreeintelecommunicationsfromtheUniversity

ofColoradoatBoulderandabachelor'sdegreeininformationsystemsfromthe

UniversityofNorthCarolinaatGreensboro.

MartinWalshaw,CCIE#5629,CCNP,CCDP,isasystemsengineerworkingfor

CiscoSystemsintheEnterpriseLineofBusinessinSouthAfrica.Hisareasof specializationincludeconvergence,security,andcontentdeliverynetworking,

whichkeepshimbusybothnightandday.Duringthelast15yearsorso,hehas

dabbledinmanyaspectsoftheITindustry,rangingfromprogramminginRPGIII

andCoboltoPCsales.WhenWalshawisnotworking,helikestospendallhis

timewithhispatientwife,Val,andhissons,JoshuaandCallum.Withouttheir

patience,understanding,andsupport,projectssuchasthiswouldnotbepossible.

Acknowledgments

Iamindebtedtomanypeoplefortheirassistanceandsupportthroughoutthe

processofwritingthisbook.Thosepeopleinclude:

DavidKurtiak,AlexKamantauskus,MarcGallo,andMartinWalshawforinvesting

theirtimeandexpertiseastechnicaleditorstomakethisbookthebestitcanbe.

JohnKane,TammiRoss,GrantMunroe,andallthefolksatCiscoPressforhaving

enoughfaithinme(oristhatthebook?)toagreetoitsproduction,andfor

toleratingtheexcruciatingdelayscausedbyworldandbusinessevents.

JeffHarringtonforallowingmetheuseofhistechnicallibraryandreference

materials.

JeffHarringtonforallowingmetheuseofhistechnicallibraryandreference materials.

Introduction

IPAddressingFundamentalsisdesignedtoexplainhowtheIPaddressspace

worksandhowitisused.Manybookshelpyougainaworkingknowledgeofthis

topic,butnonecanhelpyoubothappreciatethewhybehindthetheoryandthe

howbehindtheapplication.Mygoalistodobothwiththisbook.

Theinspirationforthisbookcameasaresultofmyteachingexperiencesat

SyracuseUniversity.I'manadjunctprofessorinSU'sSchoolofInformation

StudiesandTechnology,whereIteachapairofgraduatecourseson

telecommunicationsanddatanetworking.Despitetheadvancednatureofthese

courses,andthetalentedstudentswhoareattractedtothem,Ifoundmyself

continuouslyastoundedatthelimitsoftheirworkingknowledgeofimportant

topicssuchasIPaddressing.Aftertwoyearsofcorrectingmisperceptions,asking

studentswheretheypickeduptheirmisinformation,andtryingtoshowthema

betterwaytounderstandtheInternet'saddressspaceandtechnologies,Ifound

myselfgettingfrustrated.JustwhenIstartedthinkingthatmaybeteachingwasn't

suchagoodidea,Ihadapairofexperiencesthaterasedmydoubtsandreplaced

themwithinspiration.

OneparticularlybrightyoungmanexplainedtomethatlearningaboutIPwasa

lotliketryingtopiecetogetherajigsawpuzzle.Theonlydifferenceswerethat

youdidn'tknowwhatthepuzzlewassupposedtolooklikewhenitwasfinished,

nordidyouhavethebenefitofapicturefragmentoneachpiece.Heappreciated

myapproachtoteachingIPandnetworking,becauseIgavethemthe"big

picture,"brokeitdownintosubtopicsthatwereeasiertograsp,andthen

correlatedthosesubtopicsbacktothebigpicture.Ahealthydoseofreality,inthe

formofexaminingthepracticalusesandimpactsofeachsubject,wasalso

injectedintoeachclass.Intheend,hesaidhenotonlyunderstoodthetopic,but

alsoappreciatedbothitsmechanicsandrelevance.

Theotherexperienceoccurredinthesamesemester.Onenightbeforeclass,a

studentapproachedmewithanewbookinhishands.Youcouldtellitwasanew

book,evenfromadistance:thatshiny,unmarredcover;thesmelloffreshink;

theuncrackedspineathingofbeauty!Butthelookonhisfacewasoneof

disappointmentandanxiety.ThebookwaswrittenbyaluminaryintheInterneta

foundingfatherwhohaswrittencountlessRFCsandhasbeeninstrumentalin

guidingtheInternet'sgrowthanddevelopment.Yetmystudentsaidthebookwas

disappointing.Isuggestedthatthebookshouldbetechnicallysolidgiventhe

achievementsofitsauthor.Hesimplyrepliedthatitwouldbeagreatbookifhe

couldunderstandit!Insteadofeducatingandinformingthereader,thisbook

causedanxietyandself-doubt.Mystudentwasaskingmyadviceonwhetherhe

wassmartenoughtosucceedinthisindustry.Ofcoursehewas,Iassuredhim.It

wasthebookanditsauthorwhohadfailed.

Thesetwoeventscrystallizedinmymindtheneedforthisbook.IcalledJohn Kane,Editor-in-ChiefatCiscoPress.Wehadalongchatabouttheneedfora reader-friendlybookthatexplainsthefundamentalsoftheIPaddressspacefrom thegroundup.Abookthatunravelsthemysteriesofsubnetting,supernetting,

andCIDR.AbookthatthoroughlyexplainsthebinarymathematicsofIPv4's

addressingspaceandshowsthereaderhowanIPaddressbecomesanactive

componentinbothnetworksandinternetworks.Abookthatpreparesyoufor

successbywalkingyouthroughsomeoftheissuesandtrapsthatlieinwaitfor

anyonedaringtoeitherplanormanagetheuseofanIPaddressspace.Most

importantofall,abookthatdoesn'tpresumethatyoualreadyknowwhatthe

puzzleshouldlooklikewhenitiscompleted.Thankfully,Johnandthefolksat

CiscoPressagreed.Ihopeyouenjoyit!

IconsUsedinThisBook

Throughoutthisbook,youwillseeanumberoficonsusedtodesignateCiscoand

generalnetworkingdevices,peripherals,andotheritems.Thefollowingicon

legendexplainswhattheseiconsrepresent.

Throughoutthisbook,youwillseethefollowingiconsusedforcommonnetwork

devices

legendexplainswhattheseiconsrepresent. Throughoutthisbook,youwillseethefollowingiconsusedforcommonnetwork devices

CommandSyntaxConventions

Theconventionsusedtopresentcommandsyntaxinthisbookarethesame

conventionsusedintheIOSCommandReference.TheCommandReference

describestheseconventionsasfollows:

Verticalbars(|)separatealternative,mutuallyexclusiveelements.

Squarebrackets([])indicateanoptionalelement.

Braces({})indicatearequiredchoice.

Braceswithinbrackets([{}])indicatearequiredchoicewithinanoptional

element.

Boldfaceindicatescommandsandkeywordsthatareenteredliterallyas

shown.Inactualconfigurationexamplesandoutput(notgeneralcommand

syntax),boldfaceindicatescommandsthataremanuallyinputbytheuser

(suchasashowcommand).

Italicindicatesargumentsforwhichyousupplyactualvalues.

(suchasa show command). Italic indicatesargumentsforwhichyousupplyactualvalues.

PartI:IntroductiontoIPAddressing

Chapter1DevelopingtheInternet'sTechnologies

Chapter2ClassicalIP:TheWayItWas

Chapter3Fixed-LengthSubnetMasks

Chapter4Variable-LengthSubnetMasks

Chapter1.DevelopingtheInternet'sTechnologies

Tomanytechnicalpersonneltoday,theInternetremainsamysterythatistaken

forgranted.Virtuallyeverybodyknowswhatitisandwhatitcanbeusedfor,but

fewactuallyknowwhatgoesonbehindthescenes.TheInternet'saddressspace

andnativeprotocolshavebecomethedefactostandardformanyaspectsof

networking.TheInternetProtocol(IP)addressspaceandthevariousIP-based

protocolsandmechanismshavebeenwidelydeployedaroundtheworld.Currently

theysupportmorenetworksthanjusttheInternet.Moreimportantly,these

technologiesandconceptsshareasimilarorigin:Typically,theyaredeveloped

andratifiedinanopenandconsensus-basedforum.

Itisthisconsensus-basedapproachtodevelopingtechnologiesthatcreatessuch

confusionamongnewcomerstotheInternet.Worse,theconfusionextends

beyondtheInternetandencompassesallitscomponenttechnologies,including

theIPaddressspace.Understandinganyofthesetechnologiesrequiresan

appreciationofthecontextinwhichitwasdeveloped,andasenseofwhatitwas

originallyintendedtodo.

ThischapterexploreshowtechnologiesareratifiedforuseintheInternet.Italso

looksatthevariousstandardsbodiesandotherorganizationsthatarethe

Internet'scaretakers.Thiswillhelpyoubetterappreciatewhatdoesanddoesnot

carrytheweightoflawontheInternet.

TheInternet'sCaretakers

Numerousorganizations,standardsbodies,andevencorporationsfunctionin

differentcapacities.AllofthemcontributeinsomewaytotheInternet.Some

allocatedomainnames(suchascisco.com)orassignIPaddressestothe

Internet'sendusers.OtherscreatethetechnologiesthatmaketheInternetwork

orthatletyouusetheInternet.AlltheseentitiesareintegraltotheInternet's

operation.We'lllookateachoneinthischapter,butonlyonecantrulybe

consideredtheInternet'scaretaker.ThatorganizationistheInternetEngineering

TaskForce(IETF).

IETF

ThemannerinwhichtheInternet'stechnologybaseisdevelopedandratified

mightnotbeintuitivelyappreciated.Infact,thearrangementisoneofthemore

unconventionalapproachesyoumayeverfind.Aswestarttoexplorejusthowit

operates,andhowstandardsandotherrecommendationsaredevelopedinthis

forum,you'llappreciatewhyIcallitunconventional.Nevertheless,itisamodel

thatworksusingbothcollaborativeandcompetitiveforces.

OneoftheuniquequalitiesoftheIETFisthatitconsistsalmostentirelyofunpaid

volunteers.Don'tmisunderstandthepoint;thesearehighlytechnicalandwell-

paidengineerswhocontributetheirtimetotheIETFinadditiontotheworkthey

dofortheiremployers.Suchvolunteersdon'tpayduestojointheIETF.They

simply"join"andeitherlurkinthebackgroundoractivelycontributetothework

beingperformed.

TheIETF,andthewayitoperates,canbetracedbacktothenascentdaysofthe

Internetwhenjustafewhostswereinterconnecteddirectlywithseriallines.In

thosedays,thetechnicalpersonnelresponsibleforsupportingthevarious

interconnectedhostsrealizedthattherewasgreatbenefittoworkingtogetherfor

thesakeofderivingconsistencyinnamingconventions,thetechnologybase,

communicationsprotocols,andguidelinesforusingtheirinternetwork.Lackinga

centralbudget,mission,oranyoftheothertrappingsofaconventional

organization,nothingcouldbedictated.Onlythemutualdesiretoimprovethe

functionalityoftheirinterdependentnetworkboundthemtogether.Everything

hadtomakesensefortheentirecommunitytoformaconsensus.Otherwise,

suggestionsandrecommendationsmightnotbeadopted.Thetechnical

communitysupportingthisearlyinternetwork(agroupofinterconnected

networks)formedalooseconfederationandcalledthemselvesanengineering

taskforce.Themonikerstuck.

Informalcollaborationandcommunicationworkedquitewellforanumberof years,andthentheInternetbeganitsexponentialgrowthstagetowardtheend

ofthe1980s.ThefirstofficialmeetingoftheIETFwasheldinJanuaryof1986

andwasattendedbyjust21people.Membershipandparticipationhaveincreased

steadilysincethenandnowencompassthousandsofpeople.AlthoughtheIETF

hasgrowntremendously,itsoriginalessenceremainsembodiedinthewayitis

organized.Today,technicalprofessionalsfromcompetitivecompaniesworkside-

by-sideundertheauspicesoftheIETFtodevelopandmaintaintheInternet's

technologybase.Itsmembershipisanever-growinggroupofhighlytalented

individualswhovolunteertheirtimetocollaborativelyengineerandevolvethe

Internet'stechnologybase.TheIETF'sworkinspellingouttheprotocol-level

detailsofnewtechnologies,aswellasmethodsandprocedures,ispublished

openlyinaseriesofdocuments,whichincludethefollowing:

Internetdraftsopenlyinaseriesofdocuments,whichincludethefollowing: RequestsforComments(RFCs) Internetstandards

RequestsforComments(RFCs)

InternetstandardsInternetdrafts RequestsforComments(RFCs) BestCurrentPractices(BCPs) FYIs(ForYourInformation)

BestCurrentPractices(BCPs)

FYIs(ForYourInformation)

Eachtypeofdocumentservesaspecificpurpose,andwe'lllookateachonein

detail.FirstweneedtoexaminethehierarchyoftheIETF.Thatwillhelpyou

betterappreciatetheinnerworkingsoftheIETFasitpertainstothedevelopment

andratificationofthesedocuments.AsweexploretheIETFinthischapter,you'll

noticehowitseverynuance,includinghowtheIETFisorganizedandfunctions,is

recordedinapubliclyavailabledocumentthatfitsintooneormoreofthe

previouslymentioneddocumentclasses.

NOTE

AlloftheIETF'sdocumentationispubliclyavailableonitswebsiteatwww.ietf.org.

ManyorganizationsareaffiliatedwiththeIETF,eachwithlooselydefined

responsibilities.Thesegroupsincludethefollowing:

InternetSociety(ISOC)InternetArchitectureBoard(IAB) InternetResearchTaskForce(IRTF) InternetAssignedNumbersAuthority(IANA)

InternetArchitectureBoard(IAB)

InternetResearchTaskForce(IRTF)

InternetAssignedNumbersAuthority(IANA)

InternetCorporationforAssignedNamesandNumbers(ICANN)

InternetEngineeringSteeringGroup(IESG)

WorkinggroupsInternetEngineeringSteeringGroup(IESG)

Eachoftheseorganizationsisfurtherexploredintheremainderofthissection.

ISOC

TheISOCisaninternationalnonprofitorganization.ItdiffersfromotherInternet

organizationsinthatitisnotasuborganizationoftheIETF.Itssolemissionisto

fosterthegrowthoftheglobalInternet.Itdoessoinfairlyabstractandless-than-

obviousways.Forexample,ittheoreticallyprovidesoversighttotheIETFandits

subcomponents,butthatoversightislimitedtofinancial,logistic,andlegal

support.Forexample,itprovidesinsurancecoverageforpeopleinvolvedinthe

IETF'sstandards-creationprocesses,anditfunctionsasapublicrelationschannel

wheneveranIETFentityneedstocommunicateviathepress.

PerhapsthemostvisibleoutputoftheISOCisthatitstrusteesratifytherules

andproceduresbywhichstandardsaredevelopedfortheInternetbytheIETF.

Thus,althoughtheISOCdoesn'tdirectlyshapetheInternetoritstechnology

base,itsetstherulesbywhichtheInternetevolves.

IAB

OneofthemorecriticalsubentitiesoftheIETFistheIAB.Originallyknownasthe

InternetActivitiesBoard,theIABhasevolvedandgrownovertimeinresponseto

changesintheInternet.Today,theIABisknownastheInternetArchitecture

Board.Itisresponsibleforlong-rangeplanningandcoordinatingactivitiesacross

thevarioussubcomponentsoftheIETF.Assuch,itisuniquelypositionedtosee

thebigpictureoftheIETF'scumulativeefforts.Partofitsrolemightbetobring

issuestotheattentionofspecificareadirectorsiftheythinkalong-termitem

requiressomeattention.

IRTF

TheIRTFissponsoredandoverseenbytheIAB.Thisgroupconductsresearchinto

emergingtechnologies,andthisresearchbecomesaninputtotheIAB'slong-

rangetechnologyplanningactivities.

IANA

TheIANAisresponsibleforkeepingtrackofallnumbersandnumericvaluesthat

mustbereservedorassignedforthevariousprotocolsandtechnologies

maintainedbytheIETFtoworkproperly.ThemostobviousexampleistheIP

addressspace(thesumtotalofallIPaddresses),butIANA'sresponsibilitiesalso

includemaintainingthelistofTCPandUDPstandardizedorwell-known

applicationportnumbers.

IANAisalsotheInternet'scoreregistrar.Thisdubiousdistinctionwasconferred

bytheIAB,anditmadeIANAthe"owner"oftherootoftheInternet'sname

space.Thisrolehasnotexactlyresultedinapositiveperceptionthroughoutthe

Internetcommunity,andunfortunatelyithasovershadowedsomeofIANA'sother

responsibilities.AlthoughIANAoncewasarelativelyautonomousentitywithin

theIETF,anditstillistechnicallychargedwithmaintainingalltheunique

parametersusedontheInternet(addresses,domainnames,andportnumbers)

today,IANAappearstobeslowlymeldingintoICANN.

ICANN

TheICANNisanonprofitcorporationthatwasestablishedtomaintainIPaddress

allocation,assignmentofprotocolparameters(suchasportnumbers),and

managementoftheInternet'sdomainnamesystem(DNS).Thesefunctionshad

previouslybeenperformedbyIANA,buttheyhavesincebeendelegatedto

ICANN.

Tocarryoutitsduties,ICANNhasformedthreefunction-specificsupporting

organizations(SOs):

AddressSupportingOrganization(ASO)

DomainNameSupportingOrganization(DNSO)

ProtocolSupportingOrganization(PSO)

ICANNfunctionsastherootoftheInternet'sdomainnamespaceandcharters bothregistriesandregistrars.Theregistryfunctionisdistributedbyregions aroundtheglobe.Itallowsaddressspacetobeparsedoutandmanaged regionally.SuchregistriesareknownasRegionalInternetRegistries(RIRs).

Therearethreeregistries,butsomecovermorethanoneregion.Table1-1lists

theregionsandtheirsupportingRIRs.

Table1-1.RIRsandTheirRegions

GlobalRegion

SupportingRIR

Europe

RIPENCC

Africa

ARINandtheRIPENCC

NorthAmerica

ARIN

MiddleEast

RIPENCC

LatinAmericaandtheCaribbean

ARIN

Asia-Pacific

APNIC

ARINstandsforAmericanRegistryforInternetNumbers.APNICstandsforAsia

PacificNetworkInformationCentre.RIPENCCisabittougherforNorth

Americanstograsp;itstandsforRéseauxIPEuropéensNetworkCoordination

Centre.

EachregistryisgivenablockofIPaddressesandisresponsibleforassigningand

managingthatspacewithinitsregion.Twoothergeographicregionshave

announcedplanstoformtheirownRIRs:AfricaandLatinAmerica.ICANNisthe

onlyentitythatcancharteranRIRandassignitanaddressspace.

WithineachRIR'sregion,otherentitiescanapplytobecomeLocalInternet

Registries(LIRs),muchlikeanInternetServiceProvider(ISP)canassignaddress

blockstoitscustomers'operationalnetworks.

Registrars,ontheotherhand,areresponsibleformanagingtheassignmentof Internetdomainnames.Thisisamuchmorecontentiousissuethanmerely parsingoutnumbers.Don'tworryjustyetaboutwhydomainnamescanbe

contentious;we'llcoverthatindetailinChapter8,"InternetNames."Fornow,it

isenoughthatyoujustappreciatetheacronyms,roles,andresponsibilitiesofthe

variousbodiesthatregulatetheInternet'sgrowth,evolution,andoperation.

variousbodiesthatregulatetheInternet'sgrowth,evolution,andoperation.

TheInternet'sRegistriesandRegistrarsbyAlexKamantauskas

ThetopicofregistriesontheInternetcancausesomeconfusion.Therearemultiple"registries"asa

directresultofthebreakupoftheNetworkSolutionsmonopolyondomainnames.Priortotheadventof

ICANN,NetworkSolutionsfunctionedasboththeregistryfordomainnames(theentityresponsiblefor

makingsuretherootserverswereupdated,thewhoisserversweremaintained,andsoon)andthe

registrar(thepointofcontactinthetradingofdomainnamesasacommodity).Whencompetitionwas

introducedintothedomainnamemarket,NetworkSolutions(andnowVeriSign)maintainedtheregistry

function,andtheregistrarfunctionwassplitamongthevariouscompetingcompanies,includingNetwork

Solutions.Thatcompanywasbothregistryandregistrarforawhile,butIassure,youtheydidn'tplay

favorites.Inordertobecomeanaccreditedregistrar,youhadtoagreetoandusetheNetwork

Solutions/VeriSignregistry.

However,todaythedistinctionbetweenregistryandregistrarisgrowingfuzzierwiththeadventof

sponsoreddomainnames.Forinstance,NeuLevelisnowtheregistryforthe.bizdomainname.It

providesregistryservicesforthedomainnameforregistrarsthataresellingnamesinthe.bizspace.

So,nowyouhavetheregistryforInternetnumbers,multipleregistriesforInternetnames,and

competingregistrars.

IESG

TheInternetEngineeringSteeringGroup(IESG)providestechnicalmanagement

ofallIETFactivities,aswellasitsstandards-developmentprocess.TheIESG

consistsofareadirectors,eachofwhicharenominatedbytheIETF'snominations

committeeandserveatwo-yearterm.Theareadirectorsoverseeaspecific

technicalarea.Currentareasincludethefollowing:

Applicationstechnicalarea.Currentareasincludethefollowing: General Internet OperationsandManagement Routing Security

Generaltechnicalarea.Currentareasincludethefollowing: Applications Internet OperationsandManagement Routing Security Transport

InternetApplications General OperationsandManagement Routing Security Transport

OperationsandManagement

RoutingApplications General Internet OperationsandManagement Security Transport UserServices

SecurityApplications General Internet OperationsandManagement Routing Transport UserServices

TransportApplications General Internet OperationsandManagement Routing Security UserServices

UserServicesApplications General Internet OperationsandManagement Routing Security Transport

Theseareascorrelatealmostperfectlywiththefunctionalareasoftheworking

groups,whicharedescribedinmoredetailinthenextsection.Theonlyexception

istheGeneralArea,whichexistsasacatchallmechanismfortheIESG.Notmany

initiativesfallintothiscategory,butthosethatdocanbeassignedtowhichever

areaorareasaredeemedappropriate.

It'simportanttonotethattheoversightoftheIESGanditsareadirectorsdoesn't

extendtodirectoversightoftechnicaldevelopmentefforts.Instead,oversightis

construedasratifyingtheoutputoftheworkinggroups.Thus,theIESGcanexert

influenceonwhetheranyparticularproposaladvancestothepointwhereitcan

beimplemented.Typically,theIESGacceptstherecommendationsofworking

groups,butitcanrejectarecommendationifitbelievesthegrouphaseither

strayedfromitscharterorhasrecommendedsomethingthatwillhaveanadverse

effectontheInternetanditstechnologybase.

WorkingGroups

Thedetailworkofdevelopingspecifictechnicalsolutionstospecifictechnical

problemsisperformedbytransientorganizationswithintheIETFknownas

workinggroups.TheIETFhassoughttocreateacontinuityoftechnicalexpertise

inworkinggroupsbyorganizingthemintofunctionalareas.Eachfunctionalarea

isdirectedbyanIESGareadirector.Anareacanhavemultipleworkinggroups

operatingsimultaneously,focusedonextremelyspecificactivities.Itisimportant

tonotethattheseareasdonotnecessarilytranslatecleanlyintoareasrecognized

bytheIESG.Considerthisimperfectcorrelationbetweenworkinggroupsand

IESGareas;afeaturethatenablesflexibility,asopposedtoaflawwhichpromotes

confusion.Theoutputofanygivenworkinggroupmaybereviewedbymultiple

IESGareadirectorstoobviatepotentialconflictingtechnologiesor

recommendations.

Currently,theIETFhasactiveworkinggroupsinthefollowingfunctionalareas:

ApplicationsBroadlydefinedasthingsthatuseIPnetworksandsecurity

mechanisms,butexcludingallsecurityandnetworkmechanisms.Applications

thatrequirenetworkconnectivityrelyonwell-definedinterfacestothe

transportandnetworklayerprotocols,andthatbecomesthebailiwickofthe

ApplicationsAreaworkinggroup.

InternetTheInternetAreaencompassesdevelopingmechanismsand

capabilitiesforIPitself.Forexample,developingtheabilityforIPtobe

transportedovernewnetworktechnologiessuchasInfiniBand,FibreChannel,

andcablenetworksliesinthisfunctionalarea.

OperationsandManagementAnythingthatdefineshowthingsoperateis

theresponsibilityoftheO&Mfunctionalarea.Generallyspeaking,anything

involvingSimpleNetworkManagementProtocol(SNMP),Management

InformationBase(MIB),oroperationofservicesisdonewithintheO&Marea.

Specificexamplesofactiveworkinggroupsinthisareaincludeagroup

investigatingtheextensionofSNMPagents,DomainNameServer(DNS)

operations,andtheevolutionofSNMP.

RoutingTheRoutingfunctionalareaistightlyfocusedonroutingprotocols.

SometeamsactiveinthisareaarelookingattheRoutingInformation

Protocol(RIP),OpenShortestPathFirst(OSPF)routingprotocol,andthe

developmentofavirtualrouterredundancyprotocol(VRRP).

SecuritySecurityisfairlyself-evident,inthattheteamsinthisareafocuson

improvingtheauthentication,privacy,andsafetyofnetworkedcomputing

assetsanddata.Securityteamsarecurrentlyworkingonsuchthingsasthe

creationofanXML-based(extensiblemarkuplanguage)digitalsignatureand

anopenversionofPrettyGoodPrivacy(PGP)encryptionsoftware,among

others.

Sub-IPTheSub-IPAreaisoneofthehardestareastodescribe.Atleast,I

haveadifficulttimeunderstandingwhatdifferentiatesitfromtheInternet

functionalarea.Substantialoverlapbetweenthetwogroupsisevidentwhen

youconsiderthattwoofthecurrentlyactiveSub-IPgroupsaredeveloping

thespecificationsforIPoveropticalfacilitiesandMultiprotocolLabel

Switching(MPLS).

TransportTheTransportfunctionalareafocusesondevelopinginterfacesfor

higher-levelprotocolsandservices.Someofthespecificareasofcurrent

activityincludeIPTelephony,IPStorage,DifferentiatedServices(DiffServ),

andaudio/videotransport.

UserServicesAnythingthatdefineshowpeoplewantthingsdoneacrossa

network.ThisgrouptendstofocusondevelopingFYIsinsteadofRFCs.(If

theseacronymsdon'tmeananythingtoyou,keepreading.We'lllookatall

theoutputsofthevariousIETFsubentitiesinthenextsection,"TheInternet

StandardsProcess.")Thisgroupalsohelpsusersofalllevelsimprovethe

qualityofinformationavailableontheInternet.Thatmightsoundabitvague,

butyoucanthinkofitthisway:TheUserServicesgroupismoreofa

communicationsvehiclefortheIETFthanatechnologydevelopmentgroup.

Ifthesecategorizationssoundabitsoft,anditseemsthereisgreatpotentialfor

overlap,you'reright.Manyspecifictechnicalproblemsareworkedonjointlyby

twoormoreworkinggroups.Membershipinaworkinggroupisvoluntary.

Ifthenotionofjoiningaworkinggroupandhelpingdevelopnewstandardsfor theInternetappealstoyou,doyourselfandeveryoneintheIETFafavor,and

readRFC3160.Entitled"TheTaooftheIETF,"thisdocumenthelpsyoubetter

understandtheorganization,itsculture,andeverythingabouttheworkit

produces.TheURLiswww.ietf.org/rfc/rfc3160.txt

understandtheorganization,itsculture,andeverythingabouttheworkit produces.TheURLis www.ietf.org/rfc/rfc3160.txt

TheInternetStandardsProcess

ThewaythattechnicalstandardsaredevelopedfortheInternetmightseem arcanefromtheoutsidelookingin,butthisprocessiseminentlylogical,andit hasservedtheInternetwellforyears.ThisprocessisdocumentedintheIETF's

RFC2026,whichisalsocurrentlytheInternet'sBCP#9.Thisdocumentcanbe

IfthetermsRFCandBCParealientoyou,readon.Theremainderofthischapter

isdevotedtohelpingyouunderstandtheinnerworkingsofthisvitalfunction.The

rolesofInternetdrafts,RFCs,STDs(standards),andBCPsareallexploredand

explained.

InternetDraft

VirtuallyeverystandardpublishedbytheIETFstartsoutasanInternetdraftorI-

DorjustplaindraftinIETFparlance.Adraftcanbesubmittedbyanindividualor

canbetheproductofaworkinggroup.

ThedraftitselfconformstothetemplateusedforallRFCs,whichonlyaddstothe

terminologyconfusion.BecausetheRFCsarepublicdocuments,virtuallyanyone

intheworldcanreviewthemandmakecommentstotheauthor(s)for

consideration.Ifappropriate,thedocumentmightbesupersededbyamodified

version,oritmightdieaquietdeathifitfailstoresonatewithintheInternet

community.Ifitdoesfindsomesupport,thedocumentcaneitherbecome

embracedasadefactostandardorundergothemorerigorousstandardization

process.Theremainderofthischapterexaminesallthedocumenttypesthatthe

IETFrecognizes.Thenwe'lllookattheinnerworkingsofthatorganization's

consensus-basedstandardsadoptionmechanisms.

RFCs

ThemostcommonlyencounteredIETF-produceddocumentistheRFCs.These

documentsaren'tnecessarilyjustrequestsforcomments.Infact,manyofthem

containthespecificationsforprotocolsandtechnologiesthatareembracedas

standardsorbuiltasproducts.Inotherwords,manyRFCshaveprogressedwell

beyondthedevelopmentstagewherecommentsarebeingsolicited.Thus,thefull

nameisactuallyamisnomer.Forthisreason,RFCsofalltypesarealmostalways

referredtoassimplyRFCs.

NOTE

AlthoughthearcanenatureandnomenclatureofRFCsmightbediscouraging,rest assuredthatsomeofthesedocumentsarequiteuseful.E-mail,asubiquitousan

applicationasyoucouldhopetofind,wasfirstdescribedinRFC821.Similarly,

DNSoriginatedinapairofRFCsnumbered1034and1035.So,yousee,theycan

bequiteuseful.

TherearesixdifferenttypesofRFCs.Eachgoesthroughaslightlydifferent

processduringitsjourneytowardratification:

Proposedstandardsprocessduringitsjourneytowardratification: Draftstandards Internetstandards Experimentalprotocols

Draftstandardsprocessduringitsjourneytowardratification: Proposedstandards Internetstandards Experimentalprotocols

InternetstandardsProposedstandards Draftstandards Experimentalprotocols Informationaldocuments

ExperimentalprotocolsProposedstandards Draftstandards Internetstandards Informationaldocuments Historicstandards

InformationaldocumentsDraftstandards Internetstandards Experimentalprotocols Historicstandards

HistoricstandardsExperimentalprotocols Informationaldocuments

Ofthesesix,onlythefirstthreequalifyasstandardswithintheIETF.Thus,itis imperativetounderstandthatRFCsarenotcreatedequal.Somearesolidenough tohaveproductsdesignedaroundthem,andothersarenotintendedforuse otherthantosolicitcommentsortestforinterestinanemergingtechnology.For amuchmorecompletesummaryofthedifferencesbetweenthevarioustypesof

RFCs,refertoRFC1796,"NotallRFCsareStandards."Youcanfinditat

Justtoprovethatthingscangetevenmorecomplicated,therearealsothree

subseriesofdocumentswithintheRFCarchitecturestandards(STDs),Best

CurrentPractices(BCPs),andForYourInformation(FYI)documents.Eachis

describedinthefollowingsections.

InternetStandards

TherearethreetypesstandardstheProposedStandard,theDraftStandard,and

theInternetStandard.RFCsthatareplacedonthestandardstrackfirstbecome

ProposedStandards.Aftersixmonthsinthisstatus,suchRFCsmightundergo

additionalscrutinyandbesanctionedasDraftStandards.Evenmorescrutinyis

requiredforaDraftStandardtoberatifiedasanInternetStandard.Internet

StandardsareoftenknownasFullStandards,buttherearen'tverymanyof

them.Infact,moststandards-trackdocumentsnevermovebeyondProposed

Standard.Thatdoesn'tmeantheyaren'tuseful.Infact,manyprotocolsand

productsarebuiltaroundProposedStandards.Theexplanationforastandard's

inabilitytomovetoDraftandthenFullStandardmightsimplybearesource

issue:Onlysomanypeoplecanmakemeaningfulcontributions.Engineerswho

developaProposedStandardmightsimplyfindthemselvesdrawnintoother

initiativesbeforetheycanadvanceaProposedStandardanyfurther.Pleasedon't

misconstruethataslazinessoranythingofthesort.AdvancingProposed

Standardsiscomplex,time-consumingwork.Infact,itcantakeseveralyearsof

workbeforeaDraftStandardcanbecomeaFullStandard.Theamountofeffort

requiredtomakethishappenlimitsthenumberofRFCsthatbecomeFull

StandardstojustthosefewprotocolsthatareabsolutelyessentialfortheInternet

tofunction.

WewillexaminetheIETF'sapprovalprocessformovinganRFConthestandards

trackthroughthevariousstandardstagesinamoment.

BCPs

AsubsetoftheRFCseriesisknownastheInternet'sBestCurrentPractices

(BCPs).ThissubsetdiffersfromthetechnicalspecificationsoftenfoundinRFCs.

BCPsspecifyoperatingproceduresthatareconsensuallyagreedtobethebestfor

theInternet.Alternatively,aBCPcanbeusedtodescribehowtoapplythe

varioustechnologiesdescribedinotherIETFdocuments.Someoftheexamplesof

BCPspresentedinthischaptershouldgiveyouagoodideaofthetypeofcontent

thatcanbefoundinaBCP.

FYIs

TheFYIsubseriesofdocumentswascreatedtopresentinformationsuchasbig-

pictureoverviewsofhighlytechnicaltopics.Suchoverviewsprovideacontext

withinwhichmuchmorespecificRFCsadddetail.OtherusesoftheFYIdocuments

aretointroduceatopicorotherwisepresentinformationthatisperceivedtohave

broadappeal.WorkinggroupswithintheIETF'sUserServicesAreausually

producethistypeofdocument.

ApprovalProcess

TheprocessbywhichaproposalprogressesthroughtheIETFonitswayto

ratificationcanbetime-consumingandarduous,butitfollowsafairlydistinct

pattern.AproposalisfirstfloatedasanInternetdraft.Commentsarereceived,

andthedraftiseditedaccordingly.Thiscanbeaniterativeprocess,asopposedto

achievingcompletioninasinglepass.Ifanindividualcreatedthedraft,that

personmightrequestthatanareadirectortakethedocumenttotheIESGfor

reviewandconsideration.Ifaworkinggroupcreatedthedocument,the

chairpersonofthatgrouptakesit(afterachievingconsensusinthegroup,of

course)totheareadirectorforforwardingtotheIESG.Eitherway,theIESGmust

reviewitinthelargercontextofexistingstandardsandfuturedesiredtechnology

directions.IfanychangesaredeemednecessarybytheIESG,thedraftgoesback

toitscreator(s)forfurtherwork.Whenthereisconsensusamongthedocument's

creators,areadirector,andIESG,thedraftcanbepublishedasanRFC.

Itisimportanttonotethatadditionallayersofchecksandbalancesexistinthe

approvalprocess.Forexample,iftwoormoreareadirectorsobjecttoanInternet

draft,itisblockedfrombecominganRFC,anditcan'tbecomeastandard.This

vetopowerensuresthatatechnologydoesn'tgetratifiedthatwillhave

unacceptableimpactsonothertechnologies.Thisiscriticaltoensuretheongoing

stabilityoftheInternet'sopenprotocolsandtechnologies.

Anothercheck-and-balancemechanismisthe"lastcall."Afteradraftissubmitted

totheIESG,anIETF-wideannouncementismadetoensurethatnothingcan

escapeanyone'snotice.Inthismanner,commentsmaybesolicitedfrompeople

and/orgroupswhoweren'tfollowingaparticulardraft'sdevelopment.Such

groupsincludetheISOC,IRTF,IAB,andevenotherareadirectorsorworking

groups.Anyandallofthesepartieshavetheopportunitytosubmitcomments,

concerns,andquestionstotheworkinggroupresponsibleforthedocument.

Afterallpartieshavehadachancetoexaminethedraft(anditsimplications),the

IESGmightdecidetosanctionthedraftasanInternetStandard.Ifthatisthe

case,thedraftstillhassomehurdlestoovercome.TheIESGrequeststhatthe

editoroftheRFCs(aformalpositionwithintheIETF)publishthedraftasa

ProposedStandard.IthasstatusasanumberedRFC,butitisalsoexplicitly

identifiedasaProposedStandard.Aftersixmonths,theauthor(s)ofthatRFCcan

asktheirareadirectortoapproveitasadraftstandard.Thisisahighhurdleto

overcome.Thetechnologymustbeprovenbyatleasttwoindependent

implementationsthatdemonstratenotonlyinteroperabilitybutalsovalidationof

theconcept'sbenefits.

Asmentionedearlier,itishighlylikelythataproposedstandardwillnevermake

ittofullInternetStandardstatusandyetwillstillachievebroadacceptanceinthe

market.ThiscanbeoneofthemoreconfusingaspectsoftheIETF'sstandards-

settingprocess.ButifanRFCmakesitallthewaytoFullStandard,youcanrest

assuredithasbeenthoroughlyexaminedandtested.Ofcourse,thisisnota

guaranteethatallproductswillworkperfectly.Itjustmeansthatthevarious

companiesthatimplementtheRFCstartwithastablebasebutarefreeto

interpretitaccordingtotheirneeds.Thenextsectionexplainsthisphenomenon

andsomeofitsunintendedconsequences.

NOTE

ThereisapersistentandpervasivemisperceptionamongInternetusersthatRFCs

arethelawsoftheInternet.Insomecases,suchasRFCsthatareBCPsorSTDs,

thatmightbeagoodanalogy.Butinthevastmajorityofcases,RFCsarelittle

morethanideasfloatedpubliclytosolicitcomments.Nooneisobligatedto

complywithanRFC,noristhereanypenaltyfornoncompliance.

morethanideasfloatedpubliclytosolicitcomments.Nooneisobligatedto complywithanRFC,noristhereanypenaltyfornoncompliance.

TheBenefitsofOpenness

Makingpubliclyavailablestandardsdocumentsthatstipulateeverynuanceofa

technologyisknownasopenstandards.Openstandardsoffertremendousbenefits

thathavebeenproventimeandagainsincetheintroductionofthisconcept.In

thedaysbeforetheInternet,thepreviousparadigmwastightlyintegrated

proprietaryplatforms.Inotherwords,everyaspectofanetworkedcomputing

architecture(includingendpointdevices,cableinterfaces,computingplatforms,

operatingsystems,applications,andprinters)wastightlylinkedbythe

manufacturers.Youcouldn'tmixandmatchcomponentsfromdifferent

manufacturers;youhadtoselectonevendorforallyourneeds.

Thebenefitshaveprovenverycompelling.Competitionhasleveledtheplaying

field,priceshavedropped,andmanufacturershavecontinuedtoinnovateinorder

todevelopmeaningful(albeittemporary)advantagesovertheircompetitors.The

Internetstandards-settingprocessisoneofthewaysinwhichtechnologiescanbe

eitherdevelopedoutintheopenor,ifdevelopedprivately,grantedopenness.

CompetitiveAdvantagesofOpenness

AlthoughtheInternet'sstandards-settingprocessmightseemveryaltruistic,

especiallybecausevirtuallyalltheIETF'smembersarevolunteers,youneedto

rememberthatthingsarenotalwaysastheyfirstappear.JoiningtheIETF,orany

ofitsfunctionalcomponents,asavolunteercanrepresentasubstantial

commitmentoftimeandeffort.BecausetheIETFdoesn'tpaynetworkengineers

fortheseefforts,andmostnetworkengineersaren'tindependentlywealthy,it

standstoreasonthatsomeonemustfundorsubsidizetheirinvolvement.Usually,

thatistheengineer'semployer.

Sotheobviousquestiontoaskis"What'sinitfortheemployer?".Whywouldany

companyfundorsubsidizeanyone'sinvolvementintheIETF?Theansweris

remarkablysimple:Theyhaveavestedinterestintheoutcomeofthe

proceedings.Itisquitecommonforacompanytodevelopaproprietary

technologyandthenseektolegitimizeitsstandingintheInternetcommunityby

presentingthetechnologytotheIETFintheformofanRFC.Aworkinggroup

mightormightnotthenberequiredtoexaminetheproposalorRFCinmore

detailanddeterminewhat,ifany,changesarerequiredtomaketheproposal

moreacceptable.Othercompaniesalsobenefitfromparticipatinginthattheyget

the"insidetrack"onemergingtechnologiesthatmightormightnotbecome

approvedforuseontheInternet.

Atthispoint,youmightbewonderingwhyanycompanythathasdevelopeda

greatnewtechnologywouldwanttogiveitawaytopotentialcompetitorsby

publishingitstechnicalspecificationsasanopenstandard.Wouldn'tthecompany

bebetteroffjustkeepingthetechnologyforitselfinsteadofcreatingcompetition?

Theanswerisaresoundingno.Consumersofinformationtechnologiesallbut

demandopentechnologies.Thus,atechnologymanufacturerwouldfindamuch

largerpotentialcustomerbaseawaitinganopen-standardsproductthanitwould

foraproprietaryproduct.Anotherbenefitisthatthecompanyhasadistinct

advantageoverothercompanies.Simplystated,ithasalreadydevelopedits

product,anditcanstartsellingitlongbeforeothercompanies,whichhaveto

startfromscratch.

CreatingProprietyThroughOpenness

Thefinalnailinthecoffinofaltruismisfoundinhowsomecompaniesmanipulate

theprocessofopen-standardsdevelopment.RFC2119,alsoknownasBCP#14,

spellsoutacceptablelanguagetouseinanRFCorsimilardocumentusedto

definenewopenstandardtechnologies.Acceptablewordingdescribingafunction's

criticalityincludesthefollowing:

MUSTcriticalityincludesthefollowing: MUSTNOT REQUIRED SHALL SHALLNOT SHOULD SHOULDNOT RECOMMENDED

MUSTNOTcriticalityincludesthefollowing: MUST REQUIRED SHALL SHALLNOT SHOULD SHOULDNOT RECOMMENDED MAY

REQUIREDcriticalityincludesthefollowing: MUST MUSTNOT SHALL SHALLNOT SHOULD SHOULDNOT RECOMMENDED MAY OPTIONAL

SHALLcriticalityincludesthefollowing: MUST MUSTNOT REQUIRED SHALLNOT SHOULD SHOULDNOT RECOMMENDED MAY OPTIONAL

SHALLNOTcriticalityincludesthefollowing: MUST MUSTNOT REQUIRED SHALL SHOULD SHOULDNOT RECOMMENDED MAY OPTIONAL

SHOULDMUST MUSTNOT REQUIRED SHALL SHALLNOT SHOULDNOT RECOMMENDED MAY OPTIONAL

SHOULDNOTMUST MUSTNOT REQUIRED SHALL SHALLNOT SHOULD RECOMMENDED MAY OPTIONAL

RECOMMENDEDMUST MUSTNOT REQUIRED SHALL SHALLNOT SHOULD SHOULDNOT MAY OPTIONAL

MAYMUSTNOT REQUIRED SHALL SHALLNOT SHOULD SHOULDNOT RECOMMENDED OPTIONAL

OPTIONALREQUIRED SHALL SHALLNOT SHOULD SHOULDNOT RECOMMENDED MAY

Thesewordsareintentionallycapitalized,astheyareinthevariousIETF

publications,toindicatecompliancewiththeirdefinitionsinRFC2119/BCP#14.

Thisisn'taverylongordifficult-to-readdocument.Itshouldbeoneofthefirst thingsyoureadasyoustarttofamiliarizeyourselfwiththeworksoftheIETF,

includingtheIPaddressspace.Itcanbefoundatwww.ietf.org/rfc/rfc2119.txt

Despitethiscarefulattemptatcreatingconsistencyinproductsbasedonopen

standards,inconsistencycontinuestoabound.Eachtechnologymanufactureris

givenlatitudeindefininghowcloselyitsproductconformstotherecommended

specification.ThewordsSHOULD,SHOULDNOT,MAY,RECOMMENDED,and

OPTIONALarealmostaninvitationforvariation.Thus,dependingonhowwelltwo

ormoremanufacturersadheretotherecommendationofanopen-standards

document,theirproductsmightinteroperatewithvaryingdegreesofsuccess.The

onlywaytoachieveperfectoperabilityistomaintainasingle-vendor

infrastructure,therebydefeatingtheverypurposeofopenness.

Anotherinterestingwaythatactualproductsmightvaryfromtheopenstandard

istoincludeadditionalfunctionsorfeaturesthatareabsentfromthestandards

document.Suchtechnologiesorproductsmightstilllegitimatelyclaimtobe

"open-standard"andarefoundedonthebeliefthattheyembracetheopen

standardandthenextendit.Thisbeliefalsoleadstothecreationofaproprietary

architecturewithinanotherwiseopen-standardstechnology.

Summary

TheInternetandIPhavebothenjoyedunprecedentedlevelsofacceptanceinthe

pastdecade.DespitetheattentionlavishedontheInternet,IPhasbecomemore

widelyused.ManyorganizationsrequireIPtosupporttheirapplication

baseapplicationsthathavenothingtodowiththeInternet.Manyother

organizationsdirectlycontributetotheInternet'sevolutionandtechnological

advancebylettingtheirtechnicalpersonnelparticipateintheIETFinits

standards-settingwork.

BenFranklinoncesaidthatyoushouldenjoylawsandsausages,butdon'teven

trytounderstandhoweitheronegetsmade.Hisreasoningwasthatyouwould

loseyourappetiteforboth.Imustconfessthat,tothenewcomer,theIETF's

standards-settingprocessalsofitsthispolicy.Itisaworldinwhichastandardis

notnecessarilyastandard,butanRFCmightbe.Hopefully,theoverviewprovided

inthischapterhelpsmakesthingsabiteasiertounderstand.

ThisbookfocusesononeparticularoutputoftheIETF:theInternet'saddressing

scheme.Evenprivatenetworksmustconformtotherulesandprotocols

establishedandenforcedthroughthevariousmechanismsoutlinedinthischapter,

soanunderstandingofhowthoseentitiesoperateisessential.Thenextchapter

examinestheIPaddressspace(anditsunderlyingmathematics)muchmore

closely.

Chapter2.ClassicalIP:TheWayItWas

TheInternethasbecomesosuccessfulandubiquitousthatitisdifficulttoimagine

findingaworkingprofessionalwhoisn'tanardentuser.TheInternetwasfounded

onasuiteofcommunicationprotocolscalledtheInternetProtocol(IP).IPhas

undergonesometremendouschangesinthelasttwodecades,ashasits

underlyingaddressingsystem.ThischapterexaminestheoriginalformofIP

addressing:ClassicalIP.

ClassicalIPwasafairlysimpleapproachtocarvingalargeaddressspaceinto

smaller,moreusablespaces.Thissubdivisionwasachievedbybreakingthe

originalspaceintodistinctandhierarchicalclasses.Intheory,different-sized

classeswouldletsmall,medium,andlargeentitiesobtainappropriate-sized

addressblocks.Thischapterexplainsthesehumbleorigins,identifiessomeofthe

basicassumptionsthatunderlietheoriginaladdressingscheme,andthen

exploresthemathematicsoftheaddressspace.Thisformsasolidfoundationto

giveyouabetterunderstandingofhowtheaddressingarchitectureworkedand

wasused.

EvolutionoftheAddressSpace

IPanditsaddressingschemeevolvedslowly,sometimesevenerratically,over time.Theywerenot,contrarytoanycurrentappearances,carefullydesigned

priortoimplementation!Forexample,RFC1,publishedinApril1969,tellsus

thattheoriginalIPaddressspacewasspecifiedatjust5bits!Asyouwillseein

thischapter,that'senoughforjust32addresses!Strangeasthatmightsound,in

1969thatwasmorethanenoughfortheembeddedbaseofcomputersthatwere

beinginternetworked.Overtime,thenumberofbitsallocatedtohostaddressing

wasincreasedto6,andthen8,andfinallyuptothefamiliar32-bitformatthatis

inusetoday.

Theactualformatofthe"IPaddress"evolvedslowlyovertimeinresponsetothe evolutionoftheDARPAnet.DARPAnetwasthepredecessoroftheInternet.In essence,itwasanetworkthatinterconnectedvariousresearchfacilitiesin supportoftheU.S.DepartmentofDefense.Thenotionofclassesofaddresses, witheachclassofferingadifferingcombinationofbitsallocatedbetweennetwork

andhostidentification,wasfirstdescribedinRFC791,publishedinSeptember

1981.ThisRFCisthefoundationofwhathasbecomeClassicalIPaddressing.

Althoughitistechnicallyobsolete,ClassicalIPstilloffersamarvelousopportunity

tounderstandthecurrentstateofIPaddressing.

TheMathematicsoftheIPv4AddressSpace

ThecurrentversionoftheInternetProtocolisversion4,orIPv4.Discussingthe

mathematicsofthecurrentaddressspaceinachaptertitled"TheWayItWas" mightseemabitodd.Yetthetitleisn'tmisleadingnorthetopicoutofplace.How

theIPv4addressspaceisimplementedhaschangedradicallysinceitsinception.

We'llmakemoresenseofthatthroughoutthischapter.Fornow,justrecognize

thatIPv4isstillthecurrentversion.ItisjusttheoldwayofcarvinguptheIPv4

addressspacethathaspassedintoobsolescence.

IPaddressesaredefinedwithinamathematicalspacethatis32bitsinlength.Bit

isanabbreviationofbinarydigit.Itisthesmallestunitofdata,anditcanhavea

valueofeither0or1.Typically,apatternof8bitsiscalledabyte,although

puristswithinthedatacommunicationsandnetworkingfieldsinsistthat8bitsis

anoctet.Intruth,thisisonlyasemanticdistinction,sousewhatevertermyou

aremostfamiliarwith.

It'stimeforaquickmathematicalsanitycheck.Eachbitcanrepresentoneoftwo

differentvalues:0or1.Thus,theabsolutemaximumnumberofuniqueaddresses

youcancreatewitha32-bitaddressis2tothe32ndpower,or4,294,967,295

addresses.Thatsoundslikealotofaddresses.Ittrulywasaninexhaustible supplybackinthedayswhenonlyafewhundredcomputersweresprinkled aroundtheglobe.ThatwastheintentofthearchitectsofIPanditsaddress space:Deviseaschemathatwouldbescalablebeyondtheforeseeablefuture.

However,intoday'sageofamicroprocessorineveryhouseholdappliance,4

billiondoesn'tseemquitesolarge!Therearemorethan6billionpeopleonthe

earth,sothecurrentaddresssystemdoesn'tevenallowoneaddressperperson.

TheInternetEngineeringTaskForce(IETFthecaretakersoftheInternet's technologybase)soughttomaketheaddressspacemoreusableinnumerous

ways.TheyrecognizedthatevenaBase10numberwouldnotbeconduciveto

humanuseoftheaddressspace,becauseitwastoolarge.Base10isthedecimal

numbersystem;itusestendifferentsymbolstorepresentnumbersthatprogress

inmultiplesof10.Thisisthenumbersystemthatmosthumansconsidernative.

Unfortunately,keepingtrackofnumbersfrom1toover4billionjustisn't

practicalforhumans!Thus,additionalstepsweretakentodevelopalogical

hierarchy:

Developingameansbywhichpeoplecouldcontinueusingtheintuitive

Base10numbersystemforendpointaddressing.Remember,computersand

networksareinherentlydigital.DigitalimpliesbinarytheBase2number

system!So,somemeansofmakinganinherentlybinaryaddressingsystem

intuitivetohumanuserswascriticallyneeded.

Breakingupthenumericaddressintofourequalcomponents.Thishadthe

beneficialeffectofconvertingapotentiallylongaddressintojustfour

relativelysmallnumbers.Inrelativeterms,thatwasahugeimprovementin

usability.

Subdividingtheaddressspaceintologicalclassesofaddressspaces.

Ostensibly,classeswouldletyoupredefineaddressesforsmall,medium,and

largenetworks.

ThesethreetacticsabettedtheusabilityoftheIPaddressspaceindifferentways.

Thefirsttwodirectlyfacilitatedhumanusage.Thelasttacticwasdesignedto

maketheaddressspacemorescalableinitsapplicationthanusabletoindividual

users.ThesetacticsandtheirimpactsontheIPaddressspacearedescribed

furtherinthefollowingsections.

MakingtheAddressSpaceHuman-Friendly

MakingtheIPaddressspacehuman-friendlyrequiredtheuseofbothafamiliar

numbersystemandthesmallestnumberspossible.Addressingthefirstofthese

criteria,peoplethinkintermsoftheBase10numbersystem,whereascomputers

areinherentlybinary.Thatis,computersprocessinformationusingoneoftwo

possiblestates:eitheron/offor1/0.Eitherway,informationisencodedand

processedbycomputersusingverylongstringsthataremadeupofjusttwo symbols.Itwouldbewellbeyondthecapabilityofanypersontoreliablyrecallthe

32-bitaddressstringsofbinarynumbersrelieduponbycomputersandcomputer

networkstocommunicate.

TheInternet'soriginaladdressspacewascreatedtobeinexhaustiblesothatthe Internet'sfuturegrowthwouldnotbeartificiallyconstrained.Althoughthat designcriterionensuredafuturefortheInternet,italsocreatedamorevexing problem.Fromamorepragmaticperspective,therawaddressspacewassolarge astobeunusablebyhumans.Again,mosthumanscannotreliablyrecallspecific

32-bitstringsofbinarynumbers.

Convertinganygiven32-bitstringofbinarynumbersintodecimalnumbers

would,atleastintheory,makethenumbermorehuman-friendly.Afterall,the

Base10numbersystemissofamiliartohumanbeingsastobesecondnature.

Unfortunately,a32-bitbinarynumbercanpotentiallytranslateintoadecimal

numbersolargethatitisalmostmeaninglesstohumanbeings.Forexample,

imaginetryingtorememberwhetheryourcomputer'saddressis4,217,824,125

or4,217,924,125.

However,thosenumbersareeasiertorememberthantheirbinaryequivalents

(whichare11111011011001101110001101111101and

11111011011010000110101000011101,respectively,intheBase2number

system).Thus,youcouldsuccessfullyarguethatusingdecimalnumbersinstead

ofbinarynumbersdirectlyreducedthesizeofthe"numbers"thatpeoplewould

havetoremember.Buttheyarestillfartoocumbersometobeuseful.Youwould

havegreatdifficultyrememberingyourownIPaddress,muchlesstryingto

remembertheIPaddressesofusefuldestinationmachines.

NOTE

ThisdiscussionabouttherelativedifficultyofrememberingnumericIPaddresses predatestheuseofmnemonicsasasubstitutefornumericaddresses.Today's InternetusersseldomdirectlyuseIPaddressesforaccessinginformationstored throughouttheNet.Theintroductionofstructuredmnemonicsforhostsandtheir domainshasallbutobviatedthepracticeofusingrawIPaddresses.These

technologiesareexploredinmoredetailinChapter8,"InternetNames."

However,itisimportanttorememberthatthelogisticsofrememberingandusing

largenumbersfactoredintothedesignoftheaddressspace.

Thus,thefirstpriorityinmakingtheIPaddressspacehuman-friendlywasto provideamathematicaltranslationsothatpeoplecouldcontinuetousethe

Base10numbersystemthattheyaresofamiliarwith!Butthatstillleftunsolved

thetandemproblemsofrememberingandusinglargenumbers.

ThePurposeoftheDots

Althoughitmightseemcounterintuitive,especiallywhenweareaccustomedto thinkingintermsofonlydecimalnumbers,thelogicalsolutiontothe unmanageablylargeaddressspacewastobreakitintoaseriesofsmaller numbers.Tocontinuewiththeexampleusedintheprecedingsection,adecimal

valueof4,217,824,125presentsaninterestingcasestudy.Giventhatthis

numberhasfourcomponents(groupsofbillions,millions,thousands,and

hundreds/tens/ones),itmightseemlogicaltojustsplitthenumberalongthose

lines.Butseveralpotentialproblemsemergefromsuchanarbitrarysubdivision.

Thefirstpotentialproblemisthatsuchsubdivisionresultsinanasymmetricrange ofvalidnumbersforeachgroup.Thebillionsgroupwouldhaveavalidrangeof

just0to4,whereastheotherthreegroups'validrangeswouldbefrom0to999.

Suchasymmetryisn'tofgreatconsequence,butitheraldsacompromiseinthe

originalgoalofabsolutelyminimizingvalidnumericranges.Rememberthesmaller

thenumbers,theeasiertheyaretorememberanduse!

Thenextconcernisthatthisschemeisbasedondecimalnumbersbuttheaddress spaceisinherentlybinary.Thesameistrueofthecomputersthatusetheaddress spacedirectly.Thus,itmakesmoresensetousebinarynumberswhenevaluating potentialtechniquesforusinganaddressspace.Giventhattheaddressspaceis

32binarydigits(bits)inlength,segmentingthisspaceisalogicalmeansof

creatingmoremanageablenumbers.ThearchitectsoftheInternet'saddress

spacesawthewisdominthisapproach.Theydisaggregatedthe32-bitnumeric

addressintofourequalcomponentsof8bits.Thesecomponentsarecalledoctets.

Suchdisaggregationhadthepleasanteffectofreducingthehumanchallengeof rememberingaten-digitnumbertomerelyrememberingfournumberseachof whichisoneoctetinlength.Thevalidnumericrangefortheseoctetsisfrom

00000000to11111111.Thedecimalequivalentsare0to255.Ifyouaren'tsure

whyaddresseswerelimitedtothisrange,don'tworry.Thistopiciscoveredin

muchmoredetailinthenextsection.Adotorperiod(.)wassomewhatarbitrarily

selectedasthedelimiterthatwouldseparatethefields.Thus,theconventionwas

set:IPaddresseswouldtakethisformat:

ThisisthenativeformofIPaddresses.Yetsuchaformmightbeconfusinginthat IPaddressesaremostcommonlyencounteredintheirdecimalform.Thatis,they

useBase10numbers,whichareseparatedbythedotorperiod.Thetermusedto

describethatformofanIPaddressisdotted-decimalnotation.Hereisanexample

ofanIPaddressexpressedindotted-decimalnotation:

192.168.99.1

AllIPv4addressesadheretothisformat.Giventhedotted-decimalformat,two

reasonablequestionstoaskare"WhybothersayingthatanIPaddressisa32-bit

number?WhynotsimplysaythatanIPaddressisfourdecimalnumbers separatedbydots?"Theansweristhatnumbersareinfinite,buttheIPaddress

spaceisnot.Ithasahardupperlimitestablishedbythe32bits.Itisnecessaryto

explorebinarymathematicstounderstandthisstatement.

BinaryMathematics

UnderstandingtheIPaddressspaceabsolutelyrequirescomprehendingthebinary

mathematicsonwhichitisfounded.Althoughthismightsoundsomewhat

daunting,itreallyisquitesimple.Aswithanything,themoreyouuseit,the

easieritbecomes.

Asmentionedearlierinthischapter,theaddressspaceisinherentlybinary;it

usestheBase2numbersystem.MuchliketheBase10numbersystem,adigit's

significancedependsonitslocation.Forexample,thevalueofdigitsinthe

Base10numbersystemchangesbyafactorof10asyouchangecolumns.Thus,

inthenumber111,thenumeral1hasthreedifferentvalues:onegroupof1sin

therightmostcolumn,onegroupof10inthemiddlecolumn,andonegroupof

100intheleftmostcolumn.Addingthemresultsinthevalue111.

IntheBase2numbersystem,thedigits'significancealsodependsontheir

location.However,theirvaluechangesbyafactorof2(not10).Thenumber111,

inbinary,translatesintoonegroupof1s,onegroupof2s,andonegroupof4s,

foratotalof7inBase10.Table2-1demonstrateshowthebinarynumber

10000000translatesintotheBase10number128.

Table2-1.128ExpressedinBase2

DecimalValueofColumn

128

64

32

16

8

4

2

1

BinaryNumber

1

0

0

0

0

0

0

0

TheeightbinarydigitsandtheirdecimalequivalentsshowninTable2-1letyou

countfrom0to255inBase10numbers.Thebuildingblocksofthiscapabilityare

showninTable2-2.IftheBase10equivalentdoesnotappearintuitive,referto

Table2-1todeterminethedecimalvalueoftheBase2columns.

Table2-2.TheValueofBase2NumberColumns

Base2

Base10Equivalent

00000001

1

00000010

2

00000100

4

00001000

8

00010000

16

00100000

32

01000000

64

10000000

128

TheentriesinTable2-2demonstratethefoundationonwhichtheIPaddress

spaceisbuilt.Eachofthefourpartsofanaddresscontainsjust8bitswithwhich

toencodeavalue.However,only1ofthose8bitsisactuallysettoavalueother

than0.Noticehowthedecimalequivalentvaluedoublesasthe1movesleft

throughtheeightpossiblecolumnsofthebinarystringofnumbers.This demonstratesjustthebasicdecimalvaluesofthebinarypositions.However,the

binarystringcanbeusedtoencodedecimalvaluesthatrangefrom0to255.

Suchvaluesarecalculatedbyaddingthedecimalvaluesofeachcolumn

populatedwitha1.

CountinginBase2isfairlysimple,becauseyouhaveonlytwodigitstoworkwith!

Youincrementfrom0to1.Incrementingabovethatrequirescarryingvaluesover

intohighercolumns.ThisisthesamelogicthatappliestoBase10andeveryother

numbersystem.Forexample,everyoneknowsthat9+1=10,butweseldom

thinkaboutthisequationintermsofcolumnsandtheirrespectivevalues.What

wearereallysayingisthat9+1=onegroupof10.Thekeydifferencebetween

theBase2andBase10numbersystemsisthattheamountbywhicheach

column'svaluevaries.InBase10,eachcolumn(progressingfromrighttoleft)is

10timesthevalueoftheprecedingcolumn.Inotherwords,theprogressionis

ones,tens,hundreds,thousands.InBase2,theprogressionisadoublingofthe

valueoftheprecedingcolumn:1,2,4,8,16,32,64,128,andsoon.Those

valuesarerepresentedintheBase2numbersystembyplacinga1intheir

respectivecolumns.ThisisillustratedinTable2-2.

Thenextlogicalstepinmasteringbinarymathematicsislearninghowtocount

numbersthataren'tfactorsof2.SeeTable2-3.

Table2-3.CountinginBase2

Base2

Base10

00000000

0

00000001

1

00000010

2

00000011

3

00000100

4

00000101

5

00000110

6

00000111

7

00001000

8

00001001

9

00001010

10

00001011

11

00001100

12

00001101

13

00001110

14

00001111

15

00010000

16

11111111 255 Withoutsubjectingyoutothetediumofcountingallthewayupto255inBase2, Table2-3
11111111 255 Withoutsubjectingyoutothetediumofcountingallthewayupto255inBase2, Table2-3

11111111

255

Withoutsubjectingyoutothetediumofcountingallthewayupto255inBase2,

Table2-3attemptstodemonstratehowtocountinthatnumbersystem.Atfirst,

theprogressionofthepatternof1sand0smightseemcounterintuitive,butit

followsthesamelogicasanyothernumbersystem.Thereareonlytwosymbols withwhichtoencodevalues,sothehighest"number"youcanplaceinany

columnisa1.

Toillustratethispoint,supposethatthebinarynumberis00000001.

Incrementingitbyoneunitrequiresresettingtherightmostcolumnto0and

carryinga1overintothecolumntoitsleft.Thisyields00000010.Thisisthe

samelogicthatisappliedindecimalnumberswhenweincrement9by1toget

10.Inthatequation,agroupofnine1sisincreasedby1toyieldonegroupof10

withno1s.Thedifferenceliesinthenumberofvalidnumbersandthevalueof

thecolumns.Quiteliterally,ourbinarynumbertranslatesintodecimalasfollows:

nogroupsof128,nogroupsof64,nogroupsof32,nogroupsof16,nogroupsof

8,nogroupsof4,onegroupof2,andnounits.Summingupthegroupsyieldsa

decimalvalueof2.

Another,slightlymorecomplexexampleisthebinarynumber10101010.This

binarynumbertranslatesintodecimalasfollows:onegroupof128,nogroupsof

64,onegroupof32,nogroupsof16,onegroupof8,nogroupsof4,onegroup

of2,andnounits.Summingupthegroupsyieldsadecimalvalueof170(128+

32+8+2).

Therefore,toconvertbinarytodecimal,youmustsumupthedecimalequivalents

ofallcolumnsinthebinarystringthathavea1insteadofazero.Thissummation

mustbedoneseparatelyforeachoctetintheIPaddress.

ofallcolumnsinthebinarystringthathavea1insteadofazero.Thissummation mustbedoneseparatelyforeachoctetintheIPaddress.

NoZeroSuppression,Please!

OneoftheodditiesthatyoumighthavenoticedinTables2-2and2-3isthatleading0sarenot

suppressed.Inotherwords,youwouldn'texpressthenumericvalueof1as00000001inBase10you

wouldsuppresstheleadingzeroes.They'remeaninglessandthereforearedeleted.However,itis

importanttorememberthatIPaddressesconsistofasingle32-bitnumber;youartificiallysegment

themintogroupsof8bits.Thus,suppressingleading0smightactuallytruncatenumbersinthemiddle

ofalargerstring.SuchanactionwouldchangethevalueoftheIPaddressandwouldresultinaninvalid

value.

Althoughitiscustomaryinmathematicstosuppressleading0s,thisdoesnotholdtrueintheIP

addressspace.That'sbecausea32-bitnumberisarbitrarilysegmentedintofoursmallergroupsofbits.

Suppressingleading0sinanyofthosegroupstruncatesthewholenumber,therebychangingthetotal

values.Itisimperativetorememberthat,eventhoughyouareaccustomedtothinkingofIPaddresses

intermsoffournumbersthatrangefrom0to255,anIPaddressisreallyasingle32-bitstringof

binarynumbers.

intermsoffournumbersthatrangefrom0to255,anIPaddressisreallyasingle32-bitstringof binarynumbers.

TheAddressSpaceHierarchy

HavingexaminedthemathematicsuponwhichtheIPaddressspaceisfounded,it

istimetoexploreitshierarchicalorganization.Thehierarchyisbestdescribedas

beingcompound,becausetherearetwoaspects:

TwolevelsofaddressingwithineachIPaddress.

Classesofaddressesbasedondifferingbitallocationstothetwolevelsof

addresses.Havingsegmentedtheaddress'sbitstringintofour8-bit

componentsmakesitveryeasytocreateaddressclassesbecauseyouhave

logicalgroupingstoworkwith.

Eachofthesehierarchicalaspectsisexploredinthefollowingsections.

Two-LevelAddresses

EachIPaddressconsistsoftwoparts:anetworkaddressandahostaddress.

Together,theyenablethespecificanduniqueidentificationofendpoints.More

importantly,theyenablealevelofoperationalefficiencywithinaninternetwork.

Suchanefficiencyimprovementismadepossiblebyreducingtheworkloadofthe

routersandswitchesthatinterconnectnetworks.Simplystated,theydon'thave

to"remember"thepathtoeachindividualendpoint.Allendpointsmusthavea

uniqueIPaddress,buttheycanshareacommonnetworkaddress.Thus,itis

sufficientto"remember"thepathtoeachnetworkandtoentrustthenetworking

componentsofeachdestinationnetworktodelivertransmittedpacketsofdata

aftertheyareroutedthroughtheinternetworkandarriveattheirdestination

network.

NOTE

Aninternetworkistwoormorenetworksthatareinterconnected.

Tobetterillustratethispoint,considertheinternetworkshowninFigure2-1.

Figure2-1.NetworkAddressesServeasDestinations

In Figure2-1 ,routersprovideinterconnectivitybetweenthevariousnetworksby

InFigure2-1,routersprovideinterconnectivitybetweenthevariousnetworksby

rememberingroutestoeachnetwork.Ineachoftheseexamples,thenonzero

octetsofeachIPaddressidentifythenetworkaddress.

Thereisnoreasonforaroutertocalculateorstorearoutetoeachhost.Instead,

theroutermerelycalculatesandstoresroutestoeachnetwork.Thelocal-area

networks(LANs)areresponsibleforextendinginterconnectivitydowntothe

individualendpoints.Itisonlyatthislevelthathostaddressesbecome

significant.Forthisreason,routestodestinationsaredescribedintermsofthe

destination'snetworkaddress.Allhostaddresseswithinthatnetworkaddressare

saidtobelongtothesameaddressblock.

ClassesofAddresses

ThesecondaspectoftheIPaddressspacehierarchyisabitmorecomplex:the

entireaddressspaceissegmentedintonumericranges.Eachnumericrangeis

tailoredtoaspecificpurposebasedondifferingallocationsofbitsbetweenthe

hostandnetworkportionsoftheaddress.Simplystated,theIETFsectionedthe

four-octetaddressspaceintodistinctclassesthatwerereservedforsmall,

medium,andlargecompaniesororganizations.Eachclassofferedadifferent

numberofdefinablehostaddresses.Theexpectationwasthatmostofthe

companiesororganizationsthatwouldusetheInternetProtocolwouldfitintoone

ofthesecategories.

Logically,therewouldbemoresmallercompaniesthanlargercompanies,sothere

wouldhavetobemanyaddressblocksthatofferedarelativelysmallnumberof

usablehostaddresses.Extendingthislogic,smallcompanieswouldn'tneedvery

manyhostaddresses,butlargecompanieswouldrequireasignificantnumberof

hostaddresses.ThislogicbecamethefoundationfortheclassesofIPaddresses.

TheclassesofIPaddresseswereidentifiedwithasinglealphabeticcharacter:

ClassesA,B,C,D,andE.Eachoftheserepresentsadifferentcompromise

betweenthenumberofsupportablenetworksandhosts.

ClassA

TheClassAaddressspacewasconceivedtosatisfythescenarioofapreciousfew extremelylargeentitiesrequiringalargenumberofhostaddresses.Ingeneral terms,onlythefirstoctetisusedforthenetworkaddress.Theremainingthree octetsidentifypotentialhostaddresseswithinthatnetwork.Atfirstglance,this

mightleadyoutoconcludethatthereare255possibleClassAaddresses

(excluding0).Suchaconclusionwouldassumethattheentirefirstoctetcouldbe

usedtoidentifyClassAnetworkaddresses.Unfortunately,that'snotquitethe

case.Thefirstoctetdoes,indeed,rangefrom0to255,butthatmustsatisfythe

entireIPaddressrange,notjusttheClassAnetworks.All-0saddressesare

reservedandunusable.Consequently,theClassAaddressspacestartsat1.0.0.0

insteadof0.0.0.0.

Clearly,anuppermathematicalboundaryneededtobeestablishedthatseparated theupperlimitsoftheClassAspacefromthelowerlimitsoftheClassBspace.A remarkablyuncomplicatedanswerwasembraced:Thefirstbit(whichshould automaticallygetyouthinkinginbinarytermsratherthandecimalnumbers)ofa

ClassAaddressisalwaysa0.Table2-4liststherulesgoverningtheClassA

addressspace.Bitsineachoctetthatmayhaveeithera0or1valueare

designatedwitha-.

Table2-4.BitAllocationfortheClassAAddressSpace

 

FirstOctet

SecondOctet

ThirdOctet

FourthOctet

Usage

Network

Hosts

Host

Host

RequiredBinaryValues

0-------

--------

--------

--------

Thehighestvalueofthefirstoctet,inbinary,is01111111.Intheory,and

expressedindecimalform,thehighestClassAaddressis127(64+32+16+8

+4+2+1).ThismathematicallylimitedtheClassAaddressspacetonetworks

numbered1.0.0.0upto127.0.0.0.However,theClassAspacewasfurther

impinged!Theaddressspace127.0.0.0wasreservedforusewithloopback

testing.Thus,eventhoughitappearstosatisfythecriteriaforbeingaClassA

space,itisnotusableassuch.Thus,therangeofpossibleClassAaddressesis

from1.0.0.0to126.0.0.0.WithineachClassAaddressspace,thevalidrangefor

hostsrangesfromx.0.0.0tox.255.255.255,wherexdenotesanyvalidnumberin

theClassArange.Toillustratethispoint,10.1.99.240and10.235.5.111are

hoststhatresideonthesamenetwork:10.0.0.0.

NOTE

Throughoutthischapter,I'lluseanxasawildcardcharactertorepresentavalid

mathematicalvalueinlieuofanactualvalueforanoctetinanIPaddress

structure.

Thelastthreeoctets(thelastthreedotted-decimalnumbers)ofaClassAaddress representpossiblehostaddresseswithineachspecificnetworknumber.Itis importanttonotethattheentireaddressmustbeunique.Therefore,individual

hostaddresses(99.100.101,forexample)canbeduplicatedwithineachClassA

network.Thiscanbeapotentialsourceofconfusion,whichiswhyitisalwaysa goodideatoreferenceentireIPaddressesratherthanjustpartialaddresses.No

onewillbeconfusedastotheuniquenessof10.99.100.101comparedto

76.99.100.101.

GiventhateachClassAaddressoffersthreefulloctetsforuniquehostaddresses, thenumberofmathematicallypossibleaddressesrangesfrom

x.00000000.00000000.00000000tox.11111111.11111111.11111111,wherex

identifiesanunspecifiednetworkaddressnumber.Thisrangeequatesto

16,774,215uniquehostaddressespernetworknumber,withamaximumof126

possiblenetworkaddresses.Asyoucansee,thearchitectsoftheInternet's

addressspaceachievedtheirobjective:afairlysmallnumberofincrediblylarge

addressspaces.

ClassB

TheClassBaddressspacewasconceivedasamiddlegroundbetweentwopolar

extremes:ClassA(veryfewnetworkswithaverylargenumberofendpoints)and

ClassC(lotsofnetworks,eachwithaverysmallnumberofendpoints).The

architectsoftheaddressspacefollowedtheirconventionofusingoctet

boundaries.WhereasaClassAnetworkaddresswasdefinedwithjustasingle

octet,aClassBnetworkaddresswastreatedtohalfofthefouroctetsinanIP

address.

Having16bitsforhostaddressesmeansthateachClassBnetworkhas65,535

mathematicallypossibleaddresses.Youmightassumethat,because16bitsare

alsousedfordefininguniquenetworkaddresses,thereare65,535

mathematicallypossiblenetworkaddressesaswell.Unfortunately,that'snotquite thecase.Remember,someoftheoveralladdressspacehasalreadybeen allocatedforClassAaddresses,andmorewillbeneededforotheraddresses.The ClassBspacemustbeconstructedsoastooccupyaseparatemathematical rangeideally,contiguoustotheClassAspaceandyetleaveenoughaddressspace forotherclassesofnetworks.Again,thesolutionwasremarkablysimple:thefirst

2bitsofthefirstoctetmustbe10.

Startingthebitpatternofthefirstoctetwitha10separatesthisspacefromthe

upperlimitsoftheClassAspace.Table2-5liststherulesgoverningtheClassB

addressspace.Again,bitsineachoctetthatmayhaveeithera0or1valueare

designatedwitha-.

Table2-5.BitAllocationfortheClassBAddressSpace

 

FirstOctet

SecondOctet

ThirdOctet

FourthOctet

Usage

Network

Network

Host

Host

RequiredBinaryValues

10------

--------

--------

--------

Thehighestvalueofthefirstoctetis10111111.Thus,expressedindecimalform,

thehighestClassBaddressis191(128+32+16+8+4+2+1),which

mathematicallylimitstheClassBaddressspacetonetworksnumberedfrom

128.0.0.0to191.255.0.0.

ThelasttwooctetsofaClassBaddressrepresentpossiblehostaddresseswithin eachspecificnetworknumber.AswiththeClassAaddressspace,theentire addressmustbegloballyunique.Individualhostaddressescanbeduplicated withineachnetworkaddress.ValidClassBhostaddressesrangefrom

x.x.00000000.00000000(x.x.0.0indotted-decimalnotation)to

x.x.11111111.11111111(x.x.255.255indotted-decimalnotation),wherex

identifiesanunspecifiednetworkaddressnumber.Thisrangeyieldsamaximumof

65,535uniquehostaddressesperClassBnetwork.TherangeofpossibleClassB

networkaddressesisfrom128.0.0.0to191.255.0.0,foratotalof16,385possible

networkaddresses.ValidhostaddressesforClassBnetworksrangefromx.x.0.0

tox.x.255.255.Thus,160.10.1.32and160.10.242.17wouldbeonthesame

network(160.10.0.0).

Withinthisrangeofvalidnumbers,eachnumericcombinationofthefirsttwo

octetsrepresentsadifferentIPnetworkaddress.Thus,191.2isasseparateand

distinctfrom191.3as128.1isfrom191.254.Tobetterillustratethispoint,

considerTable2-6,whichdemonstrateshowincrementingnetworkaddresses

workswithbothdecimalandbinarynumbers.Giventhatwe'reexploringthe

incrementationofnetworkaddresses,thehostportionoftheaddressis

representedsolelywiththecharacterx.

Table2-6.IncrementingClassBNetworkAddresses

DecimalNetworkAddress

BinaryNetworkAddress

128.0.x.x

10000000.00000000.x.x

128.1.x.x

10000000.00000001.x.x

128.2.x.x

10000000.00000010.x.x

128.3.x.x

10000000.00000011.x.x

128.4.x.x

10000000.00000100.x.x

x . x 128.4. x . x 10000000.00000100. x . x 128.254. x . x 10000000.11111110.

128.254.x.x

10000000.11111110.x.x

128.255.x.x

10000000.11111111.x.x

129.0.x.x

10000001.00000000.x.x

129.1.x.x

10000001.00000001.x.x

129.2.x.x

10000001.00000010.x.x

129.3.x.x

10000001.00000011.x.x

129.4.x.x

10000001.00000100.x.x

x . x 129.4. x . x 10000001.00000100. x . x 129.254. x . x 10000001.11111110.

129.254.x.x

10000001.11111110.x.x

129.255.x.x

10000001.11111111.x.x

130.0.x.x

10000010.00000000.x.x

130.1.x.x

10000010.00000001.x.x

130.2.x.x

10000010.00000010.x.x

130.2. x . x 10000010.00000010. x . x 191.255. x . x 10111111.11111111. x . x

191.255.x.x

10111111.11111111.x.x

WhenanIPnetworkaddressisviewedasabinarystring,theincrementing appearsmuchmorelogical;therightmostbitofthenetworkaddressdetermines

howincrementingoccurs.Ifthatbitisa0,itisincrementedbyconvertingittoa

1.Ifthatbitisa1,itisincrementedbyconvertingittoa0andthencarryinga

valueovertothecolumnimmediatelytoitsleft.Thisprocessisrepeateduntila0

isencounteredandnothingfurtherneedstobe"carriedover."Althoughthis

shouldbearepetitionofwhatyousawinTable2-2,theideaofcarryingovera

valuefromoneoctettoanotheristhekeydifferencereinforcedinthistable.

ClassC

TheClassCaddressspaceoffersalargenumberofnetworkaddresses,although

eachonecansupportonlyaverylimitedquantityofhostaddresses.The

architectsoftheaddressspaceagainfollowedtheirconventionofusingoctet

boundaries.TheClassCnetworkaddressisthreeoctetsinlength,leavingjust

oneoctetforuseinidentifyinguniquehostswithineachnetwork.

Havingjust8bitsforhostaddressesmeansthateachClassCnetworkhasonly

256mathematicallypossibleaddresses.However,using24bitsfornetwork

addressesmeansthattherecanbealotofthem.Althoughthese24bitsmustbe

definedsothattheydon'toverlapwithotheraddressclasses,2,097,151ClassC

networkaddressesarestillmathematicallypossible.

DelineatingtheClassCspacefromtheClassBspacerequiresstartingthebit

patternofthefirstoctetwitha110.ThisseparatestheClassCspacefromthe

upperlimitsoftheClassBspacewhilesimultaneouslyleavingsomehigher

networknumbersavailableforuseindefiningotherclasses.Table2-7

demonstrateshowthisisachieved.AswithTables2-4and2-5,bitsineachoctet

thatmayhaveeithera0or1valuearedesignatedwitha-.

Table2-7.BitAllocationfortheClassCAddressSpace

 

FirstOctet

SecondOctet

ThirdOctet

FourthOctet

Usage

Network

Network

Network

Host

RequiredBinaryValues

110-----

--------

--------

--------

Thehighestvalueofthefirstoctetis11011111.Thus,expressedindecimalform,

thehighestClassCaddressis223(128+64+16+8+4+2+1),which

representsthehighestnetworknumberthatcanbedefinedinthisclass.Given

thattheaddressspacestartsat192(128+64,or11000000asabinarystring),

theClassCnetworkaddressspacerangesfrom192.0.0.0to223.255.255.0.Valid

hostnumbersrangefromx.x.x.0tox.x.x.255.Thus,192.168.127.144and

192.168.127.254arehostsonthesameClassCnetwork:192.168.127.0.

IncrementingaClassCnetworkaddressisrelativelysimple.Youhavethree

octetsforthispurpose,sothefirstnetworkaddressis192.0.0.Nextare192.0.1,

192.0.2,and192.0.3,untilyougetto192.0.255.Thisiswhereanappreciationof

binarymathematicshelps:Thenextavailablenetworkaddressabove192.0.255

is192.1.0.Indecimal,thismightnotbeveryintuitive,butitbecomesperfectly

clearinbinary.ConsiderTable2-8.

Table2-8.IncrementingClassCNetworkAddresses

DecimalNetworkAddress

BinaryNetworkAddress

192.0.0.x

11000000.00000000.00000000.x

192.0.1.x

11000000.00000000.00000001.x

192.0.2.x

11000000.00000000.00000010.x

x 192.0.2. x 11000000.00000000.00000010. x 192.0.254. x 11000000.00000000.11111110. x 192.0.255.

192.0.254.x

11000000.00000000.11111110.x

192.0.255.x

11000000.00000000.11111111.x

192.1.0.x

11000000.00000001.00000000.x

192.1.1.x

11000000.00000001.00000001.x

192.1.2.x

11000000.00000001.00000010.x

11000000.00000001.00000001. x 192.1.2. x 11000000.00000001.00000010. x 192.1.254. x 11000000.00000001.11111110. x

192.1.254.x

11000000.00000001.11111110.x

192.1.255.x

11000000.00000001.11111111.x

192.2.0.x

11000000.00000010.00000000.x

192.2.1.x

11000000.00000010.00000001.x

192.2.2.x

11000000.00000010.00000010.x

x 192.2.2. x 11000000.00000010.00000010. x 192.255.254. x 11000000.11111111.11111110. x

192.255.254.x

11000000.11111111.11111110.x

192.255.255.x

11000000.11111111.11111111.x

193.0.0.x

11000001.00000000.00000000.x

193.0.1.x

11000001.00000000.00000001.x

193.0.2.x

11000001.00000000.00000010.x

x 193.0.2. x 11000001.00000000.00000010. x 223.255.255. x 11011111.11111111.11111111. x

223.255.255.x

11011111.11111111.11111111.x

Thistableprovidesthecorrelationbetweendecimalandbinarynumbers.

AlthoughitwouldbeimpracticaltolisteverymathematicallypossibleClassC

networkaddress,thissubsetshouldamplydemonstratethekeyaspectsof

incrementingthesenetworkaddresses.Afteryoubecomecomfortablewith

incrementingbinarynumbers,understandingtheIPaddressspacebecomeseasy!

ValidClassChostaddressesrangefrom00000000to11111111,or0to255if

youpreferdotted-decimalnotation.Remember,onlyoneoctetisavailableforhost

identification,sotherangeislimitedtojustthese256addresses(0through255).

Initially,notalloftheseaddresseswereusable,eventhoughtheywere mathematicallypossible;thehighestandlowestaddresseswerereserved.

Address0wasconventionallyreservedforidentifyingthenetworkitself,whereas

address255wasusedasabroadcastaddresswithinthatnetwork.Such

reservationsheldtruethroughouttheentireClassicalIParchitectureandwere notuniquetoClassCaddresses.Itisstillpossibletofindinformationsourcesthat declarethatthenumberofpossibleaddressesinaClassC-sizedaddressblockis

either254or255.

ClassD

TheClassDaddressspaceisaradicaldeparturefromthefirstthreeclasses.

Unlikethepreviousthreeclasseswe'veexamined,thisclassdoesnotadhereto

theconventionofdividingthebitstringintonetworkandhostaddress

subcomponents.Asyoumightexpect,thismakesitratherdifficulttousein

uniquelyidentifyingnetworkedhostsinaninternetwork.Quitesimply,youcannot

defineanetworkaddress.Thisisbydesign;thisuniquelyflataddressspaceisnot

usedforendpointaddressing.Instead,itservesasacodethatletsahostsenda

singlestreamofIPpacketstonumerousdestinationmachinessimultaneously.

MulticastingisacomplextopicthatusesauniquebinarystringintheClassD

spacetocorrelatetoapredefinedlistofIPendpoints.Amulticastaddressisa

uniqueIPaddressthatdirectspacketswiththatdestinationaddresstopredefined

groupsofIPaddresses.Thus,thereisnoneedforthehierarchicaldivisionofbits

betweennetworkandhostaddressesinthisclass.

Despitethisbreakfromarchitecture,theClassDaddressspacemustadhereto otherconstraints.Forexample,ittoomusthaveitsownrangeofaddresses.To

achievethis,thefirst4bitsofaClassDaddressmustbe1110.Binary

mathematicsdictatesthat,giventhelocationofthis0,thelowestaddressinthis

classcanbe11100000,or128+64+32=224.Thehighestmathematically

possibleaddress,giventhisconstraintinthefirstoctet,is11101111,or128+64

+32+8+4+2+1=239.Thus,ClassDmulticastgroupaddressesarefrom

224.0.0.0to239.255.255.255.Table2-9followstheformatofthepreceding

tablesanddemonstrateshowtheoctetsareusedinthisclass.

Table2-9.BitAllocationfortheClassDAddressSpace

 

FirstOctet

SecondOctet

ThirdOctet

FourthOctet

Usage

MulticastGroup

MulticastGroup

MulticastGroup

MulticastGroup

RequiredBinaryValues

1110----

--------

--------

--------

ClassE

AClassEaddresshasbeendefinedbutisreservedbytheIETFforitsown researchandothernonroutablepurposes.Thus,ClassEaddressesexist,butthey havenotbeenreleasedforuseintheInternet.Thisaddressclassbeginsat

rangemightappearfamiliar;itisthebasisofthesubnettingmask.Subnettingis

coveredinChapter3,"Fixed-LengthSubnetMasks,"andChapter4,"Variable-

LengthSubnetMasks,"soyou'llbecomemuchmorefamiliarwiththisaspectof

theIPaddressspace.

DrawbacksofClass-BasedAddressing

ThereisasimpleelegancetothisoriginalIPv4addressingarchitecture.Theentire

addressspaceisneatlycleftalongoctetboundaries,andupperlimitsare

establishedviathefirstoctet'sinitialbitsequence.It'ssocleanandsimplethatit

isbrilliant.Unfortunately,thisschemewasdevelopedabsentanyknowledgeof

futureInternet-userdemographics.Thisclass-basedarchitecturesatisfiedthe

needsoftheInternetcommunityformorethanadecade.Therelativelyslow

growthratemaskedthearchitecturalinefficienciesoftheIPaddressspace.Quite

simply,thearchitecturewasfoundedonanabsolutelackofdata.Thus,the

architectureisinherentlymorelogicalthanpractical.

Evidenceofthisisfoundinthegreatgapsbetweentheclasses.TheClassC-sized

networkoffers255hosts,butthenextstepupinsizeisClassB,whichoffers

65,535hostaddresses.That'sahugegap!ThedifferencebetweentheClassB-

sizednetworkandClassAisevenworse:ClassAsupports16,774,215unique

hostaddresses.Ostensibly,organizationsthatrequiredanumberofaddresses

thatfellinbetweenthesecoarseclassescouldobtainmultipleaddressspaces.If

theymixedandmatchedthemfromthethreeclasses,theycouldfairlyclosely

matchthenumberofaddressesprovidedtotheirrequirements.Or,theycould

simplyrationalizetheneedfor"growth"andobtainalotmoreaddressspacethan

theyactuallyneeded.

Thepointisthatthetremendousdisparitiesbetweenthethreeprimaryaddress classes(A,B,andC)createdthepotentialforinefficiencyandwaste.Thishas

proventobetheAchilles'heelofIPv4.Insubsequentchapters,youwilllearn

moreaboutthevariousmethodsthatweredevelopedtoenhancetheefficiency

withwhichIPaddressescouldbedeployedandused.

Summary

Thebinarymathematicsandbinarytodecimalconversionspresentedinthis chapterareessentialtounderstandingtheIPaddressspace.Althoughthevarious classesofaddresseshavepassedintoobsolescence,theirmemorylingerson. Quiteafewnetwork-savvypeoplestillthinkintermsofclassesandoftendescribe theirnetworkasbeingaClassA,B,orC.Moreimportantly,thetopicspresented inthischapterformedthefoundationonwhichotherinnovationsadvancedthe

usefulnessandlongevityoftheIPv4addressspace.Thenexttwochaptersfocus

onsplittinganetworkaddressblockintosubnetworks.Subnetting,asthatprocess

iscalled,isextremelyusefulinbuildingefficientaddressallocationschemes.

Chapter3.Fixed-LengthSubnetMasks

ThefirstsignificantfeatureretrofittedtotheIPv4addressspacewasthe

introductionofsupportforathirdtierinitsarchitecture.AsdiscussedinChapter

2,"ClassicalIP:TheWayItWas,"theIPaddressspacefeaturesatwo-tier

hierarchyinwhicheachaddressconsistsofanetworkaddressandahostaddress

withinits32-bitstructure.Suchflatnessdistinctlylimitsscalabilityinanumberof

ways.Perhapsthemostconfininglimitationisthattheaddressspaceassumes

thatallnetworksfitintooneofjustthreedifferentsizesofnetworkssmall,

medium,andextremelylarge.

Creatingathirdtierforidentifyingsubnetworkaddressesisarelatively

straightforwardconceptthatinvolves"borrowing"bitsfromthehostportionofthe

address.Thesebitsareusedtocreatesubnetworkaddressesasanextensionof

thenetworkaddress.Inotherwords,smallernetworkscanbecreatedand

uniquelyaddressedfromlargernetworksandnetworkaddressspaces.Implicitin

theword"subnetwork"isthefactthatthethirdtierofaddressinformationisof

onlylocalsignificanceanduse.Thepresenceorabsenceofsubnetworksdoesnot

affectroutingtothatnetworkaddressfromaglobalperspective.Withina

subnettednetwork,thesubnetworkaddressisusedforrouting.

Thischapterexplainswhatbenefitisderivedfromthecreationofathirdtierof

addressingandexploresthemathematicsthatsupporttheuseoffixed-length

subnetworkmasks(FLSMs).Keepinmindthatthischapterexplainshow

subnettingusedtobedone(emphasisonthepasttense).Althoughfixed-length

subnettingisfunctionallyobsolete,youmightstillencounteritinlegacy

networks.Despitethisfunctionalobsolescence,FLSMservesasasimplified

introductiontoastill-relevantconcept.Evenmoreimportant,FLSMisstilla

highlyrelevanttopicformanyproprietarytechnicalcertificationexams.

highlyrelevanttopicformanyproprietarytechnicalcertificationexams.

IntroductiontoSubnetting

Subnetting,asthisprocessismorecommonlycalled,isaremarkablylogicaland

mathematicalprocess.Understandingthemathematicsofsubnettinghelpsyou

developandimplementefficientsubnettingschemesthatmakebetteruseof

availableaddressspaces.Thatistheexplicitgoalofsubnetting:touseanaddress

spacemoreefficiently.Unfortunately,subnettingisthemostconfusingandleast-

understoodaspectofIPv4.Thisislargelyduetothefactthatitmakessenseonly

whenviewedinbinarynumbers,yetmostpeoplethinkintermsofdecimal

numbers.ForthatreasonaloneIrelyextensivelyontheuseofbinary-to-decimal

translationstodemonstratetheconceptandapplicationsofsubnettingthroughout

thischapter.

Someofthespecifictopicswe'llexamineinclude

Therationalefordevelopingathirdtierofaddressing

Thelogicandmathematicsthatformthebasisofasubnet

ThesubnetmaskthatisusedtospecificallyidentifywhichbitsoftheIP

addressareusedfornetworkandsubnetworkidentification

Theconceptofanextendednetworkprefix

Examiningthesetopicspreparesyouforamorethoroughinvestigationoffixed-

lengthsubnetting.Inthelasthalfofthischapteryouwillseehowsubnetting

worksindifferent-sizednetworksandwithdifferent-sizedsubnets.

TheNeedforaThirdTierofAddressing

Inessence,subnettingoffersathirdtierwithintheIPaddressinghierarchy.The

needforathirdtierofaddressingbecameapparentfairlyearlyoninthe

Internet'sdevelopment.TheInternet'stwo-levelhierarchyassumedthateachsite

connectedtotheInternetwouldcontainonlyasinglenetwork.Therefore,each

sitewouldcontainonlyasinglelocal-areanetwork(LAN)thatcouldbesatisfied

byasingleblockofIPaddresses(characterizedbymultiplecontiguoushost

addresseswithinasinglenetworkaddress).Consequently,onlyasingle

connectiontotheInternetwouldsufficeforinterconnectivityneeds.

By1985,thiswasnolongerasafeassumption.Althoughmostorganizations

connectedtotheInternetcouldcontinuetooperatewithjustoneconnectionto

theInternet,feworganizationshadjustoneLAN.Thedawnoftheclient/server

erawasathand,andatwo-leveladdresshierarchywassuddenlyobsolete.

Organizationssuddenlybeganexperiencingtheeffectsofreachingeitherthe

technologicalorscalabilitylimitsoftheirtechnologyplatforms.

Inotherwords,somenetworksneededtobebrokenintosubcomponentsto

improveperformance.Thiswasparticularlytrueofearly,sharedEthernetLANs.

OtherorganizationsfoundthemselveswithdifferentLANtechnologieswithinthe

samelocation.That'snotuncommonwhenbudgetsaredistributedandeachgroup

intheorganizationmakesitsownpurchasingdecisions.Otherorganizations

mighthavefoundthemselvessimplytryingtospantoogreatadistancewiththeir

LAN.

Thus,severalmotivatingforcespointedinthesamedirection:Anenhancementto

theIPaddressarchitecturewasneededspecifically,athird,local,hierarchicaltier

ofaddressing.

Tobetterappreciatewhythisisthecase,considerFigure3-1.

Figure3-1.TheEmergenceofMultipleNetworksPerSiteCreated

ProblemsfortheIPAddressSpace'sTwo-LevelHierarchy

ProblemsfortheIPAddressSpace'sTwo-LevelHierarchy In Figure3-1

InFigure3-1,youcanseethattherouterinLocationBhoststwodifferentLANs.

Eachnetworkmusthaveitsownnetworkaddress;otherwise,othernetworks

won'tbeabletocommunicatewithdevicesconnectedtoit.Thisholdstrueforthe

twonetworksatthesamelocation.Theyareconnectedtodifferentinterfaceson

thesamerouter,andtherouterisresponsibleforgoverningand/orfacilitating

communicationsbetweenthem.Dependingonhowthatrouterisconfigured,it

hasseveralmainresponsibilities.Withoutgettingintoadissertationonthe

mechanicsandfunctionsofroutingprotocols,sufficeittosaythattherouteris

responsibleforthefollowing:

Advertisingthepresenceofthetwonetworksdirectlyconnectedtoit

Forwardingoutboundtraffic

Enablingcommunicationsbetweenitstwodirectly-connectednetworks

Forwardinginboundtraffictotheappropriatenetwork

Implicitintheseresponsibilitiesistheassumptionthattherouterhasameansof discriminatingbetweenthetwolocalnetworks.Inotherwords,theymusteach havetheirownnetworkaddress.IntheClassicalIPenvironment,eachofthese networkswouldhaverequireditsownaddressspace.So,ifyouassumethateach

LANconsistedofjust40totaldevices,twoClassCnetworkswouldhavebeen

required.Thattranslatesintotheassignmentof512IPaddresseswhenjust100

wouldhavesufficed,withabitofroomtospare.That'saremarkablewasteof

addresses.Itdoesn'ttakeatremendousamountofimaginationtoenvisionhow

suchwastecouldrapidlydepleteafinitesupplyofaddresses.Clearly,abetter

approachwasrequired.

Intheory,bothnetworkscouldeasilyshareasingleClassCnetworkaddressand

stillhavealotofroomforgrowth,ifonlytherewereawaytosplitupanetwork

addresslocally.Thisiswheresubnettingcomesin.

Eachnetworkatalocationrequiresitsownnetworkaddressinorderto internetwork,butthatnetworkaddress(whichisreallyjustasubnetwork address)needstobeuniqueonlylocally.So,ifyouassignedasingleClassC

network,suchasnetwork192.168.9.0,tothislocation,theentireInternetwould

usetheaddress192.168.9tocommunicatewithmachinesatthislocation,

regardlessofwhichLANtheywereon.Thataddress192.168.9isthenetwork

address.Itremainsthebasisofreachingallthesubnetworkswithinthisnetwork.

Addressesfrom192.168.9.1through192.168.9.128couldbeassignedtothe

EthernetLANshowninFigure3-1,and192.168.9.129through192.168.9.255

couldbeassignedtotheTokenRingLAN.However,thatputstheonusonthe

routeratthatlocationtodeterminewhichinterfacetouseinforwardinginbound

packets.Howtherouterdoesthisrequiresacloserlookatthemathematicsof

subnetting.

TheConceptofSubnetting

Theproblemdescribedintheprecedingsectiondemonstrateswhyathirdtierof addressingisnecessary.Whattheexampledidn'tprovideisanexplanationofhow todevelopthattier.Subnettingwasfirstexploredanddefinedinaseriesof

loosely-relatedRFCsnumbered917,940,and950.TheseRFCscalledforthe

creationofathird,logical,butlocaltierofaddressingtobecreatedfromthe

existingaddressarchitecture.RecallfromChapter2thatIPaddressesare32bits

inlengthandconsistoftwocomponentsanetworkaddressandahostaddress.

Thenetworkaddresscannotbetouched,becauseitisusedgloballyforroutingto

andfromthenetworkitidentifies.Thatleavesthehostaddressastheonlyviable

meansofdevelopingathirdtierofaddressing.

PerRFC950,thehostaddressmaybecarveduptocreateasubnetworkaddress.

Thus,thethreetiersofaddressingare

NetworkaddressThus,thethreetiersofaddressingare Subnetaddress Hostaddress

SubnetaddressThus,thethreetiersofaddressingare Networkaddress Hostaddress

HostaddressNetworkaddress Subnetaddress

Yourabilitytosubnetdependsdirectlyonthenumberofbitsallocatedbetweena networkandhostaddress.That'sbecausethesubnetaddressiscarvedfromthe hostaddress.ThemorehostbitsanIPaddresshas,themoresubnetsthatcanbe created.However,thereisaninversecorrelationbetweenthenumberofsubnets thatarecreatedandthenumberofhoststhatcanbesupportedineachsubnet.In effect,youborrowbitsfromthehostaddresstocreatethesubnetaddress. Logically,themorebitsyouborrowfromthehostfieldtocreatesubnets,the fewerbitsthatremainfortheidentificationofhosts.Ofcourse,notallIPaddress

spaceswerecreatedequal.TheClassAaddressspaceoffersmorethan16million

hostaddresses.Borrowingbitsfromafieldofthatsizewouldn'tappreciably reducetheavailablepoolofaddresses.Infact,subnettingaClassAaddressspace wouldhavethetremendousbenefitofmakingmoreefficientuseoftheavailable

poolofaddresses.SubnettingaClassCnetworkaddressspacewithjust256total

availablehostaddressesmakesyouquicklyawareofthefinitenatureofthose

addresses.We'lldelveintomoreexamplesofsubnettinglaterinthischapter.The

nextsignificantconcepttoacknowledgeisthatitiscrucialtohaveameansof

trackinghowmanybitsareborrowed.IPaddressesthataresubnettedlook

exactlylikeIPaddressesthataren'tsubnetted,soanothermechanismisrequired

tokeeptrackofsubnetsizes.Thismechanismiscalledthesubnetmask.Subnet

masksarestaticallydefinedoneachendpointdevice(suchasaprinterordesktop

computer)connectedtothenetwork.Theconceptofamaskcanbedifficultto

grasp.Manypeoplegainaworkingappreciationofhowtomakenetworked

devicesfunctionwithoutreallyunderstandingmasks.We'lllookatsubnetmasks

inmuchmoredetailinthefollowingsection.

TheSubnetMask

Asubnetmaskisa32-bitbinarynumberthatcanbeexpressedineitherdotted-

decimalordotted-binaryform.Inthisregard,asubnetmaskisstructurally similartoanIPaddress.However,therearesomeimportantdistinctions.For example,amaskisnotroutable,nordoesithavetobeunique.However,a subnetmaskdoesserveanimportantfunction:Itisusedtotellendsystems (includingroutersandhostsintheLAN)howmanybitsoftheIPaddress'shost fieldhavebeenborrowedtoidentifythesubnet.Thebitsinthemaskthatidentify

thenetworkaddress,aswellasthesubnetaddress,aresetto1s.Theremaining

bits,whichareusedforhostaddresseswithineachsubnet,aresetto0s.

Onepotentiallyconfusingpointaboutmasksisthattheycanbeusedtoidentifya

network,asubnetwork,orboth.Anetworkmaskidentifiesjustthebitsusedto

identifyanetworkaddress.Asubnetmaskidentifiesallthebitsusedfornetwork

andsubnetworkidentification.Thisleadsustotheconceptoftheextended

networkprefix,whichwe'llexamineinthenextsection.

ExtendedNetworkPrefix

Itisimportanttonotethattheborrowedbitsarealwaystheleftmostbitsinthe

hostfield.Thus,thesubnetaddressisnumericallycontiguouswiththenetwork

address.Together,theyformtheextendednetworkprefix.Theremainingbitsare

usedforhostidentification.

Tobetterdemonstratethisconceptofanextendednetworkprefix,considerthe

contentsofTable3-1,whichshowsthedotted-binaryanddotted-decimal

equivalentsofnetwork(notsubnet)masksforthevariousclassesofIPaddresses.

Notethatthemasksinthistablearejustnetworkmasks.

Table3-1.NetworkMasks

AddressClass

Dotted-DecimalForm

Dotted-BinaryForm

ClassA

255.0.0.0

11111111.00000000.00000000.00000000

ClassB

255.255.0.0

11111111.11111111.00000000.00000000

ClassC

255.255.255.0

11111111.11111111.11111111.00000000

BecausethemasksinTable3-1arenetworkmasks,notsubnetworkmasks,only

thosebitsthatareusedtoidentifythenetworkaddressaresetto1s.Thus,a

networkmaskletsyouseethat,intheoldClassAnetworkaddressspace,exactly

8bitsareusedtoidentifythenetworkand24areusedforhostidentification.

Similarly,theClassCnetworkspacefeatures24bitsfornetworkidentification,