Things They Never Taught You About Naming and Addressing

65
October 20, 10 . 1 © John Day, 2010 All Rights Reserved Things They Never Taught You About Naming and Addressing “Did I ever tell you about Mrs. McCave Who had 23 sons and she named them all Dave? Well she did and that was not a very smart thing to do Because now when she calls, “Yoo-hoo, come into the house, Dave!” All 23 of her sons come on the run “And now she wishes that she had named them . . .” <there follows a wonderful list of Dr. Seuss names she wishes she’d named them and then concludes with this excellent advice.> “But she didn’t do it and now it is too late.” - Dr. Seuss Too Many Daves Digital Technology Center University of Minnesota John Day Octl 2010

Transcript of Things They Never Taught You About Naming and Addressing

Page 1: Things They Never Taught You About Naming and Addressing

October 20, 10 . 1© John Day, 2010

All Rights Reserved

Things They Never Taught You AboutNaming and Addressing

“Did I ever tell you about Mrs. McCaveWho had 23 sons and she named them all Dave?Well she did and that was not a very smart thing to doBecause now when she calls, “Yoo-hoo, come into the house, Dave!”All 23 of her sons come on the run“And now she wishes that she had named them . . .”

<there follows a wonderful list of Dr. Seuss names she wishes she’dnamed them and then concludes with this excellent advice.>

“But she didn’t do it and now it is too late.” - Dr. Seuss Too Many Daves

Digital Technology Center

University of MinnesotaJohn Day

Octl 2010

Page 2: Things They Never Taught You About Naming and Addressing

October 20, 10 . 2© John Day, 2010

All Rights Reserved

Introduction

• This is probably the single most important topic in network architecture– And not really covered in university courses.

• And one of the most difficult and subtle topics in all of networking.– Sometimes it seems that it is more philosophy than engineering.– Although names have figured heavily in philosophy and logic, it is naming as it

relates to language. While it is informative, it is mostly not germane.– But there is nothing about addressing per se.

• The Internet has several addressing related problems today:– Address space exhaustion– Multihoming is not supported– Mobility is cumbersome and complex– Router table size is exploding

Page 3: Things They Never Taught You About Naming and Addressing

October 20, 10 . 3© John Day, 2010

All Rights Reserved

The Origins of Internet AddressingThe Root Cause of our Problems

IMP

56K Trunk

56K Trunk

56K Trunk

56K Trunk

HostHost

Host Host

Each ARPANet IMP (switch) had ports to support a maximum of 4 trunks and 4 hosts.Each IMP had a number. The host address (IP address) was the IMP # and the

Host #, i.e. a port number. Maximum number of hosts was huge: 63.

So a host’s address was its IMP Port Number.

Page 4: Things They Never Taught You About Naming and Addressing

October 20, 10 . 4© John Day, 2010

All Rights Reserved

Was There a Reason?

Was there a lot of thought given to how addressing should work?

Not really.

We were doing good to do this much!There were many much bigger problems to overcome:

Like just moving data

And addressing is a hard problem.

SureIt was easy to build for an experimental network of this size.

Page 5: Things They Never Taught You About Naming and Addressing

October 20, 10 . 5© John Day, 2010

All Rights Reserved

Did it take long to realizethere was a problem?

IMP14

IMP20

14, 1 20, 3

Host

Nope.

First time (~ 1972) one of the Air Force bases took us at our word that the network was suppose to be survivable and asked for links to two different IMPs

to connect its host to the Network.

Naming the hosts by the names of their interfacesmeant that the two connections looked like two hosts to the Net.

Still does.

Page 6: Things They Never Taught You About Naming and Addressing

October 20, 10 . 6© John Day, 2010

All Rights Reserved

Address Spaces in Operating Systems(From my OS Course)

An name space is defined as a set of identifiers with a given scope.An address space is a location-dependent name space.In Operating Systems, we have found a need for 3 such independent spaces.Virtually all uses of names in computing are for locating.

Application Name Space

Logical Name Space

Physical Name Space

Human use, relatively constant,not at all tied to the hardware,i.e. location-independent

Location Dependent but HardwareIndependent; Creates a logical addressspace larger than the physical memory;Allows processes to be re-locatable.

Location-Dependent andHardware Dependent

Page 7: Things They Never Taught You About Naming and Addressing

October 20, 10 . 7© John Day, 2010

All Rights Reserved

BBN botched the ARPANET Addressing,because they were from Boston.In Boston, there is only one way to get anywhere,

so it is easy to confusea route and an address as being the same.

Had they been from the Midwest and lived on a grid,they would have known there were lots of ways to get between two points;

and that routes and addresses are two entirely different things.

(It is not true, but it makes a good story!)

The real reason is: that we did what the phone company and every other network up to that point had done:

Name the wires coming out of the switches.

Page 8: Things They Never Taught You About Naming and Addressing

October 20, 10 . 8© John Day, 2010

All Rights Reserved

