This document discusses myths and folklore related to network protocol design. It aims to dispel myths and promote learning from both mistakes and good ideas. The document provides background on topics like protocol layers, bridges, routers, switches, and definitions. It uses examples like IPv6 and SSL versioning to illustrate issues with parameterization and version numbering in protocols. The overall message is that simplicity, robustness, and avoiding incompatible changes are important principles in network protocol design.

1. Myth ology an d Folklore of
Network Protocol Design
Radia Perlm an
Su n Microsystem s Laboratories
1

2. Messages
• Disp el m yth s an d “religion ”
– “It’s n ot w h at you don ’t k n ow th at’ll get
you . It’s w h at you do k n ow th at ain ’t tru e”
Mark Twain
• Learn from m istakes
• Learn from cool id eas
• Be p rovocative. Start lively discu ssion
2

3. Messages for stu den ts
• Don ’t believe everyth in g you h ear
• Don ’t believe th in gs you can n ot
u n derstan d
• Th ere is a lot of ran dom n ess is wh eth er
p ap ers get accep ted
• Stan dards creation is m ore p olitical
th an tech n ical
3

4. Gen eral stu ff to con sider in
design s
Sim p licity
•
Scalability
•
Man ageability
•
Robu stn ess
•
Ease of addin g n ew featu res
•
4

5. First a bit of backgrou n d in order
to m ake th e exam p les clear
5

6. Wh at are p rotocol layers?
• Ju st a way of th in kin g abou t th e
p roblem
• ISO defin ed 7 layers
• TCP/ IP su ite claim s it’s on ly 4 layers,
b u t h as at least 6 of th e ISO layers
– Perh ap s leaves ou t session layer, bu t
“BEEP” was in fash ion for awh ile
• A lot of th e layers get su bdivid ed in to
oth ers
6

7. Bridges, Rou ters, an d
Switch es! Oh m y!
• Th is discu ssion sh eds ligh t on
h ow/ wh y th in gs work today
• Need th e backgrou n d for som e oth er
exam p les
7

8. Wh y th is wh ole layer 2/ 3
th in g?
• Myth : bridges/ switch es sim p ler
d evices, design ed before rou ters
• OSI Layers
– 1: p h ysical
8

9. Wh y th is wh ole layer 2/ 3
th in g?
• Myth : bridges/ switch es sim p ler
d evices, design ed before rou ters
• OSI Layers
– 1: p h ysical
– 2: data lin k (n br-n br)
9

10. Wh y th is wh ole layer 2/ 3
th in g?
• Myth : bridges/ switch es sim p ler
d evices, design ed before rou ters
• OSI Layers
– 1: p h ysical
– 2: data lin k (n br-n br)
– 3: n etwork (create en tire p ath )
10

11. Wh y th is wh ole layer 2/ 3
th in g?
• Myth : bridges/ switch es sim p ler
d evices, design ed before rou ters
• OSI Layers
1: p h ysical
–
2: data lin k (n br-n br)
–
3: n etwork (create en tire p ath )
–
4 en d-to-en d
–
11

12. Wh y th is wh ole layer 2/ 3
th in g?
• Myth : bridges/ switch es sim p ler
d evices, design ed before rou ters
• OSI Layers
1: p h ysical
–
2: data lin k (n br-n br)
–
3: n etwork (create en tire p ath )
–
4 en d-to-en d
–
5 an d above: borin g
–
12

13. Defin ition s
• Rep eater: layer 1 relay
• Bridge: layer 2 relay
• Rou ter: layer 3 relay
13

14. Defin ition s
Rep eater: layer 1 relay
•
Bridge: layer 2 relay
•
Rou ter: layer 3 relay
•
OK: Wh at is layer 2 vs layer 3?
•
14

15. Defin ition s
Rep eater: layer 1 relay
•
Bridge: layer 2 relay
•
Rou ter: layer 3 relay
•
OK: Wh at is layer 2 vs layer 3?
•
– My defin ition : layer 3 forwards, layer 2
does n ot
15

16. Defin ition s
Rep eater: layer 1 relay
•
Bridge: layer 2 relay
•
Rou ter: layer 3 relay
•
OK: Wh at is layer 2 vs layer 3?
•
– Tru e defin ition of a layer n p rotocol:
An yth in g design ed by a com m ittee w h ose
ch arter is to design a layer n protocol
16