Saltzer’s View of Networks• Application names map to node addresses.• Node addresses map to points of attachment addresses.• Routes are sequences of points of attachments.

– Just as in an operating system.– But networks are more general than operating systems.

Application Name

NodeAddress

Point of AttachmentAddress

Page 9: Things They Never Taught You About Naming and Addressing

October 20, 10 . 9© John Day, 2010

All Rights Reserved

Saltzer Missed a Case(Hadn’t Happened Yet)

• There can be More than One path to the Next Hop.– This case does not occur in computing systems. There is only one path

from the CPU to memory.• Must route on the Node addresses, not the point of attachments

Application Name

NodeAddress

Point of AttachmentAddress

Page 10: Things They Never Taught You About Naming and Addressing

October 20, 10 . 10© John Day, 2010

All Rights Reserved

Generalizing Saltzer to Networks of Networks• Directory maintains the mapping between Application-Names and the node

addresses of all Applications reachable without an application relay.• Routes are sequences of node addresses used to compute the next hop.• Node to point of attachment mapping for all nearest neighbors to choose path

to next hop. (Saltzer missed this because they hadn’t occurred yet.)• This last mapping and the Directory are the same:

– Mapping of a name in the layer above to a name in the layer below of all nearestneighbors.

Directory

Route

Path

Page 11: Things They Never Taught You About Naming and Addressing

October 20, 10 . 11© John Day, 2010

All Rights Reserved

Applying Results to Real Architectures: The Internet(This is a Network Architecture)

• The most striking feature is that half of the addressing architecture is missing.– No wonder there are addressing problems.– The only identifier we have for anything is the IP address.

• There are no node addresses and no application names.– And the point of attachment is named twice!– If this is an Internet Protocol, where are the Network Addresses?– Domain Names are synonyms for IP addresses. URLs are pathnames through the

stack and location dependent.

MAC Address

IP Address

Socket (local)

ApplicationApplication

Name

Node Address

Point of AttachmentAddress

As if your computer worked only with absolute memory addresses.

Page 12: Things They Never Taught You About Naming and Addressing

October 20, 10 . 12© John Day, 2010

All Rights Reserved

What About This Missed Case?The Real World is More Diverse

(for better or worse, OSI understood that, sort of)

• Three distinct cases: there may be a wire, a multi-drop “wire” or another network.– A simple wire requires no point of attachment address, (source of the confusion)

• If more than one local identifiers will suffice.– A multi-drop “wire” requires point of attachment identifiers, not really addresses.– A network generally requires addresses, point of attachment? That depends.– If the wire needs more error control then LLC. If the network needs more, a subnet

dependent convergence protocol– If an Internet then Subnet Independent (node) addresses are necessary (CLNP) to

operate over Subnet-Access (X.25, IP, MAC)» (Another indicator of a repeating pattern)

Subnet-Access

SubnetDependent

SubnetIndependent

Page 13: Things They Never Taught You About Naming and Addressing

October 20, 10 . 13© John Day, 2010

All Rights Reserved

The Fundamental Flaw in theIP Architecture

• Given what we have seen we can see the mistake,– By continuing to route on the interface, the Internet architecture assumes there is a

point-to-point link under IP.• An Internet Protocol should have networks under it.• A Network is a “wire with multiple ends”, i.e. requires addresses.

– Points of attachment– Where are these in the architecture?

• By routing on the interface,– IP is a Network Protocol not an Internet Protocol– After IPng’s emphatic refusal to name the node, there has been a search for a

workaround. There is none. Loc/id split is simply the latest attempt. It is in a veryreal sense post-IPng trauma.

Page 14: Things They Never Taught You About Naming and Addressing

October 20, 10 . 14© John Day, 2010

All Rights Reserved

What Does PNA Tell Us?

• O, yea, What is PNA?• Patterns in Network Architecture

– The result of distilling principles from 40 years of experience• Trying to discern what the problem was telling us

– Or maximizing the invariances and minimizing the discontinuities

Page 15: Things They Never Taught You About Naming and Addressing

October 20, 10 . 15© John Day, 2010

All Rights Reserved

The IPC Model(A Purely CS View)

RelayingAppl

EFCPEFCP

EFCP EFCP EFCP EFCP EFCP EFCP

MuxMux

User Applications

Distributed IPC

Facilities

Page 16: Things They Never Taught You About Naming and Addressing

October 20, 10 . 16© John Day, 2010

All Rights Reserved

We Should Have Seen It Sooner

SNIC

SNDC

SNAC

LLC

MAC

Application

Session

Presentation

Transport

Network

Data Link

The Repeating StructureH

ad Shown Itself Even There

Page 17: Things They Never Taught You About Naming and Addressing

October 20, 10 . 17© John Day, 2010

All Rights Reserved

The Implications• Networking is IPC and only IPC.

– We had been concentrating on the differences, rather than the similarities.– Of course, there are layers! What else do you call cooperating shared state

that is treated as a black box? A waffle!?• All layers have the same functions, with different scope and range.

– Not all instances of layers may need all functions, but don’t need more.• A Layer is a Distributed Application that performs and manages IPC.

– A Distributed IPC Facility (DIF)• This yields a theory and an architecture that scales indefinitely,

– i.e. any bounds imposed are not a property of the architecture itself.• Solutions to many “big problems” are a consequence of the structure• Addresses are internal to the layer. Application only knows

destination application name and local handle.

Page 18: Things They Never Taught You About Naming and Addressing

October 20, 10 . 18© John Day, 2010

All Rights Reserved

A Little Remedial Networking• In 1980, Richard Watson proved that for distributed synchronization, it

was necessary and sufficient that 3 timers be bounded:• Maximum Packet Lifetime• Maximum number of Retries• Maximum time before Ack

– That no explicit state synchronization, i.e. hard state, is necessary.• SYNs, FINs are unnecessary

• IOW, all properly designed data transfer protocols are soft-state.• Including protocols like HDLC

• This also defines the bounds of interprocess communication andnetworking– To be networking, MPL must be bounded.– Otherwise, it is remote storage.

Page 19: Things They Never Taught You About Naming and Addressing

October 20, 10 . 19© John Day, 2010

All Rights Reserved19

What a Layer Looks Like

• Processing at 3 timescales, decoupled by either a State Vector or a ResourceInformation Base– IPC Transfer actually moves the data ( ≈ IP + UDP)– IPC Control (optional) for retransmission (ack) and flow control, etc.– IPC Layer Management for routing, resource allocation, locating applications,

access control, monitoring lower layer, etc.

IPCTransfer

IPCControl IPC Management

DelimitingTransfer

Relaying/ MuxingPDU Protection Common Application

Protocol

Applications, e.g., routing, resource allocation, access control, etc.

Application-entities Application Process

Page 20: Things They Never Taught You About Naming and Addressing

October 20, 10 . 20© John Day, 2010

All Rights Reserved

Only Three Kinds of Systems

• Middleboxes? We don’t need no stinking middleboxes!• NATs: either no where or everywhere,

• NATs only break broken architectures• The Architecture may have more layers, but no box need

have more than the usual complement.– Hosts may have more layers, depending on what they do.

Hosts

InteriorRouters

BorderRouters

Page 21: Things They Never Taught You About Naming and Addressing

October 20, 10 . 21© John Day, 2010

All Rights Reserved

How Does It Work?The Internet and ISPs

• The Internet floats on top of ISPs, a “e-mall.”– One in the seedy part of town, but an “e-mall”– Not the only emall and not one you always have to be connected to.

Public Internet

ISP 1 ISP 2 ISP 3

Page 22: Things They Never Taught You About Naming and Addressing

October 20, 10 . 22© John Day, 2010

All Rights Reserved

How Does It Work?The Internet and ISPs

• But there does not need to be ONE e-mall.– You mean!

• Yes, it is really an INTERnet!

Public Internet

ISP 1 ISP 2 ISP 3

Internet Rodeo Drive

Utility SCADAMy NetFacebook Boutique

Internet Mall of America

Page 23: Things They Never Taught You About Naming and Addressing

October 20, 10 . 23© John Day, 2010

All Rights Reserved

Okay, That is Far too Briefbut all we have time for

• This has major implications for:– Congestion Control– Security– Everything, including of course– Naming and Addressing

Page 24: Things They Never Taught You About Naming and Addressing

October 20, 10 . 24© John Day, 2010

All Rights Reserved

Names and Name Spaces• A name space, NS, is a set {N} of names from which all names for a given

collection of objects are taken. A name from a given name space may be boundto one and only one object at a time.

• A name is a unique string, N, in some alphabet, A, that unambiguously denotessome object or denotes a statement in some language, L. The statements in L areconstructed using the alphabet, A.

• A function, MNS, which defines the class of objects, M, that may be named withelements of NS. This is referred to as the scope of the name space (see below).This may refer to actual objects or the potential for objects to be created.

• A function, FMNS, that defines the mapping of elements of NS to elements of M.This function is one-to-one and onto. The result of this function is called abinding.

Page 25: Things They Never Taught You About Naming and Addressing

October 20, 10 . 25© John Day, 2010

All Rights Reserved

Operations on Names

• Assignment, allocates a name in a name space, essentially marks it in use.Deassignment, removes it from use. Assignment makes names available to bebound. This allows certain portions of a name space to be “reserved,” notavailable for binding.

• Binding, maps a name to an object. Once bound, any reference to the nameaccesses the object. Unbinding breaks the binding. Once unbound, anyreference will not access any object.

– An object ceases to exist when the last name referring to it is unbound.• Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an

object in a particular context, given its name.”– An object cannot be identified without locating it nor located without identifying it.

Page 26: Things They Never Taught You About Naming and Addressing