17. Layer 3 (DECn et, IP)
• Pu t sou rce, destin ation , h op cou n t on p acket
• At th e tim e DECn et was m ore p revalen t, bu t
it’s logically equ ivalen t to IP
• Th en alon g cam e “th e Eth erNET”
– reth in k rou tin g algorith m a bit, bu t it’s a lin k!
• Th e world got con fu sed. Bu ilt on layer 2
• I tried to argu e: “Bu t you m igh t w an t to talk
from on e Eth ern et to an oth er!”
• “W h ich w ill w in ? Eth ern et or DECn et?”
17

18. Problem Statem en t
Need som eth in g th at w ill sit betw een tw o Eth ern ets, an d
let a station on on e Eth ern et talk to an oth er
A C
18

19. Basic idea
• Listen p rom iscu ou sly
• Learn location of sou rce add ress b ased
on sou rce address in p acket an d p ort
from wh ich p acket received
• Forward b ased on learn ed location of
d estin ation
19

20. Wh at’s differen t between th is
an d a rep eater?
• n o collision s
• with learn in g, can u se m ore aggregate
b an dwidth th an on an y on e lin k
• n o artifacts of LAN tech n ology (# of
station s in rin g, distan ce of CSMA/ CD)
20

21. Bu t loop s are a disaster
• No h op cou n t
• Exp on en tial p roliferation
B2
B1 B3
21

22. Th u s th e Sp an n in g Tree
Algorith m
I th in k th at I sh all n ever see
A graph m ore lovely th an a tree.
A tree w h ose cru cial property
Is loop-free con n ectivity.
A tree w h ich m u st be su re to span
So pack ets can reach every LAN.
First th e Root m u st be selected
By ID it is elected.
Least cost path s from Root are traced
In th e tree th ese path s are placed.
A m esh is m ade by folk s lik e m e.
Th en bridges fin d a span n in g tree.
22

23. Both er with sp an n in g tree?
• Maybe ju st tell cu stom ers “don ’t d o
loop s”
• First bridge sold...
23

24. First Bridge Sold
A C
24

25. Myth
• Eth ern et con tin u es to be a su ccessfu l
tech n ology
25

26. So wh at is Eth ern et?
• CSMA/ CD, righ t? Not an y m ore,
really...
• sou rce, destin ation (an d n o h op cou n t)
• lim ited distan ce, scalability (n ot an y
m ore, really)
26