October 20, 10 . 26© John Day, 2010

All Rights Reserved

Types of Names• Objects may be assigned more than one name. These are called synonyms or

aliases.– Objects that may have more than one name, the names are unambiguous.– Objects that must have only one name, the names are unique.

• Names may also denote sets of names. Associated with the set is a rule thatdetermines which names are returned when the name of the set is resolved. Innetworking,

– A rule that returned all members has been called multicast.– A rule that returned one member has been called anycast.– We will refer to all forms as whatevercast!

• Synonyms or names of sets may be taken from the same or different namespaces.

– The name of an object is the name of a set of one element.

Page 27: Things They Never Taught You About Naming and Addressing

October 20, 10 . 27© John Day, 2010

All Rights Reserved

Resolving Names• There are 2.5 means to resolve names:

– Exhaustive Search– The name provides hints to narrow the search.

• The “half” is indirection:– The name or part of the name points to an object that points to a name.

• Hierarchy is the most common form of embedding hints in a name.– Hierarchy imposes a topological structure on the name space, which constrains the

names that can be assigned to an object.– There may be search rules for how to utilize the “hints.”

• Every thing up to this point is applicable to all naming in computing systems.

Page 28: Things They Never Taught You About Naming and Addressing

October 20, 10 . 28© John Day, 2010

All Rights Reserved

Is the Application in or out of the IPC environment?

• The early ARPANet/Internet didn’t worry too much about it. Theydidn’t need to. They weren’t doing any new application development.

• By 1985, OSI had tackled the problem, partly due to turf. Was theApplication process inside or outside OSI?

• It wasn’t until the web came along that we had an example that ingeneral an application protocol might be part of many applications andan application might have many application protocols.

Page 29: Things They Never Taught You About Naming and Addressing

October 20, 10 . 29© John Day, 2010

All Rights Reserved

Applications and Communication

• The Application-Entity (AE) is that part of the application concernedwith communication, i.e. shared state with its peer.

• The rest of the Application Process is concerned with the reason forthe application in the first place.

• An Application Process may have multiple AEs, they assumed, fordifferent application protocols.

• So what does this mean for naming?– Pretty much read it off.

ApplicationProcess

Application-Entities

Page 30: Things They Never Taught You About Naming and Addressing

October 20, 10 . 30© John Day, 2010

All Rights Reserved

Application Naming

• Application-process names (APN) are globally unambiguous and location-independent,but system-dependent.

– They may have synonyms of less scope from the same or different name space.– There may be multiple instances of the process in the same system.

• APN-instance-identifiers are unambiguous within the scope of the Application Process.

• Application-entity-identifiers are unambiguous within the application process.– There may be more than one Application-entity (AE) in a process.

• Unambiguous within the scope of the Application Process.– There may be more than one instance of each type of Application-Entity.

• AE-instance-identifiers are unambiguous within the scope of the AE.

• Distributed Application Name is the name of a set of application processes and system-independent.

• Few applications need all of these but a complete theory requires all of them.

ApplicationProcess

Application-Entities

Page 31: Things They Never Taught You About Naming and Addressing

October 20, 10 . 31© John Day, 2010

All Rights Reserved

What about IPC?

• The IPC Model says that an IPC Process is simply an applicationprocess dedicated to doing IPC. What does this tell us about that?– There are four kinds of Application Entities:

• An Flow Allocator AE to manage the creation of flows,• A Data Transfer AE to control data transfer, and• RIB Daemon AE to maintain shared state among the IPC Processes• Managing IPC with the (N-1)-DIF/layer

Data Transfer AE(one per flow)

Flow Allocator(one per IPC

Proc)

RMT AE(one per IPC

Proc)

CAP AEs

IPC Process(Management)

RIB Daemon

Page 32: Things They Never Taught You About Naming and Addressing

October 20, 10 . 32© John Day, 2010

All Rights Reserved

What about IPC Naming?• An IPC Process has an Application Process Name, but give it a

synonym of scope limited to the layer.• Commonly called an address• In larger layers, the address may be structured to be more effective.

• There are three local identifiers:– A Flow Allocator AE Instance Identifier,

• Commonly called a port-id– A Data Transfer AE Instance Identifier, and

• Commonly called a connection-endpoint-identifier– That are concatenated to form a connection-identifier.

AddressCEP-ids

Flows

Port-ids

bindings

Page 33: Things They Never Taught You About Naming and Addressing

October 20, 10 . 33© John Day, 2010

All Rights Reserved

To Summarize

• All identifiers except address and connection-id are local to the IPC Process.– Scope of the address is the Layer, and is not visible outside.– Scope of the connection-id is the participants in the connection.

• None has more scope than it needs.

AE-identifierIPC Process (unambiguous)DIF Management Updates

Concatentation of data-transfer-AE-instance-identifiers

Src/Dest Data Transfer AE(unique)

Connection-id

Data Transfer AE Instance-Identifier

Data Transfer AE (unique)Connection-endpoint-identifier

Allocation AE-Instance-Identifier

Allocation AE (unique)Port-id

Synonym for IPC Process’Application Process Name

Layer (unambiguous)Address

Application Process NameGlobal (unambiguous)Application Process Name

Application TermScopeCommon Term

Page 34: Things They Never Taught You About Naming and Addressing

October 20, 10 . 34© John Day, 2010

All Rights Reserved

Principles of Naming and Addressing: I

• Application names indicate what, not where.– Hence, names are organized to put similar “whats” near each other.– So what “whats” do we use?

• There is no single answer. Depends on the purpose and the importance of look upperformance generally in a distributed directory.

– The Scope of an Application Name Space is defined by the chain of databasespointed to by the Directory Forwarding Table.

• Different Application Name Spaces may name the same objects.– It is here that the concepts of query and name merge

• Some schemes will produce multiple results; some a unique result• Given the move to greater granularity more schemes will be useful in keeping them

tractable and useful.– The only requirement for IPC is that some collection of synonyms be associated

with an application process and their mapping to the directory are made known.

Page 35: Things They Never Taught You About Naming and Addressing

October 20, 10 . 35© John Day, 2010

All Rights Reserved

Principles of Naming and Addressing: II• Addresses indicate where – Not quite

– Within a DIF (layer), the “what” of interest is “forwarding.” Synonyms areassigned to facilitate forwarding, call it a forwarding-id or f-id.

– If the DIF has a sufficiently large number of members (or maybe if it doesn’t) to makeF-ids more useful.

• They are structured to reflect which elements are near each other for some concept ofnear. This is an address.

• This is an “address” in the sense of its normal usage, expressing “where” withoutindicating “how to get there.”

– An address is an synonym for an IPC Process whose scope is the DIF andstructured to be useful within the layer.

– “where” is just one kind of “what”

– Application Names and Addresses are simply two different means for locating anobject in different contexts. In this case, the object is an IPC Process.

Page 36: Things They Never Taught You About Naming and Addressing

October 20, 10 . 36© John Day, 2010

All Rights Reserved

Principles of Naming and Addressing: III

• A F-id (or address) is only unambiguous within the scope of a layer.– And no more, otherwise this leads to overloading the semantics of the address

which leads to problems– MAC addresses are 3 - 4 times longer than they need to be or should be.

• Routes are sequences of (node) addresses.• The relation of node and point of attachment is relative and hence irrelevant.

• A node address is an (N)-F-id;• A point of attachment address is an (N-1)-F-id.

– A layer routes on its address. A node address routes this layer’s address, the pointof attachment address is the address of the node in the layer below and is routed bythe layer below, not by this layer.

Page 37: Things They Never Taught You About Naming and Addressing

October 20, 10 . 37© John Day, 2010

All Rights Reserved

Principles of Naming and Addressing: IV• Since the address is structured to facilitate its use within the layer, it must be assigned by

the layer.– Only the layer knows how to make the synonym useful.

• Any addresses assigned by anyone else are not addresses.• Names of systems are useful management functions, but not for forwarding.

– Names of Hosts are distinct and not related to addressing.• An address should not be constructed by concatenating an identifier in this layer with

one from the lower layer, i.e. don’t embed MAC addresses in IP addresses.

– Why? This construction is called a pathname, hence it is route-dependent!– Addresses in adjacent layers should be completely independent.– Hierarchical address assignment within a layer organizes addresses in this layer, not the layer

below.– Each layer is a level of indirection.

Page 38: Things They Never Taught You About Naming and Addressing

October 20, 10 . 38© John Day, 2010

All Rights Reserved

Implications of the Naming Model: I

• Recursion either reduces the number of routes or shortens them.

Backbone

Regionals

Metros

Page 39: Things They Never Taught You About Naming and Addressing

October 20, 10 . 39© John Day, 2010

All Rights Reserved

Naming Implications of the Model: II

• Multihoming is a consequence of the structure.– Simply an IPC Process having more than one (N-1) binding.

• Since we are routing in this layer, there is no big deal– By routing on the address, the destination address is the destination regardless of

which interface the PDU arrived on. It is route-independent.• Route on our address, not someone else’s . . . well, duh!

– With recursion, no scaling problems, no LISP, no LISP support protocols.

An Internet

Provider Independent

Provider dependent

Application

Page 40: Things They Never Taught You About Naming and Addressing

October 20, 10 . 40© John Day, 2010

All Rights Reserved

Naming Implications of the Model: III

• Mobility is just dynamic multihoming.– Merely acquiring new (N-1)-addresses to use or losing others.

• No different than so-called “static” case, just more frequent.– (N)-address may change either by joining a different DIF

• Joining another DIF is simply acquiring another point of attachment, another potential path.– or if its topological significance changes.

• Assigning a new address is simply creating adding an additional synonym.

An Internet

Provider Independent