27. Switch es
• Eth ern et u sed to be bu s
• Easier to wire, m ore robu st if star (on e
h u ge m u ltip ort rep eater with p t-to-p t
lin ks
• If store an d forward rath er th an
rep eater, an d with learn in g, m ore
aggregate ban dwidth
• Can cascade devices…do sp an n in g
tree
• We’re rein ven ted th e bridge! 27

28. Sim p le th in gs p eop le get
wron g
• Th ey get obsessed with esoteric stu ff
like “p rovable p rop erties” of
cryp tograp h ic algorith m s, bu t m iss
b asic system issu es
28

29. Exam p le: Wh at is a version
n u m ber?
29

30. Version Nu m bers
• Wh at’s th e differen ce between a n ew
p rotocol, an d a n ew version of an
existin g p rotocol?
• For in stan ce, wh y was CLNP a “n ew
p rotocol”, an d IPv6 a “n ew version of
IP”?
30

31. Version Nu m bers
• Wh at’s th e differen ce between a n ew
p rotocol, an d a n ew version of an
existin g p rotocol?
• For in stan ce, wh y was CLNP a “n ew
p rotocol”, an d IPv6 a “n ew version of
IP”?
– Its n am e?
– Wh o d efin es it?
31

32. Defin ition th at m akes sen se
to m e
• New p rotocol m ean s differen t p rotocol
d iscrim in ator at layer n -1
• New version m ean s sam e p rotocol
d iscrim in ator, an d version n u m ber
d istin gu ish es
32

33. If you distin gu ish with version
n u m ber
• Th en if th e p acket form at is
in com p atible, th e old version n od e
m u st n ot try to p arse
• Don ’t in crease version n u m ber u n less
p acket is in com p atible
• Sp ecify p acket m u st be drop p ed if
version n u m ber is bigger
33

34. Is IPv6 a n ew version of IPv4?
IPv4 sp ec says “set version to 4”
•
Bu t doesn ’t say to look at it
•
IPv6 form at in com p atible with IPv4
•
So if you sen d an IPv4 n ode an IPv6
•
p acket, it will do wh o kn ows wh at…
34

35. Resu lt
• IPv6 n eeds n ew p rotocol typ e
• So IPv6 is a n ew p rotocol, n ot a n ew
version of IP
• IPv6 d oes h ave a version n u m b er field ,
b u t it cou ld be version 1
35

36. We learn ed ou r lesson , righ t?
• So IPv6 sp ec m u st say “drop if version
n u m ber > 6”
36

37. We learn ed ou r lesson , righ t?
• So IPv6 sp ec m u st say “drop if version
n u m ber > 6”
• Nop e…ju st says “set th is field to 6”
37

38. An oth er exam p le: SSL
• Th ey com p letely ch an ged th e form at
from SSLv2 to v3
• Not on ly did n ’t say to drop if version
n u m ber greater…
38

39. An oth er exam p le: SSL
• Th ey com p letely ch an ged th e form at
from SSLv2 to v3
• Not on ly did n ’t say to drop if version
n u m ber greater…
• Bu t m oved th e version n u m ber field !!!
39

40. Param eters
40

41. Param eters
• Min im ize th ese:
– som eon e h as to docu m en t it
– cu stom er h as to read docu m en tation an d
u n derstan d it
• How to avoid
– arch itectu ral con stan ts if p ossible
– au tom atically con figu re if p ossible
41

42. Settable Param eters
• Make su re th ey can ’t be set
in com p atibly across n odes, across
layers, etc. (e.g., h ello tim e an d d ead
tim er)
• Make su re th ey can be set at n odes on e
at a tim e an d th e n et can stay ru n n in g
42

43. Param eter tricks
• IS-IS
– p airwise p aram eters rep orted in “h ellos”
– area-wide p aram eters rep orted in LSPs
• OSPF
– cop ied m ost of IS-IS, bu t got th is wron g.
Use field in h ello to refu se to talk if n ot
iden tical!
• Bridges
– Use Root’s valu es, sen t in sp an n in g tree
m sgs
43

44. Wh at’s with IPv6?
44

45. Wh at’s with IPv6?
• A con n ection less n etwork layer
con sists of:
– Sou rce ad dress
– Destin ation add ress
– Hop cou n t
45

46. Wh at’s with IPv6?
• A con n ection less n etwork layer
con sists of:
– Sou rce ad dress
– Destin ation add ress
– Hop cou n t
• Wh at cou ld take so lon g?
46

47. Wh at’s with IPv6
• In 1992, IAB said
– Gee, IP addresses n ot big en ou gh
– Wh y don ’t we u se CLNP?
47

48. Wh at’s with IPv6?
• In 1992, IAB said
– Gee, IP addresses n ot big en ou gh
– Wh y don ’t we u se CLNP?
• Wh at’s CLNP?
– ISO’s version of IP
– 20 byte addresses
• Cam e with m atu re rou tin g p rotocols,
au tocon figu ration , im p lem en ted by all m ajor
ven d ors
48

49. Wh at’s with IPv6?
• Bu t som e vocal IETF p eop le said
– We can ’t rep lace IP with ISO!
• Resu lt
– We m ay h ave m issed ou r win dow
– Givin g a large com m ittee 13 years (an d cou n tin g)
of tim e, you can gen erate lots of p ages of sp ecs
– CLNP wou ld h ave been fin e
– An d we’d h ave bigger addresses n ow (an d a
sim p ler p rotocol)
49

50. Resu lt
• We m ay h ave m issed ou r win dow
• Givin g a large com m ittee 13 years (an d
cou n tin g) of tim e, you can get lots of p ages of
sp ecs
• CLNP wou ld h ave been fin e
• An d we’d h ave bigger addresses n ow (an d a
sim p ler p rotocol th an IPv6)
• Worse yet, we get IPv4 an d NATs, an d, if we
m igrate, very com p lex m igration
50

51. Wh at’s with IP Mu lticast?
51

52. Mu lticast
• Eth ern et: falls ou t of tech n ology
• ATM: create VC. “Add m em ber”
X A
G
C
H
52

53. IP Mu lticast
• Id ea: m ake it look “ju st like Eth ern et”
– globally u n iqu e m u lticast addresses
• IP add ress 32 bits, top 4 bits=1110
– an yon e can requ est to listen . an yon e can
sen d with ou t bein g a m em b er
• So, start ou t with u n ch an geab le
“m odel”
– sign allin g p rotocol to in form local rtr to
sen d G
53

54. Problem : Can ’t be
im p lem en ted
• variou s attem p ts:
– flood an d p ru n e
• sen d all d ata everywh ere, in case som eon e in
Alb an ia wan ts to listen
• if n ot in terested, sen d “p ru n e”
• keep track of all (S,G) p airs n br NOT in terested
in
– MOSPF
• rou ters keep track of all listen ers for all grou p s
54

55. IP Mu lticast attem p ts
• Tree bu ildin g like with ATM
– sen d join toward s Root
– create tree
• Problem s:
– wh o is Root for G?
• u n scalab le in tradom ain p rotocol to select a
Root-can didate for G
– h ow to adm in ister addresses
55

56. IP Mu lticast
• So, cam e u p with u n scalable com p lex
in tradom ain
• Th en MSDP to p iece dom ain s togeth er
x
x
x
x x
x
x x
x
x
56

57. How IP Mu lticast sh ou ld look
• Two typ es
– fin din g som eth in g (low ban dwidth , can ’t
set u p tree). Ju st flood with RPF
– con feren ce call, etc. Fin d h ost H. Build
tree to H. Have add ress of grou p be (H,G),
wh ere G on ly h as to be u n iqu e to H
57

58. Self-Stabilization
• Bad th in gs m ay h ap p en
– sick or m aliciou s devices m igh t corru p t
databases or in ject bad traffic
• On ce bad device discon n ected from
th e n et, th e n etwork sh ou ld retu rn to
n orm al op eration
• How cou ld it n ot?
58

59. Lin k State Rou tin g, ARPANET
style
• Lin k state rou tin g
– figu re ou t wh o you r n b rs are
– create LSP (wh o I am , wh o m y n brs are)
– flood LSP, keep m ost recen tly gen erated
LSP from each oth er rou ter
– u se LSP database to calcu late p ath s
59

60. How to flood
• Regu lar floodin g is exp on en tial
• Bu t h ere, on ly flood each p acket on ce
(if n ewer th an th at in database)
• How to recogn ize p acket is n ew?
• ARPANET
– sequ en ce n u m ber an d age
– sequ en ce n u m ber circu lar
– age in crem en ts after h oldin g it for n
secon ds
60

61. Arith m etic in circu lar sp ace
>x
x
<x
61

62. ARPANET disaster
• sym p tom : n et didn ’t work
• h ow do you diagn ose an d m an age a
n etwork?
• Note: th ese gu ys were really really
lu cky!
• Wh at h ad h ap p en ed: Fred, a sick
rou ter, gen erate bad LSPs before d yin g,
with sequ en ce n u m bers x, y, z
62

63. ARPANET disaster
y
x
z
xy
z x
z
xy
yz
xz yxz yxz y
xyz xyz xyz
63

64. So h ow do you fix a broken
n et?
• Patch ed version of code th at ign ore
LSPs from Fred
• On e by on e crash ed system s (n ot easy!)
an d reloaded with p atch ed cod e
• On ly after all rou ters reloaded, can
th ey be reloaded with correct version
again
64

65. Robu stn ess
• Can be design ed to be self-stab ilizin g
(p ap er from 1983)
• Pap er claim ed “bu t can ’t exp ect th e
n etwork to con tin u e op eratin g if fau lty
equ ip m en t is still con n ected”
• My th esis from 1988: rou tin g with
Byzan tin e robu stn ess
65

66. Oth er th in gs th at I cou ld ran t
abou t
• XML
• BGP
66

67. My com p lain t abou t h ow
n etworkin g is tau gh t
• It’s tau gh t like a trade sch ool…all th e
d etails of th e cu rren tly dep loyed stu ff
67

68. How n etworkin g sh ou ld be
tau gh t
• Cover con cep tu al p roblem s
• An d ran ge of solu tion s
– In terestin g ideas, even if n ot cu rren tly
dep loyed
– In terestin g ideas, even if n ever dep loyed
• Teach h ow to th in k critically
– Don ’t believe everyth in g in p rin t
– Don ’t assu m e wh at com es ou t of
stan dards bodies is p erfect
68

69. Mistakes stan dards bodies
m ake
• “We sh ou ld get extra credit becau se we
d idn ’t look at an y ideas don e b efore”
• “We are too bu sy to an swer b asic
qu estion s, or exp lain an yth in g”
• “If we revisit old decision s, we’ll lose 10
years worth of work”
– If you fin d you rself in a h ole, stop diggin g!
69

70. Lesson s
• Always seem s easy to start over with n ew
th in g. Always takes lon ger an d com es ou t
worse.
• Don ’t cast som eth in g in ston e before th ere is
a p lau sible way of realizin g it
• Min im ize con figu ration
• Don ’t ju st dive in an d start doin g stu ff. Th in k
abou t wh at p roblem you ’re solvin g before
you try to com e u p with a solu tion .
70