Provider dependent

Application

Page 41: Things They Never Taught You About Naming and Addressing

October 20, 10 . 41© John Day, 2010

All Rights Reserved

Naming Implications of the Model: IV

• How to Change the Address of a member of the DIF:– Assign the IPC Process a new synonym from the address space;– Senders use the new (N)-address as source in all active flows– Receivers record the source address of all incoming PDUs as the current address.– Advertise routes to the new address, begin to deprecate the old address– After a few routing updates, the old address simply disappears.

• Changing addresses is just another name to route to. That two go to the sameplace is mere coincidence.

• PDU Processing is unaffected by the change.

An Internet

Provider Independent

Provider dependent

Application

Page 42: Things They Never Taught You About Naming and Addressing

October 20, 10 . 42© John Day, 2010

All Rights Reserved

Implications of the Model: VChoosing a Layer

• In building the IPC Model, the first time we had multiple DIFs (data link layers inthat case to choose from), we found we needed a task to figure out which DIF touse.

IAPDir

MuxFlowMgr

– User didn’t have to see all of the wires– But the User shouldn’t have to see all of the “Nets”

either.

• This not only generalizes but has major implications.

Page 43: Things They Never Taught You About Naming and Addressing

October 20, 10 . 43© John Day, 2010

All Rights Reserved

An Inter-Net Directory?

• Inter-DIF Directory determines via what DIFs applications are available.– If this system is a not member, it either joins the DIF as before– or creates a new one.

• Which Implies that the largest address space has to be only large enough for thelargest e-mall.

• Given the structure, 32 or 48 bits is probably more than enough.• You mean?

• Right. IPv6 was a waste of time . . .• Twice.

Inter-DIFMngr

Page 44: Things They Never Taught You About Naming and Addressing

October 20, 10 . 44© John Day, 2010

All Rights Reserved

So a Global Address Space is Not Required butNeither is a Global Application Name Space

Or More Correctly, There never is One.

Inter-DIFDirectory

To PeersIn Oher DIFs

Actually one could still have distinct names spaces within aDIFs (synonyms) with its own directory database.

• Not all names need be in one Global Directory.• Coexisting application name spaces and directory of distributed databases are

not only possible, but useful.• Needless to say, a global name space can be useful, but not a requirement

imposed by the architecture.• The scope of the name space is defined by the chain of databases that point to

each other.

Page 45: Things They Never Taught You About Naming and Addressing

October 20, 10 . 45© John Day, 2010

All Rights Reserved

An Object Lesson that showsIt is just as important

to keep practice close to theoryas it is to keep theory close to practice.

Philosophical Triangulation"In the practical arts, the theoretical leaves and blossoms must not be allowed to grow too high, but must be kept close to experience, their proper soil." - Clauswitz "If we have a correct theory but merely prate about it, pigeonhole it and do not put it into practice, then that theory, however good, is of no significance. Knowledge begins with practice, and theoretical knowledge is acquired through practice and must return to practice." - Mao Zhe Dong

Or Why We are in a Gawd-Awful Mess Right Now!

Page 46: Things They Never Taught You About Naming and Addressing

October 20, 10 . 46© John Day, 2010

All Rights Reserved

The First Great Internet Addressing Crisis

• In 1992, we have the first addressing crisis.– IPv4 addresses are getting scarce

• But the real problem is Router Table Size is increasing exponentially.• The IAB convenes the ROAD process

– Recommends CLNP as IPv7• Basically IP with variable length aggregateable addresses.• CLNP names the node. Hence, fixes the multihoming problem.

• The IETF goes berserk!– No OSI, no way, no how!

• A model? We don’t need no stinking model. We’ve got• Rough Consensus and Running Code!

Page 47: Things They Never Taught You About Naming and Addressing

October 20, 10 . 47© John Day, 2010

All Rights Reserved

The IPng Process• The Rules were:

– Fixed Length Address– Continue to Name the Interface.– At least 20 octets of address– Open Standard

• Violá! IPv6!• or anything but CLNP.

• Still no solution to multihoming– Problem is now 20 years old

Page 48: Things They Never Taught You About Naming and Addressing

October 20, 10 . 48© John Day, 2010

All Rights Reserved

All is Not Well

• Less than a Year later, light dawns (slightly)!– Name the Interface, but route aggregation is a must– Implies provider based assignment.– Means change providers, must renumber. WHAT!?

• Kind of shot yourself in the foot, eh?

• Transition is dual stack with a NAT– Once you have a NAT, you don’t need v6 . . . oops.

• How many feet do you have?

Page 49: Things They Never Taught You About Naming and Addressing

October 20, 10 . 49© John Day, 2010

All Rights Reserved

Techs Play Architect

• Finally around 2000, need to deal with multihoming, but– given negative reaction to naming the node, need a workaround

• Ahh! The problem is that we have been overloading the semantics ofthe IP address with location and identifier information.– We need to split them. Loc/id split is the Answer.– A locator we can route on and a flat endpoint id (EID)

• Psssst! Can’t identify something without locating it and vice versa– Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an

object in a particular context, given its name.”• Got another foot?

• Don’t bother me with pedantic terminology,– IPv6 is the future!

Page 50: Things They Never Taught You About Naming and Addressing

October 20, 10 . 50© John Day, 2010

All Rights Reserved

Trouble is Not Much Interest in v6• It offers no benefit to those who pay for adopting it

– They just don’t know they want it.• For the next decade, there is the hype:

– Better security, better QoS, better mobility– “A desert topping and a floor wax!” - Mike O’Dell

• In fact, all of these are the same as IPv4 . . . no different

• “IPv6 has all the benefit of a minor technology change with all thedisruption of a major fork-lift upgrade.” - Geoff Huston, 2008.– Just switch to v6 and all will be well.

• By 2000, dawning awareness the architecture is running out of steam– NEWARCH, Clean Slate, FIND and GENI are hot!– Starts to be a lot of talk about loc/id split.– This is clearly the answer . . . . (really?).

Page 51: Things They Never Taught You About Naming and Addressing

October 20, 10 . 51© John Day, 2010

All Rights Reserved

Houston, We Have a Problem(The Second Great Internet Addressing Crisis)

• October 2006, major presentation at IEPG.– Router table size is on the increase, due to multihoming.

• It is either quadratic or exponential, can’t tell yet.– (does it matter!?)

– Moore’s Law won’t bail us out this time.• This is a big time crisis. We are in big trouble.

• If not fixed, it is the end of the Internet as we know it.– Net will fragment. Costs in the core will skyrocket.– NetworkWorld sits on the story for a year.– Tons of papers written on loc/id split!

Page 52: Things They Never Taught You About Naming and Addressing

October 20, 10 . 52© John Day, 2010

All Rights Reserved

But We Do Multihoming!(not really)

• We kludge it.• Because we route on the interface, this forces route aggregation to be

provider-based.– Addresses with a common prefix go to the same provider then we can

store a single route (to the provider) rather than a route for every addresson that provider.

• To do multihoming, must assign provider-independent addresses ornew AS numbers (same thing).– Can’t be aggregated Router table size increases

– Remember what our problem is? Router table size is increasing

Page 53: Things They Never Taught You About Naming and Addressing

October 20, 10 . 53© John Day, 2010

All Rights Reserved

So Why Wasn’t It Fixed?

• Odd that a DoD network touted to survive nuclear attack didn’tsupport redundant links. Lots of “good reasons:”– Not that many hosts need to be multi-homed.

• Not then, but the ones that did were the ones everyone wanted to get to.– Not everyone should have to bear the cost for a few.

• Classic committee politics: Put a condition on the solution that guarantees anyproposal will be rejected (asymmetry in this case)

• Also assumes there is a cost.– Multihoming will be to different providers, so no point.

• Assumption is wrong and even if right assumes a static network.– Remember, we tried to fix it but it was rejected by the IETF.

Page 54: Things They Never Taught You About Naming and Addressing

October 20, 10 . 54© John Day, 2010

All Rights Reserved

But By This Time• Cisco and others start proposing solutions to the

multihoming problem.– Mostly requiring patches involving NATs and a bevy of new

protocols.– In particular, LISP or Loc/ID Split Protocol

• This makes everyone nervous, but what else to do?• Well, we could work out the theoretical framework so we can see

what we are doing.

• This is a crisis! We have to build something!• Best way known to stampede people to your view.

Page 55: Things They Never Taught You About Naming and Addressing

October 20, 10 . 55© John Day, 2010

All Rights Reserved

November 2008Houston, We have a Bigger Problem

• Dave Meyer calls, ‘I have an “architectural issue” to discuss.’– He has come across two problems in implementing LISP.– Both require doing path discovery.– Path discovery doesn’t scale.– LISP won’t scale. QED– He suspects that any loc/id approach will have the same problem.

• draft-meyer-loc-id-implications-01.txt• In case you didn’t notice, we just went to DefCon1

• Dave: Why hasn’t anyone noticed this in the last 15 years?

Page 56: Things They Never Taught You About Naming and Addressing

October 20, 10 . 56© John Day, 2010

All Rights Reserved

Dave is Right

• All proposals based on loc/id split have the same flaw.• Once put in the context of the PNA theory, it is obvious.• Let us look at it very carefully. What do the locator and the identifier

name?

Endpoint Identifier

Locators

The Locator Locates the Wrong Thing!The locator is part of the path, not the final destination.

No wonder Dave ran into path discovery issues.

Page 57: Things They Never Taught You About Naming and Addressing

October 20, 10 . 57© John Day, 2010

All Rights Reserved

Apply the e2e principle!(the answer to everything)

Solve the Problem in the Hosts

• There are poor misguided souls claiming this.– Mostly done by changing the definition of multihoming.– Ignore that it might take seconds if not minutes to do the failover.

• Remember the fundamental problem is that the network doesn’t knowthat two paths go to the same place.– This is a problem of delivering, not sending.– There is no host-based solution.

• There is no solution as long as one routes only on the interfaceaddress. Which means . . .

Page 58: Things They Never Taught You About Naming and Addressing

October 20, 10 . 58© John Day, 2010

All Rights Reserved

If Loc/ID Doesn’t Scale

• Then there is no solution involving routing on the interface that scales.• In other words,

• But we saw that coming a long time ago.

IP is Fundamentally Flawed(v4 or v6)

Page 59: Things They Never Taught You About Naming and Addressing

October 20, 10 . 59© John Day, 2010

All Rights Reserved

So What Is the IETF Plan B?

• Plan A• What are the major Universities working on?• Plan A• What are the vendors working on?• Plan A . . . . Still?

• Talk about scary, there was a summit in the Spring of 2009 to discuss the addressing crisis• The agenda: to determine what form of loc/id split to use!

– It is important to get those deck chairs lined up very neatly.

Page 60: Things They Never Taught You About Naming and Addressing

October 20, 10 . 60© John Day, 2010

All Rights Reserved

What Do the Vendors Say?• Yes, there may be some scaling issues with loc/id split.• But we recommend using it, they are very unlikely to ever be a problem.

• You mean unlikely as in “it is very unlikely a lot of people will defaulton home mortgages”?– (we know where that went)

• Don’t worry! It won’t happen very often, only in a crisis.

A Black Swan?

Page 61: Things They Never Taught You About Naming and Addressing

October 20, 10 . 61© John Day, 2010

All Rights Reserved

But Everything Works Fine!

• Yes and it will for a few more years.

• When you notice it, it means we are already over the cliff.Vince Fuller, Cisco.

“Has he vertigo? No, only about ten stories more!” - Ogden Nash

Page 62: Things They Never Taught You About Naming and Addressing

October 20, 10 . 62© John Day, 2010

All Rights Reserved

Wanna Hear the Real P*sser?

• We had the right answer in 1992.• The answer we had known since 1972.

– It was rejected by the IETF.• And to add insult to injury, it was DEPLOYED and

Operational in the routers.– We could have spent the last 15 years working on transition– Rather than 100s of millions on a small incremental step that

provides no benefit to your bottom line and is fundamentallyflawed.

– You just can’t make this stuff up!

Page 63: Things They Never Taught You About Naming and Addressing

October 20, 10 . 63© John Day, 2010

All Rights Reserved

The Problem was Never Separating Locator from Identifier.It was and is at least

Separating Logical Location from Physical Location• It is impossible to locate something without also identifying it.• This pseudo-problem arises from not having a complete address architecture.

– And creates enough epicycles upon epicycles to make Clavius proud• And from not being precise in your terms, Or as Wittgenstein said,

– “7 That of which we can not speak, we must pass over in silence.”• But we will give O’Dell the last word:

– When all you have is a hammer, everything looks like your thumb

Location dependent,Route independent

Route Dependent

LocationIndependence

Application Name Space

Logical Name Space

Physical Name Space

Application Names

Node Address

Point of Attachment

Page 64: Things They Never Taught You About Naming and Addressing

October 20, 10 . 64© John Day, 2010

All Rights Reserved

The Latest Word

• Recent meetings of the RRG keystone cops has determined that theendpoint-identifier should be aggregatable.

• Golly, Gee! Do you think!? Like a node address? In CLNP?– For those readers of Timothy Garton Ash, doesn’t it remind you of that joke

that circulated in the Eastern Block around ‘89?– Communism is the longest most torturous road from capitalism to capitalism.

• Actually, no, a location-dependent application (transport) identifier!– So if my application moves I have to change its EID?– Looks that way. Doesn’t it?– Starting with a flawed idea and patching it isn’t going to make it any better.

• Did someone say something about lipstick on a pig?– All this because they don’t do theory. They have rough consensus and . . .

• We Entrust the Infrastructure of the World Economy to these guys?

Page 65: Things They Never Taught You About Naming and Addressing

October 20, 10 . 65© John Day, 2010

All Rights Reserved

Conclusions• Most of the problems in the Internet today: scaling, multihoming,

mobility, distributed applications, etc. are rooted in not having acomplete addressing architecture.– The Internet is more like DOS, than UNIX.

• The Internet has less than half an addressing architecture.– Unlike an OS, there is no indirection in its addressing architecture.

• Imagine trying to do re-locatable code without virtual addresses!– More identifiers without decoupling the name spaces solves nothing.– Loc/id split was just post IPng trauma.

• Such intense reaction to naming the node, that there had to be a workaround.• There isn’t. (Just like there isn’t in operating systems)

• Now Mrs McCave wishes she had fixed that problem in the 70s.• But she didn’t do it and now it is too late! . . . for IP.