P. 1
Virtual Switch: High-impact Technology - What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors

Virtual Switch: High-impact Technology - What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors


|Views: 3,466|Likes:
Published by Emereo Publishing
A virtual switch is a software program that allows one virtual machine (VM) to communicate with another.
Just like its counterpart, the physical Ethernet switch, a virtual switch does more than just forward data packets. It can intelligently direct communication on the network by inspecting packets before passing them on. Some vendors embed virtual switches right into their virtualization software, but a virtual switch can also be included in a server's hardware as part of its firmware.

This book is your ultimate resource for Virtual Switch. Here you will find the most up-to-date information, analysis, background and everything you need to know.

In easy to read chapters, with extensive references and links to get you to know all there is to know about Virtual Switch right away, covering: Virtual security switch, Virtual Switching Instance, Virtual firewall, OpenSolaris Network Virtualization and Resource Control, InterSwitch Trunk, Windows Virtual PC, Virtual network, EtherChannel, Network virtualization, Cisco Unified Computing System, Logical partition (virtual computing platform), Juniper EX-Series, Linux on Power, Metro Ethernet, List of TCP and UDP port numbers, Address Book Server, Advanced Message Queuing Protocol, Aggregate Server Access Protocol, ALCAP, Anti-replay, Any-source multicast, Apache Wave, AppleTalk Echo Protocol, Application Exchange, Archie search engine, Architecture for Control Networks, Asynchronous Layered Coding, Bidirectional Forwarding Detection, BIND method, Binkp, Boot Service Discovery Protocol, Bootstrap Protocol, Border Gateway Multicast Protocol, Border Gateway Protocol, Bridging Systems Interface, BSDRadius, CA/Browser Forum, CalDAV, CardDAV, CCSO Nameserver, Certificate Management over CMS, Certificate Management Protocol, Challenge-handshake authentication protocol, Character Generator Protocol, Cipher suite, Cisco WAAS, Common Address Redundancy Protocol, Common Indexing Protocol, Common Open Policy Service, Compiled Wireless Markup Language, Computer port (software), Conch (SSH), Connection-oriented protocol, Connectionless protocol, Constrained Shortest Path First, Cookie exchange, Cross Registry Information Service Protocol, Data Validation and Certification Server, Datagram Congestion Control Protocol, Datagram Transport Layer Security, Daytime Protocol, DCE Distributed File System, Default-free zone, Diameter (protocol), Diameter Credit-Control Application, DICT, Directory Assistance Service, Directory information tree, Discard Protocol, DIXIE, Domain Name System, Domain Name System Security Extensions, DVB-IPTV, Echo Protocol, Endpoint Handlespace Redundancy Protocol, Ephemeral port, Extensible Name Service, Exterior Gateway Protocol, External Data Representation, FAST TCP, Fibre Channel over IP, File eXchange Protocol, File Transfer Protocol, Files2u, Finger protocol, First Hop Redundancy Protocols, FLIP (Fast-Local-Internet-Protocol), Forward-confirmed reverse DNS, GENA, Geo URI, GNTP, Gopher (protocol), GPRP, GroupDAV, Handle System, High Frequency Internet Protocol, Hopcount, Host Identity Protocol, Host Monitoring Protocol, HOTP, HTTP body data, ICMPv6, Ident, IGMP snooping, Internet 0, Internet chess server, Internet Content Adaptation Protocol, Internet Control Message Protocol, Internet Fibre Channel Protocol, Internet Group Management Protocol, Internet Group Management Protocol with Access Control (IGMP-AC), Internet Imaging Protocol, Internet Open Trading Protocol, Internet Protocol Control Protocol, Internet Protocol Suite, Multipurpose Transaction Protocol, Transport Sample Protocol, Internet Streaming Media Alliance, IP Flow Information Export, IP Managed VAS...and much more

This book explains in-depth the real drivers and workings of Virtual Switch. It reduces the risk of your technology, time and resources investment decisions by enabling you to compare your understanding of Virtual Switch with the objectivity of experienced professionals.
A virtual switch is a software program that allows one virtual machine (VM) to communicate with another.
Just like its counterpart, the physical Ethernet switch, a virtual switch does more than just forward data packets. It can intelligently direct communication on the network by inspecting packets before passing them on. Some vendors embed virtual switches right into their virtualization software, but a virtual switch can also be included in a server's hardware as part of its firmware.

This book is your ultimate resource for Virtual Switch. Here you will find the most up-to-date information, analysis, background and everything you need to know.

In easy to read chapters, with extensive references and links to get you to know all there is to know about Virtual Switch right away, covering: Virtual security switch, Virtual Switching Instance, Virtual firewall, OpenSolaris Network Virtualization and Resource Control, InterSwitch Trunk, Windows Virtual PC, Virtual network, EtherChannel, Network virtualization, Cisco Unified Computing System, Logical partition (virtual computing platform), Juniper EX-Series, Linux on Power, Metro Ethernet, List of TCP and UDP port numbers, Address Book Server, Advanced Message Queuing Protocol, Aggregate Server Access Protocol, ALCAP, Anti-replay, Any-source multicast, Apache Wave, AppleTalk Echo Protocol, Application Exchange, Archie search engine, Architecture for Control Networks, Asynchronous Layered Coding, Bidirectional Forwarding Detection, BIND method, Binkp, Boot Service Discovery Protocol, Bootstrap Protocol, Border Gateway Multicast Protocol, Border Gateway Protocol, Bridging Systems Interface, BSDRadius, CA/Browser Forum, CalDAV, CardDAV, CCSO Nameserver, Certificate Management over CMS, Certificate Management Protocol, Challenge-handshake authentication protocol, Character Generator Protocol, Cipher suite, Cisco WAAS, Common Address Redundancy Protocol, Common Indexing Protocol, Common Open Policy Service, Compiled Wireless Markup Language, Computer port (software), Conch (SSH), Connection-oriented protocol, Connectionless protocol, Constrained Shortest Path First, Cookie exchange, Cross Registry Information Service Protocol, Data Validation and Certification Server, Datagram Congestion Control Protocol, Datagram Transport Layer Security, Daytime Protocol, DCE Distributed File System, Default-free zone, Diameter (protocol), Diameter Credit-Control Application, DICT, Directory Assistance Service, Directory information tree, Discard Protocol, DIXIE, Domain Name System, Domain Name System Security Extensions, DVB-IPTV, Echo Protocol, Endpoint Handlespace Redundancy Protocol, Ephemeral port, Extensible Name Service, Exterior Gateway Protocol, External Data Representation, FAST TCP, Fibre Channel over IP, File eXchange Protocol, File Transfer Protocol, Files2u, Finger protocol, First Hop Redundancy Protocols, FLIP (Fast-Local-Internet-Protocol), Forward-confirmed reverse DNS, GENA, Geo URI, GNTP, Gopher (protocol), GPRP, GroupDAV, Handle System, High Frequency Internet Protocol, Hopcount, Host Identity Protocol, Host Monitoring Protocol, HOTP, HTTP body data, ICMPv6, Ident, IGMP snooping, Internet 0, Internet chess server, Internet Content Adaptation Protocol, Internet Control Message Protocol, Internet Fibre Channel Protocol, Internet Group Management Protocol, Internet Group Management Protocol with Access Control (IGMP-AC), Internet Imaging Protocol, Internet Open Trading Protocol, Internet Protocol Control Protocol, Internet Protocol Suite, Multipurpose Transaction Protocol, Transport Sample Protocol, Internet Streaming Media Alliance, IP Flow Information Export, IP Managed VAS...and much more

This book explains in-depth the real drivers and workings of Virtual Switch. It reduces the risk of your technology, time and resources investment decisions by enabling you to compare your understanding of Virtual Switch with the objectivity of experienced professionals.

More info:

Published by: Emereo Publishing on Jun 17, 2011
Copyright:Traditional Copyright: All rights reserved
List Price: $39.95


Read on Scribd mobile: iPhone, iPad and Android.
This book can be read on up to 6 mobile devices.
Full version available to members
See more
See less



  • Virtual security switch
  • Virtual Switching Instance
  • Virtual firewall
  • OpenSolaris Network Virtualization and Resource Control
  • InterSwitch Trunk
  • Windows Virtual PC
  • Virtual network
  • EtherChannel
  • Network virtualization
  • Cisco Unified Computing System
  • Logical partition (virtual computing platform)
  • Juniper EX-Series
  • Linux on Power
  • Metro Ethernet
  • List of TCP and UDP port numbers
  • Address Book Server
  • Advanced Message Queuing Protocol
  • Aggregate Server Access Protocol
  • Anti-replay
  • Any-source multicast
  • Apache Wave
  • AppleTalk Echo Protocol
  • Application Exchange
  • Archie search engine
  • Architecture for Control Networks
  • Asynchronous Layered Coding
  • Bidirectional Forwarding Detection
  • BIND method
  • binkp
  • Boot Service Discovery Protocol
  • Bootstrap Protocol
  • Border Gateway Multicast Protocol
  • •Border Gateway Multicast Protocol [3]
  • Border Gateway Protocol
  • Bridging Systems Interface
  • Bridging Systems Interface (BSI)
  • BSDRadius
  • CA/Browser Forum
  • CalDAV
  • CardDAV
  • CCSO Nameserver
  • Certificate Management over CMS
  • CMC (Certificate Management over CMS)
  • Certificate Management Protocol
  • CMP (Certificate Management Protocol)
  • Challenge-handshake authentication protocol
  • Character Generator Protocol
  • Cipher suite
  • Cisco WAAS
  • Common Address Redundancy Protocol
  • Common Indexing Protocol
  • Common Open Policy Service
  • Compiled Wireless Markup Language
  • Computer port (software)
  • Conch (SSH)
  • Connection-oriented protocol
  • Connectionless protocol
  • Constrained Shortest Path First
  • Cookie exchange
  • Cross Registry Information Service Protocol
  • Data Validation and Certification Server
  • Datagram Congestion Control Protocol
  • Datagram Transport Layer Security
  • Daytime Protocol
  • DCE Distributed File System
  • Default-free zone
  • Diameter (protocol)
  • Diameter Credit-Control Application
  • DICT
  • Directory Assistance Service
  • Directory information tree
  • Discard Protocol
  • Domain Name System
  • Domain Name System Security Extensions
  • Echo Protocol
  • Endpoint Handlespace Redundancy Protocol
  • Ephemeral port
  • Extensible Name Service
  • Exterior Gateway Protocol
  • External Data Representation
  • Fibre Channel over IP
  • File eXchange Protocol
  • File Transfer Protocol
  • Files2u
  • Finger protocol
  • First Hop Redundancy Protocols
  • FLIP (Fast-Local-Internet-Protocol)
  • Forward-confirmed reverse DNS
  • GENA
  • Geo URI
  • GNTP
  • Gopher (protocol)
  • GPRP
  • GroupDAV
  • Handle System
  • High Frequency Internet Protocol
  • Hopcount
  • Host Identity Protocol
  • Host Monitoring Protocol
  • HOTP
  • HTTP body data
  • ICMPv6
  • Ident
  • IGMP snooping
  • Internet 0
  • Internet chess server
  • Internet Content Adaptation Protocol
  • Internet Control Message Protocol
  • Internet Fibre Channel Protocol
  • Internet Group Management Protocol
  • Internet Group Management Protocol with Access Control (IGMP-AC)
  • Internet Imaging Protocol
  • Internet Open Trading Protocol
  • Internet Protocol Control Protocol
  • Internet Protocol Suite
  • Multipurpose Transaction Protocol
  • Transport Sample Protocol
  • Internet Streaming Media Alliance
  • IP Flow Information Export
  • IP Managed VAS
  • IP multicast
  • IPFC
  • IPsec
  • IS-IS
  • Jughead (search engine)
  • KA9Q
  • KAME project
  • L2TPv3
  • Layer 2 Tunneling Protocol
  • LDAP
  • Lightweight Telephony Protocol
  • Link-local Multicast Name Resolution
  • List of DNS record types
  • List of RADIUS servers
  • LogZilla
  • LysKOM
  • M3UA
  • MAC-Forced Forwarding
  • MacIP
  • Mail Transfer Protocol
  • Mapping of Airline Traffic over Internet Protocol
  • Media Delivery Index
  • Media Gateway Controller
  • Media Resource Control Protocol
  • Message posting protocol
  • Message send protocol
  • MetaWeblog
  • Metro Ring Protocol
  • Micro Transport Protocol
  • Microsoft Point-to-Point Encryption
  • MIMIC Simulator
  • MiMMS
  • MSN Direct
  • Multicast Listener Discovery
  • Multicast Source Discovery Protocol
  • Multiplexed Transport Layer Security
  • NAT-T
  • Neighbor Discovery Protocol
  • Net-SNMP
  • Network Control Protocol
  • Network Data Representation
  • Network File System (protocol)
  • Network Security Services
  • Network Time Protocol
  • OAuth
  • OCSP stapling
  • OFTP
  • Online Certificate Status Protocol
  • Open Archives Initiative Protocol for Metadata Harvesting
  • Open Network Computing Remote Procedure Call
  • Open port
  • Open Shortest Path First
  • Parallel Line Internet Protocol
  • Password authentication protocol
  • Path MTU Discovery
  • Peg DHCP
  • Ping sweep
  • PKI Resource Query Protocol
  • Pool Element
  • Pool Registrar
  • Pool User
  • Port number
  • Portmap
  • Professional video over IP
  • Proxy ARP
  • QOTD
  • Query flooding
  • Radio over IP
  • RadioVIS
  • Radius Values
  • RadSec
  • rdate
  • Realm-Specific IP
  • Realtek Remote Control Protocol
  • Registered port
  • Reliable Datagram Sockets
  • Reliable server pooling
  • Reliable User Datagram Protocol
  • Remote File System
  • Remote Job Entry
  • Remote Process Execution
  • Remote Shell
  • Resource reservation protocol
  • Reverse Address Resolution Protocol
  • Reverse telnet
  • rlogin
  • Route poisoning
  • Routing Information Protocol
  • Rsyslog
  • Salmon (protocol)
  • Scalable TCP
  • SCTP packet structure
  • SCVP
  • SDES
  • SDXF
  • Seamoby
  • Secure Neighbor Discovery Protocol
  • Secure Shell
  • Security Parameter Index
  • Sender Policy Framework
  • Serial Line Internet Protocol
  • Server Name Indication
  • Service discovery
  • Service Location Protocol
  • Session Announcement Protocol
  • Session Description Protocol
  • Shared Whois Project
  • SILC (protocol)
  • Simple Network Management Protocol
  • Simple Update Protocol
  • SMART Multicast
  • Space Communications Protocol Specifications
  • SPDY
  • Spotnet
  • Streaming Text Oriented Messaging Protocol
  • Syslog
  • Syslog-ng
  • syslog-ng
  • T.38 ITU-T recommendation
  • T/TCP
  • TCP-Illinois
  • TCP/IP Illustrated
  • TCP/IP model
  • TCP Port Service Multiplexer
  • TCPware
  • Telnet
  • Text over IP
  • Time Protocol
  • Time-based One-time Password Algorithm
  • Tinc (protocol)
  • Transport Layer
  • Transport Layer
  • Transport Layer Security
  • Traversal Using Relay NAT
  • TSIG
  • Tsunami UDP Protocol
  • Type-length-value
  • UDP Data Transport
  • UDP Helper Address
  • UDP-based Data Transfer Protocol
  • Usenet
  • User Datagram Protocol
  • Variant object
  • Venturi Transport Protocol
  • Veronica (search engine)
  • Virtual Router Redundancy Protocol
  • Virtual Switch Redundancy Protocol
  • VTun
  • WAN optimization
  • WebDAV
  • Webfinger
  • WebNFS
  • Whois
  • Wide area information server
  • Wireless Application Protocol
  • XML Enabled Directory
  • XML Interface for Network Services
  • Xpress Transport Protocol
  • Zeta-TCP
  • List of IP protocol numbers
  • Routing protocol
  • Babel (protocol)
  • Connectionless routing
  • Diffusing update algorithm
  • Distance Vector Multicast Routing Protocol
  • Distance-vector routing protocol
  • DVSR
  • Enhanced Interior Gateway Routing Protocol
  • Equal-cost multi-path routing
  • Flooding algorithm
  • Fuzzy routing
  • Geographic routing
  • Holddown
  • ICMP Router Discovery Protocol
  • Interior gateway protocol
  • Interior Gateway Routing Protocol
  • Link-state routing protocol
  • Lollipop sequence numbering
  • Longest prefix match
  • Multicast Open Shortest Path First
  • Multicast VLAN Registration
  • NAK (protocol message)
  • Narada multicast protocol
  • Path vector protocol
  • Pragmatic General Multicast
  • Private Network-to-Network Interface
  • Protocol Independent Multicast
  • R-SMLT
  • Reliable multicast
  • Resource Public Key Infrastructure
  • Routing loop problem
  • Split horizon route advertisement
  • Vehicular Reactive Routing protocol
  • Vehicular Reactive Routing protocol (VRR)[1]
  • Article Sources and Contributors
  • Image Sources, Licenses and Contributors
  • License

Virtual Switch

High-impact Technology - What You Need to Know:
Definitions, Adoptions, Impact, Benefits, Maturity, Vendors
Kevin Roebuck
A virtual switch is a software program that allows one virtual machine (VM) to communicate with another.
Just like its counterpart, the physical Ethernet switch, a virtual switch does more than just forward data
packets. It can intelligently direct communication on the network by inspecting packets before passing
them on. Some vendors embed virtual switches right into their virtualization software, but a virtual switch
can also be included in a server’s hardware as part of its firmware.
This book is your ultimate resource for Virtual Switch. Here you will find the most up-to-date information,
analysis, background and everything you need to know.
In easy to read chapters, with extensive references and links to get you to know all there is to know
about Virtual Switch right away, covering: Virtual security switch, Virtual Switching Instance, Virtual fire-
wall, OpenSolaris Network Virtualization and Resource Control, InterSwitch Trunk, Windows Virtual PC,
Virtual network, EtherChannel, Network virtualization, Cisco Unified Computing System, Logical partition
(virtual computing platform), Juniper EX-Series, Linux on Power, Metro Ethernet, List of TCP and UDP port
numbers, Address Book Server, Advanced Message Queuing Protocol, Aggregate Server Access Protocol,
ALCAP, Anti-replay, Any-source multicast, Apache Wave, AppleTalk Echo Protocol, Application Exchange,
Archie search engine, Architecture for Control Networks, Asynchronous Layered Coding, Bidirectional
Forwarding Detection, BIND method, Binkp, Boot Service Discovery Protocol, Bootstrap Protocol, Border
Gateway Multicast Protocol, Border Gateway Protocol, Bridging Systems Interface, BSDRadius, CA/Brows-
er Forum, CalDAV, CardDAV, CCSO Nameserver, Certificate Management over CMS, Certificate Manage-
ment Protocol, Challenge-handshake authentication protocol, Character Generator Protocol, Cipher suite,
Cisco WAAS, Common Address Redundancy Protocol, Common Indexing Protocol, Common Open Policy
Service, Compiled Wireless Markup Language, Computer port (software), Conch (SSH), Connection-ori-
ented protocol, Connectionless protocol, Constrained Shortest Path First, Cookie exchange, Cross Regis-
try Information Service Protocol, Data Validation and Certification Server, Datagram Congestion Control
Protocol, Datagram Transport Layer Security, Daytime Protocol, DCE Distributed File System, Default-free
zone, Diameter (protocol), Diameter Credit-Control Application, DICT, Directory Assistance Service, Direc-
tory information tree, Discard Protocol, DIXIE, Domain Name System, Domain Name System Security Ex-
tensions, DVB-IPTV, Echo Protocol, Endpoint Handlespace Redundancy Protocol, Ephemeral port, Extensi-
ble Name Service, Exterior Gateway Protocol, External Data Representation, FAST TCP, Fibre Channel over
IP, File eXchange Protocol, File Transfer Protocol, Files2u, Finger protocol, First Hop Redundancy Protocols,
FLIP (Fast-Local-Internet-Protocol), Forward-confirmed reverse DNS, GENA, Geo URI, GNTP, Gopher (pro-
tocol), GPRP, GroupDAV, Handle System, High Frequency Internet Protocol, Hopcount, Host Identity Proto-
col, Host Monitoring Protocol, HOTP, HTTP body data, ICMPv6, Ident, IGMP snooping, Internet 0, Internet
chess server, Internet Content Adaptation Protocol, Internet Control Message Protocol, Internet Fibre
Channel Protocol, Internet Group Management Protocol, Internet Group Management Protocol with Access
Control (IGMP-AC), Internet Imaging Protocol, Internet Open Trading Protocol, Internet Protocol Control
Protocol, Internet Protocol Suite, Multipurpose Transaction Protocol, Transport Sample Protocol, Internet
Streaming Media Alliance, IP Flow Information Export, IP Managed VAS...and much more
This book explains in-depth the real drivers and workings of Virtual Switch. It reduces the risk of your
technology, time and resources investment decisions by enabling you to compare your understanding of
Virtual Switch with the objectivity of experienced professionals.

Topic relevant selected content from the highest rated entries, typeset, printed and shipped.
Combine the advantages of up-to-date and in-depth knowledge with the convenience of printed
A portion of the proceeds of each book will be donated to the Wikimedia Foundation to
support their mission: to empower and engage people around the world to collect and develop
educational content under a free license or in the public domain, and to disseminate it effectively
and globally.
The content within this book was generated collaboratively by volunteers. Please be advised
that nothing found here has necessarily been reviewed by people with the expertise required
to provide you with complete, accurate or reliable information. Some information in this book
maybe misleading or simply wrong. The publisher does not guarantee the validity of the
information found here. If you need specifc advice (for example, medical, legal, fnancial, or risk
management) please seek a professional who is licensed or knowledgeable in that area.
Sources, licenses and contributors of the articles and images are listed in the section entitled
“References”. Parts of the books may be licensed under the GNU Free Documentation License. A
copy of this license is included in the section entitled “GNU Free Documentation License”
All used third-party trademarks belong to their respective owners.
Virtual security switch 1
Virtual Switching Instance 3
Virtual firewall 3
OpenSolaris Network Virtualization and Resource Control 8
InterSwitch Trunk 11
Windows Virtual PC 12
Virtual network 25
EtherChannel 26
Network virtualization 29
Cisco Unified Computing System 31
Logical partition (virtual computing platform) 32
Juniper EX-Series 35
Linux on Power 37
Metro Ethernet 39
List of TCP and UDP port numbers 44
Address Book Server 77
Advanced Message Queuing Protocol 78
Aggregate Server Access Protocol 85
Anti-replay 87
Any-source multicast 87
Apache Wave 88
AppleTalk Echo Protocol 94
Application Exchange 94
Archie search engine 94
Architecture for Control Networks 95
Asynchronous Layered Coding 97
Bidirectional Forwarding Detection 98
BIND method 99
binkp 99
Boot Service Discovery Protocol 100
Bootstrap Protocol 102
Border Gateway Multicast Protocol 104
Border Gateway Protocol 104
Bridging Systems Interface 116
BSDRadius 117
CA/Browser Forum 118
CalDAV 119
CardDAV 121
CCSO Nameserver 123
Certificate Management over CMS 125
Certificate Management Protocol 125
Challenge-handshake authentication protocol 127
Character Generator Protocol 128
Cipher suite 129
Cisco WAAS 131
Common Address Redundancy Protocol 132
Common Indexing Protocol 134
Common Open Policy Service 135
Compiled Wireless Markup Language 135
Computer port (software) 136
Conch (SSH) 137
Connection-oriented protocol 137
Connectionless protocol 138
Constrained Shortest Path First 139
Cookie exchange 140
Cross Registry Information Service Protocol 140
Data Validation and Certification Server 141
Datagram Congestion Control Protocol 141
Datagram Transport Layer Security 143
Daytime Protocol 144
DCE Distributed File System 145
Default-free zone 146
Diameter (protocol) 147
Diameter Credit-Control Application 154
DICT 158
Directory Assistance Service 161
Directory information tree 162
Discard Protocol 163
Domain Name System 164
Domain Name System Security Extensions 176
Echo Protocol 189
Endpoint Handlespace Redundancy Protocol 190
Ephemeral port 190
Extensible Name Service 191
Exterior Gateway Protocol 192
External Data Representation 192
Fibre Channel over IP 196
File eXchange Protocol 197
File Transfer Protocol 198
Files2u 205
Finger protocol 206
First Hop Redundancy Protocols 208
FLIP (Fast-Local-Internet-Protocol) 208
Forward-confirmed reverse DNS 208
GENA 210
Geo URI 211
GNTP 213
Gopher (protocol) 214
GPRP 222
GroupDAV 223
Handle System 223
High Frequency Internet Protocol 228
Hopcount 228
Host Identity Protocol 229
Host Monitoring Protocol 230
HOTP 230
HTTP body data 232
ICMPv6 233
Ident 235
IGMP snooping 237
Internet 0 238
Internet chess server 240
Internet Content Adaptation Protocol 242
Internet Control Message Protocol 243
Internet Fibre Channel Protocol 246
Internet Group Management Protocol 247
Internet Group Management Protocol with Access Control (IGMP-AC) 250
Internet Imaging Protocol 251
Internet Open Trading Protocol 251
Internet Protocol Control Protocol 252
Internet Protocol Suite 254
Multipurpose Transaction Protocol 260
Transport Sample Protocol 261
Internet Streaming Media Alliance 261
IP Flow Information Export 262
IP Managed VAS 264
IP multicast 264
IPFC 271
IPsec 271
IS-IS 278
Jughead (search engine) 280
KA9Q 281
KAME project 282
L2TPv3 283
Layer 2 Tunneling Protocol 283
LDAP 288
Lightweight Telephony Protocol 297
Link-local Multicast Name Resolution 298
List of DNS record types 299
List of RADIUS servers 303
LogZilla 308
LysKOM 310
M3UA 311
MAC-Forced Forwarding 312
MacIP 312
Mail Transfer Protocol 313
Mapping of Airline Traffic over Internet Protocol 314
Media Delivery Index 314
Media Gateway Controller 318
Media Resource Control Protocol 318
Message posting protocol 319
Message send protocol 319
MetaWeblog 320
Metro Ring Protocol 321
Micro Transport Protocol 321
Microsoft Point-to-Point Encryption 323
MIMIC Simulator 323
MiMMS 324
MSN Direct 326
Multicast Listener Discovery 327
Multicast Source Discovery Protocol 327
Multiplexed Transport Layer Security 328
NAT-T 328
Neighbor Discovery Protocol 329
Net-SNMP 330
Network Control Protocol 334
Network Data Representation 335
Network File System (protocol) 335
Network Security Services 340
Network Time Protocol 343
OAuth 347
OCSP stapling 349
OFTP 350
Online Certificate Status Protocol 351
Open Archives Initiative Protocol for Metadata Harvesting 353
Open Network Computing Remote Procedure Call 356
Open port 357
Open Shortest Path First 358
Parallel Line Internet Protocol 372
Password authentication protocol 373
Path MTU Discovery 374
Peg DHCP 375
Ping sweep 376
PKI Resource Query Protocol 377
Pool Element 379
Pool Registrar 380
Pool User 381
Port number 381
Portmap 384
Professional video over IP 386
Proxy ARP 388
QOTD 390
Query flooding 391
Radio over IP 392
RadioVIS 394
Radius Values 405
RadSec 406
rdate 407
Realm-Specific IP 407
Realtek Remote Control Protocol 408
Registered port 409
Reliable Datagram Sockets 410
Reliable server pooling 410
Reliable User Datagram Protocol 413
Remote File System 414
Remote Job Entry 415
Remote Process Execution 416
Remote Shell 416
Resource reservation protocol 418
Reverse Address Resolution Protocol 421
Reverse telnet 422
rlogin 423
Route poisoning 425
Routing Information Protocol 426
Rsyslog 429
Salmon (protocol) 431
Scalable TCP 432
SCTP packet structure 432
SCVP 444
SDES 445
SDXF 447
Seamoby 451
Secure Neighbor Discovery Protocol 452
Secure Shell 453
Security Parameter Index 458
Sender Policy Framework 459
Serial Line Internet Protocol 466
Server Name Indication 467
Service discovery 471
Service Location Protocol 472
Session Announcement Protocol 475
Session Description Protocol 475
Shared Whois Project 477
SILC (protocol) 478
Simple Network Management Protocol 480
Simple Update Protocol 487
SMART Multicast 487
Space Communications Protocol Specifications 499
SPDY 500
Spotnet 501
Streaming Text Oriented Messaging Protocol 502
Syslog 503
Syslog-ng 505
T.38 ITU-T recommendation 508
T/TCP 511
TCP-Illinois 511
TCP/IP Illustrated 515
TCP/IP model 516
TCP Port Service Multiplexer 524
TCPware 525
Telnet 526
Text over IP 529
Time Protocol 532
Time-based One-time Password Algorithm 533
Tinc (protocol) 534
Transport Layer 536
Transport Layer Security 540
Traversal Using Relay NAT 555
TSIG 556
Tsunami UDP Protocol 558
Type-length-value 559
UDP Data Transport 560
UDP Helper Address 561
UDP-based Data Transfer Protocol 563
Usenet 566
User Datagram Protocol 580
Variant object 585
Venturi Transport Protocol 586
Veronica (search engine) 586
Virtual Router Redundancy Protocol 587
Virtual Switch Redundancy Protocol 589
VTun 590
WAN optimization 591
WebDAV 593
Webfinger 598
WebNFS 598
Whois 599
Wide area information server 608
Wireless Application Protocol 610
XML Enabled Directory 616
XML Interface for Network Services 618
Xpress Transport Protocol 626
Zeta-TCP 627
List of IP protocol numbers 629
Routing protocol 633
Babel (protocol) 635
Connectionless routing 635
Diffusing update algorithm 636
Distance Vector Multicast Routing Protocol 638
Distance-vector routing protocol 639
DVSR 643
Enhanced Interior Gateway Routing Protocol 643
Equal-cost multi-path routing 649
Flooding algorithm 650
Fuzzy routing 651
Geographic routing 652
Holddown 653
ICMP Router Discovery Protocol 654
Interior gateway protocol 654
Interior Gateway Routing Protocol 655
Link-state routing protocol 656
Lollipop sequence numbering 660
Longest prefix match 661
Multicast Open Shortest Path First 661
Multicast VLAN Registration 662
NAK (protocol message) 662
Narada multicast protocol 663
Path vector protocol 663
Pragmatic General Multicast 664
Private Network-to-Network Interface 665
Protocol Independent Multicast 665
R-SMLT 666
Reliable multicast 667
Resource Public Key Infrastructure 668
Routing loop problem 669
Split horizon route advertisement 670
Vehicular Reactive Routing protocol 671
Article Sources and Contributors 673
Image Sources, Licenses and Contributors 688
Article Licenses
License 690
Virtual security switch
Virtual security switch
A Virtual Security Switch is a software Ethernet switch with embedded security controls within it that runs within
Virtual Environments such as VMware, Citrix, Microsoft and Virtual Iron. The primary purpose of a Virtual Security
Switch is to provide security measures such as isolation, control and content inspection between virtual machines.
Virtual Machines within enterprise server environments began to gain popularity in 2005 and quickly started to
become a standard in the way companies deploy servers and applications. In order to deploy these servers within a
virtual environment, a virtual network needed to be formed and as a result companies such as VMware created a
resource called a Virtual Switch. The purpose of the Virtual Switch was to provide network connectivity within the
Virtual Environment so that virtual machines and applications could communicate within the virtual network as well
as to the physical network.
This concept of a Virtual Network introduced a number of problems as it related to security within virtual
environment due to only having virtual switching technology within the environment and not security technologies.
Unlike physical networks that have switches with ACL’s, Firewalls, Anti-Virus Gateways, or intrusion prevention
devices, the Virtual Network was very wide open. The Virtual Security Switch concept is one where switching and
security have joined forces so that security controls could be placed within the virtual switch and provide per port
inspection and isolation within the virtual environment. This concept allowed security to get as close as possible to
the end points that it intends to protect without having to reside on the end points (Host Based on Virtual Machines)
By eliminating the need to deploy host based security solutions on virtual machines a significant performance
improvement can be achieved when deploying security within the virtual environment. This is because Virtual
Machines share computing resources (CPU, Memory, Disk, etc.) unlike physical servers that have dedicated
resources. One example of understanding this is to picture 20 virtual machines running on a dual processor server
and each virtual server having its own Host Based Firewall running on them. This would make up 20 firewalls using
the same resources that the 20 virtual machines are using. This defeats the purpose of virtualization, which is to
apply those resources to virtual servers not security applications. Deploying security centrally within the virtual
environment is in a sense 1 firewall vs. 20 firewalls.
Problem Example
Because Virtual Machines are essentially operating systems & applications packaged into a single file called disk
images they have now become more mobile. For the first time in history servers can be moved around, exchanged
and file shared just like MP3 files shared on the Peer to Peer networks. Administrators can now download
pre-installed virtual servers via the internet to speed up the deployment time of new servers. No longer is it required
for an administrator to go through the lengthy software installation process, because these virtual disk images have
pre-installed operating systems and applications. They are in a sense, Virtual Appliances.
This mobility of server images has now created the potential problem that entire servers can become infected and
passed around in the wild. Imagine downloading the latest Fedora Linux Server from a web site like
ThoughtPolice.co.uk [1] , installing it in your virtual environment and later learning that there was a Trojan on that
server that later took down your virtual network. This could be catastrophic. There is obviously the trust factor that
now needs to be taken in account for when downloading virtual server images. But who do you trust? Do you trust
downloading an image from VMware’s Virtual Market Place [2]? Do you trust installing one that the previous IT
Manager within your company created?
The Virtual Security Switch concept is one that monitors your trust decision by providing isolation and security
monitoring between virtual machines. A Virtual Security Switch can isolate VM’s from each other, restrict what
types of communication is allowed between each other as well as monitor for the spread of malicious content or
denial of service attacks.
Virtual security switch
The concept of a Virtual Security Switch was introduced by John U. Peterson in 2006 while investigating how to
bring security closer to servers within the datacenters of physical networks. John was VP of Product Management at
Fortinet and later Chief Product Officer at Reflex Security
and while at both companies John worked to bring
security and switching together. John was successful in doing so at Reflex Security and introduced the industry’s first
10 gigabit Network Security Switch [4] which had a port density to support 80 physical servers connected to it. By
leveraging this knowledge in switching coupled with the firewall experience he obtained while serving as Worldwide
Systems Engineering Director at NetScreen Technologies, John was able to quickly introduce a Virtual Security
Switch with L2-L7 Firewall features along with network switching features. John then took this concept and adapted
it to software that could run as a virtual appliance within environments such as VMWare and used the concept as a
spring board to launch a company called Montego Networks. Subsequent to that, 3 U.S. patents were filed
surrounding the integration of security capabilities within a virtual switch.
Relevant Links
http:/ / www. vmwaresecurity.com
http:/ / www. comnews. com/ features/2007_may/ 0507security_rules. aspx
http:/ / www. vmware.com/ security
http:/ / www. networkworld.com/ news/ 2008/ 010808-firewall-options-lacking.html
Virtual security switch
[1] http:/ / www. thoughtpolice. co. uk
[2] http:// www. vmware.com/ appliances/
[3] http:// www. reflexsecurity.com
[4] http:/ / www. tolly. com/ ts/ 2007/ Reflex/MG10/ TollyTS207219ReflexMG10July2007RF. pdf
Virtual Switching Instance
Similar to VRF (Virtual Routing and Forwarding Instance) maintained in IP/MPLS routers to deliver layer 3 VPNs,
IP VPNs, IP/MPLS switches maintain a Virtual Switching Instance (VSI) to deliver layer 2 VPNs, VPLS.
As VRFs keep IP route entries for a particular L3 VPN, VSIs keep MAC address entries for a particular VPLS.
MAC addresses are learned on pseudowires (an L2 switch learns MAC addresses on ports).
Virtual firewall
A virtual firewall (VF) is a network firewall service or appliance running entirely within a virtualized environment
and which provides the usual packet filtering and monitoring provided via a physical network firewall. The VF can
be realized as a traditional software firewall on a guest virtual machine already running, or it can be a purpose-built
virtual security appliance designed with virtual network security in mind, or it can be a virtual switch with additional
security capabilities, or it can be a managed kernel process running within the host hypervisor.
Structural Fire Walls
Before the term "firewall" was applied to network technology a "fire wall" was used in building design and
mechanical engineering to designate a wall or partition composed of flame-resistant materials put in place to protect
more flammable structural components from catching fire or spreading flames, either accidentally in the case of an
unexpected fire, or where flame is usually present and needs to be isolated. Many building codes require fire-rated
materials in human-inhabited areas. Fire walls protect vulnerable assets (such as spaces that might contain people)
and prevent destructive events from spreading too quickly.
Network Firewalls
Computer networks are much like any other kind of inhabited space; networks have assets, they have participants
and they have rules. Some computer networks are private and others public, some contain sensitive assets and others
less so, and so on. Generally users and traffic residing on one network need to be protected from users and traffic on
a different but connected network. Yet all these networks are inter-connected to a degree (this being the origin of the
term "internetwork"
) — even if they are only connected via sneakernet — and this interconnectedness is both a
critical feature and an emergent vulnerability.
So it is not too surprising that the idea for "fire wall" functionality as applied to computer networks has been around
since the early days of the Internet, and saw serious development in the 1990s.
It was eventually recognized that
the very same problems applied in networks as existed in construction; containment and isolation. Network
engineers began working with routers and packet filters as early containment technology, and from these efforts
eventually emerged the sophisticated purpose-built network firewalls common in computer clouds, data centers and
home computers.
The intent of fire walls and firewalls are much the same; minimize or eliminate damage to important assets by
isolating or blocking destructive influences.
Virtual firewall
Virtual firewall
The problem
So long as a computer network runs entirely over physical hardware and cabling, it is a physical network. As such it
can be protected by physical firewalls and fire walls alike; the first and most important protection for a physical
computer network always was and remains a physical, locked, flame-resistant door.

Since the inception of the
Internet this was the case, and structural fire walls and network firewalls were for a long time both necessary and
Since about 1998 there has been an explosive increase in the use of "virtual machines" (VM) in addition to —
sometimes instead of — physical machines to offer many kinds of computer and communications services on local
area networks and over the broader Internet. The advantages of virtual machines are well explored elsewhere.

Virtual machines can operate in isolation (for example as a guest operating system on a personal computer) or under
a unified virtualized environment overseen by a supervisory virtual machine monitor or "hypervisor" process. In the
case where many virtual machines operate under the same virtualized environment they might be connected together
via a virtual network consisting of virtualized network switches between machines and virtualized network interfaces
within machines. The resulting virtual network could then implement traditional network protocols (for example
TCP) or virtual network provisioning such as VLAN or VPN, though the latter while useful for their own reasons are
in no way required.
There is a continued perception that virtual machines are inherently secure because they are seen as "sandboxed"
within the host operating system.


And the host in like manner is secured against exploitation from the virtual
machine itself
and the host is no threat to the virtual machine because it is a physical asset protected by
traditional physical and network security.
And even when this is not explicitly assumed early testing of virtual
infrastructures often proceeds in isolated lab environments where security is not as a rule an immediate concern, and
security may only come to the fore when the same solution is moving into production or onto a computer cloud,
where suddenly virtual machines of different trust levels may wind up on the same virtual network running across
any number of physical hosts.
Because they are true networks, virtual networks may end up suffering the same kinds of vulnerabilities long
associated with a physical network, some of which being:
• Users on machines within the virtual network have access to all other machines on the same virtual network.
• Compromising or misappropriating one virtual machine on a virtual network is sufficient to provide a platform for
additional attacks against other machines on the same network segment.
• If a virtual network is internetworked to the physical network or broader Internet then machines on the virtual
network might have access to external resources (and external exploits) that could leave them open to
• Network traffic that passes directly between machines without passing through security devices is unmonitored.
The problems created by the near invisibility of between-virtual machine (VM-to-VM) traffic on a virtual network
are exactly like those found in physical networks, complicated by the fact that the packets may be moving entirely
inside the hardware of a single physical host:
• Because the virtual network traffic may never leave the physical host hardware, security administrators cannot
observe VM-to-VM traffic, cannot intercept it, and so cannot know what that traffic is for.
• Logging of VM-to-VM network activity within a single host and verification of virtual machine access for
regulatory compliance purposes becomes difficult.
• Inappropriate uses of virtual network resources and bandwidth consumption VM-to-VM are difficult to discover
or rectify.
• Unusual or inappropriate services running on or within the virtual network could go undetected.
Virtual firewall
And there are security issues known only in virtualized environments that wreak havoc with physical security
measures and practices, and some of these are touted as actual advantages of virtual machine technology over
physical machines
• VMs can be deliberately (or unexpectedly) migrated between trusted and untrusted virtualized environments
where migration is enabled.
• VMs and/or virtual storage volumes can be easily cloned and the clone made to run on any part of the virtualized
environment, including a DMZ.
• Many companies use their purchasing or IT departments as the IT security lead agency, applying security
measures at the time a physical machine is taken from the box and initialized. Since virtual machines can be
created in a few minutes by any authorized user and set running without a paper trail, they can in these cases
bypass established "first boot" IT security practices.
• VMs have no physical reality leaving not a trace of their creation nor (in larger virtualized installations) of their
continued existence. They can be as easily destroyed as well, leaving nearly no digital signature and absolutely no
physical evidence whatsoever.
In addition to the network traffic visibility issues and uncoordinated VM sprawl, a rogue VM using just the virtual
network, switches and interfaces (all of which run in a process on the host physical hardware) can potentially break
the network as could any physical machine on a physical network — and in the usual ways — though now by
consuming host CPU cycles it can additionally bring down the entire virtualized environment and all the other VMs
with it simply by overpowering the host physical resources the rest of the virtualized environment depend upon.
This was likely to become a problem, but it was perceived within the industry as a well understood problem and one
potentially open to traditional measures and responses.



The solution
One method to secure, log and monitor VM-to-VM traffic involved routing the virtualized network traffic out of the
virtual network and onto the physical network via VLANs, and hence into a physical firewall already present to
provide security and compliance services for the physical network. The VLAN traffic could be monitored and
filtered by the physical firewall and then passed back into the virtual network (if deemed legitimate for that purpose)
and on to the target virtual machine.
Not surprisingly LAN managers, security experts and network security vendors began to wonder if it might be more
efficient to keep the traffic entirely within the virtualized environment and secure it from there.



Enter the virtual firewall.
A virtual firewall (VF) then is a firewall service or appliance running entirely within a virtualized environment —
even as another virtual machine, but just as readily within the hypervisor itself — providing the usual packet filtering
and monitoring that a physical firewall provides. The VF can be installed as a traditional software firewall on a guest
VM already running within the virtualized environment; or it can be a purpose-built virtual security appliance
designed with virtual network security in mind; or it can be a virtual switch with additional security capabilities; or it
can be a managed kernel process running within the host hypervisor that sits atop all VM activity and so has deep
access to the virtual network and its traffic and can even access VM active memory and virtualized storage.
The current direction in virtual firewall technology is a combination of security-capable virtual switches
, and
virtual security appliances integrating at the kernel level.


Virtual firewall
Virtual firewalls can operate in different modes to provide security services, depending on the point of deployment.
Typically these are either bridge-mode or hypervisor-mode (hypervisor-based, hypervisor-resident). Both may
come shrink wrapped as a virtual security appliance and may install a virtual machine for management purposes.
A virtual firewall operating in bridge-mode acts like its physical-world firewall analog; it sits in a strategic part of
the network infrastructure — usually at an inter-network virtual switch or bridge — and intercepts network traffic
destined for other network segments and needing to travel over the bridge. By examining the source origin, the
destination, the type of packet it is and even the payload the VF can decide if the packet is to be allowed passage,
dropped, rejected, or forwarded or mirrored to some other device. Initial entrants into the virtual firewall field were
largely bridge-mode, and many offers retain this feature.
By contrast, a virtual firewall operating in hypervisor-mode is not actually part of the virtual network at all, and as
such has no physical-world device analog. A hypervisor-mode virtual firewall resides in the virtual machine monitor
or hypervisor where it is well positioned to capture VM activity including packet injections. The entire monitored
VM and all its virtual hardware, software, services, memory and storage can be examined, as can changes in these.
Further, since a hypervisor-based virtual firewall is not part of the network proper and is not a virtual machine its
functionality cannot be monitored in turn or altered by users and software limited to running under a VM or having
access only to the virtualized network.
Bridge-mode virtual firewalls can be installed just as any other virtual machine in the virtualized infrastructure.
Since it is then a virtual machine itself, the relationship of the VF to all the other VM may become complicated over
time due to VMs disappearing and appearing in random ways, migrating between different physical hosts, or other
uncoordinated changes allowed by the virtualized infrastructure.
Hypervisor-mode virtual firewalls require a modification to the physical host hypervisor kernel in order to install
process hooks or modules allowing the virtual firewall system access to VM information and direct access to the
virtual network switches and virtualized network interfaces moving packet traffic between VMs or between VMs
and the network gateway. The hypervisor-resident virtual firewall can use the same hooks to then perform all the
customary firewall functions like packet inspection, dropping, and forwarding but without actually touching the
virtual network at any point. Hypervisor-mode virtual firewalls can be very much faster than the same technology
running in bridge-mode because they are not doing packet inspection in a virtual machine, but rather from within the
kernel at native hardware speeds.
VF offerings
A sampling of organizations that offer one kind or another of VF technology.
Who What How
Altor Networks
Virtual Gateway
Virtual security.
Security Gateway Virtual Edition
Virtual security.
Nexus 1000v
Virtual switch - Switch ACL
Security Virtual Server Protection
Virtual security.
Reflex Systems
Reflex vTrust
Virtual security - Hypervisor Mode
Trend Micro
Server Security
Virtual security
Virtual firewall
Additional reading
"Zeus Bot Appears in EC2 Cloud, Detected, Dismissed"
Babcock, Charles. InformationWeek Dec 2009
"40,000 Firewalls! Help Please!?"
Texiwill. The Virtualization Practice. Sept 2009
"OPINION / Why do we need virtual security? "
Ben-Efraim, Amir. Government Security News. Aug 2009
"Keep Your Virtual Networks Safe"
Zillion Magazine. Jul 2009
"The virtual blind spot"
Schultz, Beth. NetworkWorld. July 2010
"Cloud security in the real world: 4 examples"
Brandel, Mary. CSO: Security & Risk. June 2010
"Securing mixed environments - not everybody will be virtualized"
Ogren, Eric. ComputerWorld. June 2010
"New security tools protect virtual machines"
Strom, David. Network World March 2011
[1] (http:// www. isoc. org/internet/ history/ brief.shtml) "A Brief History of the Internet" Barry M. Leiner, Vinton G. Cerf, David D. Clark, et
al., Internet Society
[2] (http:/ / www. darkreading.com/ security/ management/ showArticle. jhtml?articleID=208803808) "Who Invented the Firewall?" Higgins,
Kelly Jackson, Dark Reading Jan 2008
[3] (http:/ / searchnetworking. techtarget.com/ news/ article/0,289142,sid7_gci1347565,00. html#) "Physical network security key to fighting
low-tech threats" Morisey, Michael. SearchNetworking.com, Feb 2009.
[4] (http:/ / www. skullbox. net/ physicalnetworksecurity. php) "Physical Network Security" Rodriguez, Erik. Skullbox.com May 2005.
[5] (http:/ / www. devx.com/ vmspecialreport/ Article/30383) "The Pros and Cons of Virtual Machines in the Datacenter" Chao, Wellie,
DevX.com Jan 2006
[6] (http:/ / www. vmware. com/ virtualization/virtual-machine.html) "Transform your Business with Virtualization", Vmware Virtualization
[7] (http:/ / ask-leo.com/ does_a_sandbox_or_virtual_machine_help_protect_your_privacy.html) "Does a sandbox or virtual machine help
protect your privacy?" Notenboom, Leo. Oct 2008
[8] (http:// searchservervirtualization.techtarget. com/ news/ article/ 0,289142,sid94_gci1273735,00. html) "Virtual machine security threat
levels; don’t believe the hype" Botelho, Bridget. IT Knowledge Exchange. Nov 2008
[9] (http:/ / searchenterpriselinux. techtarget.com/ tip/ Meditations-on-a-virtually-secure-world) "Meditations on a virtually secure world"
Korelc, Justin and Ed Tittel. SearchEnterpriseLinux.com Apr 2006
[10] (http:// www. coresecurity. com/ content/ vulnerability-vmware) "Core Security Technologies Discovers Critical Vulnerability In Vmware's
Desktop Virtualization Software" Core Security Technologies, Feb 2008
[11] (http:// www. tml. tkk. fi/ Publications/ C/ 25/ papers/ Reuben_final.pdf) "A Survey on Virtual Machine Security" Reuben, JS. Helsinki
University of Technology, undated
[12] (http:/ / www. sans. org/reading_room/analysts_program/ VMware_ITAudit_Sep09.pdf) "IT Audit for the Virtual Environment"
SANS.org, Dec 2009
[13] (http:/ / www. ibm. com/ developerworks/ systems/ library/es-pwr5-virtualvlan/index. html) "POWER5 Virtualization: How to work with
VLANs using the IBM Virtual I/O Server" IBM Inc. Nov 2008
[14] (http:// redmondmag. com/ articles/ 2009/ 02/ 01/ secure-virtual-networks.aspx) "Secure Virtual Networks" Wettern, Joern.
Redmondmag.com Feb 2009
[15] (http:// searchnetworking. techtarget.com. au/ articles/ 36232-Why-Hyper-V-virtual-networks-are-less-secure-than-physical-networks)
"Why Hyper-V virtual networks are less secure than physical networks" Shields, Greg. TechTarget SearchNetworking, Oct 2009
[16] (http:/ / news. cnet. com/ 8301-13846_3-10395695-62.html) "Security considerations for virtual environments" Rosenberg, David. Cnet
News Nov 2009
[17] (http:// www. apani. com/ News-Info/Alternative-to-Hardware-based-Firewalls-and-VLANs.html) "Software-Based Access Management
Protects Mixed Networks of Virtual and Physical Machines without Complex Rule Sets and High IT Overhead" Apani Inc. Aug 2008
[18] (http:/ / static2. altornetworks.com/ docs/ Hosting. pdf) "Secure Virtualized Hosting" Altor Networks Inc.
[19] (http:/ / vmblog. com/ archive/ 2008/ 03/ 26/ best-practices-for-securing-virtual-networks-part-one-of-three.aspx) "Best Practices for
Securing Virtual Networks" Moore, Hezi. March 2008 vmblog.com
[20] (http:// www. cisco. com/ en/ US/ products/ ps9902/ index. html) Introduction to the Nexus 1000V. Cisco Inc.
[21] (http:/ / go4idm. blogspot. com/ 2009/ 08/ vmsafe-apis-reassure-wary-it-security.html) "VMsafe APIs reassure wary IT security
professionals" Lukkad, VJ. Identity and Access Management Blog. Aug 2009
[22] (http:/ / www. vminformer.com/ tag/ virtual-firewall/) "Should I have a Firewall for my Virtual World?" VMInformer.
[23] (http:/ / www. vmware. com/ appliances/ directory/uploaded_files/ AltorNetworksCaseStudy-Winsert.pdf) Case Study: Winsert Inc.
[24] http:// www. altornetworks.com
[25] http:/ / www. checkpoint. com
[26] http:/ / www. checkpoint. com/ products/ security-gateway-virtual-edition/index.html
Virtual firewall
[27] http:/ / www. cisco. com
[28] http:// www. cisco. com/ en/ US/ products/ ps9902/ index. html
[29] http:/ / www. ibm. com
[30] http:/ / www-01.ibm. com/ software/ tivoli/ products/ virtual-server-protection/
[31] http:/ / www. reflexsystems. com
[32] http:// www. reflexsystems. com/ Products/ vTrust
[33] http:/ / us. trendmicro.com/ us/ home/
[34] http:/ / us. trendmicro.com/ us/ solutions/ enterprise/ security-solutions/ server-security/
[35] http:// www. informationweek.com/ cloud-computing/blog/ archives/ 2009/ 12/ zeus_bot_appear.html|
[36] http:/ / www. virtualizationpractice.com/ blog/ ?p=1489|
[37] http:// www. gsnmagazine. com/ cms/ industry-sectors/ it-security/ 2454. html|
[38] http:// static. altornetworks.com/ docs/ zillion-keep-virtual-network-safe.pdf|
[39] http:/ / www. networkworld.com/ supp/ 2010/ ndc4/ 071210-ndc4-virtual-machines.html?page=1|
[40] http:// www. csoonline. com/ article/596820/ cloud-security-in-the-real-world-4-examples?page=1|
[41] http:/ / blogs. computerworld.com/ 16264/ securing_mixed_environments_not_everybody_will_be_virtualized|
[42] http:// www. networkworld.com/ reviews/ 2011/ 030711-virtualization-security-test.html|
OpenSolaris Network Virtualization and
Resource Control
OpenSolaris network virtualization and resource control is a set of OpenSolaris features, currently under
development by Sun Microsystems as an open source project. OpenSolaris provides an internal network
virtualization and quality of service scenario, implemented through the features of the OpenSolaris Crossbow
umbrella project.
Major features of the Crossbow project include:
• Virtual NIC (VNIC) pseudo-network interface technology
• Exclusive IP zones
• Bandwidth management and flow control on a per interface and per VNIC basis
The Crossbow project software, combined with next generation network interfaces like xge and bge, enable network
virtualization and resource control for a single system. By combining VNICs with features such as exclusive IP
or the Sun xVM hypervisor, system administrators can run applications on separate virtual machines to
improve performance and provide security. Resource management and flow control features provide bandwidth
management and quality of service for packet flows on separate virtual machines. You can allocate bandwidth
amounts and manage data flows not only for the physical network interface but also for any containers configured on
the interface. The Crossbow resource control features enable increased system efficiency and the ability to limit the
amount of bandwidth consumed by a process or virtual machine.
OpenSolaris Network Virtualization and Resource Control
Features of the Crossbow project
This section briefly describes the main features of the Crossbow network virtualization and resource control project.
For further details on each feature, see the Crossbow Network Virtualization Architecture document available for
download at the OpenSolaris Crossbow documentation page
A VNIC is a pseudo network interface that is configured on top of a system's physical Network adapter, also called a
network interface (NIC). A physical interface can have more than one VNIC. Each VNIC operates like and appears
to the system as a physical NIC. The individual VNIC is assigned a media access control address (MAC address),
which can be configured to a value other than the default MAC address assigned to the physical NIC. You can use
the resource control features of Crossbow to allocate separate bandwidths to the individual VNICs. Moreover, you
can configure a virtual machine, such as an exclusive IP zone or xVM domain on top of a VNIC.
Virtual switch
When the first VNIC is created on a system, a virtual switch is also created above the physical interface. Though not
directly accessible to the user, the virtual switch provides connectivity between all VNICs configured on the same
physical interface, enabling the virtual network in a box scenario. The virtual switch forwards packets between the
system's VNICs. Thus, packets from an internal VNIC source never have to pass to the external network to reach an
internal network destination.
Exclusive IP zones
An exclusive IP zone
is a separate instance of a full TCP/IP stack, which functions as a non-global zone
. Each
exclusive IP zone is built upon a physical network interface and has its own IP-related state. IP instances support
DHCPv4 and IPv6 address autoconfiguration. An exclusive IP zone can have its own routing table and routing
protocols separate from the global zone on a system. Moreover, a system administrator can run the ifconfig command
within an exclusive IP instance to set up a logical interface within the exclusive IP zone.
Modifications to the TCP/IP MAC layer
In OpenSolaris, the MAC layer is part of the larger Data link layer of the TCP/IP protocol stack. The Crossbow
project modifies this layer with several new features, including the MAC client interface. This virtual entity is a
kernel data structure that is not externally visible to the system administrator. However, the MAC client interface
along with the VNIC driver provides the VNIC functionality in OpenSolaris. Additionally, Crossbow modifications
to the MAC layer enable a system administrator to assign a different MAC address to each VNIC on a system.
Resource management and flow control
The Crossbow project features provide bandwidth management and flow control on a per VNIC basis. A system
administrator can configure different bandwidth allocations to the various VNICs on a host through the new
Crossbow-related commands dladm.1m
and flowadm.1m
. Traffic through each VNIC can be classified and
separated into individual flows, based on port number, destination IP address, and other parameters. These features
can be used to improve system efficiency and enable differentiated services for separate VNICs.
OpenSolaris Network Virtualization and Resource Control
Observability features
Standard Solaris observability tools can be used to monitor the status of exclusive IP instances, VNICs, and virtual
machines running on VNICs. For example, familiar tools such as ping and snoop can report status on the operations
of a VNIC. Additionally, the netstat.1m
command has been extended for Crossbow to report statistics on packet
flows defined with the flowadm command.
Crossbow code availability
The exclusive IP zones feature is included in the Solaris 10 8/07 release. The first version of the Crossbow feature
set was incorporated in OpenSolaris 2009.06. Source code can be downloaded from the OpenSolaris Crossbow site
External links
• OpenSolaris Crossbow project site
. The project page for OpenSolaris Crossbow, which includes technical
specifications, documentation and latest news about the project.
• dladm man pages
. Links for the most current dladm man pages, which is one of the main tools used to manage
virtual network resources.
[1] http:/ / www. opensolaris. org/os/ community/crossbow
[2] http:/ / www. opensolaris. org/os/ project/crossbow/ faq/#ip_instances
[3] http:// www. opensolaris. org/os/ project/crossbow/ Docs
[4] http:// docs. sun. com/ app/ docs/ doc/ 817-1592/6mhahuoul?a=view#indexterm-168
[5] http:// docs. sun. com/ app/ docs/ doc/ 817-1592/6mhahuoto?a=view#indexterm-140
[6] http:// docs. sun. com/ app/ docs/ doc/ 819-2240/dladm-1m?a=view
[7] http:// docs. sun. com/ app/ docs/ doc/ 819-2240/flowadm-1m?a=view
[8] http:// www. dlc. sun. com/ osol/ netvirt/downloads/ 20070214. netstat. 1m. txt
[9] http:// www. opensolaris. org/os/ project/crossbow
• Belgaied, Kais and Lu, Roamer. “Crossbow Hardware Resources Management and Virtualization” (http:/ / www.
opensolaris. org/os/ project/crossbow)
• Droux, Nicolas, "Crossbow Network Virtualization Architecture" (http:// www.opensolaris. org/os/ project/
crossbow/ Docs)
• Rami, Rosen, Virtualization in OpenSolaris (http:/ / www.freesoftwaremagazine.com/ articles/
• System Administration Guide: Solaris Containers-Resource Management and Solaris Zones (http:/ / www.docs.
sun.com/ app/ docs/ doc/ 2450)
• Rami, Rosen, Open Solaris lecture (slides in pdf) (http:// www.haifux.org/ lectures/ 160/ solLec. pdf)
• Moellenkamp, Joerg Configuration of Crossbow Network Virtualisation (http:/ / www.c0t0d0s0. org/permalink/
Upcoming-Solaris-Features-Crossbow-Virtualisation. html)
• Moellenkamp, Joerg Configuration of Crossbow Bandwidth Limiting and Accounting (http:/ / www.c0t0d0s0.
org/archives/ 5674-Upcoming-Solaris-Features-Crossbow-Part-2-Limiting-and-Accounting.html)
InterSwitch Trunk
InterSwitch Trunk
InterSwitch Trunk (IST) is one or more parallel point-to-point links (Link aggregation) that connect two switches
together to create a single logical switch. The IST allows the two switches to share addressing information,
forwarding tables, and state information, permitting rapid (less than one second) fault detection and forwarding path
modification. The link may have different names depending on the vendor. For example, Brocade calls this an
Inter-Chassis Link (ICL).
Cisco calls this a VSL (Virtual Switch Link).
Edge switches, servers or PC's see the two aggregate switches as one large switch. This allows any vendor's
equipment configured to use the IEEE 802.3ad static link aggregation protocol to connect to both switches and take
advantage of load balancing, redundant connections.
The IST protocol was developed by Nortel (now acquired by Avaya) to enhance the capabilities of Link aggregation,
and is required to be configured prior to configuring the SMLT, DSMLT or R-SMLT functions on the two aggregate
(core, distribution, or access) switches. The edge equipment can be configured with any of the following; Multi-Link
Trunking (MLT), DMLT, IEEE 802.3ad static link aggregation, IEEE 802.3ad Static Gigabit EtherChannel (GEC),
IEEE 802.3ad Static Fast EtherChannel (FEC), SMLT, DSMLT, and other static link aggregation protocols.
United States Patent 7173934
Product Support
IST is supported on Nortel's Routing Switch 1600, 5500, 8300, ERS 8600 and MERS 8600 products.
[1] http:/ / www. brocade. com/ forms/getFile?p=documents/ white_papers/ Brocade_Multi-Chassis_Trunking_WP. pdf
[2] http:// www. cisco. com/ en/ US/ docs/ switches/ lan/ catalyst6500/ ios/ 12. 2SX/ configuration/guide/ vss. html#wp1062284
External links
• Designing a Resilient Network (http:/ / www. nortel.com/ products/ 01/ passport/ 8600_rss/ collateral/
• Eliminate Single Points of Failure (http:// www. nortel.com/ products/ 01/ passport/ 8600_rss/ collateral/
nn108460-060304. pdf)
• Resilient Terabit Cluster - Always on Networking (http:/ / products. nortel. com/ go/ product_assoc.
jsp?segId=0& parId=0&catId=null&rend_id=25821&contOid=100175078& prod_id=44781&locale=en-US)
Windows Virtual PC
Windows Virtual PC
Windows Virtual PC
Windows Virtual PC running Windows XP Mode on a Windows 7 host
Developer(s) Microsoft
Initial release
September 19, 2009
Stable release
6.1.7600.16393 / February 10, 2011
Operating system
Windows 7 – All editions
32-bit: 9.1 MB
64-bit: 9.9 MB
Type Virtual machine
Microsoft Virtual PC for Mac
Virtual PC 6.1 for Mac
Stable release 7.0.3 / August 14, 2007
Development status Discontinued
Operating system
Mac OS X 10.2.8 or later
Proprietary commercial software
Original: microsoft.com/mac/products/
Australian: microsoft.com/australia/office/mac/virtualpc7/
Windows Virtual PC (successor to Microsoft Virtual PC 2007, Microsoft Virtual PC 2004, and Connectix
Virtual PC) is a virtualization program for Microsoft Windows. In July 2006 Microsoft released the
Windows-hosted version as a free product.
In August 2006 Microsoft announced the Macintosh-hosted version
would not be ported to Intel-based Macintosh computers, effectively discontinuing the product as PowerPC-based
Macintosh computers are no longer manufactured. The newest release, Windows Virtual PC, does not run on
versions of Windows earlier than Windows 7, and does not emulate MS-DOS or operating systems earlier than
Windows XP SP3 Professional.
The older versions, which support a wider range of host and emulated operating
systems, remain available.
Virtual PC virtualizes a standard PC and its associated hardware. Supported Windows operating systems can run
inside Virtual PC. Other operating systems such as Linux may run, but are not officially supported, and Microsoft
does not provide the necessary drivers (called "Virtual Machine Additions") for Linux.
Windows Virtual PC
Connectix Virtual PC, Microsoft Virtual PC 2004, Microsoft Virtual PC 2007, and Windows Virtual PC are
successive versions of the same software. Windows Virtual PC runs only under Windows 7 and emulates operating
systems from XP Professional on, but the earlier Microsoft versions which run under older versions of Windows are
still available, and can emulate operating systems older than Windows XP.
Windows Virtual PC
Windows Virtual PC entered public beta testing on April 30, 2009,
and was released alongside Windows 7.
Unlike its predecessors, this version supports only Windows 7 host operating systems.
It originally required
hardware virtualization support but on March 19, 2010, Microsoft released an update to Microsoft Virtual PC which
allows it to run on PCs without hardware support.
Windows Virtual PC is available free of charge for certain editions of Windows 7,
either pre-installed by OEMs or
via download from the Microsoft website.
New features
• USB support and redirection – connect peripherals such as flash drives and digital cameras, and print from the
guest to host OS printers. However, USB isochronous devices like webcams, microphones (bi-directional audio
streams) are not supported
• Seamless application publishing and launching – run Windows XP Mode applications directly from the Windows
7 desktop
• Support for multithreading – run multiple virtual machines concurrently, each in its own thread for improved
stability and performance
• Smart card redirection – use smart cards connected to the host
• Integration with Windows Explorer – manage all VMs from a single Explorer folder (%USER%\Virtual
Removed features
• The Virtual Machine console is replaced by an integrated Virtual Machines shell folder. Several options from the
console have been removed such as Restore at start, CPU time performance settings, muting sound in inactive
virtual machines, full-screen resolution related options, configuring the host key, mouse capture options and
settings for requiring administrator permissions.
• Official guest support for operating systems earlier than Windows XP Professional
• Drag-and-drop file sharing between the guest and the host
• Direct sharing of folders between host and guest operating system (Only volumes may be shared between
operating systems)
• Ability to commit changes in undo disks upon turning off virtual machines (Doing so is now only possible
through virtual machine Settings dialog box)
• Ability to use physical and virtual Parallel ports
• User interface controls for using virtual floppy disks (Virtual floppy disk functionality, however, is still supported
and may be accessed using a script)
• Virtual PC additions for guest operating systems no longer supported have been removed. However, installing
Virtual Machine Additions from an older Microsoft virtualization product works for some guest OSes.


• Properties of the Virtual Machine like Guest OS, processor, processor features, video mode, Video RAM, code
cache, IDE controller reads and writes, ethernet reads and writes, video frame rate and command line options can
no longer be viewed.
Windows Virtual PC
System requirements
System requirements for Windows Virtual PC:

• Computer running Windows 7 (Ultimate, Enterprise, Professional, Home Premium or Basic Editions )
• 1+ GHz processor (32- or 64-bit)
• 1.25 GB memory required, 2 GB recommended
• Additional 15 GB of hard disk space per virtual Windows environment recommended
• Optional: if the processor supports hardware-assisted virtualization technology such as AMD-V or Intel-VT, it
will be used. Before March 19, 2010, such a processor was mandatory.
Windows XP Mode
Windows XP Mode (XPM)
is a virtual machine package for Windows Virtual PC containing a pre-installed,
licensed copy of Windows XP Professional with Service Pack 3 as its guest OS. Previously, both the CPU and
motherboard had to support hardware virtualization,
but an update in early 2010 eliminated this requirement.
Pre-installed integration components allow applications running within the virtualized environment to appear as if
running directly on the host,

sharing the native desktop and Start Menu of Windows 7 as well as participating
in file type associations. XP Mode applications run in a Terminal Services session in the virtualized Windows XP,
and are accessed via Remote Desktop Protocol by a client running on the Windows 7 host.

Applications running in Windows XP mode do not have compatibility issues, as they are actually running inside a
Windows XP virtual machine and redirected using RDP to the Windows 7 host. For 64-bit editions of Windows 7,
XP Mode may be used to run 16-bit applications; it includes NTVDM.
Windows XP Mode is available free of charge to users of Windows 7 Professional, Enterprise, and Ultimate.
Users of other editions of Windows 7 are not eligible to download and use it.

This restriction does not apply
to Windows Virtual PC itself.
XP Mode can also be run with the VMware Player and other VMware virtual machine software
, adhering to
Microsoft’s limitation to machines running under Windows 7 Professional, Enterprise, or Ultimate.
Emulated environment
Virtual PC emulates the following environments:
• Intel Pentium II (32-bit) processor (but virtualizes the host processor on Windows versions) with an Intel 440BX
• Standard SVGA VESA graphics card (S3 Trio 32 PCI with 4 MB video RAM, adjustable in later versions up to
16 MB by manually editing a virtual machine's settings file).
• System BIOS from American Megatrends (AMI).
• Creative Labs Sound Blaster 16 ISA PnP. (When Vista is installed as both the host (main) and guest (virtual)
operating systems, settings are synchronized with the host and audio configuration is not required.)
• DEC 21041 (DEC 21140 in newer versions) Ethernet network card.
• Microsoft Virtual PC 2007 and earlier do not have the ability to redirect USB devices to the guest machine,
although devices connected to the host OS via USB can be used as normal by Virtual PC.
• Programs using undocumented features of hardware, exotic timings, or unsupported opcodes may not work.
• The Macintosh version of Virtual PC uses dynamic recompilation to translate the x86 code used by PCs into
equivalent PowerPC code for Macs.
• The Windows version of Virtual PC also uses dynamic recompilation, but only to translate x86 kernel mode and
real mode code into x86 user mode code; original user mode and virtual 8086 mode code run natively.
Windows Virtual PC
• Guest call traps are used, especially for guest extensions, to accelerate emulation or offer additional features, such
as integration with the host environment.
• Virtual PC and Virtual Server encapsulate virtual hard disks in the Virtual Hard Disk (VHD) file format, for
which Microsoft has made all documentation available under the Open Specification Promise.
Earlier versions of Virtual PC supported the following features: (now removed in Microsoft Virtual PC 2004, 2007,
and Windows Virtual PC):
• Older versions of Virtual PC (v5.0 or earlier) may have the hard disk formatted after creating the Virtual Hard
Disk file. Newer versions must partition and format the Virtual Hard Disk file manually.
• A Virtual Switch available in Virtual PC version 4.1 or earlier allows adding multiple network adapters.
• Older operating systems are supported with Virtual Machine additions.
• Older versions of Virtual PC for Macintosh can run on Mac OS 9.2.2 or earlier. Support of Apple System 7.5 was
dropped in version 3.
Virtual Machine Integration Components
Windows Virtual PC may enable guest operating systems running inside virtual machines to interact with their host
operating system beyond what is feasible between two physical computers, such as sharing physical hardware
components or exchanging data. To do so however, Integration Components must be installed on the guest operating
systems. When no integration component is installed, the only mean of communicating between two machines
(either virtual or physical) is through a virtual network interface. Even the mouse cursor can only be controlled by
one operating system (either real or virtual) at any given time. However, once the Integration Components are
installed on the guest operating systems, the following features are automatically activated:
• Mouse cursor sharing: Mouse cursor can be move freely between the machines.
• Host-initiated shutdown: Virtual machine can be shutdown, restarted or put into standby or hibernation via a set
of API functions.
• Time synchronization: The virtual machine's clock will be automatically synchronized with the host operating
system's clock.
• Process responsiveness monitoring: Host operating system will be able to detect whether the software on the guest
operating system is responsive or hung.
• Dynamic screen resolution: The screen resolution of the guest operating system can simply be changed by
resizing the window into which it is running.
In addition to features described above, guest operating systems may also take advantage of the following integration
features but only when the administrator activates them:
• Audio sharing: Audio played on the guest operating system may be brought to the host operating system and
played on it.
• Clipboard sharing: Contents such as text, picture or everything that is cut or copied to Windows Clipboard maybe
pasted in other machines.
• Printer sharing: Guest operating systems may print on the host operating system's printer . This feature should not
be confused with File and Printer Sharing over an emulated network connection.
• Smart card sharing: Smart cards connected to host operating system may be accessed on guest operating systems.
• File sharing: Windows Virtual PC can also share disk partitions and disk drives of the host operating system with
guest operating systems.

This includes USB mass storage devices that are connected later.
In Windows Virtual PC, enabling integration features automatically makes the virtual machine user account
accessible using Remote Desktop Connection.
Windows Virtual PC
Supported host and guest operating systems
Virtual PC allows multiple guest operating systems to run virtualized on a single physical host. Although a number
of popular host and guest operating systems lack official Microsoft support, there are sometimes few, if any,
technical obstacles impeding installation. Instead, a configuration may be unsupported due to Microsoft's own
licensing restrictions,

or a decision to focus testing and support resources elsewhere, especially when
production use of a legacy product fades.

A program manager on Microsoft's core virtualization team explains what official support entails:
With each release of Virtual PC we spend a significant amount of time trying to decide which (guest)
operating system should be officially supported. While Virtual PC is capable of running many operating
systems, official support for an operating system means that we will test it thoroughly, not ship Virtual PC if
an issue exists with that operating system, and provide full support for customers who encounter problems
while running these operating systems under Virtual PC.
—Ben Armstrong, "Virtual PC Guy"
As a product positioned for desktop use, Virtual PC provides official support for a different set of operating systems
than its server-oriented counterpart, Microsoft Virtual Server and the more advanced Hyper-V.

While the
latter products support a range of server operating systems,

Virtual PC 2007 supports only one variety as host
and another as guest;
its successor, Windows Virtual PC, supports none.
And, whereas Virtual Server and
Hyper-V have officially supported select Linux guests since 2006
and 2008,
respectively, as of 2009, no
Microsoft release of Virtual PC has officially supported Linux. Nonetheless, a number of Linux distributions
run successfully in Virtual PC 2007, and can be used with the Virtual Machine Additions from Virtual Server (see

Lastly, while 64-bit host support was introduced with Virtual PC 2007, no release has been able to
virtualize a 64-bit guest;


Microsoft has thus far reserved this functionality for Hyper-V, which runs only
on 64-bit (x64) editions of Windows Server 2008.

Table of supported operating systems
In the following table and notes, "support" refers to official Microsoft support, as described above.
Virtual PC 2004




Virtual PC 2007


Windows Virtual PC



Operating system (host or guest?) Host Guest Host Guest Host Guest
32-bit 64-bit 32-bit 32-bit 64-bit 32-bit 32-bit 64-bit 32-bit 64-bit
Windows 7 Ultimate Uns Uns Uns
Yes Yes Yes
Windows 7 Enterprise Uns Uns Uns
Yes Yes Yes
Windows 7 Professional Uns Uns Uns
Yes Yes Yes
Windows 7 Home Premium Uns Uns Uns
Uns Uns Uns
Windows 7 Home Basic Uns Uns Uns Uns Uns Uns
[J] Uns
Windows 7 Starter Uns
Uns Uns
Uns Uns
Windows Server 2008 Standard Uns Uns Uns
[E] Uns Uns Uns Uns
Windows Vista Ultimate Uns Uns Uns
Yes Yes
[D][G] Uns Uns
Windows Vista Enterprise Uns Uns Uns
Yes Yes
[D][G] Uns Uns
Windows Vista Business Uns Uns Uns
Yes Yes
[D][G] Uns Uns
Windows Virtual PC
Windows Vista Home Premium Uns Uns Uns
[D][F] Uns Uns
[J] Uns
Windows Vista Home Basic Uns Uns Uns
[F] Uns Uns
[J] Uns
Windows Vista Starter Uns
Uns Uns
N/A Yes
Windows Server 2003 Standard
[B] Uns
Yes Yes Yes Yes
Uns Uns Uns Uns
Windows XP Professional Yes Uns Yes Yes Yes Yes Uns Uns Yes Uns
Windows XP Tablet PC Edition
Yes N/A Yes Yes N/A Yes
Windows XP Media Center Edition Uns
[γ] Uns
Uns Uns
Windows XP Home Edition Uns
N/A Yes
[H] Uns
Windows XP Starter Edition Uns
N/A Yes
N/A Yes
Windows 2000 Server Uns N/A Yes Uns N/A Yes Uns N/A Uns N/A
Windows 2000 Professional Yes N/A Yes Uns N/A Yes Uns N/A Uns N/A
Windows Me Uns
N/A Yes
[C] Uns
Windows 98 Second Edition Uns N/A Yes Uns N/A Yes Uns N/A Uns N/A
Windows 98 (original release) Uns
N/A Yes
[C] Uns
Windows 95 Uns
N/A Yes
[C][β] Uns
Windows NT 4.0 Workstation Uns
N/A Yes
[C] Uns
Windows NT 3.51 Workstation Uns N/A Uns Uns N/A Uns Uns N/A Uns N/A
Windows NT 3.1 | NT 3.5 Uns
[ε] Uns
[ε] Uns
IBM OS/2 (select editions) Uns
[A] Uns
[A] Uns
16-bit 16-bit 16-bit 16-bit 16-bit 16-bit
Windows 3.1 Uns
Uns Uns
Windows 3.0 Uns
[C][α] Uns Uns
MS-DOS 6.22 Uns
[C][α] Uns Uns
Microsoft support
Yes Supported
Uns Unsupported
N/A Version nonexistent
? Status unconfirmed
Full or near-full functionality
Partial functionality
Unusable or fails install
(grey) Status unconfirmed
Windows Virtual PC
Notes – Details of Microsoft support
  Supported editions: OS/2 Warp Version 4 Fix Pack 15, OS/2 Warp Convenience Pack 1, and OS/2 Warp
Convenience Pack 2.


  Support added in Virtual PC 2004 Service Pack 1 (SP1) for Windows Server 2003, Standard Edition as a host.
  For Virtual PC 2007, Microsoft designated the following legacy operating systems "compatible", but
discontinued official support: MS-DOS 6.22, Windows NT 4.0 Workstation, Windows 95, the original release of
Windows 98 and Windows Me.

  For Windows Vista guests in Virtual PC 2007, the Windows Aero graphical user interface is disabled due to
limitations of the emulated S3 Trio
graphics card; the interface falls back to the Vista Home Basic theme. However,
Aero effects can be rendered by connecting to the guest via Remote Desktop Connection from an Aero-enabled host.
  Support added in Virtual PC 2007 Service Pack 1 (SP1) for Windows Server 2008 Standard as a guest.
  Microsoft's January 2008 EULA supplement

for Windows Vista lifted restrictions

installation of Vista Home Basic and Home Premium as guest operating systems.



  Microsoft's January 2008 EULA supplement

for Windows Vista lifted restrictions
barring use of


and Microsoft-DRM-protected content within virtualized environments.


  Support added in a Virtual PC 2007 Service Pack 1 (SP1) hotfix rollup, dated February 20, 2009, for
Windows XP Home as both host and guest, and for all Home editions of Windows Vista as hosts.
  The pre-configured XP Mode of Windows Virtual PC is restricted to Windows 7 Professional, Enterprise, and
Ultimate hosts.
However, an equivalent environment can be configured manually by installing Windows XP SP3 as
a guest (requires an XP license and installation media or files) and applying an integration components update
(available for download
from Microsoft) to enable seamless mode and other Windows 7 integration features.
10. The integration components enabling seamless mode and other features
of Windows Virtual PC support only the
following guests: Windows XP Pro Service Pack 3 (SP3);
Windows Vista Business SP1, Enterprise SP1, and
Ultimate SP1;
and Windows 7 Professional, Enterprise, and Ultimate.

Notes – Unsupported installations
  Virtual PC 2007 does not include Virtual Machine Additions for MS-DOS as a self installing disk image (installed
using a batch file), however the files are included in the Virtual Machine Additions ISO image file (typically found in
the 'Program Files' folder where Virtual PC was installed) and can be extracted by various means (a number of file
compression software packages support extracting files from ISO image files) for manual installation, also the DOS
additions from Virtual PC 2004 can be used without problem as can the DOS additions from Virtual Server 2005.
  The Virtual Machine Additions included with Virtual PC 2007 will not install on Windows 95 guests, but the
additions from Virtual PC 2004 can be used.
  In informal testing, Microsoft virtualization manager Ben Armstrong found XP Media Center 2004 "distorted and
unusable" under Virtual PC 2004, but Media Center 2005 worked "beautifully", sans TV features.
  MSDN blogs report that pre-release versions of Windows 7, similar to the forthcoming Ultimate edition,
successfully as both host and guest operating systems on Virtual PC 2007 Service Pack 1 (SP1). Integration features
provided by Virtual Machine Additions function normally, but Virtual PC 2007 must be SP1 or later.


"Windows 7 on Virtual PC on Windows 7"

for more caveats.
  Although Windows NT 3.1 and NT 3.5 refuse to install on newer processors (NT 3.51 fixes this), it is possible to
modify files on the install CD to allow install.
Windows Virtual PC
Linux guests
Installing a Linux-based guest environment in Virtual PC is possible. RedHat and SuSe Linux guests are supported.
Linux additions are supported in Microsoft Virtual Server, and these additions should also work in Virtual PC.
Some Linux distributions must be installed in text mode, as they do not support Microsoft Virtual PC's emulated
graphics chip. Ubuntu 8.10 (Intrepid Ibex) must be installed in SafeMode, but does not require other changes.
Some websites specialize in listing operating systems that run successfully as Virtual PC guests, to help users avoid
issues when installing Linux distributions or other operating systems lacking official Microsoft support.
Intel-based Mac support
Microsoft announced on August 7, 2006, that Virtual PC for Mac would not be ported to the Intel Mac platform.
Microsoft stated, "Alternative solutions offered by Apple and other vendors, combined with a fully packaged retail
copy of Windows, will satisfy this need."
Similar products available at the time were Parallels Desktop and
VMware Fusion.
Previous versions
Virtual PC by Connectix
Virtual PC was originally developed for the Macintosh and released by Connectix in June 1997. The first version of
Virtual PC designed for Windows-based systems, version 4.0, was released in June 2001. Connectix sold versions of
Virtual PC bundled with a variety of guest operating systems, including Windows, OS/2, and Red Hat Linux. As
virtualization's importance to enterprise users became clear, Microsoft took interest in the sector and acquired Virtual
PC and Virtual Server (unreleased at the time) from Connectix in February 2003.
Earlier versions of Virtual PC supported the following features: (now removed in Microsoft Virtual PC 2004, 2007,
and Windows Virtual PC):
• Older versions of Virtual PC (v5.0 or earlier) may have the hard disk formatted after creating the Virtual Hard
Disk file. Newer versions must partition and format the Virtual Hard Disk file manually.
• A Virtual Switch available in Virtual PC version 4.1 or earlier allows adding multiple network adapters.
• Older operating systems are supported with Virtual Machine additions.
• Older versions of Virtual PC for Macintosh can run on Mac OS 9.2.2 or earlier. Support of Apple System 7.5 are
dropped in version 3.
Guest extensions
Under agreement with Connectix, Innotek GmbH (makers of VirtualBox, now part of Sun Microsystems which is
itself owned by Oracle) ported version 5.0 to run on an OS/2 host.
This version also included guest extensions
(VM additions) for OS/2 guests, which could run on Windows, OS/2 or Mac OS X hosts using Virtual PC versions
5, 6 or 7. A new version of the guest extensions was later included with Microsoft's Virtual PC 2004.
Microsoft Virtual PC 2004 and 2007
On July 12, 2006, Microsoft released Virtual PC 2004 SP1 for Windows as a free product, but the Mac version was
not made free. The equivalent version for Mac, version 7, was the final version of Virtual PC for Mac.
Virtual PC 2007 was released only for the Windows platform, with public beta testing beginning October 11, 2006,
and production release on February 19, 2007. It added support for hardware virtualization, viewing virtual machines
on multiple monitors and support for Windows Vista as both host and guest. (The Windows Aero interface is
disabled on Windows Vista guests due to limitations of the emulated video hardware; however, Aero effects can be
rendered by connecting to the guest via Remote Desktop Connection from an Aero-enabled Vista host.)
Windows Virtual PC
On May 15, 2008, Microsoft released Virtual PC 2007 Service Pack 1, which added support for both Windows XP
SP3 and Vista SP1 as guest and host OSes, as well as Windows Server 2008 Standard as a guest OS.

A hotfix
rollup for Virtual PC 2007 SP1, released February 20, 2009, solved networking issues and enhanced the maximum
screen resolution to 2048×1920 (32-bit),
enabling 16:9 resolutions such as 1920×1080. A security update was
released on 14 July 2009 to address an elevation of privilege vulnerability in guest operating systems.
Virtual PC 2007 Versions
Date Version Description
? 6.0.122 Beta
2007-01-02 6.0.142 Release Candidate 1
2007-02-22 6.0.156 Release to Manufacturing
2008-05-15 6.0.192
Service Pack 1
2009-02-20 6.0.210
Security Update MS09-33
[1] "Download details: Windows Virtual PC" (http:/ / www.microsoft.com/ downloads/ details.
aspx?familyid=2B6D5C18-1441-47EA-8309-2545B08E11DD& displaylang=en). Microsoft Download Center. Microsoft corporation.
September 19, 2009. . Retrieved June 5, 2010.
[2] "Windows Virtual PC" (http:// www.microsoft.com/ downloads/ en/ details.aspx?FamilyID=2b6d5c18-1441-47ea-8309-2545b08e11dd).
Microsoft Download Center. Microsoft corporation. March 17, 2010. . Retrieved February 2, 2011.
[3] "Description of Virtual PC for Windows 7" (http:// support. microsoft.com/ ?kbid=958559). Microsoft support. Microsoft Corporation. April
1, 2010. . Retrieved June 5, 2010.
[4] http:// www. microsoft.com/ windows/ virtualpc/
[5] "Virtual PC 7 for Mac" (http:// www. microsoft.com/ australia/ office/mac/ virtualpc7/default. aspx). Microsoft for Mac - Australian
website. Microsoft corporation. . Retrieved June 10, 2010.
[6] "Virtual PC 7 for Mac - Which Edition is Right for Me" (http:// www. microsoft.com/ australia/ office/mac/ virtualpc7/ editions.aspx).
Microsoft for Mac - Australian website. Microsoft corporation. . Retrieved June 10, 2010.
[7] http:// www. microsoft.com/ mac/ products/ virtualpc/ virtualpc.aspx?pid=virtualpc
[8] http:// www. microsoft.com/ australia/ office/mac/ virtualpc7/ default.aspx
[9] "Virtual PC is free!" (http:// blogs. msdn. com/ virtual_pc_guy/archive/ 2006/ 07/ 12/ 662535. aspx). July 12, 2006. . Retrieved 14 October
[10] Thefreecountry: Free PC/Intel x86 Emulators and Virtual Machines (http:/ / www. thefreecountry.com/ emulators/ pc. shtml)
[11] Hachman, Mark (30 April 2009). "Microsoft Posts Windows Virtual PC Beta" (http:/ / www.pcmag.com/ article2/0,2817,2346296,00.
asp). PC Magazine. Ziff-Davis. . Retrieved June 28, 2009.
[12] "Windows Virtual PC" (http:/ / www. microsoft.com/ windows/ virtual-pc/default. aspx). Microsoft.com. .
[13] "Compare some of the many features of Virtual PC 2007 to Windows Virtual PC" (http:/ / www. microsoft.com/ windows/ virtual-pc/
features/compare.aspx). Microsoft corporation. .
[14] Selling Windows 7 to the Enterprise: Microsoft Switzerland Technology Specialist presentation (http:// www.acommit. ch/ Portals/ 0/
Windows 7 RC Partnerevent Mischa Faden.pdf)
[15] Are Windows Virtual PC "Options" Still available ? (http:// social. technet. microsoft.com/ Forums/ en-US/w7itprovirt/thread/
[16] "Windows Virtual PC" (http:// blogs. technet. com/ windows_vpc/ archive/2009/ 08/ 04/ windows-virtual-pc.aspx#3273920). Windows
Virtual PC blog. Microsoft corporation. August 4, 2009. . Retrieved 9 June 2010. "@EnricoG: Drag and Drop is not a supported feature in
WVPC. Clipboard sharing (for cut, copy and paste) and drive/folder sharing are supported."
[17] "Folder Sharing between Windows 7 and VM" (http:/ / blogs. technet. com/ b/ windows_vpc/ archive/ 2009/ 12/ 22/
folder-sharing-between-windows-7-and-vm. aspx). Windows Virtual PC blog. Microsoft corporation. December 21, 2009. . Retrieved August
20, 2010.
[18] Armstrong, Ben (September 18, 2009). "Windows Virtual PC and Undo Disks" (http:// blogs. msdn. com/ virtual_pc_guy/ archive/2009/
08/ 18/ windows-virtual-pc-and-undo-disks.aspx). Virtual PC Guy's Blog. Microsoft corporation. . Retrieved June 9, 2010.
Windows Virtual PC
[19] Armstrong, Ben (June 26, 2009). "Creating Virtual Hard Disks with Windows Virtual PC" (http:/ / blogs. msdn. com/ virtual_pc_guy/
archive/2009/ 06/26/ creating-virtual-hard-disks-with-windows-virtual-pc.aspx#9831105). Virtual PC Guy's Blog. Microsoft corporation. .
Retrieved June 9, 2010. "Windows Virtual PC does not support parallel ports. As Tom mentions, you will have to use a USB adapter if you
want this functionality."
[20] Armstrong, Ben (October 1, 2009). "Using Floppy Disks with Windows Virtual PC" (http:// blogs.msdn. com/ virtual_pc_guy/archive/
2009/ 10/ 01/ using-floppy-disks-with-windows-virtual-pc.aspx). Virtual PC Guy's Blog. Microsoft corporation. . Retrieved June 9, 2010.
[21] Installing DOS additions under VPC 2007 (http:/ / blogs. msdn. com/ b/ virtual_pc_guy/archive/ 2007/ 10/ 30/
installing-dos-additions-under-vpc-2007. aspx)
[22] Installing Windows 98 on Windows Virtual PC (http:// blogs.msdn. com/ b/ virtual_pc_guy/archive/ 2010/ 05/ 27/
installing-windows-98-on-windows-virtual-pc. aspx)
[23] Using Virtual PC 2004 Additions to Enhance the Windows 2000 Guest Experience on Windows Virtual PC (http:// blogs.msdn. com/ b/
cjacks/archive/2010/ 07/ 19/ using-virtual-pc-2004-additions-to-enhance-the-windows-2000-guest-experience-on-windows-virtual-pc.aspx)
[24] http:// www. microsoft.com/ windows/ virtual-pc/support/ requirements.aspx
[25] "Windows XP Mode for Windows 7 brochure" (http:// download. microsoft.com/ download/ 7/ 5/ A/
75A2C993-BFCC-47D0-8B6C-7C8CE2BA9833/ Windows XP Mode for Windows 7_brochure.pdf). Microsoft corporation. 2009. .
Retrieved June 28, 2009.
[26] "Windows XP Mode in Windows 7 and Virtual PC - Part 1: Maintaining Application Compatibility" (http:/ / capitalhead.com/ articles/
windows-xp-mode-in-windows-7-and-virtual-pc---part-1-maintaining-application-compatibility.aspx). Windows XP Mode in Windows 7 and
Virtual PC - Part 1: Maintaining Application Compatibility. . Retrieved 2009-06-16.
[27] "Windows Virtual PC: FAQ" (http:// www. microsoft.com/ windows/ virtual-pc/support/ faq. aspx). Windows Virtual PC website.
Microsoft Corporation. . Retrieved 22 November 2010.
[28] Secret No More: Revealing Windows XP Mode for Windows 7 - SuperSite Blog (http:// community. winsupersite. com/ blogs/ paul/
archive/ 2009/ 04/24/ secret-no-more-revealing-virtual-windows-xp-for-windows-7.aspx)
[29] "Download Windows Virtual PC and Windows XP Mode" (http:// www.microsoft.com/ windows/ virtual-pc/download.aspx). .
[30] Rafael Rivera. "Windows XP Mode Internals – Part 2 (Application Publishing Magic)" (http:// www. withinwindows. com/ 2009/ 04/ 28/
windows-xp-mode-internals-part-2-application-publishing-magic/ ). WithinWindows.com. . Retrieved 2009-04-30.
[31] "Download Windows XP Mode" (http:// www. microsoft. com/ windows/ virtual-pc/download.aspx). Windows Virtual PC website.
Microsoft Corporation. . Retrieved 22 November 2010. "(After selecting an inappropriate edition of Windows 7) You are not eligible to
download Windows XP Mode. You must have Windows 7 Professional, Enterprise, or Ultimate to run Windows XP Mode."
[32] Run XP Mode in VMware Workstation or Player with Activation Intact (http:// www.mydigitallife.info/ 2010/ 05/ 13/
run-xp-mode-in-vmware-workstation-or-player-with-activation-intact/ comment-page-1/#comment-855307)
[33] "Overview of the technical specifications of virtual machines in Virtual PC 2004" (http:// support. microsoft.com/ kb/ 833144).
Microsoft.com. 2004-10-27. . Retrieved 2010-05-23.
[34] Tulloch, Mitch (2010). Understanding Microsoft Virtualization Solutions, From the Desktop to the Datacenter (http:// download. microsoft.
com/ download/ 5/ B/ 4/ 5B46A838-67BB-4F7C-92CB-EABCA285DFDD/ 693821ebook. pdf) (2nd ed.). Redmond, WA: Microsoft Press.
pp. 133–136. .
[35] "USB Architecture in Windows Virtual PC" (http:/ / blogs. technet.com/ b/ windows_vpc/ archive/ 2009/ 12/ 14/
usb-architecture-in-windows-virtual-pc. aspx). Windows Virtual PC blog. Microsoft corporation. December 13, 2009. . Retrieved August 20,
[36] Bergstein, Brian (2007-02-28). "Microsoft puts up roadblocks on Vista for Mac owners" (http:// www. nytimes. com/ 2007/ 02/ 28/
technology/ 28iht-ptvista. 4752719. html). The New York Times. Associated Press (New York: The New York Times Company). . Retrieved
2009-07-10. "Microsoft says the blockade is necessary for security reasons … Cherry says that what is really going on is that Microsoft
wanted to create more differences between the multiple editions of Vista, presumably giving people more reason to buy the most expensive
[37] "Microsoft Software License Terms" (http:/ / download.microsoft.com/ documents/ useterms/ Windows
Vista_Ultimate_English_36d0fe99-75e4-4875-8153-889cf5105718. pdf). Microsoft Use Terms (http:/ / www.microsoft.com/ about/ legal/
useterms/ ). Microsoft. p. 13. . Retrieved 2009-07-10. "If you [install the software within a virtual system], you may not play or access content
or use applications protected by any Microsoft digital, information or enterprise rights management technology or other Microsoft rights
management services or use BitLocker." (The later Vista SP1 EULA (http:// download. microsoft.com/ documents/ useterms/ Windows Vista
SP1_Ultimate_English_c64c444e-952d-497f-9f69-5811ffdcd774. pdf) adopted the amended terms of the January 2008 Supplement.)
[38] Armstrong, Ben (2007-01-03). "Why won't the Virtual PC 2007 Virtual Machine Additions load on Windows 95?" (http:// blogs. msdn.
com/ virtual_pc_guy/archive/ 2007/ 01/ 03/ why-won-t-the-virtual-pc-2007-virtual-machine-additions-load-on-windows-95.aspx). Virtual PC
Guy's Weblog (http:/ / blogs. msdn. com/ virtual_pc_guy/). MSDN Blogs. . Retrieved 2009-07-10.
[39] Armstrong, Ben (2007-10-30). "Installing DOS additions under VPC 2007" (http:// blogs. msdn.com/ virtual_pc_guy/ archive/2007/ 10/
30/ installing-dos-additions-under-vpc-2007.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/). MSDN Blogs. .
Retrieved 2009-07-10.
[40] "Microsoft Virtualization Technologies" (http:/ / technet. microsoft.com/ en-us/ library/bb897466. aspx). Infrastructure Planning and
Design. Microsoft TechNet. 2008-02-25 [First published 2007-11-12]. . Retrieved 2009-07-10.
Windows Virtual PC
[41] Davis, Megan (2005-05-24). Blade, Tina. ed. "Virtual PC vs. Virtual Server: Comparison of Features and Uses" (http:// download.
microsoft.com/ download/ 1/ 4/ d/ 14d17804-1659-435d-bc11-657a6da308c0/VSvsVPC. doc) (Microsoft Word). Microsoft Download
Center (Microsoft.com). . Retrieved 2009-07-10. See also download details (http:/ / www. microsoft.com/ downloads/ details.
[42] "Virtual Server 2005 Frequently Asked Questions" (http:// www.microsoft.com/ windowsserversystem/ virtualserver/evaluation/
virtualizationfaq. mspx). Microsoft Virtual Server. Microsoft.com. 2008-05-14 [First published 2003-02-20]. . Retrieved 2009-07-10.
[43] "Virtualization with Hyper-V: Supported Guest Operating Systems" (http:// www.microsoft.com/ windowsserver2008/ en/ us/
hyperv-supported-guest-os. aspx). Windows Server 2008 – Product Information. Microsoft.com. . Retrieved 2009-07-10.
[44] "Virtual PC 2007 SP1 Release Notes" (http:// download.microsoft.com/ download/8/ f/ 4/ 8f44a346-1f62-4bb2-b957-7508ea1f7d80/
relnotes.htm). Microsoft Download Center. Microsoft.com. 2008-05-15. . Retrieved 2009-07-10. See also download details (http:/ / www.
microsoft. com/ downloads/ details. aspx?displaylang=en& FamilyID=9f3d3eb5-5e03-4712-999c-e96f91bdf128).
[45] "Windows Virtual PC Tips" (http:// www.microsoft.com/ downloads/ info.aspx?na=90& p=& SrcDisplayLang=en&SrcCategoryId=&
SrcFamilyId=ffc6c931-6216-4a1d-bdab-936fef353060&u=http:// download.microsoft.com/ download/ 7/ D/ 6/
7D686A6A-B0F7-42E5-BB3B-4972A8C42C9F/Windows+ Virtual+PC+ Tips.pdf). Microsoft Download Center. Microsoft. 2009-05-18. .
Retrieved 2009-07-10. See also download details (http:// www. microsoft.com/ downloads/ details.aspx?displaylang=en&
FamilyID=ffc6c931-6216-4a1d-bdab-936fef353060). (Contains a more precise and complete list of supported operating systems than the
Requirements page (http:/ / www.microsoft.com/ windows/ virtual-pc/support/ requirements.aspx) on Microsoft.com.)
[46] Armstrong, Ben (2006-04-03). "Linux is now supported under Virtual Server" (http:// blogs. msdn. com/ virtual_pc_guy/archive/2006/ 04/
03/ 566273. aspx). Virtual PC Guy's Weblog (http:/ / blogs. msdn. com/ virtual_pc_guy/ ). MSDN Blogs. . Retrieved 2009-07-10.
[47] Earp, Sean (2008-06-29). "Linux on Hyper-V" (http:// blogs. technet.com/ seanearp/archive/ 2008/ 06/ 29/ linux-on-hyper-v.aspx). The
Sean Blog (http:/ / blogs. technet. com/ seanearp/ default. aspx). Microsoft TechNet. . Retrieved 2009-07-10. (Also links to individual posts on
installing various Linux distributions in Virtual PC 2007.)
[48] Armstrong, Ben (2007-10-23). "Updated Virtual Machine Additions for Linux available" (http:/ / blogs. msdn. com/ virtual_pc_guy/
archive/2007/ 10/23/ updated-virtual-machine-additions-for-linux-available.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/
virtual_pc_guy/default. aspx). MSDN Blogs. . Retrieved 2009-06-28. "As always – this is only supported on Virtual Server – but should
work just fine on Virtual PC."
[49] "Virtual Machine Additions for Linux" (http:// www.microsoft.com/ downloads/ details.
aspx?FamilyID=bf12642f-77dc-4d45-ae4e-e1b05e0a2674&DisplayLang=en). Microsoft Download Center. Microsoft.com. 2007-10-24. .
Retrieved 2009-07-10.
[50] Cummings, Joanne (2006-11-01). "Microsoft Virtual PC: Good Enough – for the Price" (http:// redmondmag.com/ Articles/ 2006/ 11/01/
Microsoft-Virtual-PC-Good-Enough--for-the-Price. aspx?Page=1). Redmondmag.com (http:// redmondmag.com/ ). 1105 Media. . Retrieved
[51] Woolsey, Jeff (2007-07-10). "Microsoft Virtualization and Virtual PC 2007" (http:// blogs. technet. com/ virtualization/archive/ 2007/ 07/
10/ microsoft-virtualization-and-virtual-pc-2007.aspx). Microsoft Virtualization Team Blog (http:/ / blogs. technet.com/ virtualization/).
Microsoft TechNet. . Retrieved 2009-07-10.
[52] Savill, John (2009-05-07). "Does Windows Virtual PC in Windows 7 support 64-bit guest OSs?" (http:/ / windowsitpro. com/ article/
articleid/102040/q-does-windows-virtual-pc-in-windows-7-support-64-bit-guest-oss.html). Windows IT Pro. Penton Media. . Retrieved
[53] "Virtualization with Hyper-V: FAQ" (http:/ / www.microsoft.com/ windowsserver2008/ en/ us/ hyperv-faq.aspx). Windows Server 2008 –
Product Information. Microsoft.com. . Retrieved 2009-07-10.
[54] "Microsoft Virtual PC 2004 – Product Details" (http:// www. microsoft.com/ PRODUCTS/ info/product. aspx?view=22&
pcid=ba9e68ed-9571-4d10-82d2-b51828c33297&type=ovr#ProductDetails). Product Information Center. Microsoft.com. . Retrieved
[55] "Readme for Microsoft Virtual PC 2004 Service Pack 1" (http:// download. microsoft.com/ download/ 6/ 9/ d/
69de9b67-6498-41fb-9add-95ceab6eb5cc/readmesp1. htm). Microsoft Download Center. Microsoft.com. 2004-10-12. . Retrieved
2009-07-10. See also download details (http:// www.microsoft. com/ downloads/ details. aspx?displaylang=en&
[56] " Demo: Microsoft Virtual PC 2004 Features (http:/ / technet. microsoft.com/ en-us/ bb643127. aspx)". Event Review: Microsoft Virtual PC
Overview – Session TNT1-103. Microsoft TechNet. Retrieved on 2009-07-10.
[57] "Download Details: Virtual PC 2004 SP1" (http:/ / www.microsoft.com/ downloads/ details.aspx?displaylang=en&
FamilyID=6d58729d-dfa8-40bf-afaf-20bcb7f01cd1). Microsoft Download Center. Microsoft.com. 2006-08-30. . Retrieved 2009-07-10.
[58] "Virtual PC 2007 Release Notes" (http:/ / download. microsoft.com/ download/ 4/ 4/ c/ 44ccd131-67fb-4224-a96e-193be1765b43/relnotes.
htm). Microsoft Download Center. Microsoft.com. 2007-02-19. . Retrieved 2009-07-10. See also download details (http:// www. microsoft.
com/ downloads/ details. aspx?displaylang=en& FamilyID=10c298be-d794-4313-801f-04e7c1ad5da0).
[59] "Description of the hotfix rollup package for Virtual PC 2007 Service Pack 1: February 20, 2009" (http:// support. microsoft. com/ kb/
958162). Microsoft Help and Support. Microsoft.com. 2009-02-20. . Retrieved 2009-07-10.
[60] "Windows Virtual PC – Requirements" (http:// www.microsoft. com/ windows/ virtual-pc/ support/ requirements.aspx). Microsoft.com. .
Retrieved 2009-07-10.
Windows Virtual PC
[61] "Windows Virtual PC – FAQ" (http:/ / www.microsoft.com/ windows/ virtual-pc/support/ faq.aspx). Microsoft.com. . Retrieved
[62] "Windows Virtual PC Beta" (http:// www.microsoft. com/ downloads/ details.
aspx?familyid=65E1C5EB-DF9B-415F-B2D6-27F6EF5DCEB9& displaylang=en). Microsoft Download Center. Microsoft.com. 2009-05-04.
. Retrieved 2009-07-10.
[63] Armstrong, Ben (2004-10-26). "Windows 3.11 on Virtual PC" (http:// blogs.msdn. com/ virtual_pc_guy/ archive/2004/ 10/ 26/ 247793.
aspx). Virtual PC Guy's WebLog (http:// blogs. msdn. com/ virtual_pc_guy/ ). MSDN Blogs. . Retrieved 2009-07-10. (Microsoft manager Ben
Armstrong reports that Windows 3.11 installs without a problem in Virtual PC 2004.)
[64] Armstrong, Ben (2005-01-26). "Why we emulated the devices that we do?" (http:/ / blogs. msdn. com/ virtual_pc_guy/archive/ 2005/01/
26/ 361361. aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/ ). MSDN Blogs. . Retrieved 2009-07-10.
[65] Schweigert, Marc (2007-03-14). "Get the Windows Vista Aero theme in a Guest OS using Virtual PC 2007" (http:// blogs. msdn.com/
publicsector/ archive/2007/ 03/ 14/ get-the-windows-vista-aero-theme-in-a-guest-os-using-virtual-pc-2007.aspx). Microsoft Public Sector
Developer and Platform Evangelism Team Blog (http:// blogs. msdn. com/ publicsector/ default.aspx). MSDN Blogs. . Retrieved 2009-07-10.
[66] Savill, John (June 2007). "Running the Aero UI When Using Virtual PC 2007" (http:/ / windowsitpro. com/ article/ articleid/95814/
running-the-aero-ui-when-using-virtual-pc-2007.html) (Fee required). Windows IT Pro (Penton Media). . Retrieved 2009-07-10.
[67] "Microsoft Software Supplemental License Terms" (http:// download.microsoft.com/ documents/ useterms/ Windows Vista_Ultimate and
Ultimate SP1, Supplemental_English_d512375b-79d7-41e5-852d-45f69f7378dd. pdf). Microsoft Use Terms (http:/ / www. microsoft.com/
about/legal/ useterms/ ). Microsoft. January 2008. . Retrieved 2009-07-10.
[68] Armstrong, Ben (2008-01-22). "Virtualization Announcements" (http:/ / blogs. msdn. com/ virtual_pc_guy/archive/ 2008/ 01/ 22/
virtualization-announcements.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/). MSDN Blogs. . Retrieved
[69] Oiaga, Marius (2008-01-22). "The Windows Vista Virtualization Doors Are Wide Opened" (http:/ / news. softpedia.com/ news/
The-Windows-Vista-Virtualization-Doors-Are-Opened-Wide-76958.shtml). Softpedia News (http:/ / news. softpedia.com/ ). Softpedia. .
Retrieved 2009-07-10.
[70] Microsoft Partner Program (https:// partner.microsoft. com/ licensinghandbook) (March 2008). Licensing Reseller Handbook for Microsoft
Partners (http:// download. microsoft.com/ download/ 2/ 4/ f/ 24f49403-31b4-4cf3-a4f5-6c439f92be24/MS_ReselleRev0308_LoRes. pdf).
Microsoft. p. 58. . Retrieved 2009-07-10. "Windows Vista Home Basic and Windows Vista Home Premium cannot be used within a virtual (or
otherwise emulated) hardware system."
[71] Albro, Edward N.; Eric Dahl (2007-02-20). "The Most Annoying Things About Windows Vista" (http:/ / www. pcworld.com/ article/
129126-3/the_most_annoying_things_about_windows_vista. html). PC World. International Data Group. . Retrieved 2009-07-10. "Well, this
is only a licensing provision, so nothing in the software will prevent you from running either Home version in a virtual machine. But that
would be wrong."
[72] Lai, Eric (2007-06-22). "Analysis: DRM may be why Microsoft flip-flopped on Vista virtualization" (http:/ / www.computerworld.com/
action/ article.do?command=viewArticleBasic& articleId=9025466). Computerworld. International Data Group. . Retrieved 2009-07-10.
(Microsoft originally planned to rescind the restrictions in June 2007.)
[73] Armstrong, Ben (2008-01-23). "Using BitLocker under Virtual PC / Virtual Server" (http:/ / blogs. msdn. com/ virtual_pc_guy/archive/
2008/01/ 23/ using-bitlocker-under-virtual-pc-virtual-server.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/ ).
MSDN Blogs. . Retrieved 2009-07-10. (Instructions were reposted the day after Microsoft released its Vista EULA Supplement in January
[74] Armstrong, Ben (2007-04-30). "Using Vista BitLocker under Virtual PC / Virtual Server" (http:// blogs. msdn. com/ virtual_pc_guy/
archive/2007/ 04/30/ using-vista-bitlocker-under-virtual-pc-virtual-server.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/
virtual_pc_guy/). MSDN Blogs. . Retrieved 2009-07-10. (Instructions provided in the post were deleted to comply with Microsoft's original
Vista EULA).
[75] Malach, Eyal (2008-02-19). "Encrypting Vista with BitLocker in Virtual PC or Virtual Machine" (http:// blogs. microsoft.co.il/ blogs/
eyalm/archive/ 2008/02/ 19/ encrypting-vista-with-bitlocker-in-virtual-pc-or-virtual-machine.aspx). Eyal Malach Blog (http:// blogs.
microsoft. co. il/blogs/ eyalm/ ). Microsoft Blogs – Israel (http:// blogs. microsoft.co.il/ ). . Retrieved 2009-07-10.
[76] Oiaga, Marius (2007-06-02). "Install Windows Vista Ultimate in Windows Vista – Vista Virtualization Guidelines" (http:/ / news. softpedia.
com/ news/ Install-Windows-Vista-Ultimate-IN-Windows-Vista-56273.shtml). Softpedia News (http:/ / news.softpedia.com/ ). Softpedia. .
Retrieved 2009-07-10.
[77] "RAIL QFE Beta Windows XP SP3" (http:/ / www.microsoft. com/ downloads/ details.
aspx?familyid=943B6AC7-87F2-45DF-A516-21321D559AC3& displaylang=en). Microsoft Download Center. Microsoft.com. 2009-05-04. .
Retrieved 2009-07-10.
[78] "Windows Virtual PC Evaluation Guide" (http:// technet. microsoft.com/ en-us/ library/dd744684(WS. 10).aspx). Windows 7 Technical
Library (http:// technet. microsoft.com/ en-us/ library/dd349342(WS.10). aspx). Microsoft TechNet. 2009-05-04. . Retrieved 2009-07-10.
Also available for download (http:// www.microsoft.com/ Downloads/ details.
[79] "RAIL QFE Beta for Vista SP1" (http:// www.microsoft.com/ downloads/ details.
aspx?familyid=DB29EB2B-F095-4172-8E83-9C5623045D4E&displaylang=en). Microsoft Download Center. Microsoft.com. 2009-05-04. .
Retrieved 2009-07-10.
Windows Virtual PC
[80] Armstrong, Ben (2004-11-06). "Windows Media Center 2005 under Virtual PC" (http:// blogs. msdn. com/ virtual_pc_guy/archive/2004/
11/ 06/ 253225. aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/ ). MSDN Blogs. . Retrieved 2009-07-10.
[81] "Windows 7 Release Candidate: FAQ" (http:// www.microsoft.com/ windows/ windows-7/ faq.aspx). Microsoft.com. 2009. . Retrieved
[82] Armstrong, Ben (2009-01-13). "Windows 7 on Virtual PC on Windows 7" (http:// blogs. msdn.com/ virtual_pc_guy/ archive/2009/ 01/ 13/
windows-7-on-virtual-pc-on-windows-7.aspx). Virtual PC Guy's WebLog (http:/ / blogs. msdn. com/ virtual_pc_guy/). MSDN Blogs. .
Retrieved 2009-07-10.
[83] Krishnamoorthy, Ajoy (2009-01-19). "Installing Virtual PC 2007 SP1 in Windows 7" (http:/ / blogs.msdn. com/ ajoyk/ archive/2009/ 01/
19/ installing-virtual-pc-2007-sp1-in-windows-7.aspx). Ajoyk – Patterns and Practices, VSTS, Process (http:/ / blogs.msdn. com/ ajoyk/
default. aspx). MSDN Blogs. . Retrieved 2009-07-10.
[84] Manning, James (2009-01-10). "Upgrading to SP1 fixes VM Additions for Win7 Beta!" (http:// blogs. msdn.com/ jmanning/ archive/ 2009/
01/ 10/ upgrading-to-sp1-fixes-vm-additions-for-win7-beta.aspx). James Manning's Blog (http:/ / blogs. msdn. com/ jmanning/ default.aspx).
MSDN Blogs. . Retrieved 2009-07-10.
[85] http:// blogs. msdn. com/ virtual_pc_guy/archive/ 2009/ 01/ 13/ windows-7-on-virtual-pc-on-windows-7.aspx
[86] What Works and What Doesn't in Microsoft Virtual PC 2004 (http:/ / vpc. visualwin. com/ )
[87] Cohen, Peter (2006-08-07). "WWDC: Microsoft kills Virtual PC for Mac" (http:// www.macworld. com/ news/ 2006/ 08/ 07/ vpc/ index.
php). MacWorld. . Retrieved 2007-10-08.
[88] Innotek/Connectix Virtual PC (http:// www. bityard. com/ article.php?sid=100)
[89] Microsoft releases Virtual PC 2007 SP1 (http:// arstechnica. com/ journals/ microsoft.ars/ 2008/ 05/ 15/
[90] "Virtual PC 2007 SP1 Release Notes" (http:// www.microsoft.com/ downloads/ details.
aspx?FamilyID=9f3d3eb5-5e03-4712-999c-e96f91bdf128& displaylang=en). Microsoft. 2008-05-15. . Retrieved 2009-06-28.
[91] KB958162 (http:// support. microsoft.com/ kb/ 958162)
[92] MS09-033 (http:// www.microsoft. com/ technet/ security/ bulletin/ MS09-033.mspx)
[93] "Download details: Microsoft Virtual PC 2007 SP1" (http:// www.microsoft.com/ downloads/ en/ details.
aspx?familyid=28C97D22-6EB8-4A09-A7F7-F6C7A1F000B5& displaylang=en). Microsoft Download Center. Microsoft Corporation. May
5, 2005. . Retrieved April 1, 2011.
[94] "Description of the hotfix rollup package for Virtual PC 2007 Service Pack 1: February 20, 2009 (Revision: 1.2)" (http:// support. microsoft.
com/ kb/ 958162). Microsoft Support. Microsoft Corporation. February 20, 2009. . Retrieved April 1, 2011.
[95] "Vulnerability in Virtual PC and Virtual Server Could Allow Elevation of Privilege (969856)" (http:// www.microsoft.com/ technet/
security/bulletin/ MS09-033. mspx). Microsoft TechNet. Microsoft Corporation. July 14, 2009. . Retrieved April 1, 2011.
External links
• Windows Virtual PC for Windows (http:// www.microsoft. com/ windows/ virtual-pc/)
• Download Windows Virtual PC (http:/ / www.microsoft.com/ downloads/ details.
• Download Windows XP Mode (http:/ / www. microsoft.com/ downloads/ details. aspx?displaylang=en&
• Download Microsoft Virtual PC 2007 SP1 for Windows (http://www. microsoft.com/ downloads/ details.
• Download Microsoft Virtual PC 2004 SP1 for Windows (http:/ /www. microsoft.com/ downloads/ details.
aspx?FamilyId=6D58729D-DFA8-40BF-AFAF-20BCB7F01CD1& displaylang=en)
• Hardware Assisted Virtualization Detection Tool (http:// go. microsoft.com/ fwlink/?LinkId=163321)
• Virtual PC Blog on Microsoft MSDN (http:/ / blogs. msdn. com/ virtual_pc_guy/)
Virtual network
Virtual network
A virtual network is a computer network that consists, at least in part, of virtual network links. A virtual network
link is a link that does not consist of a physical (wired or wireless) connection between two computing devices but is
implemented using methods of network virtualization.
The two most common forms of virtual networks are protocol-based virtual networks (such as VLANs, VPNs, and
VPLSs) and virtual networks that are based on virtual devices (such as the networks connecting virtual machines
inside a hypervisor). In practice, both forms can be used in conjunction.
VLANs (Virtual LANs) are logical LAN's (Local Area Networks), based on physical LAN's. A VLAN can be
created by partitioning a physical LAN into multiple logical LAN's (subnets) using a VLAN ID. Alternatively,
several physical LAN's can function as a single logical LAN. The partitioned network can be on a single router, or
multiple VLAN's can be on multiple routers just as multiple physical LAN's would be. A VLAN can be on a VPN.
A VPN (Virtual Private Network) consists of multiple remote end-points (typically routers, VPN gateways of
software clients) joined by some sort of tunnel over another network, usually a third party network. Two such end
points constitute a 'Point to Point Virtual Private Network' (or a PTP VPN). Connecting more than two end points by
putting in place a mesh of tunnels creates a 'Multipoint VPN'.
A VPLS (Virtual Private LAN Service) is a specific type of Multipoint VPN. VPLS are divided into Transparent
LAN Services (TLS) and Ethernet Virtual Connection Services. A TLS sends what it receives, so it provides
geographic separation, but not VLAN subnetting. An EVCS adds a VLAN ID, so it provides geographic separation
and VLAN subnetting.
A common example of a virtual network that is based on virtual devices is the network inside a VMware ESX virtual
host that is implemented using virtual switches (vSwitches). Such networks can use non-virtual protocols such as
Ethernet as well as virtualization protocols such as the VLAN protocol IEEE 802.1Q.
• RAD VPLS Tutorial
• Types of VPNs
• VMware Virtual Networking Concepts
retrieved 26 October 2008
[1] http:/ / www2. rad.com/ networks/ 2006/ vpls/ main. htm
[2] http:// www. juniper.net/ techpubs/ software/junos/ junos83/ swconfig83-vpns/ id-10066935.html#id-10066935
[3] http:/ / www. vmware.com/ files/ pdf/ virtual_networking_concepts.pdf
EtherChannel between a switch and a server.
EtherChannel is a port link
aggregation technology or port-channel
architecture used primarily on Cisco
switches. It allows grouping several
physical Ethernet links to create one
logical Ethernet link for the purpose of
providing fault-tolerance and
high-speed links between switches,
routers and servers. An EtherChannel
can be created from between two and eight active Fast, Gigabit or 10-Gigabit Ethernet ports, with an additional one
to eight inactive (failover) ports which become active as the other active ports fail. EtherChannel is primarily used in
the backbone network, but can also be used to connect end user machines.
EtherChannel technology was invented by Kalpana in the early 1990s. They were later acquired by Cisco Systems in
1994. In 2000 the IEEE passed 802.3ad which is an open standard version of EtherChannel.
Using an EtherChannel has numerous advantages, and probably the most desirable aspect is the bandwidth. Using
the maximum of 8 active ports a total bandwidth of 800 Mbit/s, 8 Gbit/s or 80 Gbit/s is possible depending on port
speed. This assumes there is a traffic mixture, as those speeds do not apply to a single application only. It can be
used with Ethernet running on twisted pair wiring, single-mode and multimode fiber.
Because EtherChannel takes advantage of existing wiring it makes it very scalable. It can be used at all levels of the
network to create higher bandwidth links as the traffic needs of the network increase. All Cisco switches have the
ability to support EtherChannel.
When an EtherChannel is configured all adapters that are part of the channel share the same Layer 2 (MAC) address.
This makes the EtherChannel transparent to network applications and users because they only see the one logical
connection; they have no knowledge of the individual links.
EtherChannel aggregates the traffic across all the available active ports in the channel. The port is selected using a
Cisco-proprietary hash algorithm, based on source or destination MAC addresses, IP addresses or TCP and UDP port
numbers. The hash function gives a number between 0 and 7, and the following table shows how the 8 numbers are
distributed among the 2 to 8 physical ports. In the hypothesis of real random hash algorithm, 2, 4 or 8 ports
configurations lead to fair load-balancing, whereas other configurations lead to unfair load-balancing.
Number of Ports Load Balancing
8 1:1:1:1:1:1:1:1
7 2:1:1:1:1:1:1
6 2:2:1:1:1:1
5 2:2:2:1:1
4 2:2:2:2
3 3:3:2
2 4:4
Fault-tolerance is another key aspect of EtherChannel. Should a link fail, the EtherChannel technology will
automatically redistribute traffic across the remaining links. This automatic recovery takes less than one second and
is transparent to network applications and the end user. This makes it very resilient and desirable for mission-critical
Spanning tree protocol can be used with an EtherChannel. STP treats all the links as a single one and BPDUs are
only sent down one of the links. Without the use of an EtherChannel, STP would effectively shutdown any
redundant links between switches until one connection goes down. This is where an EtherChannel is most desirable,
it allows full use of all available links between two devices.
EtherChannels can be also configured as VLAN trunks. If any single link of an EtherChannel is configured as a
VLAN trunk, the entire EtherChannel will act as a VLAN trunk. Cisco ISL, VTP and IEEE 802.1Q are compatible
with EtherChannel.
A limitation of EtherChannel is that all the physical ports in the aggregation group must reside on the same switch.
Avaya's SMLT protocol removes this limitation by allowing the physical ports to be split between two switches in a
triangle configuration. Cisco's Virtual Switching System allows the creation of a Multichassis Etherchannel (MEC)
similar to the DMLT protocol allowing ports to be aggregated towards different physical chassis that conform a
single "virtual switch" entity.
EtherChannel is made up of the following key elements:
Intel PRO/1000 MT Server Adapter that supports
• Ethernet links — EtherChannel works over links defined by the
IEEE 802.3 standard, including all sub-standards. All links in a
single EtherChannel must be the same speed.
• Compatible hardware — The entire line of Cisco Catalyst
switches as well as Cisco IOS software-based routers support
EtherChannel. Configuring an EtherChannel between a switch
and a computer would either require special network interface
cards (NICs) such as the model pictured here, or support built
into the operating system. FreeBSD, for example, supports
EtherChannel via LACP on standard NICs. Multiple
EtherChannels per device are supported; the number depends
on the type of equipment. Catalyst 6500 and 6000 switches support a maximum of 64 EtherChannels.
• Configuration — An EtherChannel must be configured using the Cisco IOS on switches and router, and using
specific drivers when connecting a server. There are two main ways an EtherChannel can be set up. The first is by
manually issuing a command on each port of the device that is part of the EtherChannel. This must be done for
the corresponding ports on both sides of the EtherChannel. The second way is using Cisco Port Aggregation
Protocol (PAgP) for the automated aggregation of Ethernet ports.
EtherChannel vs. 802.3ad
EtherChannel and IEEE 802.3ad standards are very similar and accomplish the same goal. There are a few
differences between the two, other than the fact that EtherChannel is Cisco proprietary and 802.3ad is an open
standard, listed below:
EtherChannel IEEE 802.3ad
Requires switch configuration. Little, if any, configuration of switch required to form aggregation. Some initial setup of the switch may
be required.
Supports different packet distribution
Supports only standard distribution mode.
Both technologies are capable of automatically configuring this logical link. EtherChannel supports both LACP and
Cisco's PAgP, whereas 802.3ad uses LACP.
[1] Understanding EtherChannel Load Balancing and Redundancy on Catalyst switches — Cisco Systems (http:/ / www. cisco. com/ en/ US/
tech/ tk389/ tk213/ technologies_tech_note09186a0080094714. shtml#ioscat4k)
• "Network Connectivity: Advanced Networking Services — Teaming" (http:// www.intel. com/ support/
network/ sb/ CS-009747. htm). Intel. 2007-09-13. Retrieved 2007-02-27.
• "EtherChannel and IEEE 802.3ad Link Aggregation" (http:// publib. boulder.ibm. com/ infocenter/pseries/ v5r3/
index. jsp?topic=/ com. ibm. aix. commadmn/ doc/ commadmndita/ etherchannel_intro.htm). pSeries and AIX
Information Center. IBM. 2006. Retrieved 2007-02-27.
• "Cross-Stack EtherChannel on a Catalyst 3750 Switch Configuration Example" (http:/ / www.cisco. com/ en/ US/
products/hw/ switches/ ps5023/ products_configuration_example09186a00806cb982.shtml).
External links
• Cisco's Introduction to EtherChannel (http:// www.cisco. com/ en/ US/ tech/ tk389/ tk213/
technologies_tech_note09186a0080094714. shtml)
Network virtualization
Network virtualization
In computing, Network Virtualization is the process of combining hardware and software network resources and
network functionality into a single, software-based administrative entity, a virtual network. Network virtualization
involves platform virtualization, often combined with resource virtualization.
Network virtualization is categorized as either external, combining many networks, or parts of networks, into a
virtual unit, or internal, providing network-like functionality to the software containers on a single system. Whether
virtualization is internal or external depends on the implementation provided by vendors that support the technology.
Components of a virtual network
Various equipment and software vendors offer network virtualization by combining any of the following:
• Network hardware, such as switches and network adapters, also known as network interface cards (NICs)
• Network elements such as Firewalls, Load Balancers
• Networks, such as virtual LANs (VLANs) and containers such as virtual machines (VMs) and Solaris Containers
• Network storage devices
• Network M2M elements such as Telecommunications 4G HLR and SLR devices
• Network Mobile elements such as Laptops, Tablets and Cell Phones
• Network media, such as Ethernet and Fibre Channel
Following is a survey of common network virtualization scenarios and examples of vendor implementation of these
External network virtualization
Some vendors offer external network virtualization, in which one or more local networks are combined or
subdivided into virtual networks, with the goal of improving the efficiency of a large corporate network or data
center. The key components of an external virtual network are the VLAN and the network switch. Using VLAN and
switch technology, the system administrator can configure systems physically attached to the same local network
into different virtual networks. Conversely, VLAN technology enables the system administrator to combine systems
on separate local networks into a VLAN spanning the segments of a large corporate network.
Internal network virtualization
Other vendors offer internal network virtualization. Here a single system is configured with containers, such as the
Xen domain, combined with hypervisor control programs or pseudo-interfaces such as the VNIC
, to create a
“network in a box.” This solution improves overall efficiency of a single system by isolating applications to separate
containers and/or pseudo interfaces.
Examples of internal network virtualization
Citrix and Vyatta have built a Virtual Network Stack
combining Vyatta's routing, firewall and IPsec VPN
functionality with Citrix Netscaler load balancer, Branch Repeater WAN optimization and Access Gateway SSL
VPN. The vNetworkStack project is defining entire virtualized network architectures for branch offices, datacenters
and cloud computing environments.
OpenSolaris network virtualization features (see OpenSolaris Network Virtualization and Resource Control) enable
the "network in the box" scenario. The features of the OpenSolaris Crossbow Project
provide the ability for
containers such as zones or virtual machines on a single system to share resources and exchange data. Major
Crossbow features include VNIC pseudo-interfaces and virtual switches, which emulate network connectivity by
Network virtualization
enabling containers to exchange data without having to pass that data onto the external network.
Microsoft Virtual Server uses virtual machines such as those provided by Xen to create a network in the box scenario
for x86 systems. These containers can run different operating systems, such as Windows or Linux, and be associated
with or independent of a system's NIC.
Combined internal and external network virtualization
Some vendors offer both internal and external network virtualization software in their product line. For example,
Machine-To-Machine Intelligence (M2MI) technologu covers both Internal, External and Multi-vendor software and
hardware based technologies. Machine-To-Machine Intelligence is unique in its approach of applying "whitelist"
blocking across all multi-vendor network elements, this approach ensures that Virtual Machines can not be "ARP
spoofed", a technique used to compromise Virtual Machines at the network level. VMware provides products that
offer both internal and external network virtualization only. VMware's basic approach is network in the box on a
single system, using virtual machines that are managed by hypervisor software. VMware then provides its VMware
Infrastructure software to connect and combine networks in multiple boxes into an external virtualization scenario.
Network virtualization initiatives
• Global Environment for Network Innovations
• Future Internet Research and Experimentation
• AKARI Project
• Victor Moreno and Kumar Reddy (2006). Network Virtualization. Indianapolis: Cisco Press.
• NetworkVirtualization.com | News
retrieved 3 June 2008
[1] http:/ / www. opensolaris. org/os/ project/crossbow/ faq/#vnic_what
[2] http:// www. vnetworkstack. com
[3] http:/ / networkvirtualization.com
Cisco Unified Computing System
Cisco Unified Computing System
The Cisco Unified Computing System (UCS) is a data center computing solution composed of computing
hardware, virtualization software, switching fabric, and management software. The idea behind the system is to
reduce total cost of ownership and improve scalability by integrating the different components into a cohesive
platform that can be managed as a single unit. Just-In-Time deployment of resources and 1:N redundancy are also
possible with a system of this type.
The computing component of the UCS is available in two versions; the B-Series (a modular package consisting of a
powered chassis and full or half slot blade servers), and the C-series rackmount servers (that can be used with or
without UCS, or mixed with blade UCS systems). Both form factors utilize the same standard components seen
throughout the industry, including Intel Nehalem processors and DIMM memory. The servers are distinctive for
supporting Converged Network Adapters ( CNAs), Port Virtualization, and in some models the Catalina chipset
(ASICs that expand the number of memory sockets than can be connected to a single memory bus.
Virtualization is provided through a partnership with VMWare and uses a version of that company's ESXi. Unlike
other VMWare software, ESX and ESXi run directly on the system hardware without the need for any other
software, and provide the necessary hypervisor functions to host several guest operating systems (such as Windows
or Linux) on the physical server. Guest operating systems are limited to 255 gigabytes of RAM and 8 processors.
The Cisco 6100 Series switch (called a "Fabric Interconnect") provides network connectivity for the chassis and
blade servers connected to it through 10 Gigabit and Fiber Channel over Ethernet (FCoE). The Fabric Interconnects
are derived from the Nexus 5000 and run NX-OS as well as the UCS Manager software. The FCoE component is
necessary for connection to SAN storage, since the UCS system itself has very little storage capacity. Cisco currently
produces two models: the 20-port Cisco UCS 6120XP and the 40-port Cisco UCS 6140XP.
The Fabric Interconnect can further connect to multiple Fabric Extenders, Port Extenders using VNTag
to the
Fabric Interconnects, allowing a large number of servers to be managed by one Fabric Interconnect (or two in
Active-Active failover).
Management of the system is handled by the Cisco UCS Manager software embedded into the 6100 series switch,
which is accessed by the administrator through a common browser such as Internet Explorer or Firefox. Virtual
machines can be moved from one physical chassis to another, applications may be moved between virtual machines,
and management may even be conducted remotely from an iPhone. (SiMU) In addition to the embedded software,
administrators may also manage the system from VMWare's vSphere.
Cisco Unified Computing System
[1] http:/ / wikibon.org/wiki/ v/ Edge_Virtual_Bridging#VN-Tag
Cisco, Inc. “Cisco UCS B-Series Blade Servers”. (2010). Retrieved from Cisco Product Datasheet (http:/ / www.
cisco. com/ en/ US/ prod/ collateral/ ps10265/ ps10280/ ps10915/
data_sheet_c78-588109_ps10280_Products_Data_Sheet. html)
SiMU - Simple iPhone Monitoring of UCS. (2010) Retrieved from Blogspot.com (http:// ucs-simu. blogspot. com/ )
External links
• Unified Computing (http:// www.cisco. com/ ewb/ go/ unifiedcomputing) on Cisco website
• Product Datasheet for UCS Blade systems (http:/ / www.cisco. com/ en/ US/ prod/ collateral/ps10265/ ps10280/
ps10915/data_sheet_c78-588109_ps10280_Products_Data_Sheet. html) on cisco.com
• UCS-SIMU Blog (http:// ucs-simu. blogspot. com/ ) on blogspot.com
• Edge Virtual Switching (http:// wikibon.org/wiki/ v/ Edge_Virtual_Bridging#VN-Tag)
• Nehalem memory with catalina (http:/ / rodos. haywood.org/2009/ 06/ nehalem-memory-with-catalina.html) on
• Cisco UCS 6120XP 20-Port Fabric Interconnect (http:/ / www.cisco. com/ en/ US/ products/ ps10301/ index.
html) on company website
Logical partition (virtual computing platform)
A logical partition, commonly called an LPAR, is a subset of computer's hardware resources, virtualized as a
separate computer. In effect, a physical machine can be partitioned into multiple logical partitions, each hosting a
separate operating system.
IBM developed the concept of Hypervisors (virtual machines in CP-40 and CP-67 and in 1972 provided it for the
S/370 as Virtual Machine Facility/370
. IBM introduced the Start Interpretive Execution (SIE) instruction as part
of 370-XA on the 3081, and VM/XA versions of VM to exploit it. PR/SM is a type-1 Hypervisor based on the CP
component of VM/XA that runs directly on the machine level and allocates system resources across LPAR's to share
physical resources. It is a standard feature on IBM System z machines.
The terms PR/SM and LPAR are often used interchangeably, including in IBM documentation. Formally, LPAR
designates the logical partitioning function and mode of operation, whereas PR/SM is the commercial designation of
the feature.
This technology was later developed separately by Amdahl, and Hitachi Data Systems for the mainframe
architecture ESA/390 in the mid 1980s; and continued by IBM for zSeries and System z architectures. LPAR and
PR/SM reconfigurations can be made without rebooting the computer, i.e., while some LPARs remain active.
Reconfigurations can include changing channel path definitions and device definitions.
z/VM supports the z/Architecture HiperSockets function for high-speed TCP/IP communication among virtual
machines and logical partitions (LPARs) within the same IBM zSeries server. This function uses an adaptation of the
Queued-Direct Input/Output (QDIO) high-speed I/O protocol.
IBM later extended the idea to non-mainframe servers, such as the pSeries in October 2001
and iSeries, albeit
with varying technical specifications. Multiple operating systems are compatible with LPARs, including z/OS,
z/VM, z/VSE, z/TPF, AIX, Linux (including Linux on zSeries), and i5/OS. In storage systems, such as the IBM
TotalStorage DS8000, LPARs allow for multiple virtual instances of a storage array to exist within a single physical
Logical partition (virtual computing platform)
Hardware partitioning
Logical partitioning divides hardware resources. Two LPARs may access memory from a common memory chip,
provided that the ranges of addresses directly accessible to each do not overlap. One partition may indirectly control
memory controlled by a second partition, but only by commanding a process in that partition. CPUs may be
dedicated to a single LPAR or shared. While on Amdahl's MDF it was possible to configure an LPAR with both
shared and dedicated CPUs it is no longer possible with mainframes.
On IBM mainframes, LPARs are managed by the PR/SM facility. IBM mainframes operate exclusively in LPAR
mode, even when there is only one partition on a machine. Multiple LPARs running z/OS can form a Sysplex or
Parallel Sysplex, whether on one machine or spread across multiple machines.
On IBM System P Power hardware, LPARs are managed by the Power Hypervisor. The Hypervisor or PowerVM
acts as a virtual switch between the LPARs and also handles the virtual SCSI traffic between LPARs.
Micro-Partitioning supports 10 times as many LPARs as processors with fractional allocations. It was introduced
with the POWER5 processor. All IBM POWER5 and POWER6 systems may be partitioned. Note that a full system
partition may be defined where all resources are consumed by a single partition. System P servers with PowerVM
enabled allow LPARs with shared CPUs to delegate their unused cycles into the shared pool. Dedicated processors
are not available for sharing. Unused cycles become available for other partitions and are governed by the parameters
specified when the LPAR is defined. Changes to a running partition can be made dynamically up to the maximum
value set, and down to the minimum value set in the active profile. The changing of resource allocations without
restart of the logical partition is called dynamic logical partitioning. IBM PowerVM (formerly known as Advanced
POWER Virtualization or APV) is the licensed/purchased feature that enables the virtualization features on p4,5,6,7
series servers.

LPARs safely allow combining multiple test, development, quality assurance, and production work on the same
server, offering advantages such as lower costs, faster deployment, and more convenience. IBM mainframe LPARs
are Common Criteria EAL5 certifiable, equivalent to physically unconnected servers, so they support the highest
security requirements, including military use. Nearly all IBM mainframes run with multiple LPARs with the IBM
System z9 and IBM System z10 supporting up to 60 LPARs.
[1] Singh, Karan (2009-12-02). "Security on the Mainframe" (http:// www. redbooks. ibm.com/ redpieces/ pdfs/ sg247803. pdf). . Retrieved
[2] 1990, 2002, Copyright IBM Corp. (2002-04-12). z/VM™ built on IBM Virtualization Technology General Information Version 4 Release 3.0
(http:// www. vm.ibm. com/ pubs/ HCSF8A50. PDF). GC24-5991-04. .
[3] Singh, Karan (2009-12-02). "Security on the Mainframe" (http:// www. redbooks. ibm.com/ redpieces/ pdfs/ sg247803. pdf). . Retrieved
2010-04-06., page 83
[4] Griffiths, Nigel (2005-06-29). "POWER5 Virtualization: How to set up the Virtual I/O Server" (http:// www. ibm. com/ developerworks/ aix/
library/au-aix-vioserver-v2/index. html). . Retrieved 2008-09-25.
[5] Singh, Karan (2009-12-02). "Security on the Mainframe" (http:/ / www. redbooks. ibm.com/ redpieces/ pdfs/ sg247803. pdf). . Retrieved
[6] System p Virtualization (http:// www-01. ibm. com/ common/ ssi/ cgi-bin/ssialias?infotype=an& subtype=ca& appname=Demo&
htmlfid=897/ ENUS207-269IBM)
[7] 207-269, IBM Announcement (2007-11-06). "IBM System p Virtualization — The most complete virtualization offering for UNIX and
Linux" (http:// www-01. ibm. com/ common/ ssi/ cgi-bin/ssialias?infotype=an& subtype=ca& appname=Demo& htmlfid=897/
ENUS207-269). . Retrieved 2010-04-06.
Logical partition (virtual computing platform)
External links
• Security on the Mainframe (http:// www. redbooks.ibm. com/ redpieces/ pdfs/ sg247803. pdf), December 2009,
by Karan Singh, Chapter 4. Virtualization, page 24 and page 83.
• System i and System p: Logical Partitioning Guide (https:/ / www-01.ibm. com/ servers/ resourcelink/ lib03030.
nsf/ web+ search/ 0E6125F89F8B8EF6852572E6007E884D/$file/ sa76-0098. pdf)
• IBM System p Virtualization — The most complete virtualization offering for UNIX and Linux (http:// www-01.
ibm. com/ common/ ssi/ cgi-bin/ ssialias?infotype=an& subtype=ca& appname=Demo& htmlfid=897/
Juniper EX-Series
Juniper EX-Series
Juniper EX-Series
Manufacturer Juniper Networks
Type Network switch
Processor Internet Processor
Juniper EX-Series is a series of Ethernet network switches designed and manufactured by Juniper Networks.

These switches run on Juniper's network operating system, JUNOS.
Juniper's then CEO and present Chairman,
Scott Kriens said that the product launch marked the beginning of a transcending chapter in Juniper's history,
declaring, "The switch is on". The EX series switch was launched after 12 years since the start of the company in
Models and Platforms
The Juniper EX series switches includes five different families: EX2500, EX3200,EX4200,EX4500 and EX8200
The Juniper EX2500 line of 10Gb Ethernet switches address high-performance server access requirements with
twenty-four 10 GbE SFP+ ports that deliver wire-speed performance and 700 nanosecond latency. The EX2500
Series will support 480 Gigabit per second (Gbps) throughput (full duplex) in a 1 rack-unit (RU) footprint. The
EX2500 Series is expected to be available in 2Q 2009.
The EX2500 Series has both power and fan redundancy as
standard features. The EX2500 Series comes with dual, load-sharing power supplies, as well as redundant,
variable-speed fans to protect from single power supply or fan failure. The EX2500 is a rebranded OEM product
which does not run JunOS. Its technical configuration
, performance and physical case style is similar to the Blade
Network Technologies RackSwitch G8124
The Juniper 3200 switches are 24-port or 48-port boxes with 10/100/1000 Mbit/s Ethernet ports supporting power
over Ethernet (PoE). They can also support 1G Ethernet and 10G Ethernet uplinks.
The Juniper 4200 series is built on modular chassis used for data centers and large corporate offices. They also come
in 24-port and 48-port models and support PoE as well as 1 Gig Ethernet and 10Gig Ethernet uplinks. They also have
a 24-port fiber option.
These switches are stackable, and 10 of them can be linked to create a single virtual switch
supporting up to 480 10/100/1000 Ethernet ports, forty 1G Ethernet or twenty 10G Ethernet ports. EX4200 Virtual
Chassis can be expanded by using optical ports and/or ethernet ports (VCE - Virtual Chassis Expansion), thus
allowing to manage device as a single switch even if locations are separated. Optical modules support up to 80
kilometers range.
Juniper EX-Series
The Juniper EX4500 series consists models which differ in the direction of the airflow used for cooling and the
support for Converged Enhanced Ethernet. All models are two rack units high and have forty 10G Ethernet SFP+
ports. Two slots are available which can be used to add four 10G Ethernet SFP+ ports per slot. The roadmap for
these switches includes the ability to stack them together and with switches of the EX4200 series.
The Juniper 8200 series are core switches for 10G Ethernet backbones that comes in two models. One has an
eight-slot 1.6 Tbit/s chassis that supports up to 64 ports. The other has a sixteen-slot 3.2 Tbit/s chassis that supports
up to 128 ports. Separate external routing engine XRE200 can be used to offload switches REs.
The EX switches support a range of features including high availability and network access control (NAC). The
NAC support, which Juniper calls Unified Access Control (UAC), enables the switches to enforce access policies
rather than rely on firewalls, VPN gateways or switches made by other vendors.
Juniper Networks EX-series Ethernet switches are compliant with Internet protocol (IP) telephony solutions from
They are also interoperable with leading network management platforms from AlterPoint, CA, EMC, HP,
IBM, InfoVista and SolarWinds.
Network World Lab Alliance certified that Juniper switches a credible alternative for enterprise access in switching in
comparison with other vendors' access switches.
[1] "Juniper Networks to Extend EX-series Ethernet Switch Interoperability to Industry Leading" (http:// www. reuters.com/ article/
pressRelease/idUS141190+ 06-Aug-2008+BW20080806). Reuters. Aug 6, 2008. . Retrieved 2009-04-26.
[2] "Juniper launches Ethernet switches with built-in NAC" (http:/ / www.networkworld.com/ news/ 2008/
012908-juniper-ethernet-switches-nac. html). Network World. 2008-01-29. . Retrieved 2009-04-26.
[3] "EX series Ethernet Switches" (http:// www. juniper.net/ us/ en/ products-services/ switching/ ex-series/ ). Juniper Networks. . Retrieved
[4] "Juniper Networks to Extend EX-Series Ethernet Switch Interoperability to Industry Leading Network Management Platforms" (http:/ / www.
redorbit.com/ news/ technology/ 1512464/ juniper_networks_to_extend_exseries_ethernet_switch_interoperability_to_industry/index.html).
Redorbit. . Retrieved 2009-04-26.
[5] "Juniper Makes The Switch" (http:/ / www. internetnews. com/ infra/article.php/ 3724536). InternetNews.com. January 29, 2008. . Retrieved
[6] "Juniper Networks Adds to EX Family with 10 Gigabit Ethernet Switch" (http:/ / findarticles.com/ p/ articles/ mi_m0EIN/is_2009_Feb_24/
ai_n31375892/ ). Business Wire. Feb 24, 2009. . Retrieved 2009-04-26.
[7] http:// www. juniper.net/ techpubs/ en_US/ release-independent/junos/ information-products/pathway-pages/ ex-series/ hardware/ex2500.
[8] http:// www. bladenetwork. net/ RackSwitch-G8124.html
[9] "Juniper EX4500 datasheet" (http:// www.juniper. net/ us/ en/ local/ pdf/ datasheets/ 1000322-en.pdf). Juniper Networks. Aug 2, 2010. .
Retrieved 2009-09-02.
[10] "Juniper Networks EX-series Ethernet Switches Achieve Avaya Interoperability Certification to Deliver Enterprise IP Telephony Solutions"
(http:/ / www. avaya.com/ gcm/ master-usa/ en-us/ corporate/pressroom/ pressreleases/ 2008/ pr-080917.htm). Avaya. . Retrieved
[11] "Juniper switch proves to be credible choice :Review shows the EX 4200 to be fast, feature-rich and manageable" (http:// www.
networkworld.com/ reviews/ 2008/ 071408-test-juniper-switch.html). Network World. 07/14/2008. . Retrieved 2009-04-26.
Linux on Power
Linux on Power
Linux on Power is the combination of any Linux-based operating system running on Power Architecture
technology, a microprocessor architecture.
Power Architecture is one of the many architectures the Linux kernel has been compiled to run on allowing
computers such as PowerPC-based Power Macintosh computers originally designed to run Mac OS to use
GNU/Linux distributions such as Debian.
IBM supports Linux on Power with its line of Power servers, which has gone through an evolution of names; eServer
p5 series, RS/6000, P Series, System P, and as of April 2008, IBM Power Systems. Linux releases that run on this
type of hardware are a ppc64 Linux port compiled to run on IBM POWER based servers.
Since the release of eServer p5 series and the Linux 2.6 kernel, many Linux distributions can take advantage of
POWER hardware features such as logical partitioning, Micro-Partitioning and RTAS. IBM at one time offered an
entry/midrange line of servers called OpenPower which only run Linux, as opposed to other POWER-based servers
that can also run the AIX operating system.
Virtualization on Power6 and OpenPower
POWER6 based IBM systems have built in virtualization capabilities derived from mainframe technology. On
System P, this virtualization package is referred to as PowerVM. There is an additional layer between hardware and
operating systems which is called the hypervisor. IBM Power6 systems support up to 256 logical partitions on one
machine, with a maximum of 10 per processor. These micropartitions can run in a shared processor pool and utilize
automatic load balancing.
The hypervisor also allows the assignment of virtual I/O and network adapters to logical partitions.
• The hypervisor acts as a virtual switch for internal network connectivity. This allows for network communication
between the LPARs to be direct (memory to memory) and not have to leave the physical machine. A dedicated
virtual I/O server (VIO) partition (running a Linux or AIX-based system) can act as a network bridge between the
internal VLAN, on which the VIO server is connected, to a physical external network.
• SCSI virtualization is implemented via virtual SCSI device assignment from the VIO to the client LPAR. The
VIO server has the physical storage; parts of that storage (whole disks, logical volumes or partitions) are shared to
the clients through a VSCSI server to VSCSI client relationship.
Any SUSE Linux distributions or Debian installation with real resources assigned can be used as a virtual I/O server.
There are only two kernel modules, ibmvscsis and ibmveth, that need to be loaded to provide this functionality. Both
modules are licensed under the GPL and part of the distribution kernel.
For dynamic LPAR changes on the fly (for example, adding CPU or memory, or removing a PCI adapter), some
lopdiags additional packages
are needed for RSCT (Reliable Scalable Cluster Technology) communication with
the HMC (Hardware Management Console). Those packages are provided from IBM in RPM format but not in
source code. After installing these packages, dynamic reconfiguration of CPU and hotpluggable PCI adapters can be
done without rebooting the operating system. Reducing the memory amount assigned to the logical partition still
requires reboot of the target LPAR.
Linux on Power
Pricing and costs
The two largest commercial Linux vendors, Red Hat and Novell, offer licensing and support based on a "per physical
machine" system for System P servers. Cost is not based on number of processors installed, which is different from
pricing on IBM's System Z servers, where licensing and support is based on the number of IFLs. Purchasing higher
model numbered servers, such as a p570 or p590, allows for a smaller monetary investment but yet leaves room for
more physical expansion if capacity exceeds the original investment. Each LPAR on a System P machine can be as
small as 0.1 processors. This allows the total number of LPARs on a physical machine to go as high as 10 times the
number of physical processors. A higher number of logical servers reduces the "per-server" cost.
Systems running Linux on Power Architecture are:
• IBM POWER Systems
• JS43, JS23, JS20, JS21, QS20, QS21, QS22 Blade Center
• OpenPower
• Cell blade server from Mercury Computer Systems
• PlayStation 3
Linux distributions
Officially supported distributions
• For IBM System p and i – SUSE SLES8, SLES9, SLES10 and SLES11
• For IBM System p and i – Red Hat EL AS 3, 4 and 5
Working distributions
• Debian
• Fedora Core
• Gentoo
• openSUSE
• Ubuntu
[1] http:/ / www14. software. ibm.com/ webapp/ set2/ sas/ f/ lopdiags
Metro Ethernet
Metro Ethernet
A Metro Ethernet is a computer network that covers a metropolitan area and that is based on the Ethernet standard.
It is commonly used as a metropolitan access network to connect subscribers and businesses to a larger service
network or the Internet. Businesses can also use Metro Ethernet to connect branch offices to their Intranet.
Ethernet has been a well known technology for decades. An Ethernet interface is much less expensive than a
SONET/SDH or PDH interface of the same bandwidth. Ethernet also supports high bandwidths with fine granularity,
which is not available with traditional SDH connections. Another distinct advantage of an Ethernet-based access
network is that it can be easily connected to the customer network, due to the prevalent use of Ethernet in corporate
and, more recently, residential networks. Therefore, bringing Ethernet in to the Metropolitan Area Network (MAN)
introduces a lot of advantages to both the service provider and the customer (corporate and residential).
Metro Ethernet system
A typical service provider Metro Ethernet
network is a collection of Layer 2 or/and
Layer 3 switches or/and routers connected
through optical fiber. The topology could be
a ring, hub-and-spoke (star), or full or
partial mesh. The network will also have a
hierarchy: core, distribution (aggregation)
and access. The core in most cases is an
existing IP/MPLS backbone, but may
migrate to newer forms of Ethernet
Transport in the form of 10G or 100G
Ethernet on the MAN can be used as pure
Ethernet, Ethernet over SDH, Ethernet over
MPLS or Ethernet over DWDM. Pure
Ethernet-based deployments are cheap but
less reliable and scalable, and thus are
usually limited to small scale or
experimental deployments. SDH-based
deployments are useful when there is an
existing SDH infrastructure already in place,
its main shortcoming being the loss of flexibility in bandwidth management due to the rigid hierarchy imposed by
the SDH network. MPLS based deployments are costly but highly reliable and scalable, and are typically used by
large service providers.
Pure Ethernet MANs
A pure Ethernet MAN uses only layer 2 switches for all of its internal structure. This allows for a very simple and
cheap design, and also for a relatively simple initial configuration. The original Ethernet technology was not well
suited for service provider applications; as a shared-media network, it was impossible to keep traffic isolated, which
made implementation of private circuits impossible. Ethernet MANs became feasible in the late 90s due to the
development of new techniques to allow transparent tunneling of traffic through the use of Virtual LANs as "point to
point" or "multipoint to multipoint" circuits. Combined with new features such as VLAN Stacking (also known as
VLAN Tunneling), and VLAN Translation, it became possible to isolate the customers' traffic from each other and
from the core network internal signaling traffic. However, Ethernet is constantly evolving and has now carrier class
Metro Ethernet
features with the recent addition of IEEE 802.1ad (Provider Bridges)(also known as QinQ or stacked VLANs) and
IEEE 802.1ah (Provider Backbone Bridges) (also known as MAC in MAC or PBB) and IEEE 802.1Qay (Provider
Backbone Transport) (also known as PBT or PBB-TE). Spanning-tree, broadcast packets and dynamic MAC
learning are disabled and sub 50ms failover features are introduced.
There are three main shortcomings with a pure non PBT/PBB enabled Ethernet MAN approach:
• By design, layer 2 switches use fixed tables to direct traffic based on the MAC address of the endpoints. As the
network gets larger, the number of MAC address transiting through the network may grow beyond the capacity of
the core switches. If the core table gets full, the result is a catastrophic loss of performance due to the flooding of
packets over the entire network structure. This can be overcome to some degree by smart network design and
keeping your network segments and rings small enough to support the MAC table limitations of the equipment. In
a pure ethernet network, the network should be designed in a modular grouping where your less expensive,
smaller MAC table devices are in small geographically significant segments connected by larger aggregation
devices which are interconnected that support two tag manipulation and very large MAC tables. This design
keeps locally geographically significant segments interconnected with less expensive equipment, and larger
geographically connected areas interconnected with more expensive, more feature laden equipment. This keeps
the MAC tables small and helps keep the pure ethernet network scalable.
• Network stability is relatively fragile, especially if compared to the more advanced SDH and MPLS approaches.
The recovery time for the standard spanning tree protocol is in the range of tens of seconds, much higher than
what can be obtained in the alternative networks (usually a fraction of second). There are a number of
optimizations, some standardized through the IEEE, and others vendor-specific, that seek to alleviate this
problem. The clever use of such features allow the network to achieve good stability and resilience, at the cost of
a more complex configuration and possible use of non-standard, vendor-specific, mechanisms. Some vendor's
implementations of RSTP achieve sub 50ms convergence in typical sized rings. RSTP also provides for easy
deployment of complex designs such as multi-ring, figure eight, etc. If designed appropriately, in many networks
the fragility in this network design can be overcome without the additional expense of MPLS.
• Traffic engineering is very limited. There are few tools to manage the topology of the network; also, the fact that
forwarding is done hop-by-hop, added to the possibility of broadcasts even for unicast packets (for instance, while
learning new addresses), makes predicting the real traffic pattern very difficult for a networking novice. Custom
tools, such as topology maps that outline where blocking ports occur in the network during normal and backup
conditions may need to be built to fully understand and troubleshoot the network quickly.
Despite these shortcomings, non PBT/PBB enabled Ethernet-based MANs are used for two primary purposes:
• For small scale deployments (under a few hundred customers), a pure Ethernet MAN can be highly cost-effective.
It also has the advantage of not requiring advanced knowledge of IP and related protocols, such as BGP and
MPLS, which are necessary for an MPLS-based deployment. Even for larger scale deployments for thousands and
thousands of customers can be achieved if careful network design rules are followed. In order to do this
effectively skilled networking professionals need to be utilized.
• In large scale Metro Ethernets, it is common for the access part of the network to use a pure layer 2 design. At this
level, the pure layer 2 design is deemed to be cheaper while still operating under its design limitations. From the
distribution layer and above, traffic is aggregated and routed using an MPLS-based Metro Ethernet design. In
very large networks MPLS may be unavoidable, but with careful network design, the use of both PBT and MPLS
and their associated cost and complexity can be postponed if not eliminated entirely by careful network planning
and design.
Myths regarding Pure Ethernet:
The biggest myth being propagated regarding pure metro-ethernet or carrier ethernet is that there are 4094 VLANs
available network wide for a provider network. This is simply not true. There are 4094 VLANs available on each
switched path. So the VID(vlan id) cannot be reused along the path from point a to point z, but can be reused
Metro Ethernet
anywhere else in the network as long as the paths are separated. Larger pure ethernet aggregation devices allow for
traffic classification up to two tags deep. This allows for up to 16.7 million paths on a device of this nature, which
should be used to aggregate devices that can only classify traffic based on 4094 VLAN ids. So with proper network
design, in most networks VLAN exhaustion is not an issue if the network is designed appropriately. The network
should be designed so that devices supporting large MAC tables and traffic classification of two tags are
interconnected, and they act as an aggregator for less expensive, smaller mac table, one tag switches in attached rings
and segments. Attaching these devices to interconnect larger areas provides for the theoretic possibility of up to 16.7
million unique paths between these devices, limited only by the device processing and memory capabilities. In a
properly designed geographically significant modular network, more expensive services such as MPLS and PBT can
be postponed or eliminated entirely. VLANs are locally significant only.
Another myth is that RSTP convergence takes many seconds. In certain situations and with some equipment this
may be true. However, some vendors are offering devices that will converge RSTP in sub-50ms with little to no
planning or effort. Advanced network planning may be required to achieve these speeds in certain situations, but it is
possible with certain vendor's RSTP deployment. Problems with spanning tree in many instances arise from poor
planning, design, and deployment. Spanning tree should be segmented and designed in small domains to be
successful. A spanning tree domain is an area in which BPDUs will propagate. While advanced features of MSTP
can be utilized, so can building manual spanning tree domains with legacy RSTP by disabling or blocking BPDUs on
certain planned segments. In this way you create domains of segments and rings where spanning-tree is enabled, and
keep the segments manageable. It is also essential to chose a root bridge and backup root bridge carefully. Path-costs
should be modified so that the network administrator knows exactly what will happen to the traffic in the event of a
failed segment anywhere in the network.
Another myth is that L2 metro-ethernet connections remove the need for using L3 routers or L3 switches. This is
also not true. While equipment will operate just fine over your new metro-ethernet gear on L2 without a router. The
whole point is to provide low latency transport. Why send unnecessary broadcast traffic over a metro-ethernet
connection that you are probably paying for by Mbps? In most situations routing over your metro-ethernet
connection will keep your broadcast traffic down to a bare minimum and help utilize your connection's bandwidth
for real traffic, not superfluous packets. This is especially important with more and more nodes on each end of the
connection. Routers are not very expensive. If you are paying out hundreds or thousands monthly for a
metro-ethernet connection, spend the extra money and get a good router.
SONET/SDH-based Ethernet MANs
A SONET/SDH based Ethernet MAN is usually used as an intermediate step in the transition from a traditional,
time-division based network, to a modern statistical network (such as Ethernet). In this model, the existing SDH
infrastructure is used to transport high-speed Ethernet connections. The main advantage of this approach is the high
level of reliability, achieved through the use of the native SDH protection mechanisms, which present a typical
recovery time of 50 ms for severe failures. On the other hand, an SDH-based Ethernet MAN is usually more
expensive, due to costs associated with the SDH equipment that is necessary for its implementation. Traffic
engineering also tends to be very limited. Hybrid designs use conventional Ethernet switches at the edge of the core
SDH ring to alleviate some of these issues, allowing for more control over the traffic pattern and also for a slight
reduction in cost.
Metro Ethernet
MPLS-based Ethernet MANs
An MPLS based Metro Ethernet network uses MPLS in the Service Provider Network. The subscriber will get an
Ethernet interface on Copper (ex:-100BASE-TX) or fiber (ex:-100BASE-FX). The customer's Ethernet packet is
transported over MPLS and the service provider network uses Ethernet again as the underlying technology to
transport MPLS. So, it is Ethernet over MPLS over Ethernet.
Here, Label Distribution Protocol (LDP) signaling is used as site to site signaling for the inner label (VC label) and
Resource reSerVation Protocol-Traffic Engineering (RSVP-TE) or LDP may be used as Network signaling for the
outer label.
One of the restoration mechanisms used in an MPLS based Metro Ethernet Networks is Fast ReRoute-FRR (MPLS
local protection)
The main advantages of an MPLS-based Metro Ethernet against a pure Ethernet are:
• Scalability: There is a horrible myth in MPLS proponents that pure Ethernet MAN are limited to a maximum of
4,094 VLANs for the whole network, and that when using MPLS, Ethernet VLANs have local meaning only (like
Frame Relay PVC). This is untrue. Each local segment that data traverses is limited to 4094 VLANs even without
MPLS, not the whole network. In a properly designed simple VLAN network, each switched path can have 4094
single tag VLANs. Some larger aggregation equipment can classify traffic by two VLANs, so with properly
placed two tag aggregation devices in the center of the network, up to 16.7 million different virtual switches can
be assigned network wide—which eliminates many of the reasons to use MPLS. When crossing the agg devices,
there are 16.7 million vlan combinations—so then end segments and rings of single tag devices can receive only
the traffic that they need—leaving 4094 inst.
• Resiliency: pure Ethernet network resiliency relies on STP, RSTP or MSTP (30 to sub 50ms sec convergence)
while MPLS-based MANs use MPLS-based mechanism (i.e. MPLS Fast Reroute) to achieve SDH-like (50
msecs) convergence times. Some vendors RSTP convergence is also sub-50ms, but this convergence time can't be
relied on from vendor to vendor. For each deployment situation the benefit versus cost of MPLS must be weighed
carefully. In some situations the cost may not warrant the benefits, particularly if sub 50ms convergence time is
already being achieved.
• Multiprotocol convergence: with the maturity on pseudowires standards (ATM Virtual Leased Line VLL, FR
VLL, etc.) an MPLS-based Metro Ethernet can backhaul not only IP/Ethernet traffic but virtually any type of
traffic coming from customer networks or other access networks (i.e. ATM aggregation for UMTS or TDM
aggregation for GSM).
• End to End OAM: MPLS-based MAN offers a wider set of troubleshooting and OAM MPLS-based tools which
enrich Service Providers ability to effectively troubleshoot and diagnose network problems. These include for
example, MAC ping, MAC traceroute, LSP ping etc.
The Metro Ethernet Forum (MEF) has defined three types of services that can be delivered through Metro Ethernet:
• E-Line also known as Virtual Private Wire Service (VPWS), Virtual Leased Line (VLL), Point-to-Point, or
Ethernet Private Wire Service (EPVS).
• E-LAN also known as Virtual Private LAN Services (VPLS), Transparent LAN Services and
• E-TREE also known as Rooted-MultiPoint.
Additionally, various access services can be provided with Metro Ethernet including; High Speed Internet access and
IP/VPN access.
There are lot of vendors supplying equipment for Metro Ethernet deployments. They include ADTRAN, ADVA
Optical Networking, Alcatel-Lucent, C-COR, Fujitsu Network Communications (FNC), Ciena, Cisco, Creanord
cyaninc.com, DATACOM
, Dahili Network, Ericsson, Extreme Networks, Foundry Networks, Hatteras Networks,
Huawei, IPITEK
, Juniper Networks, MAIPU
, MRV, Nortel Networks, RAD Data Communications, Redback
Metro Ethernet
Networks an Ericsson Company, Tejas Networks, Tellabs, ZTE and many more.
In June 2002, HKBN built the largest Metro Ethernet IP network in the world, covering 1.62 million homes in Hong
Kong. and it will continue to expand towards the 2.0 million target by 2010.
In late September 2007 Verizon Business announced that it is implementing a Metro Ethernet solution across
Asia-Pacific including Australia, Singapore, Japan and Hong Kong using Nortel equipment.[5]
Africa's largest and most developed privately owned MPLS Based Metro Ethernet Network is in Kenya. Reaching
more than 5000 corporate entities, Kenya Data Networks is providing High End Services using Alcatel Core and
Siemens Access equipment. KDN is now moving into FTTH projects and intends to cover more than 100 000
buildings in East Africa within the next 3 years.
Further reading
• Halabi, Sam (2003). Metro Ethernet. Cisco Press. ISBN 1-58705-096-X.
• MPLS network over a Metro Ethernet network
External links
• Metro Ethernet Forum (MEF)
• The Challenges of Ethernet Access
• Carrier Ethernet Forum
[1] http:/ / www. creanord.com
[2] http:/ / www. datacom. ind. br
[3] http:// www. ipitek.com
[4] http:/ / www. maipu. com
[5] http:/ / www. computerworld.com. au/ index. php/ id;1898868494;fp;16;fpid;1
[6] http:/ / www. ipitek.com/ mpls-over-ethernet.php
[7] http:// vpls. org/
[8] http:/ / www. metroethernetforum.org/
[9] http:/ / www. ethernetaccess. com/ Home/ 0,6583,19479-The_Challenges_of_Ethernet_Access,00.html
[10] http:/ / www. carrierethernet.us. com/
[11] http:// vpls. us/
List of TCP and UDP port numbers
List of TCP and UDP port numbers
This is a list of Internet socket port numbers used by protocols of the Transport Layer of the Internet Protocol Suite
for the establishment of host-to-host communications.
Originally, these port numbers were used by the Transmission Control Protocol (TCP) and the User Datagram
Protocol (UDP), but are used also for the Stream Control Transmission Protocol (SCTP), and the Datagram
Congestion Control Protocol (DCCP). SCTP and DCCP services usually use a port number that matches the service
of the corresponding TCP or UDP implementation if they exist.
The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port
numbers for specific uses.
However, many unofficial uses of both well-known and registered port numbers occur
in practice.
Table legend
Color coding of table entries
Official Port/application combination is registered with IANA
Unofficial Port/application combination is not registered with IANA
Conflict Port is in use for multiple applications (may be official or unofficial)
Well-known ports: 0–1023
The port numbers in the range from 0 to 1023 are the well-known ports. They are used by system processes that
provide widely-used types of network services. On Unix-like operating systems, a process must execute with
superuser privileges to be able to bind a network socket to an IP address using one of the well-known ports.
Description Status
0 UDP Reserved Official
1 TCP UDP TCP Port Service Multiplexer (TCPMUX) Official
Management Utility
Compression Process
4 TCP UDP Unassigned Official
5 TCP UDP Remote Job Entry Official
6 TCP UDP Unassigned Official
7 TCP UDP Echo Protocol Official
8 TCP UDP Unassigned Official
9 TCP UDP Discard Protocol Official
10 TCP UDP Unassigned Official
Active Users (systat service
12 TCP UDP Unassigned Official
13 TCP UDP Daytime Protocol (RFC 867) Official
14 TCP UDP Unassigned Official
List of TCP and UDP port numbers
netstat service
16 TCP UDP Unassigned Official
17 TCP UDP Quote of the Day Official
18 TCP UDP Message Send Protocol Official
19 TCP UDP Character Generator Protocol (CHARGEN) Official
20 TCP FTP—data transfer Official
21 TCP FTP—control (command) Official
22 TCP UDP Secure Shell (SSH)—used for secure logins, file transfers (scp, sftp) and port forwarding Official
23 TCP Telnet protocol—unencrypted text communications Official
24 TCP UDP Priv-mail : any private mail system. Official
25 TCP Simple Mail Transfer Protocol (SMTP)—used for e-mail routing between mail servers Official
26 TCP UDP Unassigned Official
27 TCP UDP NSW User System FE Official
34 TCP UDP Remote File (RF)—used to transfer files between machines Unofficial
35 TCP UDP Any private printer server protocol Official
37 TCP UDP TIME protocol Official
Resource Location Protocol
(RLP)—used for determining the location of higher level services from hosts
on a network
40 TCP UDP Unassigned Official
41 TCP UDP Graphics Official
42 TCP UDP nameserver, ARPA Host Name Server Protocol Official
42 TCP UDP WINS Unofficial
43 TCP WHOIS protocol Official
49 TCP UDP TACACS Login Host protocol Official
Remote Mail Checking Protocol
51 TCP UDP IMP Logical Address Maintenance Official
52 TCP UDP XNS (Xerox Network Systems) Time Protocol Official
53 TCP UDP Domain Name System (DNS) Official
54 TCP UDP XNS (Xerox Network Systems) Clearinghouse Official
55 TCP UDP ISI Graphics Language (ISI-GL) Official
56 TCP UDP XNS (Xerox Network Systems) Authentication Official
Route Access Protocol (RAP)
57 TCP Mail Transfer Protocol (MTP) Unofficial
58 TCP UDP XNS (Xerox Network Systems) Mail Official
67 UDP Bootstrap Protocol (BOOTP) Server; also used by Dynamic Host Configuration Protocol (DHCP) Official
68 UDP Bootstrap Protocol (BOOTP) Client; also used by Dynamic Host Configuration Protocol (DHCP) Official
69 UDP Trivial File Transfer Protocol (TFTP) Official
70 TCP Gopher protocol Official
List of TCP and UDP port numbers
71 TCP Genius protocol Official
79 TCP Finger protocol Official
80 TCP UDP Hypertext Transfer Protocol (HTTP) Official
81 TCP Torpark—Onion routing Unofficial
82 UDP Torpark—Control Unofficial
83 TCP MIT ML Device Official
88 TCP UDP Kerberos—authentication system Official
90 TCP UDP dnsix (DoD Network Security for Information Exchange) Securit Attribute Token Map Official
90 TCP UDP Pointcast Unofficial
99 TCP WIP Message Protocol Unofficial
101 TCP NIC host name Official
102 TCP
ISO-TSAP (Transport Service Access Point) Class 0 protocol
104 TCP UDP ACR/NEMA Digital Imaging and Communications in Medicine Official
105 TCP UDP CCSO Nameserver Protocol (Qi/Ph) Official
107 TCP
Remote TELNET Service
SNA Gateway Access Server
109 TCP Post Office Protocol v2 (POP2) Official
110 TCP Post Office Protocol v3 (POP3) Official
111 TCP UDP ONC RPC (SunRPC) Official
113 TCP
ident—Authentication Service/Identification Protocol,
used by IRC servers to identify users
113 UDP
Authentication Service
115 TCP Simple File Transfer Protocol (SFTP) Official
117 TCP UUCP Path Service Official
118 TCP UDP SQL (Structured Query Language) Services Official
119 TCP Network News Transfer Protocol (NNTP)—retrieval of newsgroup messages Official
123 UDP Network Time Protocol (NTP)—used for time synchronization Official
135 TCP UDP DCE endpoint resolution Official
Microsoft EPMAP (End Point Mapper), also known as DCE/RPC Locator service,
used to remotely
manage services including DHCP server, DNS server and WINS. Also used by DCOM
137 TCP UDP NetBIOS NetBIOS Name Service Official
138 TCP UDP NetBIOS NetBIOS Datagram Service Official
139 TCP UDP NetBIOS NetBIOS Session Service Official
143 TCP Internet Message Access Protocol (IMAP)—management of email messages Official
Background File Transfer Program (BFTP)
153 TCP UDP SGMP, Simple Gateway Monitoring Protocol Official
156 TCP UDP SQL Service Official
DMSP, Distributed Mail Service Protocol
161 UDP Simple Network Management Protocol (SNMP) Official
List of TCP and UDP port numbers
Simple Network Management Protocol Trap (SNMPTRAP)
170 TCP Print-srv, Network PostScript Official
177 TCP UDP X Display Manager Control Protocol (XDMCP) Official
179 TCP BGP (Border Gateway Protocol) Official
194 TCP UDP Internet Relay Chat (IRC) Official
199 TCP UDP SMUX, SNMP Unix Multiplexer Official
201 TCP UDP AppleTalk Routing Maintenance Official
209 TCP UDP The Quick Mail Transfer Protocol Official
210 TCP UDP ANSI Z39.50 Official
213 TCP UDP Internetwork Packet Exchange (IPX) Official
218 TCP UDP Message posting protocol (MPP) Official
220 TCP UDP Internet Message Access Protocol (IMAP), version 3 Official
256 TCP UDP 2DEV "2SP" Port Unofficial
259 TCP UDP ESRO, Efficient Short Remote Operations Official
264 TCP UDP BGMP, Border Gateway Multicast Protocol Official
280 TCP UDP http-mgmt Official
308 TCP Novastor Online Backup Official
311 TCP Mac OS X Server Admin (officially AppleShare IP Web administration) Official
318 TCP UDP PKIX TSP, Time Stamp Protocol Official
319 UDP Precision time protocol event messages Official
320 UDP Precision time protocol general messages Official
323 TCP UDP IMMP, Internet Message Mapping Protocol Unofficial
350 TCP UDP MATIP-Type A, Mapping of Airline Traffic over Internet Protocol Official
351 TCP UDP MATIP-Type B, Mapping of Airline Traffic over Internet Protocol Official
366 TCP UDP ODMR, On-Demand Mail Relay Official
369 TCP UDP Rpc2portmap Official
370 TCP codaauth2—Coda authentication server Official
370 UDP codaauth2—Coda authentication server Official
370 UDP
securecast1—Outgoing packets to NAI's servers
371 TCP UDP ClearCase albd Official
383 TCP UDP HP data alarm manager Official
384 TCP UDP A Remote Network Server System Official
AURP, AppleTalk Update-based Routing Protocol
389 TCP UDP Lightweight Directory Access Protocol (LDAP) Official
401 TCP UDP UPS Uninterruptible Power Supply Official
402 TCP Altiris, Altiris Deployment Client Unofficial
411 TCP Direct Connect Hub Unofficial
412 TCP Direct Connect Client-to-Client Unofficial
427 TCP UDP Service Location Protocol (SLP) Official
List of TCP and UDP port numbers
443 TCP HTTPS (Hypertext Transfer Protocol over SSL/TLS) Official
444 TCP UDP SNPP, Simple Network Paging Protocol (RFC 1568) Official
445 TCP Microsoft-DS Active Directory, Windows shares Official
445 TCP Microsoft-DS SMB file sharing Official
464 TCP UDP Kerberos Change/Set password Official
465 TCP Cisco protocol Unofficial
465 TCP SMTP over SSL Unofficial
475 TCP UDP tcpnethaspsrv (Aladdin Knowledge Systems Hasp services, TCP/IP version) Official
497 TCP Dantz Retrospect Official
500 UDP Internet Security Association and Key Management Protocol (ISAKMP) Official
501 TCP STMF, Simple Transportation Management Framework—DOT NTCIP 1101 Unofficial
502 TCP UDP asa-appl-proto, Protocol Unofficial
502 TCP UDP Modbus, Protocol Unofficial
504 TCP UDP Citadel—multiservice protocol for dedicated clients for the Citadel groupware system Official
510 TCP First Class Protocol Unofficial
512 TCP Rexec, Remote Process Execution Official
512 UDP comsat, together with biff Official
513 TCP rlogin Official
513 UDP Who Official
514 TCP Shell—used to execute non-interactive commands on a remote system (Remote Shell, rsh, remsh) Official
514 UDP Syslog—used for system logging Official
515 TCP Line Printer Daemon—print service Official
517 UDP Talk Official
518 UDP NTalk Official
520 TCP efs, extended file name server Official
520 UDP Routing Information Protocol (RIP) Official
524 TCP UDP NetWare Core Protocol (NCP) is used for a variety things such as access to primary NetWare server resources,
Time Synchronization, etc.
525 UDP Timed, Timeserver Official
530 TCP UDP RPC Official
531 TCP UDP AOL Instant Messenger, IRC Unofficial
532 TCP netnews Official
533 UDP netwall, For Emergency Broadcasts Official
540 TCP UUCP (Unix-to-Unix Copy Protocol) Official
542 TCP UDP commerce (Commerce Applications) Official
543 TCP klogin, Kerberos login Official
544 TCP kshell, Kerberos Remote shell Official
545 TCP OSIsoft PI (VMS), OSISoft PI Server Client Access Unofficial
546 TCP UDP DHCPv6 client Official
547 TCP UDP DHCPv6 server Official
List of TCP and UDP port numbers
548 TCP Apple Filing Protocol (AFP) over TCP Official
550 UDP new-rwho, new-who Official
554 TCP UDP Real Time Streaming Protocol (RTSP) Official
556 TCP Remotefs, RFS, rfs_server Official
560 UDP rmonitor, Remote Monitor Official
561 UDP monitor Official
563 TCP UDP NNTP protocol over TLS/SSL (NNTPS) Official
587 TCP
e-mail message submission
591 TCP FileMaker 6.0 (and later) Web Sharing (HTTP Alternate, also see port 80) Official
593 TCP UDP HTTP RPC Ep Map, Remote procedure call over Hypertext Transfer Protocol, often used by Distributed
Component Object Model services and Microsoft Exchange Server
604 TCP
TUNNEL profile,
a protocol for BEEP peers to form an application layer tunnel
623 UDP ASF Remote Management and Control Protocol (ASF-RMCP) Official
631 TCP UDP Internet Printing Protocol (IPP) Official
631 TCP UDP Common Unix Printing System (CUPS) Unofficial
635 TCP UDP RLZ DBase Official
636 TCP UDP Lightweight Directory Access Protocol over TLS/SSL (LDAPS) Official
639 TCP UDP MSDP, Multicast Source Discovery Protocol Official
641 TCP UDP SupportSoft Nexus Remote Command (control/listening): A proxy gateway connecting remote control traffic Official
646 TCP UDP LDP, Label Distribution Protocol, a routing protocol used in MPLS networks Official
647 TCP
DHCP Failover protocol
648 TCP
RRP (Registry Registrar Protocol)
651 TCP UDP IEEE-MMS Official
652 TCP DTCP, Dynamic Tunnel Configuration Protocol Unofficial
653 TCP UDP SupportSoft Nexus Remote Command (data): A proxy gateway connecting remote control traffic Official
654 TCP
Media Management System (MMS) Media Management Protocol (MMP)
IBM RMC (Remote monitoring and Control) protocol, used by System p5 AIX Integrated Virtualization
Manager (IVM)
and Hardware Management Console to connect managed logical partitions (LPAR) to
enable dynamic partition reconfiguration
660 TCP Mac OS X Server administration Official
665 TCP sun-dr, Remote Dynamic Reconfiguration Unofficial
666 UDP Doom, first online first-person shooter Official
674 TCP ACAP (Application Configuration Access Protocol) Official
691 TCP MS Exchange Routing Official
692 TCP Hyperwave-ISP Official
694 TCP UDP Linux-HA High availability Heartbeat Official
695 TCP
IEEE-MMS-SSL (IEEE Media Management System over SSL)
698 UDP OLSR (Optimized Link State Routing) Official
699 TCP Access Network Official
List of TCP and UDP port numbers
700 TCP EPP (Extensible Provisioning Protocol), a protocol for communication between domain name registries and
registrars (RFC 5734)
701 TCP
LMP (Link Management Protocol (Internet)),
a protocol that runs between a pair of nodes and is used to
manage traffic engineering (TE) links
702 TCP

(Internet Registry Information Service) over BEEP (Blocks Extensible Exchange Protocol)
(RFC 3983)
706 TCP Secure Internet Live Conferencing (SILC) Official
711 TCP
Cisco Tag Distribution Protocol


—being replaced by the MPLS Label Distribution Protocol
712 TCP Topology Broadcast based on Reverse-Path Forwarding routing protocol (TBRPF) (RFC 3684) Official
712 UDP Promise RAID Controller Unofficial
720 TCP SMQP, Simple Message Queue Protocol Unofficial
749 TCP UDP Kerberos (protocol) administration Official
750 TCP rfile Official
750 UDP loadav Official
750 UDP kerberos-iv, Kerberos version IV Official
751 TCP UDP pump Official
751 TCP UDP kerberos_master, Kerberos authentication Unofficial
752 TCP qrh Official
752 UDP qrh Official
752 UDP passwd_server, Kerberos Password (kpasswd) server Unofficial
753 TCP
Reverse Routing Header (rrh)
753 UDP Reverse Routing Header (rrh) Official
753 UDP userreg_server, Kerberos userreg server Unofficial
754 TCP tell send Official
754 TCP krb5_prop, Kerberos v5 slave propagation Unofficial
754 UDP tell send Official
760 TCP UDP ns Official
760 TCP UDP krbupdate [kreg], Kerberos registration Unofficial
782 TCP Conserver serial-console management server Unofficial
783 TCP SpamAssassin spamd daemon Unofficial
829 TCP CMP (Certificate Management Protocol) Unofficial
843 TCP
Adobe Flash socket policy server
847 TCP DHCP Failover protocol Official
860 TCP iSCSI (RFC 3720) Official
873 TCP rsync file synchronisation protocol Official
USA only
888 TCP cddbp, CD DataBase (CDDB) protocol (CDDBP)—unassigned but widespread use Unofficial
901 TCP Samba Web Administration Tool (SWAT) Unofficial
901 TCP VMware Virtual Infrastructure Client (UDP from server being managed to management console) Unofficial
901 UDP VMware Virtual Infrastructure Client (UDP from server being managed to management console) Unofficial
List of TCP and UDP port numbers
902 TCP ideafarm-door 902/tcp self documenting Door: send 0x00 for info Official
902 TCP VMware Server Console (TCP from management console to server being Managed) Unofficial
902 UDP ideafarm-door Official
902 UDP VMware Server Console (UDP from server being managed to management console) Unofficial
903 TCP
VMware Remote Console
904 TCP VMware Server Alternate (if 902 is in use, i.e. SUSE linux) Unofficial
911 TCP Network Console on Acid (NCA)—local tty redirection over OpenSSH Unofficial
953 TCP UDP Domain Name System (DNS) RNDC Service Unofficial
981 TCP SofaWare Technologies Remote HTTPS management for firewall devices running embedded Check Point
FireWall-1 software
987 TCP Microsoft This Secure Hypertext Transfer Protocol (HTTPS) port makes Windows SharePoint Services
viewable through Remote Web Workplace
989 TCP UDP FTPS Protocol (data): FTP over TLS/SSL Official
990 TCP UDP FTPS Protocol (control): FTP over TLS/SSL Official
(Netnews Administration System)
992 TCP UDP TELNET protocol over TLS/SSL Official
993 TCP Internet Message Access Protocol over SSL (IMAPS) Official
995 TCP Post Office Protocol 3 over TLS/SSL (POP3S) Official
999 TCP ScimoreDB Database System Unofficial
1001 TCP JtoMB Unofficial
1002 TCP Opsware agent (aka cogbot) Unofficial
1023 TCP UDP
Registered ports: 1024–49151
The range of port number from 1024 to 49151 are the registered ports. They are assigned by IANA for specific
service upon application by a requesting entity.
On most systems registered ports can be used by ordinary users.
UDP Description Status
1024 TCP UDP
1025 TCP NFS or IIS or Teradata Unofficial
1026 TCP Often used by Microsoft DCOM services Unofficial
1029 TCP Often used by Microsoft DCOM services Unofficial
1058 TCP UDP
nim, IBM AIX Network Installation Manager
1059 TCP UDP
nimreg, IBM AIX Network Installation Manager
1080 TCP SOCKS proxy Official
1085 TCP UDP WebObjects Official
1098 TCP UDP rmiactivation, RMI Activation Official
1099 TCP UDP rmiregistry, RMI Registry Official
List of TCP and UDP port numbers
1109 UDP
1109 TCP
1109 TCP Kerberos Post Office Protocol (KPOP) Unofficial
1110 UDP
School network discovery protocol (for Intel's CMPC platform)
1140 TCP UDP
1167 UDP phone, conference calling Unofficial
1169 TCP UDP Tripwire Official
1176 TCP
Perceptive Automation
Home automation server
1182 TCP UDP
Intelligent Transfer Protocol
1194 TCP UDP OpenVPN Official
1198 TCP UDP The cajo project Free dynamic transparent distributed computing in Java Official
1200 TCP
scol, protocol used by SCOL 3D virtual worlds server to answer world name resolution client
1200 UDP scol, protocol used by SCOL 3D virtual worlds server to answer world name resolution client
1200 UDP Steam Friends Applet Unofficial
1214 TCP Kazaa Official
1217 TCP Uvora Online Unofficial
1220 TCP QuickTime Streaming Server administration Official
1223 TCP UDP
TGP, TrulyGlobal
Protocol, also known as "The Gur Protocol" (named for Gur Kimchi of
1234 UDP VLC media player Default port for UDP/RTP stream Unofficial
1236 TCP Symantec BindView Control UNIX Default port for TCP management server connections Unofficial
1241 TCP UDP Nessus Security Scanner Official
1270 TCP UDP Microsoft System Center Operations Manager (SCOM) (formerly Microsoft Operations Manager
(MOM)) agent
1293 TCP UDP IPSec (Internet Protocol Security) Official
1301 TCP Palmer Performance OBDNet Unofficial
1309 TCP Altera Quartus jtagd Unofficial
1311 TCP Dell OpenManage HTTPS Official
1313 TCP Xbiim (Canvii server) Unofficial
1319 TCP AMX ICSP Official
1319 UDP AMX ICSP Official
1337 UDP Men and Mice DNS Official
1337 TCP Men and Mice DNS Official
1337 TCP PowerFolder P2P Encrypted File Synchronization Program Unofficial
1337 TCP WASTE Encrypted File Sharing Program Unofficial
1352 TCP
IBM Lotus Notes/Domino
(RPC) protocol
List of TCP and UDP port numbers
1387 TCP UDP
cadsi-lm, LMS International
(formerly Computer Aided Design Software, Inc. (CADSI)) LM
1414 TCP IBM WebSphere MQ (formerly known as MQSeries) Official
1417 TCP UDP Timbuktu Service 1 Port Official
1418 TCP UDP Timbuktu Service 2 Port Official
1419 TCP UDP Timbuktu Service 3 Port Official
1420 TCP UDP Timbuktu Service 4 Port Official
1431 TCP
Reverse Gossip Transport Protocol (RGTP)
, used to access a General-purpose
Reverse-Ordered Gossip Gathering System (GROGGS
) bulletin board, such as that
implemented on the Cambridge University's Phoenix system
1433 TCP MSSQL (Microsoft SQL Server database management system) Server Official
1434 TCP UDP MSSQL (Microsoft SQL Server database management system) Monitor Official
1470 TCP Solarwinds Kiwi Log Server Official
1494 TCP Citrix XenApp Independent Computing Architecture (ICA) thin client protocol Official
1500 TCP NetGuard GuardianPro firewall (NT4-based) Remote Management Unofficial
1501 UDP NetGuard GuardianPro firewall (NT4-based) Authentication Client Unofficial
1503 TCP UDP Windows Live Messenger (Whiteboard and Application Sharing) Unofficial
1512 TCP UDP Microsoft Windows Internet Name Service (WINS) Official
1513 TCP UDP Garena Garena Gaming Client Official
1521 TCP nCube License Manager Official
1521 TCP Oracle database default listener, in future releases official port 2483 Unofficial
1524 TCP UDP ingreslock, ingres Official
1526 TCP Oracle database common alternative for listener Unofficial
1533 TCP IBM Sametime IM—Virtual Places Chat Microsoft SQL Server Official
1547 TCP UDP Laplink Official
1550 Gadu-Gadu (direct client-to-client) Unofficial
1581 UDP MIL STD 2045-47001 VMF Official
1589 UDP Cisco VQP (VLAN Query Protocol) / VMPS Unofficial
1627 iSketch Unofficial
1645 TCP UDP radius auth, RADIUS authentication protocol (default for Cisco and Juniper Networks RADIUS
1646 TCP UDP radius acct, RADIUS authentication protocol (default for Cisco and Juniper Networks RADIUS
1666 TCP Perforce Unofficial
1677 TCP UDP Novell GroupWise clients in client/server access mode Official
1688 TCP Microsoft Key Management Service for KMS Windows Activation Unofficial
1701 UDP Layer 2 Forwarding Protocol (L2F) & Layer 2 Tunneling Protocol (L2TP) Official
1707 TCP Romtoc Packet Protocol (L2F) & Layer 2 Tunneling Protocol (L2TP) Unofficial
1716 TCP America's Army Massively multiplayer online game (MMO) Unofficial
1719 UDP H.323 Registration and alternate communication Official
1720 TCP H.323 Call signalling Official
List of TCP and UDP port numbers
1723 TCP UDP Microsoft Point-to-Point Tunneling Protocol (PPTP) Official
1725 UDP Valve Steam Client Unofficial
1755 TCP UDP Microsoft Media Services (MMS, ms-streaming) Official
1761 UDP cft-0 Official
1761 TCP cft-0 Official
1761 TCP Novell Zenworks Remote Control utility Unofficial
1762–1768 TCP UDP cft-1 to cft-7 Official
1801 TCP UDP Microsoft Message Queuing Official
1812 TCP UDP radius, RADIUS authentication protocol Official
1813 TCP UDP radacct, RADIUS accounting protocol Official
1863 TCP MSNP (Microsoft Notification Protocol), used by the .NET Messenger Service and a number of
Instant Messaging clients
1883 TCP UDP MQ Telemetry Transport (MQTT), formerly known as MQIsdp (MQSeries SCADA protocol) Official
1886 TCP Leonardo over IP Pro2col Ltd Unofficial
1900 UDP Microsoft SSDP Enables discovery of UPnP devices Official
1920 TCP IBM Tivoli Monitoring Console (https) Unofficial
1935 TCP Adobe Systems Macromedia Flash Real Time Messaging Protocol (RTMP) "plain" protocol Official
1947 TCP UDP SentinelSRM (hasplm), Aladdin HASP License Manager Official
1967 UDP Cisco IOS IP Service Level Agreements (IP SLAs) Control Protocol Unofficial
1970 TCP UDP
Netop Business Solutions
Netop Remote Control
1971 TCP UDP
Netop Business Solutions
Netop School
1972 TCP UDP InterSystems Caché Official
1975–1977 UDP
Cisco TCO (Documentation
1984 TCP
Big Brother
System and Network Monitor
1985 UDP Cisco HSRP Official
1994 TCP UDP Cisco STUN-SDLC (Serial Tunneling—Synchronous Data Link Control) protocol Official
1997 TCP Chizmo Networks Transfer Tool Unofficial
1998 TCP UDP Cisco X.25 over TCP (XOT) service Official
2000 TCP UDP Cisco SCCP (Skinny) Official
2001 UDP CAPTAN Test Stand System Unofficial
2002 TCP Secure Access Control Server (ACS) for Windows Unofficial
2030 Oracle Services for Microsoft Transaction Server Unofficial
2031 TCP UDP
mobrien-chat(http:// chat.mobrien. com:2031
2041 TCP Mail.Ru Agent communication protocol Unofficial
2049 UDP Network File System Official
2049 UDP shilp Official
2053 UDP lot105-ds-upd Lot105 DSuper Updates Official
2053 TCP lot105-ds-upd Lot105 DSuper Updates Official
2053 TCP knetd Kerberos de-multiplexor Unofficial
List of TCP and UDP port numbers
2056 UDP Civilization 4 multiplayer Unofficial
2073 TCP UDP DataReel Database Official
2074 TCP UDP Vertel VMF SA (i.e. App.. SpeakFreely) Official
2082 TCP Infowave Mobility Server Official
2082 TCP CPanel default Unofficial
2083 TCP Secure Radius Service (radsec) Official
2083 TCP CPanel default SSL Unofficial
2086 TCP GNUnet Official
2086 TCP WebHost Manager default Unofficial
2087 TCP WebHost Manager default SSL Unofficial
2095 TCP CPanel default Web mail Unofficial
2096 TCP CPanel default SSL Web mail Unofficial
2102 TCP UDP zephyr-srv Project Athena Zephyr Notification Service server Official
2103 TCP UDP zephyr-clt Project Athena Zephyr Notification Service serv-hm connection Official
2104 TCP UDP zephyr-hm Project Athena Zephyr Notification Service hostmanager Official
2105 TCP UDP IBM MiniPay Official
2105 TCP UDP eklogin Kerberos encrypted remote login (rlogin) Unofficial
2105 TCP UDP zephyr-hm-srv Project Athena Zephyr Notification Service hm-serv connection (should use port
2144 TCP Iron Mountain LiveVault Agent UnOfficial
2145 TCP Iron Mountain LiveVault Agent UnOfficial
2156 UDP Talari Reliable Protocol Official
2161 TCP APC Agent Official
2181 TCP UDP EForward-document transport system Official
2190 UDP TiVoConnect Beacon Unofficial
2200 UDP
Tuxanci game server
2210 UDP NOAAPORT Broadcast Network Official
2210 TCP NOAAPORT Broadcast Network Official
2210 TCP MikroTik Remote management for "The Dude" Unofficial
2211 UDP EMWIN Official
2211 TCP EMWIN Official
2211 TCP MikroTik Secure management for "The Dude" Unofficial
2212 UDP LeeCO POS Server Service Official
2212 TCP LeeCO POS Server Service Official
2212 TCP Port-A-Pour Remote WinBatch Unofficial
2219 TCP UDP NetIQ NCAP Protocol Official
2220 TCP UDP NetIQ End2End Official
2221 TCP ESET Anti-virus updates Unofficial
2222 TCP DirectAdmin default & ESET Remote Administration Unofficial
List of TCP and UDP port numbers
2223 UDP Microsoft Office OS X antipiracy network monitor Unofficial
2261 TCP UDP CoMotion Master Official
2262 TCP UDP CoMotion Backup Official
2301 TCP HP System Management Redirect to port 2381 Unofficial
2302 UDP ArmA multiplayer (default for game) Unofficial
2302 UDP Halo: Combat Evolved multiplayer Unofficial
2303 UDP ArmA multiplayer (default for server reporting) (default port for game +1) Unofficial
2305 UDP ArmA multiplayer (default for VoN) (default port for game +3) Unofficial
2369 TCP Default for BMC Software Control-M/Server—Configuration Agent, though often changed during
2370 TCP Default for BMC Software Control-M/Server—to allow the Control-M/Enterprise Manager to
connect to the Control-M/Server, though often changed during installation
2381 TCP HP Insight Manager default for Web server Unofficial
2401 TCP CVS version control system Unofficial
2404 TCP IEC 60870-5 -104, used to send electric power telecontrol messages between two systems via
directly connected data circuits
2420 UDP Westell Remote Access Official
2427 UDP Cisco MGCP Official
2447 TCP UDP ovwdb—OpenView Network Node Manager (NNM) daemon Official
2483 TCP UDP Oracle database listening for unsecure client connections to the listener, replaces port 1521 Official
2484 TCP UDP Oracle database listening for SSL client connections to the listener Official
2500 TCP THEÒSMESSENGER listening for TheòsMessenger client connections Official
2501 TCP TheosNet-Admin listening for TheòsMessenger client connections Official
2518 TCP UDP Willy Official
2525 TCP SMTP alternate Unofficial
2546 TCP UDP EVault—Data Protection Services Unofficial
2593 TCP UDP RunUO—Ultima Online server Unofficial
2598 TCP new ICA—when Session Reliability is enabled, TCP port 2598 replaces port 1494 Unofficial
2599 TCP SonicWALL Antispam traffic between Remote Analyzer (RA) and Control Center (CC) Unofficial
2610 TCP Dark Ages Unofficial
2612 TCP UDP QPasa from MQSoftware Official
2638 TCP Sybase database listener Unofficial
2700–2800 TCP KnowShowGo P2P Official
2710 TCP XBT Bittorrent Tracker Unofficial
2710 UDP XBT Bittorrent Tracker experimental UDP tracker extension Unofficial
2710 TCP Knuddels.de Unofficial
2713 TCP UDP Raven Trinity Broker Service Official
2714 TCP UDP Raven Trinity Data Mover Official
2735 TCP UDP NetIQ Monitor Console Official
List of TCP and UDP port numbers
2809 TCP corbaloc:iiop URL, per the CORBA 3.0.3 specification Official
2809 TCP IBM WebSphere Application Server (WAS) Bootstrap/rmi default Unofficial
2809 UDP corbaloc:iiop URL, per the CORBA 3.0.3 specification. Official
2868 TCP UDP Norman Proprietary Event Protocol NPEP Official
2944 UDP Megaco Text H.248 Unofficial
2945 UDP Megaco Binary (ASN.1) H.248 Unofficial
2947 TCP gpsd GPS daemon Official
2948 TCP UDP WAP-push Multimedia Messaging Service (MMS) Official
2949 TCP UDP WAP-pushsecure Multimedia Messaging Service (MMS) Official
2967 TCP Symantec AntiVirus Corporate Edition Unofficial
3000 TCP Miralix License server Unofficial
3000 TCP Cloud9 Integrated Development Environment server Unofficial
3000 UDP Distributed Interactive Simulation (DIS), modifiable default Unofficial
3001 TCP Miralix Phone Monitor Unofficial
3001 TCP Opsware server (Satellite) Unofficial
3002 TCP Miralix CSTA Unofficial
3003 TCP Miralix GreenBox API Unofficial
3004 TCP Miralix InfoLink Unofficial
3005 TCP Miralix TimeOut Unofficial
3006 TCP Miralix SMS Client Connector Unofficial
3007 TCP Miralix OM Server Unofficial
3008 TCP Miralix Proxy Unofficial
3017 TCP Miralix IVR and Voicemail Unofficial
3025 TCP netpd.org Unofficial
3030 TCP UDP NetPanzer Unofficial
3050 TCP UDP gds_db (Interbase/Firebird) Official
3051 TCP UDP Galaxy Server (Gateway Ticketing Systems) Official
3074 TCP UDP Xbox LIVE and/or Games for Windows - LIVE Official
3100 TCP HTTP used by Tatsoft as the default listen port Unofficial
3101 TCP BlackBerry Enterprise Server communication to cloud Unofficial
3128 TCP HTTP used by Web caches and the default for the Squid (software) Unofficial
3128 TCP HTTP used by Tatsoft as the default client connection Unofficial
3225 TCP UDP FCIP (Fiber Channel over Internet Protocol) Official
3233 TCP UDP WhiskerControl research control protocol Official
3235 TCP UDP Galaxy Network Service (Gateway Ticketing Systems) Official
3260 TCP iSCSI target Official
3268 TCP UDP msft-gc, Microsoft Global Catalog (LDAP service which contains data from Active Directory
3269 TCP UDP msft-gc-ssl, Microsoft Global Catalog over SSL (similar to port 3268, LDAP over SSL) Official
3283 TCP Apple Remote Desktop reporting (officially Net Assistant, referring to an earlier product) Official
List of TCP and UDP port numbers
3299 TCP SAP-Router (routing application proxy for SAP R/3) Unofficial
3300 TCP UDP Debate Gopher backend database system Unofficial
3305 TCP UDP odette-ftp, Odette File Transfer Protocol (OFTP) Official
3306 TCP UDP MySQL database system Official
3313 TCP
- File Integrity Monitoring Software
3333 TCP Network Caller ID server Unofficial
3386 TCP UDP GTP' 3GPP GSM/UMTS CDR logging protocol Official
3389 TCP UDP
Microsoft Terminal Server (RDP) officially registered as Windows Based Terminal (WBT) - Link
3396 TCP UDP Novell NDPS Printer Agent Official
3412 TCP UDP xmlBlaster Official
3455 TCP UDP [RSVP] Reservation Protocol Official
3423 TCP Xware xTrm Communication Protocol Official
3424 TCP Xware xTrm Communication Protocol over SSL Official
3478 TCP UDP STUN, a protocol for NAT traversal Official
3483 UDP Slim Devices discovery protocol Official
3483 TCP Slim Devices SlimProto protocol Official
3516 TCP UDP Smartcard Port Official
3527 UDP Microsoft Message Queuing Official
3532 TCP UDP Raven Remote Management Control Official
3533 TCP UDP Raven Remote Management Data Official
3535 TCP
SMTP alternate
3537 TCP UDP ni-visa-remote Unofficial
3544 UDP Teredo tunneling Official
3605 UDP ComCam IO Port Official
3606 TCP UDP Splitlock Server Official
3632 TCP distributed compiler Official
3689 TCP Digital Audio Access Protocol (DAAP)—used by Apple’s iTunes and AirPort Express Official
3690 TCP UDP Subversion version control system Official
3702 TCP UDP Web Services Dynamic Discovery (WS-Discovery), used by various components of Windows
3723 TCP UDP Used by many Battle.net Blizzard games (Diablo II, Warcraft II, Warcraft III, StarCraft) Unofficial
3724 UDP World of Warcraft Online gaming MMORPG Official
3724 TCP World of Warcraft Online gaming MMORPG Official
3724 TCP Club Penguin Disney online game for kids Unofficial
3784 TCP UDP Ventrilo VoIP program used by Ventrilo Unofficial
3785 UDP Ventrilo VoIP program used by Ventrilo Unofficial
3800 TCP Used by HGG programs Unofficial
3880 TCP UDP IGRS Official
List of TCP and UDP port numbers
3868 TCP SCTP Diameter base protocol (RFC 3588) Official
3872 TCP Oracle Management Remote Agent Unofficial
3899 TCP Remote Administrator Unofficial
3900 TCP
udt_os, IBM UniData UDT OS
3945 TCP UDP
EMCADS service, a Giritech
product used by G/On
3978 TCP UDP OpenTTD game (masterserver and content service) Unofficial
3979 TCP UDP OpenTTD game Unofficial
3999 TCP UDP Norman distributed scanning service Official
4000 TCP UDP Diablo II game Unofficial
4001 TCP Microsoft Ants game Unofficial
4007 TCP PrintBuzzer printer monitoring socket server Unofficial
4018 TCP UDP protocol information and warnings Official
4069 UDP
Minger Email Address Verification Protocol
4089 TCP UDP OpenCORE Remote Control Service Official
4093 TCP UDP PxPlus Client server interface ProvideX Official
4096 TCP UDP Ascom Timeplex BRE (Bridge Relay Element) Official
4100 WatchGuard Authentication Applet—default Unofficial
4111 TCP Xgrid Official
4116 TCP UDP Smartcard-TLS Official
4125 TCP Microsoft Remote Web Workplace administration Unofficial
4172 TCP UDP Teradici PCoIP Official
4201 TCP TinyMUD and various derivatives Unofficial
4226 TCP UDP Aleph One (game) Unofficial
4224 TCP Cisco Audio Session Tunneling Unofficial
4321 TCP
Referral Whois (RWhois) Protocol
4323 UDP Lincoln Electric's ArcLink/XT Unofficial
4433-4436 TCP Axence nVision Unofficial
4500 UDP IPSec NAT Traversal (RFC 3947) Official
4534 UDP Armagetron Advanced default server port Unofficial
4567 TCP Sinatra default server port in development mode (HTTP) Unofficial
4569 UDP Inter-Asterisk eXchange (IAX2) Official
4610–4640 TCP QualiSystems TestShell Suite Services Unofficial
4662 UDP OrbitNet Message Service Official
4662 TCP OrbitNet Message Service Official
4662 TCP
Default for older versions of eMule
4664 TCP Google Desktop Search Unofficial
4672 UDP
Default for older versions of eMule
4711 TCP
eMule optional web interface
List of TCP and UDP port numbers
4711 TCP McAfee Web Gateway 7 - Default GUI Port HTTP Unofficial
4712 TCP McAfee Web Gateway 7 - Default GUI Port HTTPS Unofficial
4728 TCP
Computer Associates Desktop and Server Management (DMP)/Port Multiplexer
4747 TCP Apprentice Unofficial
4750 TCP BladeLogic Agent Unofficial
4840 TCP UDP OPC UA TCP Protocol for OPC Unified Architecture from OPC Foundation Official
4843 TCP UDP OPC UA TCP Protocol over TLS/SSL for OPC Unified Architecture from OPC Foundation Official
4847 TCP UDP Web Fresh Communication, Quadrion Software & Odorless Entertainment Official
4894 TCP UDP LysKOM Protocol A Official
4899 TCP UDP Radmin remote administration tool (program sometimes used by a Trojan horse) Official
4949 TCP Munin Resource Monitoring Tool Official
4950 TCP UDP Cylon Controls UC32 Communications Port Official
4982 TCP UDP Solar Data Log (JK client app for PV solar inverters ) Unofficial
4993 TCP UDP Home FTP Server web Interface Default Port Unofficial
5000 TCP commplex-main Official
5000 TCP UPnP—Windows network device interoperability Unofficial
5000 TCP VTun—VPN Software Unofficial
5000 UDP
FlightGear multiplayer
5000 UDP VTun—VPN Software Unofficial
5001 TCP commplex-link Official
5001 TCP Slingbox and Slingplayer Unofficial
5001 TCP Iperf (Tool for measuring TCP and UDP bandwidth performance) Unofficial
5001 UDP Iperf (Tool for measuring TCP and UDP bandwidth performance) Unofficial
5002 TCP
5003 TCP UDP FileMaker Official
5004 TCP UDP,DCCP RTP (Real-time Transport Protocol) media data (RFC 3551, RFC 4571) Official
5005 TCP UDP,DCCP RTP (Real-time Transport Protocol) control protocol (RFC 3551, RFC 4571) Official
5029 TCP Sonic Robot Blast 2 : Multiplayer Unofficial
5031 TCP UDP AVM CAPI-over-TCP (ISDN over Ethernet tunneling) Unofficial
5050 TCP Yahoo! Messenger Unofficial
5051 TCP
ita-agent Symantec Intruder Alert
5060 TCP UDP Session Initiation Protocol (SIP) Official
5061 TCP Session Initiation Protocol (SIP) over TLS Official
5070 TCP
Binary Floor Control Protocol (BFCP),
published as RFC 4582, is a protocol that allows for
an additional video channel (known as the content channel) alongside the main video channel in a
video-conferencing call that uses SIP. Also used for Session Initiation Protocol (SIP) preferred
port for PUBLISH on SIP Trunk to Cisco Unified Presence Server (CUPS)
5082 TCP UDP Qpur Communication Protocol Official
5083 TCP UDP Qpur File Protocol Official
List of TCP and UDP port numbers
5084 TCP UDP EPCglobal Low Level Reader Protocol (LLRP) Official
5085 TCP UDP EPCglobal Low Level Reader Protocol (LLRP) over TLS Official
5093 UDP SafeNet, Inc Sentinel LM, Sentinel RMS, License Manager, Client-to-Server Official
5099 TCP UDP SafeNet, Inc Sentinel LM, Sentinel RMS, License Manager, Server-to-Server Official
5104 TCP
IBM Tivoli Framework NetCOOL/Impact
HTTP Service
5106 TCP A-Talk Common connection Unofficial
5107 TCP A-Talk Remote server connection Unofficial
5108 TCP VPOP3 Mail Server Webmail Unofficial
5109 TCP UDP VPOP3 Mail Server Status Unofficial
5110 TCP ProRat Server Unofficial
5121 TCP Neverwinter Nights Unofficial
5150 TCP UDP
ATMP Ascend Tunnel Management Protocol
5150 TCP UDP Malware Cerberus RAT Unofficial
5151 TCP ESRI SDE Instance Official
5151 UDP ESRI SDE Remote Start Official
5154 TCP UDP BZFlag Official
5176 TCP ConsoleWorks default UI interface Unofficial
5190 TCP ICQ and AOL Instant Messenger Official
5222 TCP
Extensible Messaging and Presence Protocol (XMPP) client connection
5223 TCP Extensible Messaging and Presence Protocol (XMPP) client connection over SSL Unofficial
5246 UDP
Control And Provisioning of Wireless Access Points (CAPWAP) CAPWAP control
5247 UDP
Control And Provisioning of Wireless Access Points (CAPWAP) CAPWAP data
5269 TCP
Extensible Messaging and Presence Protocol (XMPP) server connection
5298 TCP UDP
Extensible Messaging and Presence Protocol (XMPP) JEP-0174: Link-Local Messaging /
XEP-0174: Serverless Messaging
5310 TCP UDP Ginever.net data communication port Unofficial
5311 TCP UDP Ginever.net data communication port Unofficial
5312 TCP UDP Ginever.net data communication port Unofficial
5313 TCP UDP Ginever.net data communication port Unofficial
5314 TCP UDP Ginever.net data communication port Unofficial
5315 TCP UDP Ginever.net data communication port Unofficial
5351 TCP UDP NAT Port Mapping Protocol—client-requested configuration for inbound connections through
network address translators
5353 UDP Multicast DNS (mDNS) Official
5355 TCP UDP LLMNR—Link-Local Multicast Name Resolution, allows hosts to perform name resolution for
hosts on the same local link (only provided by Windows Vista and Server 2008)
5357 TCP UDP Web Services for Devices (WSDAPI) (only provided by Windows Vista, Windows 7 and Server
List of TCP and UDP port numbers
5358 TCP UDP WSDAPI Applications to Use a Secure Channel (only provided by Windows Vista, Windows 7
and Server 2008)
5402 TCP UDP
mftp, Stratacache OmniCast
content delivery system MFTP file sharing protocol
5405 TCP UDP NetSupport Manager Official
5421 TCP UDP NetSupport Manager Official
5432 TCP UDP PostgreSQL database system Official
5433 TCP Bouwsoft file/webserver <http://www.bouwsoft.be> Unofficial
5445 UDP Cisco Unified Video Advantage Unofficial
5450 TCP OSIsoft PI Server Client Access Unofficial
5457 TCP OSIsoft PI Asset Framework Client Access Unofficial
5458 TCP OSIsoft PI Notifications Client Access Unofficial
5495 TCP Applix TM1 Admin server Unofficial
5498 TCP Hotline tracker server connection Unofficial
5499 UDP Hotline tracker server discovery Unofficial
5500 TCP VNC remote desktop protocol—for incoming listening viewer, Hotline control connection Unofficial
5501 TCP Hotline file transfer connection Unofficial
5517 TCP Setiqueue Proxy server client for SETI@Home project Unofficial
5550 TCP Hewlett-Packard Data Protector Unofficial
5555 TCP Freeciv versions up to 2.0, Hewlett-Packard Data Protector, McAfee EndPoint Encryption
Database Server, SAP, Default for Microsoft Dynamics CRM 4.0
5556 TCP UDP Freeciv Official
5591 TCP Default for Tidal Enterprise Scheduler master-Socket used for communication between
Agent-to-Master, though can be changed
5631 TCP
pcANYWHEREdata, Symantec pcAnywhere (version 7.52 and later
5632 UDP pcANYWHEREstat, Symantec pcAnywhere (version 7.52 and later) status Official
5656 TCP IBM Sametime p2p file transfer Unofficial
5666 TCP NRPE (Nagios) Unofficial
5667 TCP NSCA (Nagios) Unofficial
5678 UDP Mikrotik RouterOS Neighbor Discovery Protocol (MNDP) Unofficial
5721 TCP UDP Kaseya Unofficial
5723 TCP Operations Manager Unofficial
5741 TCP UDP IDA Discover Port 1 Official
5742 TCP UDP IDA Discover Port 2 Official
5800 TCP VNC remote desktop protocol—for use over HTTP Unofficial
5814 TCP UDP Hewlett-Packard Support Automation (HP OpenView Self-Healing Services) Official
5850 TCP COMIT SE (PCR) Unofficial
5852 TCP Adeona client: communications to OpenDHT Unofficial
5900 TCP UDP Virtual Network Computing (VNC) remote desktop protocol (used by Apple Remote Desktop and
5912 TCP Default for Tidal Enterprise Scheduler agent-Socket used for communication between
Master-to-Agent, though can be changed
List of TCP and UDP port numbers
5938 TCP UDP
remote desktop protocol
5984 TCP UDP CouchDB database server Official
5999 TCP
file update tool
6000 TCP X11—used between an X client and server over the network Official
6001 UDP X11—used between an X client and server over the network Official
6005 TCP Default for BMC Software Control-M/Server—Socket used for communication between
Control-M processes—though often changed during installation
6005 TCP Default for Camfrog Chat & Cam Client http:/ / www.camfrog.com Unofficial
6050 TCP Brightstor Arcserve Backup Unofficial
6050 TCP Nortel Software Unofficial
6051 TCP Brightstor Arcserve Backup Unofficial
6072 TCP iOperator Protocol Signal Port Unofficial
6086 TCP PDTP—FTP like file server in a P2P network Official
6100 TCP Vizrt System Unofficial
6100 TCP Ventrilo This is the authentication port that must be allowed outbound for version 3 of Ventrilo Official
6101 TCP Backup Exec Agent Browser Unofficial
6110 TCP UDP softcm, HP Softbench CM Official
6111 TCP UDP spc, HP Softbench Sub-Process Control Official
6112 UDP "dtspcd"—a network daemon that accepts requests from clients to execute commands and launch
applications remotely
6112 TCP "dtspcd"—a network daemon that accepts requests from clients to execute commands and launch
applications remotely
6112 TCP Blizzard's Battle.net gaming service, ArenaNet gaming service, Relic gaming sercive Unofficial
6112 TCP Club Penguin Disney online game for kids Unofficial
6113 TCP Club Penguin Disney online game for kids Unofficial
6129 TCP DameWare Remote Control Official
6257 UDP WinMX (see also 6699) Unofficial
6260 TCP UDP planet M.U.L.E. Unofficial
6262 TCP Sybase Advantage Database Server Unofficial
6343 UDP SFlow, sFlow traffic monitoring Official
6346 TCP UDP gnutella-svc, gnutella (FrostWire, Limewire, Shareaza, etc.) Official
6347 TCP UDP gnutella-rtr, Gnutella alternate Official
6350 TCP UDP App Discovery and Access Protocol Official
6389 TCP EMC CLARiiON Unofficial
6432 TCP PgBouncer - A connection pooler for PostgreSQL Official
6444 TCP UDP Sun Grid Engine—Qmaster Service Official
6445 TCP UDP Sun Grid Engine—Execution Service Official
6502 TCP UDP Netop Business Solutions - NetOp Remote Control Unofficial
6503 UDP Netop Business Solutions - NetOp School Unofficial
6522 TCP Gobby (and other libobby-based software) Unofficial
List of TCP and UDP port numbers
6523 TCP Gobby 0.5 (and other libinfinity-based software) Unofficial
6543 UDP
Paradigm Research & Development
6566 TCP SANE (Scanner Access Now Easy)—SANE network scanner daemon Unofficial
6571 Windows Live FolderShare client Unofficial
6600 TCP Music Playing Daemon (MPD) Unofficial
6619 TCP UDP odette-ftps, Odette File Transfer Protocol (OFTP) over TLS/SSL Official
6646 UDP McAfee Network Agent Unofficial
6660–6664 TCP Internet Relay Chat (IRC) Unofficial
6665–6669 TCP Internet Relay Chat (IRC) Official
6679 TCP UDP Osorno Automation Protocol (OSAUT) Official
6679 TCP IRC SSL (Secure Internet Relay Chat)—often used Unofficial
6697 TCP IRC SSL (Secure Internet Relay Chat)—often used Unofficial
6699 TCP WinMX (see also 6257) Unofficial
6702 TCP Default for Tidal Enterprise Scheduler client-Socket used for communication between
Client-to-Master, though can be changed
6771 UDP Polycom server broadcast Unofficial
6789 TCP
Datalogger Support Software
Campbell Scientific Loggernet Software
6881–6887 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6888 TCP UDP MUSE Official
6888 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6889–6890 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6891–6900 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6891–6900 TCP UDP Windows Live Messenger (File transfer) Unofficial
6901 TCP UDP Windows Live Messenger (Voice) Unofficial
6901 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6902–6968 TCP UDP BitTorrent part of full range of ports used most often Unofficial
6969 TCP UDP acmsoda Official
6969 TCP BitTorrent tracker Unofficial
6970–6999 TCP UDP BitTorrent part of full range of ports used most often Unofficial
7000 TCP Default for Vuze's built in HTTPS Bittorrent Tracker Unofficial
7001 TCP Default for BEA WebLogic Server's HTTP server, though often changed during installation Unofficial
7002 TCP Default for BEA WebLogic Server's HTTPS server, though often changed during installation Unofficial
7005 TCP Default for BMC Software Control-M/Server and Control-M/Agent for Agent-to-Server, though
often changed during installation
7006 TCP Default for BMC Software Control-M/Server and Control-M/Agent for Server-to-Agent, though
often changed during installation
7010 TCP
Default for Cisco AON AMC (AON Management Console)
7025 TCP Zimbra LMTP [mailbox]—local mail delivery Unofficial
7047 TCP Zimbra conversion server Unofficial
7133 TCP Enemy Territory: Quake Wars Unofficial
List of TCP and UDP port numbers
7144 TCP Peercast Unofficial
7145 TCP Peercast Unofficial
7171 TCP Tibia Unofficial
7306 TCP Zimbra mysql [mailbox] Unofficial
7307 TCP Zimbra mysql [logger] Unofficial
7312 UDP Sibelius License Server Unofficial
7400 TCP UDP RTPS (Real Time Publish Subscribe) DDS Discovery Official
7401 TCP UDP RTPS (Real Time Publish Subscribe) DDS User-Traffic Official
7402 TCP UDP RTPS (Real Time Publish Subscribe) DDS Meta-Traffic Official
7547 TCP UDP CPE WAN Management Protocol Technical Report 069 Official
7615 TCP
ISL Online
communication protocol
7670 TCP BrettspielWelt BSW Boardgame Portal Unofficial
7676 TCP Aqumin AlphaVision Remote Command Interface Unofficial
7700 UDP P2P DC (RedHub) Unofficial
7777 TCP iChat server file transfer proxy Unofficial
7777 TCP Oracle Cluster File System 2 Unofficial
7777 TCP Windows backdoor program tini.exe default Unofficial
7777 TCP Xivio.com Chat Server Interface Unofficial
7778 TCP
Bad Trip MUD
7777-7788 UDP Unreal Tournament series default server Unofficial
7777-7788 TCP Unreal Tournament series default server Unofficial
7787-7788 TCP GFI EventsManager 7 & 8 Official
7831 TCP
Default used by Smartlaunch Internet Cafe Administration
7880 TCP UDP PowerSchool Gradebook Server Unofficial
7915 TCP
Default for YSFlight server [86]
7935 TCP
Fixed port used for Adobe Flash Debug Player to communicate with a debugger (Flash IDE, Flex
Builder or fdb).
7937-9936 TCP UDP
(Legato) Networker or Sun Solcitice Backup
8000 UDP
iRDMI (Intel Remote Desktop Management Interface)
—sometimes erroneously used instead
of port 8080
8000 TCP
iRDMI (Intel Remote Desktop Management Interface)
—sometimes erroneously used instead
of port 8080
8000 TCP Commonly used for internet radio streams such as those using SHOUTcast Unofficial
8001 TCP Commonly used for internet radio streams such as those using SHOUTcast Unofficial
8002 TCP Cisco Systems Unified Call Manager Intercluster Unofficial
8008 TCP HTTP Alternate Official
8008 TCP IBM HTTP Server administration default Unofficial
8009 TCP ajp13—Apache JServ Protocol AJP Connector Unofficial
8010 TCP XMPP File transfers Unofficial
List of TCP and UDP port numbers
8011-8014 TCP HTTP/TCP Symon Communications Event and Query Engine Unofficial
8074 TCP Gadu-Gadu Unofficial
8078 TCP UDP Default port for most Endless Online-based servers Unofficial
8080 TCP HTTP alternate (http_alt)—commonly used for Web proxy and caching server, or for running a
Web server as a non-root user
8080 TCP Apache Tomcat Unofficial
8080 UDP FilePhile Master/Relay Unofficial
8081 TCP HTTP alternate, VibeStreamer, e.g. McAfee ePolicy Orchestrator (ePO) Unofficial
8086 TCP HELM Web Host Automation Windows Control Panel Unofficial
8086 TCP Kaspersky AV Control Center Unofficial
8087 TCP Hosting Accelerator Control Panel Unofficial
8087 TCP Parallels Plesk Control Panel Unofficial
8087 UDP Kaspersky AV Control Center Unofficial
8089 TCP Splunk Daemon Unofficial
8090 TCP HTTP Alternate (http_alt_alt)—used as an alternative to port 8080 Unofficial
8100 TCP Console Gateway License Verification Unofficial
8116 UDP Check Point Cluster Control Protocol Unofficial
8118 TCP Privoxy—advertisement-filtering Web proxy Official
8123 TCP Polipo Web proxy Official
8192 TCP Sophos Remote Management System Unofficial
8193 TCP Sophos Remote Management System Unofficial
8194 TCP Sophos Remote Management System Unofficial
8200 TCP GoToMyPC Unofficial
8222 TCP
VMware Server Management User Interface
(insecure Web interface).
See also port 8333
8243 TCP UDP
HTTPS listener for Apache Synapse
8280 TCP UDP
HTTP listener for Apache Synapse
8291 TCP Winbox—Default on a MikroTik RouterOS for a Windows application used to administer
MikroTik RouterOS
8303 UDP Teeworlds Server Official
8332 TCP
Bitcoin JSON-RPC server
8333 TCP
8333 TCP
VMware Server Management User Interface
(secure Web interface).
See also port 8222
8400 TCP UDP cvp, Commvault Unified Data Management Official
8442 TCP UDP
CyBro A-bus, Cybrotech Ltd.
8443 TCP SW Soft Plesk Control Panel, Apache Tomcat SSL, Promise WebPAM SSL, McAfee ePolicy
Orchestrator (ePO)
8484 TCP UDP MapleStory Unofficial
8500 TCP UDP ColdFusion Macromedia/Adobe ColdFusion default and Duke Nukem 3D—default Unofficial
8501 TCP
[95] DukesterX —default
List of TCP and UDP port numbers
8601 TCP
Wavestore CCTV protocol [[96]]
8602 TCP UDP Wavestore Notification protocol Unofficial
8691 TCP Ultra Fractal default server port for distributing calculations over network computers Unofficial
8701 UDP SoftPerfect Bandwidth Manager Unofficial
8702 UDP SoftPerfect Bandwidth Manager Unofficial
8767 UDP TeamSpeak—default Unofficial
8768 UDP TeamSpeak—alternate Unofficial
8880 UDP cddbp-alt, CD DataBase (CDDB) protocol (CDDBP) alternate Official
8880 TCP cddbp-alt, CD DataBase (CDDB) protocol (CDDBP) alternate Official
8880 TCP WebSphere Application Server SOAP connector default Unofficial
8880 TCP Win Media Streamer to Server SOAP connector default Unofficial
8881 TCP
Atlasz Informatics Research Ltd [97] Secure Application Server
8882 TCP
Atlasz Informatics Research Ltd [97] Secure Application Server
8883 TCP UDP Secure MQ Telemetry Transport (MQTT over SSL) Official
8887 TCP HyperVM HTTP Official
8888 TCP HyperVM HTTPS Official
8888 UDP NewsEDGE server Official
8888 TCP NewsEDGE server Official
8888 TCP
Sun Answerbook dwhttpd server (deprecated by docs.sun.com
8888 TCP GNUmp3d HTTP music streaming and Web interface Unofficial
8888 TCP LoLo Catcher HTTP Web interface (www.optiform.com) Unofficial
8888 TCP D2GS Admin Console Telnet administration console for D2GS servers (Diablo 2) Unofficial
8888 TCP Earthland Relams 2 Server (AU1_2) Unofficial
8888 TCP MAMP Server Unofficial
8889 TCP MAMP Server Unofficial
8889 TCP Earthland Relams 2 Server (AU1_1) Unofficial
8983 TCP Default for Apache Solr 1.4 Unofficial
9000 TCP Buffalo LinkSystem Web access Unofficial
9000 TCP DBGp Unofficial
9000 TCP SqueezeCenter web server & streaming Unofficial
9000 UDP UDPCast Unofficial
9001 TCP UDP
ETL Service Manager
9001 Microsoft Sharepoint Authoring Environment Unofficial
9001 cisco-xremote router configuration Unofficial
9001 Tor network default Unofficial
9001 TCP DBGp Proxy Unofficial
9009 TCP UDP Pichat Server—Peer to peer chat software Official
9030 TCP Tor often used Unofficial
List of TCP and UDP port numbers
9043 TCP WebSphere Application Server Administration Console secure Unofficial
9050 TCP Tor Unofficial
9051 TCP Tor Unofficial
9060 TCP WebSphere Application Server Administration Console Unofficial
9080 UDP glrpc, Groove Collaboration software GLRPC Official
9080 TCP glrpc, Groove Collaboration software GLRPC Official
9080 TCP WebSphere Application Server HTTP Transport (port 1) default Unofficial
9090 TCP Webwasher, Secure Web, McAfee Web Gateway - Default Proxy Port Unofficial
9090 TCP Openfire Administration Console Unofficial
9090 TCP SqueezeCenter control (CLI) Unofficial
9091 TCP Openfire Administration Console (SSL Secured) Unofficial
9100 TCP PDL Data Stream Official
9101 TCP UDP Bacula Director Official
9102 TCP UDP Bacula File Daemon Official
9103 TCP UDP Bacula Storage Daemon Official
9105 TCP UDP Xadmin Control Daemon Official
9110 UDP SSMP Message protocol Unofficial
9119 TCP UDP MXit Instant Messenger Official
9191 TCP Catamount Software - PocketMoney Sync Unofficial
9293 TCP Sony PlayStation RemotePlay Unofficial
9300 TCP IBM Cognos 8 SOAP Business Intelligence and Performance Management Unofficial
9303 UDP D-Link Shareport Share storage and MFP printers Unofficial
9306 TCP Sphinx Native API Official
9312 TCP Sphinx SphinxQL Official
9418 TCP UDP git, Git pack transfer service Official
9420 TCP MooseFS distributed file system—master server to chunk servers Unofficial
9421 TCP MooseFS distributed file system—master server to clients Unofficial
9422 TCP MooseFS distributed file system—chunk servers to clients Unofficial
9535 TCP UDP mngsuite, LANDesk Management Suite Remote Control Official
9536 TCP UDP laes-bf, IP Fabrics Surveillance buffering function Official
9561 TCP UDP
Network Time System
9600 UDP Omron FINS, OMRON FINS PLC communication Official
9675 TCP UDP Spiceworks Desktop, IT Helpdesk Software Unofficial
9676 TCP UDP Spiceworks Desktop, IT Helpdesk Software Unofficial
9695 UDP
9800 TCP UDP WebDAV Source Official
9800 WebCT e-learning portal Unofficial
9875 TCP Club Penguin Disney online game for kids Unofficial
9898 UDP MonkeyCom Official
List of TCP and UDP port numbers
9898 TCP MonkeyCom Official
9898 TCP Tripwire—File Integrity Monitoring Software Unofficial
9987 UDP TeamSpeak 3 server default (voice) port (for the conflicting service see the IANA list) Unofficial
9996 TCP UDP The Palace "The Palace" Virtual Reality Chat software.—5 Official
9999 Hydranode—edonkey2000 TELNET control Unofficial
9999 TCP
Lantronix UDS-10/UDS100
RS-485 to Ethernet Converter TELNET control
9999 Urchin Web Analytics Unofficial
10000 Webmin—Web-based Linux admin tool Unofficial
10000 BackupExec Unofficial
10000 Ericsson Account Manager (avim) Unofficial
10001 TCP
Lantronix UDS-10/UDS100
RS-485 to Ethernet Converter default
10008 TCP UDP
Octopus Multiplexer, primary port for the CROMP protocol
, which provides a
platform-independent means for communication of objects across a network
10009 TCP UDP Cross Fire, a multiplayer online First Person Shooter Unofficial
10010 TCP Open Object Rexx (ooRexx) rxapi daemon Official
10017 AIX,NeXT, HPUX—rexd daemon control Unofficial
10024 TCP Zimbra smtp [mta]—to amavis from postfix Unofficial
10025 TCP Zimbra smtp [mta]—back to postfix from amavis Unofficial
10050 TCP UDP Zabbix-Agent Official
10051 TCP UDP Zabbix-Trapper Official
10113 TCP UDP NetIQ Endpoint Official
10114 TCP UDP NetIQ Qcheck Official
10115 TCP UDP NetIQ Endpoint Official
10116 TCP UDP NetIQ VoIP Assessor Official
10200 TCP
FRISK Software International's fpscand virus scanning daemon for Unix platforms
10200 TCP
FRISK Software International's f-protd virus scanning daemon for Unix platforms
10201–10204 TCP
FRISK Software International's f-protd virus scanning daemon for Unix platforms
10308 Lock-on: Modern Air Combat Unofficial
10480 SWAT 4 Dedicated Server Unofficial
10823 UDP Farming Simulator 2011 Default Server Unofficial
11211 memcached Unofficial
11235 Savage:Battle for Newerth Server Hosting Unofficial
11294 Blood Quest Online Server Unofficial
11371 OpenPGP HTTP key server Official
11576 IPStor Server management communication Unofficial
12010 TCP
ElevateDB default database port
12011 TCP Axence nVision Unofficial
12012 TCP Axence nVision Unofficial
List of TCP and UDP port numbers
12012 TCP Audition Online Dance Battle, Korea Server—Status/Version Check Unofficial
12012 UDP Audition Online Dance Battle, Korea Server—Status/Version Check Unofficial
12013 TCP UDP Audition Online Dance Battle, Korea Server Unofficial
12035 UDP
Linden Lab
viewer to sim on SecondLife
12222 UDP Light Weight Access Point Protocol (LWAPP) LWAPP data (RFC 5412) Official
12223 UDP Light Weight Access Point Protocol (LWAPP) LWAPP control (RFC 5412) Official
12345 NetBus—remote administration tool (often Trojan horse). Also used by NetBuster. Little Fighter 2
12489 TCP NSClient/NSClient++/NC_Net (Nagios) Unofficial
12975 TCP LogMeIn Hamachi (VPN tunnel software; also port 32976)—used to connect to Mediation Server
(bibi.hamachi.cc); will attempt to use SSL (TCP port 443) if both 12975 & 32976 fail to connect
12998–12999 UDP
Takenaka RDI
Mirror World on SecondLife
13000–13050 UDP
Linden Lab
viewer to sim on SecondLife
13008 TCP UDP Cross Fire, a multiplayer online First Person Shooter Unofficial
13075 TCP
for BMC Software Control-M/Enterprise Manager Corba communication, though
often changed during installation
13195-13196 TCP UDP Ontolux Ontolux 2D Unofficial
13720 TCP UDP Symantec NetBackup—bprd (formerly VERITAS) Official
13721 TCP UDP Symantec NetBackup—bpdbm (formerly VERITAS) Official
13724 TCP UDP Symantec Network Utility—vnetd (formerly VERITAS) Official
13782 TCP UDP Symantec NetBackup—bpcd (formerly VERITAS) Official
13783 TCP UDP Symantec VOPIED protocol (formerly VERITAS) Official
13785 TCP UDP Symantec NetBackup Database—nbdb (formerly VERITAS) Official
13786 TCP UDP Symantec nomdb (formerly VERITAS) Official
14439 TCP
APRS UI-View Amateur Radio
14567 UDP Battlefield 1942 and mods Unofficial
15000 TCP psyBNC Unofficial
15000 TCP Wesnoth Unofficial
15000 TCP Kaspersky Network Agent Unofficial
15000 TCP hydap, Hypack Hydrographic Software Packages Data Acquisition Official
15000 UDP hydap, Hypack Hydrographic Software Packages Data Acquisition Official
15567 UDP Battlefield Vietnam and mods Unofficial
15345 TCP UDP XPilot Contact Official
16000 TCP shroudBNC Unofficial
16080 TCP
Mac OS X Server Web (HTTP) service with performance cache
16384 UDP Iron Mountain Digital online backup Unofficial
16567 UDP Battlefield 2 and mods Unofficial
17500 TCP Dropbox LanSync Protocol (db-lsp); used to synchronize file catalogs between Dropbox clients on
your local network.
List of TCP and UDP port numbers
17500 UDP Dropbox LanSync Discovery (db-lsp-disc); used to synchronize file catalogs between Dropbox
clients on your local network; is transmitted to broadcast addresses.
18010 TCP Super Dancer Online Extreme(SDO-X)—CiB Net Station Malaysia Server Unofficial
18104 TCP RAD PDF Service Official
18180 TCP DART Reporting server Unofficial
18200 TCP UDP Audition Online Dance Battle, AsiaSoft Thailand Server—Status/Version Check Unofficial
18201 TCP UDP Audition Online Dance Battle, AsiaSoft Thailand Server Unofficial
18206 TCP UDP Audition Online Dance Battle, AsiaSoft Thailand Server—FAM Database Unofficial
18300 TCP UDP Audition Online Dance Battle, AsiaSoft SEA Server—Status/Version Check Unofficial
18301 TCP UDP Audition Online Dance Battle, AsiaSoft SEA Server Unofficial
18306 TCP UDP Audition Online Dance Battle, AsiaSoft SEA Server—FAM Database Unofficial
18400 TCP UDP Audition Online Dance Battle, KAIZEN Brazil Server—Status/Version Check Unofficial
18401 TCP UDP Audition Online Dance Battle, KAIZEN Brazil Server Unofficial
18505 TCP UDP Audition Online Dance Battle, Nexon Server—Status/Version Check Unofficial
18506 TCP UDP Audition Online Dance Battle, Nexon Server Unofficial
18605 TCP UDP X-BEAT—Status/Version Check Unofficial
18606 TCP UDP X-BEAT Unofficial
19000 TCP UDP Audition Online Dance Battle, G10/alaplaya Server—Status/Version Check Unofficial
19001 TCP UDP Audition Online Dance Battle, G10/alaplaya Server Unofficial
19226 TCP Panda Software AdminSecure Communication Agent Unofficial
19283 TCP UDP
K2 - KeyAuditor & KeyServer, Sassafras Software Inc.
Software Asset Management tools
19294 TCP
Google Talk Voice and Video connections
19295 UDP
Google Talk Voice and Video connections
19302 UDP
Google Talk Voice and Video connections
19315 TCP UDP
KeyShadow for K2 - KeyAuditor & KeyServer, Sassafras Software Inc.
Software Asset
Management tools
19638 TCP Ensim Control Panel Unofficial
19771 TCP UDP
Softros LAN Messenger
19812 TCP 4D database SQL Communication Unofficial
19813 TCP 4D database Client Server Communication Unofficial
19814 TCP 4D database DB4D Communication Unofficial
19880 TCP
Softros LAN Messenger
19999 DNP - Secure (Distributed Network Protocol - Secure), a secure version of the protocol used in
SCADA systems between communicating RTU's and IED's
20000 DNP (Distributed Network Protocol), a protocol used in SCADA systems between communicating
RTU's and IED's
20000 Usermin, Web-based user tool Unofficial
20014 TCP DART Reporting server Unofficial
20720 TCP Symantec i3 Web GUI server Unofficial
List of TCP and UDP port numbers
21001 TCP
AMLFilter, AMLFilter Inc.
amlf-admin default port
21011 TCP
AMLFilter, AMLFilter Inc.
amlf-engine-01 default http port
21012 TCP
AMLFilter, AMLFilter Inc.
amlf-engine-01 default https port
21021 TCP
AMLFilter, AMLFilter Inc.
amlf-engine-02 default http port
21022 TCP
AMLFilter, AMLFilter Inc.
amlf-engine-02 default https port
22136 TCP
FLIR Systems
Camera Resource Protocol
22222 TCP
Davis Instruments, WeatherLink IP
22347 TCP UDP
Software protection system
22350 TCP UDP
Software protection system
23073 Soldat Dedicated Server Unofficial
23399 Skype Default Protocol Unofficial
23513 Duke Nukem 3D#Source code Duke Nukem Ports Unofficial
24444 NetBeans integrated development environment Unofficial
24465 TCP UDP
Tonido Directory Server for Tonido
which is a Personal Web App and P2P platform
24554 TCP UDP BINKP, Fidonet mail transfers over TCP/IP Official
24800 Synergy: keyboard/mouse sharing software Unofficial
24842 StepMania: Online: Dance Dance Revolution Simulator Unofficial
25000 TCP Teamware Office standard client connection Official
25003 TCP Teamware Office client notifier Official
25005 TCP Teamware Office message transfer Official
25007 TCP Teamware Office MIME Connector Official
25010 TCP Teamware Office Agent server Official
25565 Minecraft Dedicated Server Unofficial
25565 MySQL Standart MySQL port Unofficial
25826 UDP
collectd default port
25888 UDP Xfire (Firewall Report, UDP_IN) IP Address ( resolves to
gameservertracking.xfire.com. Use unknown.
25999 TCP Xfire Unofficial
26000 UDP id Software's Quake server Official
26000 TCP id Software's Quake server Official
26000 TCP CCP's EVE Online Online gaming MMORPG Unofficial
26900 TCP CCP's EVE Online Online gaming MMORPG Unofficial
26901 TCP CCP's EVE Online Online gaming MMORPG Unofficial
27000 UDP (through 27006) id Software's QuakeWorld master server Unofficial
27000-27009 TCP FlexNet Publisher's License server (from the range of default ports) Unofficial
27010 Source engine dedicated server port Unofficial
27014 Source engine dedicated server port (rare) Unofficial
List of TCP and UDP port numbers
27015 GoldSrc and Source engine dedicated server port Unofficial
27016 Magicka server port Unofficial
27017 mongoDB server port Unofficial
27374 Sub7 default. Unofficial
27500 UDP (through 27900) id Software's QuakeWorld Unofficial
27888 UDP Kaillera server Unofficial
27900-27901 Nintendo Wi-Fi Connection Unofficial
27901 UDP (through 27910) id Software's Quake II master server Unofficial
27960 UDP (through 27969) Activision's Enemy Territory and id Software's Quake III Arena, Quake III and
Quake Live and some ioquake3 derived games
28000 Bitfighter Common/default Bitfighter Server Unofficial
28001 Starsiege: Tribes Common/default Tribes v.1 Server Unofficial
28395 TCP www.SmartSystemsLLC.com Used by Smart Sale 5.0 Unofficial
28785 UDP
Cube 2 Sauerbraten
28786 UDP
Cube 2 Sauerbraten Port 2
28910 Nintendo Wi-Fi Connection Unofficial
28960 UDP Call of Duty; Call of Duty: United Offensive; Call of Duty 2; Call of Duty 4: Modern Warfare;
Call of Duty: World at War (PC Version)
29000 Perfect World International Used by the Perfect World International Client Unofficial
29900-29901 Nintendo Wi-Fi Connection Unofficial
29920 Nintendo Wi-Fi Connection Unofficial
30000 Pokémon Netbattle Unofficial
30301 BitTorrent Unofficial
30564 TCP Multiplicity: keyboard/mouse/clipboard sharing software Unofficial
30718 UDP Lantronix Discovery for Lantronix serial-to-ethernet devices Unofficial
30777 TCP ZangZing agent Unofficial
31337 TCP Back Orifice—remote administration tool (often Trojan horse) Unofficial
31415 ThoughtSignal—Server Communication Service (often Informational) Unofficial
31456 TCP TetriNET IRC gateway on some servers Unofficial
31457 TCP TetriNET Official
31458 TCP TetriNET Used for game spectators Unofficial
32123 TCP x3Lobby Used by x3Lobby, an internet application. Unofficial
32245 TCP MMTSG-mutualed over MMT (encrypted transmission) Unofficial
32769 TCP FileNet RPC Unofficial
32976 TCP LogMeIn Hamachi (VPN tunnel software; also port 12975)—used to connect to Mediation Server
(bibi.hamachi.cc); will attempt to use SSL (TCP port 443) if both 12975 & 32976 fail to connect
33434 TCP UDP traceroute Official
34443 Linksys PSUS4 print server Unofficial
34567 TCP
dhanalakshmi.org EDI service
List of TCP and UDP port numbers
36963 UDP Any of the USGN online games, most notably Counter Strike 2D multiplayer (2D clone of popular
CounterStrike computer game)
37659 TCP Axence nVision Unofficial
37777 TCP Digital Video Recorder hardware Unofficial
40000 TCP UDP SafetyNET p Real-time Industrial Ethernet protocol Official
40001 TCP UDP JamesWebster port Real-time Industrial Ethernet protocol Official
41823 TCP UDP Murealm Client Unofficial
43047 TCP TheòsMessenger second port for service TheòsMessenger Official
43048 TCP TheòsMessenger third port for service TheòsMessenger Official
43594–43595 TCP Jagex, RuneScape, FunOrb, etc Unofficial
47808 TCP UDP BACnet Building Automation and Control Networks (47808
= BAC0
) Official
49151 TCP UDP
Dynamic, private or ephemeral ports: 49152–65535
The range above the registered ports contains dynamic, or private, ports that cannot be registered with IANA. It is
used for custom or temporary purposes and for automatic allocation of ephemeral ports.
[1] "Port Numbers" (http:/ / www. iana. org/assignments/ port-numbers). The Internet Assigned Numbers Authority (IANA). .
[2] compressnet/tcp (http:/ / replay. waybackmachine.org/ 19970609031515/ http:/ / www. con.wesleyan. edu/ ~triemer/network/ compressnet/
[3] CompressNET Management Utility standard port (http:// www. whatport.com/ port/2. html)
[4] CompressNET Compression Process standard port (http:/ / www. whatport.com/ port/3. html)
[5] "systat and netstat" (http:/ / etutorials. org/Networking/ network+security+assessment/ Chapter+ 5.+Assessing+ Remote+ Information+
Services/5.2+ systat+ and+netstat/ ). eTutorials. .
[6] RFC 887, Resource Location Protocol (http:/ / tools. ietf.org/ html/ rfc887)
[7] [[Internet Experiment Note|IEN 99 (ftp:// ftp.rfc-editor.org/in-notes/ ien/ ien99. txt)], NI FTP: Summary and Assessment]
[8] RFC 1476, RAP: Internet Route Access Protocol (http:/ / tools. ietf.org/ rfc/rfc1476.txt)
[9] RFC 983, ISO Transport Services on Top of the TCP (http:/ / tools. ietf.org/rfc/rfc983.txt)
[10] The Remote User Telnet Service (http:/ / tools. ietf.org/ rfc/rfc818.txt)
[11] Internet Assigned Numbers Authority (IANA) Protocol Registries, Port Numbers (http:/ / www. iana.org/assignments/ port-numbers)
[12] RFC 1413, Identification Protocol (http:// www.ietf.org/ rfc/rfc1413.txt)
[13] COM Fundamentals - Guide - COM Clients and Servers - Inter-Object Communications - Microsoft RPC (http:/ / msdn2. microsoft.com/
en-us/library/ms691207(VS. 85).aspx)
[14] RFC 1068, Background File Transfer Program (BFTP) (http:// tools.ietf. org/rfc/rfc1068.txt)
[15] RFC 1056, PCMAIL: A Distributed Mail System for Personal Computers (http:/ / tools. ietf.org/rfc/rfc1056.txt)
[16] Cisco Document ID: 7244, Understanding Simple Network Management Protocol (SNMP) Traps (http:/ / www. cisco. com/ en/ US/ tech/
tk648/ tk362/ technologies_tech_note09186a0080094aa5. shtml)
[17] NAI Antivirus FAQ (http:/ / www. nai. com/ asp_set/ anti_virus/ alerts/ faq.as)
[18] RFC 1504, [[Appletalk (http:// www. faqs. org/ rfcs/rfc1504.html)] Update-Based Routing Protocol]
[19] RFC 4409, Message Submission for Mail (http:/ / www.ietf.org/ rfc/rfc4409.txt)
[20] RFC 3620, The TUNNEL Profile (http:/ / www.ietf.org/ rfc/rfc3620.txt)
[21] INTERNET DRAFT, DHCP Failover Protocol (http:/ / www. ietf.org/proceedings/ 04mar/ I-D/draft-ietf-dhc-failover-12.txt) (expired:
September 2003)
[22] RFC 3632, VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 (http:// tools. ietf.org/rfc/rfc3632.txt)
[23] IEEE Standard (1244.3-2000) for Media Management System (MMS) Media Management Protocol (MMP) (http:/ / standards. ieee. org/
reading/ ieee/ std_public/ new_desc/ storage/ 1244. 3-2000.html)
[24] Integrated Virtualization Manager on IBM System p5 (http:/ / www.redbooks.ibm. com/ redpapers/pdfs/ redp4061.pdf)
[25] IEEE Standard (1244.2-2000) for Media Management Systems (MMS) Session Security, Authentication, Initialization Protocol (SSAIP)
(http:// standards. ieee. org/reading/ ieee/ std_public/ new_desc/ storage/ 1244. 2-2000. html)
List of TCP and UDP port numbers
[26] RFC 4204, Link Management Protocol (http:/ / www. ietf. org/rfc/rfc4204.txt)
[27] RFC 3981, IRIS: The Internet Registry Information Service (IRIS) Core Protocol (http:/ / tools.ietf.org/rfc/rfc3981.txt)
[28] Internet Registry Information Service (IRIS) (http:/ / www. verisign.com/ research/Internet_Registry_Information_Service/index.html)
[29] Internet-Draft, Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) (http:// www.
ietf.org/ proceedings/ 02nov/ I-D/draft-ietf-crisp-iris-beep-00.txt)
[30] Tag Distribution Protocol Internet-Draft (http:// tools. ietf.org/ html/ draft-doolan-tdp-spec-00)
[31] United States Patent 7286529, Discovery and tag space identifiers in a tag distribution protocol (TDP) (http:// www.patentstorm. us/
patents/ 7286529-claims. html)
[32] Cisco IOS Software Release 11.1CT New Features (http:/ / www.cisco. com/ en/ US/ products/ sw/ iosswrel/ ps1820/
prod_bulletin09186a0080091d01. html)
[33] Cisco IOS Software Releases 12.0 S, MPLS Label Distribution Protocol (LDP) (http:// www.ciscosystems. ch/ en/ US/ docs/ ios/ 12_0s/
feature/guide/ fsldp22. html#wp1517250)
[34] World Intellectual Property Organization (WIPO) WO/2004/056056, Arrangement in a Router of a Mobile Network for Optimizing Use of
Messages Carrying Reverse Routing Headers (http:/ / www. wipo. int/ pctdb/ en/ wo.jsp?wo=2004056056)
[35] http:// www. adobe. com/ devnet/ flashplayer/articles/ fplayer9_security_04.html
[36] Port 903: "Required ports for configuring an external firewall to allow ESX and VirtualCenter traffic" (http:// kb. vmware.com/ kb/
1005189), 2009-07-07. Retrieved on 2009-08-04.
[37] http:// www. ietf.org/ rfc/rfc4707.txt
[38] http:/ / www. redbooks. ibm. com/ abstracts/ sg247296. html?Open
[39] http:// www. easybits. com
[40] http:// www. autonoc. com/
[41] http:/ / www. perceptiveautomation.com/ corp/ overview.html
[42] http:/ / www. perceptiveautomation.com/ indigo/
[43] http:// www. accelenet. com/ products-technology.htm
[44] http:// www. accelenet. com/ support-technical-library.htm
[45] Brief descriptions of registered TCP and UDP ports (http:// andrew.triumf.ca/ports2/ )
[46] http:// www. vocaltec. com/
[47] Remote Procedure Call (http:// www-12. lotus. com/ ldd/ doc/ domino_notes/ 7.0/ help7_designer.nsf/
f4b82fbb75e942a6852566ac0037f284/ 490ed302dc02dc868525704a003f3429?OpenDocument)
[48] http:// www. lmsintl. com/ support/ current-releases
[49] http:/ / www. groggs.group.cam. ac. uk/protocol. txt
[50] http:// www. groggs.group.cam. ac. uk/
[51] http:/ / www. netop. com
[52] http:/ / www. cisco. com/ en/ US/ netsol/ networking_solutions_networking_basic09186a00800a3524. html
[53] http:// bb4.com
[54] http:/ / chat.mobrien.com:2031
[55] Tuxánci game (http:/ / www.tuxanci. org/server/ howto)—a multiplatform game, inspired by the Czech game Bulanci (http:// bulanci.
sleepteam. com/ ), distributed under the GNU General Public License
[56] http:/ / www. ionx.co.uk/ products/ verisys
[57] http:/ / support. microsoft.com/ kb/ 306759
[58] http:// help.godaddy. com/ article/355
[59] IBM U2 product family (http:// www-306.ibm. com/ software/ data/ u2/ )
[60] http:/ / www. giritech.com/
[61] IETF Draft of the Minger Email Address Verification Protocol (http:// tools. ietf.org/html/ draft-hathcock-minger-05#section-2)
[62] RFC 2167, Referral Whois (RWhois) Protocol (http:// tools. ietf. org/html/ rfc2167)
[63] eMule Ports (http:// www.emule-project.net/ home/ perl/help. cgi?l=1& topic_id=122&rm=show_topic)
[64] "Port Details - Port 4728" (http:// isc. sans. edu/ port.html?port=4728). SANS. .
[65] FlightGear Howto: Multiplayer (http:// wiki. flightgear.org/Howto:_Multiplayer)
[66] ARX Passersystem, Användarmanual (http:// www. assa. se/ Other/ ASSA/ Products/Broschyrer Svenska/ Passersystem/
[67] Symantec Intruder Alert product support (http:// www.symantec.com/ business/ support/ overview.jsp?pid=51971)
[68] "Binary Floor Control Protocol" (http:/ / ietfreport.isoc. org/rfc/rfc4582.txt). Internet Society IETF. November 2006. .
[69] IBM Tivoli Netcool/Impact (http:/ / www-306.ibm. com/ software/ tivoli/ products/ netcool-impact/)
[70] RFC 2107, Ascend Tunnel Management Protocol (http:// tools. ietf.org/html/ rfc2167)
[71] RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core (http:/ / tools. ietf.org/ html/ rfc3920)
[72] RFC 5415, Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification (http:/ / tools.ietf.org/html/ rfc5415)
[73] http:// xmpp.org/extensions/ xep-0174.html
[74] http:// stratacache.com/ 1!_omnicast. html
[75] pcAnywhere IP port usage (http:// service1. symantec. com/ SUPPORT/ pca. nsf/ pfdocs/ 1998122810210812)
List of TCP and UDP port numbers
[76] How to change the IP ports that pcAnywhere uses (http:/ / service1.symantec. com/ SUPPORT/ pca.nsf/ pfdocs/ 2001021417112312)
[77] TeamViewer Desktop Sharing (http:// www.teamviewer. com/ index.aspx)
[78] CVSup.org (http:// www.cvsup. org/faq.html#fwtk)
[79] http:// www. p-rd.com/ index. html
[80] prd Technologies Ltd Billing & Rating Solutions (http:// www.p-rd.com/ downloads/ PRD - history and introduction. pdf)
[81] http:/ / www. campbellsci. com/ datalogger-software
[82] Application-Oriented Networking – Cisco Systems (http:// www.cisco. com/ en/ US/ products/ ps6692/ Products_Sub_Category_Home.
[83] ISL Online (http:// www.islonline. com/ )
[84] http:// www. badtripmud.com
[85] Smartlaunch 4.1 Cyber Cafe Management Software Product Overview (http:// www. smartlaunch.net/ Download/
[86] http:// www. ysflight. com/
[87] Flex 3 – Adobe Flex 3 Help (http:// livedocs. adobe. com/ flex/3/ html/ help.html?content=debugging_02.html)
[88] Intel DMI (Desktop Management Interface) (http:// www.intel. com/ support/ tokenexpress/ pro/sb/ cs-016261.htm)
[89] Powered by Google Docs (http:// docs. google. com/ viewer?a=v&q=cache:g1tLcfWiecQJ:www.crcnetbase.com/ doi/ abs/ 10. 1201/
9781420070286. ax2+ VMware+Management+ Interface+port+TCP+UDP& hl=en& gl=us& pid=bl&
[90] VMware Communities: Change MUI ports? (http:/ / www. vmware.com/ community/ message. jspa?messageID=425783)
[91] Apache Synapse (http:/ / synapse. apache. org)
[92] Bitcoin Forum: Command Line and JSON-RPC (http:/ / www.bitcoin. org/smf/ index. php?topic=63.msg452#msg452)
[93] Bitcoin FAQ (http:/ / www. bitcoin. org/faq#How_do_I_generate_coins)
[94] http:// www. cybrotech. co. uk
[95] http:// www. dukesterx. net
[96] http:/ / www. wavestore. com/ knowledge-base
[97] http:// www. atlasz. com
[98] http:// docs. sun. com/ app/ docs
[99] ETL Electronics (http:/ / etlelectronique.com/ defaulten. aspx)
[100] http:// nts. softros. com/ server.html
[101] http:/ / www. ccnx. org
[102] Lantronix Discontinued Products / No Longer Supported (http:// www. lantronix.com/ support/ discontinued. html)
[103] Lantronix UDS-10 UDS100 User Guide (http:/ / www. lantronix.com/ pdf/ UDS10-UDS100_UG.pdf)
[104] http:/ / hoople.org/hoople/ readme. txt
[105] Manual pages - F-PROT Antivirus Support - Unix (http:// www.f-prot.com/support/ unix/ unix_manpages/ fpscand.8.html)
[106] Manual pages - F-PROT Antivirus Support - Unix (http:// www.f-prot.com/support/ unix/ unix_manpages/ f-protd.8. html)
[107] Starting and Configuring the ElevateDB Server (http:// www.elevatesoft.com/ manual?action=viewtopic& id=edb2sql&
[108] http:// wiki.secondlife. com/ wiki/ Authentication_Flow
[109] http:/ / www. takenaka. co. jp/
[110] Scheduler-Usage: Forums: Controlm-M Usage Forum Index -> Control-M Enterprise Manager (http:// www.scheduler-usage.com/
modules. php?name=Forums&file=viewtopic&t=1229)
[111] Automatic Packet Reporting System 'APRS Wiki'
[112] Mac OS X Server 10: Web service uses ports 80 and 16080 by default (http:/ / docs.info. apple.com/ article.html?artnum=106407)
[113] http:/ / www. sassafras. com/
[114] How do I allow my internal XMPP client or server to connect to the Talk service? (http:/ / code. google.com/ support/ bin/ answer.
py?hl=en& answer=62464), Google Code Help, accessed December 15, 2010.
[115] http:// messenger. softros. com
[116] http:// sourceforge.net/ projects/ amlfilter/
[117] http:// www. flir.com/
[118] http:/ / davisnet. com/ weather/products/ weather_product.asp?pnum=06555
[119] http:/ / wibu. com/ wibukey. php
[120] http:// wibu. com/ codemeter.php
[121] http:// www. tonido. com
[122] http:/ / collectd. org/wiki/ index. php/ Networking_introduction
[123] http:/ / sauerbraten. org/docs/ config.html
[124] http:// www. dhanalakshmi. org
[125] http:// www. iana. org/assignments/ port-numbers
List of TCP and UDP port numbers
External links
• User-updateable list of standard/nonstandard TCP/IP Ports and related information (http:// www. portsdb. org.
• List of selected/nonstandard TCP/IP ports and related information (http:/ / www.akerman. ca/ port-table.html)
• List of TCP/UDP ports with information about trojans and malware (http:/ / www.bekkoame. ne. jp/ ~s_ita/ port/
port1-99. html)
• Windows TCP/IP Ephemeral, Reserved, and Blocked Port Behavior (http:/ / www.microsoft.com/ technet/
community/ columns/ cableguy/ cg1205.mspx)
• Known TCP/UDP ports used by Apple software (http:// docs. info.apple. com/ article. html?artnum=106439)
• List of commonly used TCP/UDP ports in Linux (http:// tcp-udp-ports.com/ linux-ports.php)
• SANS List of only the 'preferred' service for each port/protocol combo (http:// isc. sans. org/services. html)
• SANS: Intrusion Detection FAQ: What port numbers do well-known trojan horses use? (http:/ / www.sans. org/
security-resources/ idfaq/ oddports. php)
Address Book Server
Address Book Server dates back several years before the inclusion of the feature to share contacts in 10.6 Server.
This product is based on Sync Services and synchronised contacts between network MacIntosh computers, thus
allowing the contacts to be present in the local Address Book in the same manner as any other contacts. The server
has a friendly web interface which can be used to provide access to Windows / Linux or remote users.
This product is not to be confused with the Address Book Server included in Snow Leopard Server (10.6). Unlike
Apple's offering this Address Book Server offers more features, such as a web interface and also supports 10.4 and
Address Book Server consists of two separate components. One server side package which requires installation on a
dedicated server and a client components which installs a panel in System Preferences. Once installed the server will
publish its presence on the local network using Bonjour and can be accessed via Safari bookmarks. The client
requires some basic configuration. Once enabled you contacts and calendar events can be synchronised (published)
to your server. Once published the records can be accessed via the server web interface. At this stage any other
clients can also enabled to synchronise their own local records with the server.
The basic setup of Address Book Server consist of clients periodically synchronising with the server. During
synchronisation any changes (or the entire data set) is fetched form the server, then via Sync Services compared with
the local records present on the server. Any differences between the local records and those received form the server
are sent back to the server to update the central database.
More details about Address Book Server are available on the website.
Address Book Server
Address Book Server in OS X Server
The Address Book Server in Mac OS X Server is a server that allows an organization to share contacts across many
Macintoshes and iPhones. It is based upon the CardDAV protocol
. It appears in Mac OS X 10.6. It is also open
[1] "Apple Mac OS X 10.6 (Snow Leopard) Server Operating System Review" (http:// www. macworld.com/ reviews/ product/ 405150/ review/
mac_os_x_106_snow_leopard_server. html?expand=true). Macworld. . Retrieved 5 June 2010.
[2] "Mac OS Forge - Calendar and Contacts Server" (http:// www.macosforge.org/post/ calendar-and-contacts-server/). . Retrieved 5 June
External links
• http:/ / www. addressbookserver. com
Advanced Message Queuing Protocol
The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for
message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including
point-to-point and publish-and-subscribe), reliability and security
AMQP mandates the behaviour of the messaging provider and client to the extent that implementations from
different vendors are truly interoperable, in the same way as SMTP, HTTP, FTP, etc. have created interoperable
systems. Previous attempts to standardize midleware have happened at the API level (e.g. JMS) and this did not
create interoperability
. Unlike JMS, which merely defines an API, AMQP is a wire-level protocol. A wire-level
protocol is a description of the format of the data that is sent across the network as a stream of octets. Consequently
any tool that can create and interpret messages that conform to this data format can interoperate with any other
compliant tool irrespective of implementation language.
AMQP was originally designed to provide a vendor-neutral (i.e. interoperable across multiple vendors) protocol for
managing the flow of messages across an enterprise's business systems.
AMQP is middleware to provide a point of rendezvous between back-end systems (data stores and services) and
front end systems such as end user applications. The first applications were for trading desks in the financial
industry, where real time order and market data are transmitted. Though originally used inside of enterprises, AMQP
can easily be used to move messages between organizations.
AMQP lets system architects build common messaging patterns out of a simpler underlying model. Typical
messaging patterns are: request-response, in which messages are sent to or from specific recipients,
publish-and-subscribe, in which information is distributed to a set of recipients according to various subscription
criteria, and round-robin, in which tasks are distributed fairly among a set of recipients. Realistic applications
combine these, e.g. round-robin for distributing work plus request-response for sending back responses.
The protocol specification defines a binary wire protocol used between a client and server (also known as a broker).
In addition the specification outlines a message queuing model and services that an implementation must provide.
The queuing model of AMQP provides for a wide range of messaging use-cases and further refines the functions of
the clients and brokers. The function of brokers can be usefully broken into two kinds: exchanges and message
queues. Message queues store messages, and various implementations can achieve various quality of service. For
Advanced Message Queuing Protocol
example a slow but tornado-proof message queue would keep redundant copies in multiple geographic regions while
a fast but fragile message queue might keep everything in a single process's RAM. To help improve interoperability
some of these aspects of the message queues are specified in the protocol, e.g. you can state what you need when
asking a message queue broker implementation to create a new queue.
The standard AMQP exchanges have no semantics for storing messages. They route them to queues, which store
them on behalf of recipients. Exchanges implement a range of message routing techniques: one-to-one message
passing (like email to one recipient), one-to-N (like an email list), one-to-one-of-N (like a queue for the next open
checkout), and so on. Since all exchanges accept messages from N senders, AMQP allows all one-to-any routing to
be N-to-any. The rules that configure an exchange, known as bindings, can range from very simple (pass everything
into this message queue) to procedural inspections of message content. AMQP allows arbitrary exchange semantics
through custom exchanges (which can queue, generate, consume, and route messages in any way desired by the
Messages consist of an envelope of properties used in routing and by applications and a content, of any size. AMQP
message contents are opaque binary blobs. Messages are passed between brokers and clients using the protocol
commands Basic.Publish and Basic.Deliver. These commands are asynchronous so that conditions that arise from a
command's evaluation are signalled by sending additional commands back on the channel that carried the command
originally. AMQP also provides a synchronous message delivery command, Basic.Get/Get-Ok.
Examples of error conditions include signalling by an exchange that it could not route a message because no route
was found, or signalling that a message queue declined to accept a message (say because it was full). Message
brokers may be configured to handle exceptions in different ways. For example, routing the associated message to a
dead letter queue or even bringing the broker to a hard stop.
AMQP was developed from mid-2004 to mid-2006 by JPMorgan Chase & Co. and iMatix Corporation who also
developed implementations in C/C++ and Java. JPMorgan Chase & Co. and iMatix documented the protocol as an
interoperable specification and assigned to a working group that included Red Hat, Cisco Systems, TWIST, IONA
Technologies, and iMatix. As of November 2009, the working group consists of Bank of America, Barclays, Cisco
Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Inc., Goldman Sachs, Progress Software,
iMatix Corporation, JPMorgan Chase Bank Inc. N.A, Microsoft Corporation, Novell, Rabbit Technologies Ltd., Red
Hat, Inc., Solace Systems, Tervela Inc., TWIST Process Innovations ltd, WS02 and 29West Inc.
A notable design goal of AMQP was to enable the creation of open standard protocol stacks for business messaging
both within and between firms by combining AMQP with one of the many open standards describing business
transactions, such as FpML or more generically as a reliable transport for SOAP.
Whilst AMQP originated in the financial services industry, it has general applicability to a broad range of
middleware problems.
The AMQP model
AMQP defines a number of entities. From a connection perspective the relevant ones are:
• Message broker: a server to which AMQ clients connect using the AMQ protocol. Message brokers can run in a
cluster but these details are implementation specific and are not covered by the specification.
• User: a user is an entity that, by providing credentials in form of a password, may or may not be authorized to
connect to a broker.
• Connection: a physical connection e.g. using TCP/IP or SCTP. A connection is bound to a user.
• Channel: a logical connection that is tied to a connection. Hence communication over a channel is stateful. Clients
that perform concurrent operations on a connection should maintain a distinct channel for each of those. Clients
Advanced Message Queuing Protocol
that use a threaded model of concurrency can for example encapsulate the channel declaration in a thread-local
Entities in the AMQP model used for message
The entities used for the actual sending and receiving of messages are
all declared on a channel. A declaration assures the issuing client that
the entity exists (or was previously declared by another client). Any
attempt to declare a named entity with different properties than it was
declared before will result in an error. In order to change the properties
of such an entity it must be deleted prior to a re-declaration (with
changed properties).
Some of these entities are named. The naming must be unique within
the scope of the entity and its broker. Since clients usually (at least no
such operations are defined in the AMQP specification) do not have
the means to get a list of all available named entities, the knowledge of
an entity name is what allows the client to perform operations on it.
Names are encoded in UTF-8, must be between 1 and 255 characters in length and must start with a digit, a letter or
an underscore character.
Exchanges are the entities to which messages are sent. They are named and have a type as well as properties such as:
• passive: the exchange will not get declared but an error will be thrown if it does not exist.
• durable: the exchange will survive a broker restart.
• auto-delete: the exchange will get deleted as soon as there are no more queues bound to it. Exchanges to which
queues have never been bound will never get auto deleted.
Queues are the entities which receive messages. They are named and have properties but not a type. Clients can
subscribe to queues to the effect that the message broker delivers (pushes) the contents of the queue to the client.
Alternatively clients can pop (pull) messages from the queue as they see fit.
Messages are guaranteed to be delivered in the order that they were first delivered to a queue, unless certain kinds of
rerouting operations (e.g. due to failures) occur.
The properties of queues are:
• alternate-exchange: when messages are rejected by a subscriber or orphaned by queue deletion, its messages get
routed to this exchange and get removed from the queue.
• passive: the queue will not get declared but an error will be thrown if it does not exist.
• durable: the queue will survive a broker restart.
• exclusive: there can only be one client for this specific queue.
• auto-delete: the queue will get deleted as soon as no more subscriptions are active on it. This shares the same
constraint as the auto-delete property for exchanges: if no subscription has been ever active on the queue it will
not get auto-deleted. An exclusive queue however will always get auto-deleted when the client terminates its
Note that queues are scheduled to replace exchanges in AMQP/1.0.
Advanced Message Queuing Protocol
Messages are unnamed and are published to an exchange. They consist of a header and a content body. While the
body is opaque data the header contains a number of optional properties:
• routing-key: this field is used in ways dependent on the type of the exchange.
• immediate: the message will get handled as unroutable if at least one of the queues which would receive the
message has no subscription on it.
• delivery-mode: indicates that a message might need persistence. Only for such messages the broker makes a
best-effort to prevent a loss of the message before consumption. If there is uncertainty on the broker's end about
the successful delivery of a message (e.g. in case of errors) it might deliver a message more than once. Non
persistent delivery modes do not show this kind of behavior.
• priority: an indicator (a range between 0 and 9) that a message has higher precedence than others.
• expiration: the duration in milliseconds before the broker may handle the message as unroutable.
A binding is a relationship between one queue and one exchange that specifies how messages flow from the
exchange to the queue. The binding properties match the routing algorithm used in exchanges. Bindings (and
exchange algorithms) can be placed on a curve of increasing complexity:
• Unconditional - the binding has no properties and requests "all" messages from the exchange.
• Conditional on a fixed string - the binding has one property, the routing key and requests all messages that have
an identical routing key.
• Conditional on a pattern match - the binding has one property, the routing key and requests all messages that
match the routing key using a pattern-matching algorithm. Arbitrary pattern syntaxes could be used. AMQP
implements topic matching.
• Conditional on multiple fixed strings - the binding has a table of properties, the arguments and requests all
messages whose headers match these arguments, using logical ANDs or ORs to combine matches.
• Conditional on multiple patterns - the binding has a table of properties, the arguments and requests all messages
whose headers match these arguments, using a pattern matching algorithm and logical combinations.
• Conditional on algorithmic comparison - the binding has an algorithmic expression (like an SQL SELECT
WHERE clause) and requests all messages whose headers match that expression.
• Conditional on content inspection - the binding specifies arbitrary criteria that are resolved by inspection of the
actual message content.
Not all these are implemented as standard, or by all implementations.
Exchange types and the effect of bindings
These four entities form the basic model of the AMQP. The key to understand how a message is passed to a queue
lies in the relationship between the type of an exchange and the resulting interpretation of the routing key.
An exchange will deliver up to one copy of a message to a queue if the routing key in the message matches a binding
(subsequent semantically identical bindings will not lead to duplicate copies). What constitutes a match however is
solely dependent on the type of an exchange:
• a direct exchange matches when the routing key property of a message and the key of the binding are identical.
• a fanout exchange always matches, even on bindings without a key.
• a topic exchange matches the routing key property of a message on binding key words. Words are strings which
are separated by dots. Two additional characters are also valid: the *, which matches 1 word and the #, which
matches 0..N words. Example: *.stock.# matches the routing keys usd.stock and eur.stock.db but not
Advanced Message Queuing Protocol
• a headers exchange matches on the presence of keys as well as key–value pairs which can be concatenated with
logical and–or connections in a messages header. In this case the routing key is not a criterion for matching that is
considered by the exchange. Neither does the binding carry a single routing key but special format which contains
header keys and / or key-value-pairs which match on the header key being present or the header key being present
and the value being the same respectively.
Other e.g. vendor-specific exchanges are explicitly permitted in the specification.
The concept of binding named queues to named exchanges has powerful properties (with binding making those two
entities independent of each other). It is, for instance, possible to bind a single queue with multiple bindings to the
same or to different exchanges. Or multiple consumers can share the name of a queue and bind to it with the same
parameters and will therefore get only message that the other consumers did not consume. Or multiple consumers
can declare independent queues but share the bindings and get all the message every other consumer would get on
the bound exchange with these bindings.
Specification revisions and the future of AMQP
The following specifications of the AMQ protocol have been published, in chronological order:
• 0-8 in June 2006
• 0-9 in December 2006
• 0-10 (documents are undated)
• 0-9-1 in November 2008
• 1.0 draft
in May 2010
The draft 1.0 specification changes the AMQP model illustrated above by removing the concepts of exchanges and
bindings, and replacing these with queues and links. This change aims to remedy two problems with the previous
1. The publisher needs to know too much about the receivers topology (what exchanges and exchange types are
2. Producer flow control is challenging - if an Exchange is routing a message to 2 different queues, one empty and
the other nearly full, what flow control information should be relayed to the producer and how would that be
According to John O'Hara[4] however, JPMorganChase and RedHat introduced links into AMQP/1.0 simply to solve
an operational problem of slow consumers causing memory build up in brokers.
Other changes include the introduction of a queue addressing schema similar to E-mail and XMPP. This raises
addresses to first-class entities, and allows for the publication of service location records using the DNS.
The process of bringing the 1.0 Specification to a Standard involves a requirement elicitation phase, then the release
of a "public review" spec (PR) which should be reviewed and asked for comments, optionally resulting in further
modifications. When there are no substantive changes to the PR, it is voted to be the 1.0 Recommendation. When
there are at least two implementations that pass a special test coverage, the Recommendation is voted to be 1.0
. As of 29-Dec-2010, a Recommendation spec has been produced and is waiting for two or more
implementations proven to interoperate
Advanced Message Queuing Protocol
These are the known publicly available AMQP implementations:
• OpenAMQ
, an open-source implementation of AMQP, written in C by iMatix. Runs on Linux, AIX, Solaris,
Windows, OpenVMS. APIs in C/C++ and Java JMS. Discontinued by iMatix
after their switching to ØMQ.
• StormMQ, currently the only message queuing service using AMQP. Offered as a managed service, there is no
software to install and no licence fees to pay. Customers pay for a subscription out of OPEX, and use a solution in
the Cloud, Co-Hosted or On-Site.
• RabbitMQ, an independent open-source implementation bought by VMware in 2010. The server is written in
• Apache Qpid, a project in the Apache Foundation. Bindings to many languages without the use of DLLs.
• Red Hat Enterprise MRG
implements the latest version of AMQP 0-10 providing rich set of features like full
management, federation, Active-Active clustering using Apache Qpid as upstream, adds a web console and many
enterprise features. Also available in the latest 3 versions of Fedora as AMQP Infrastructure
Other Products Integrating with AMQP
There are many integrations of other products with AMQP, including:
• Zyre
, a broker that implements RestMS
and AMQP to provide RESTful HTTP access to AMQP
There are many clients, including:
, a Common Lisp client library for AMQP.
• libamqp
a C client for AMQP 1.0.
Comparative specifications
These are the known open specifications that cover the same or similar space as AMQP:
• Stomp, a text-based pub-sub protocol developed at Codehaus; uses the JMS-like semantics of 'destination'.
• RestMS
, an HTTP-based message routing and queuing protocol that provides AMQP interoperability through
an optional profile.
• XMPP, the Extensible Messaging and Presence Protocol.
There are also vendor specific, proprietary specifications includes those by the Amazon Simple Queue Service, IBM
WebSphere MQ, Microsoft Message Queuing, JMS and the OpenWire as used by ActiveMQ.
There has not as yet been a formal comparison of these and other protocols in the same space, although an informal
comparison of XMPP and AMQP may be found here
. JMS, the Java Messaging service, is often compared to
AMQP. However, JMS is an API specification (part of the Java EE specification) that defines how message
producers and consumers are implemented. JMS does not guarantee interoperability between implementations, and
the JMS-compliant messaging system in use may need to be deployed on both client and server. On the other hand,
AMQP is a wire-level protocol specification. In theory AMQP provides interoperability as different
AMQP-compliant software can be deployed on the client and server sides. Note that, like HTTP and XMPP, AMQP
does not have a standard API.
Advanced Message Queuing Protocol
[1] O'Hara, J. (2007). "Toward a commodity enterprise middleware" (http:// www.acm.org/ acmqueue/ digital/ Queuevol5no4_May2007.pdf).
Acm Queue 5: 48–55. doi:10.1145/1255421.1255424. .
[2] Vinoski, S. (2006). "Advanced Message Queuing Protocol" (http:/ / steve. vinoski.net/ pdf/IEEE-Advanced_Message_Queuing_Protocol.
pdf). Ieee Internet Computing 10: 87–89. doi:10.1109/MIC.2006.116. .
[3] http:/ / www. amqp.org/confluence/ download/ attachments/ 4489238/ amqp-1-0-recommendation-draft.pdf?version=1&
[4] http:// lists. amqp. org/ pipermail/amqp-pmc/2010-May/ 001319. html
[5] http:// www. amqp.org/confluence/ display/ AMQP/ Process+ SIG
[6] http:// www. amqp.org/confluence/ display/ AMQP/ AMQP+ Specification
[7] http:// www. openamq. org/
[8] http:/ / www. h-online.com/ open/ news/ item/ iMatix-to-drop-OpenAMQ-support-by-2011-968262.html
[9] http:// www. redhat.com/ mrg
[10] http:// fedoraproject.org/ wiki/ Features/ AMQP_Infrastructure
[11] http:// www. zyre.com/
[12] http:/ / www. restms. org
[13] http:// github.com/ lisp/ de. setf. amqp
[14] http:/ / libamqp.org
[15] http:/ / www. restms. org/
[16] http:// www. opensourcery. co. za/ 2009/04/ 19/ to-amqp-or-to-xmpp-that-is-the-question/
External links
• AMQP Website (http:/ / www.amqp.org/)
• Original background whitepaper (http:// www.openamq. org/doc:amqp-background)
• OMG Analysis of AMQP and comparison with DDS-RTPS (http:/ / www.omg. org/news/ meetings/ workshops/
• Google Tech Talk, with video and slides, about RabbitMQ (http:/ / google-ukdev.blogspot. com/ 2008/ 09/
• Presentation of AMQP and RestMS messaging at FOSDEM 2009 (http:/ / www.slideshare. net/ pieterh/
• What is wrong with AMQP (and how to fix it) (http:// www.imatix. com/ articles:whats-wrong-with-amqp) —
iMatix secession reasons
• List of AMQP clients (http:/ / www. delicious. com/ alexisrichardson/ AMQP+ client)
Aggregate Server Access Protocol
Aggregate Server Access Protocol
The Aggragate Server Access Protocol is used by the Reliable server pooling (RSerPool) framework for the
communication between
• Pool Elements and Pool Registrars (Application Layer),
• Pool Users and Pool Registrars (Application Layer),
• Pool Users and Pool Elements (Session Layer).
Standards Documents
• Aggregate Server Access Protocol (ASAP)
• Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
• Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
• Reliable Server Pooling Policies
External links
• Thomas Dreibholz's Reliable Server Pooling (RSerPool) Page
• IETF RSerPool Working Group
[1] http:/ / tools. ietf.org/html/ rfc5352
[2] http:// tools. ietf.org/html/ rfc5354
[3] http:// tools. ietf.org/html/ rfc5355
[4] http:// tools. ietf.org/html/ rfc5356
[5] http:// tdrwww.iem. uni-due. de/ dreibholz/rserpool/
[6] http:/ / www. ietf.org/ old/ 2009/ html. charters/OLD/ rserpool-charter.html
Control plane protocol for the transport layer in 3rd Generation UMTS networks is called ALCAP (Access Link
Control Application Part). ALCAP is defined by 3GPP as equivalent of ITU recommendation Q.2630.2. Basic
functionality of ALCAP is multiplexing of different users onto one AAL2 transmission path using channel IDs
(CIDs). It is used in the UMTS access network UTRAN along with ATM, while IPBCP is use for IP links in the core
of the network.
ALCAP makes it possible for up to 248 channels to be multiplexed onto one AAL2 bearer.
Protocol Stack
| SAAL |
| AAL5 |
| ATM |
| Physical layer |
Access Link Control Application Part (ALCAP)
ALCAP is the protocol used for control plane of transport layer UMTS in charge of managing and multiplexing
users into ATM AAL2 virtual connections. ALCAP is specified for Iub, Iur and Iu (circuit switched domain)
interfaces. This protocol is only used when these interfaces are ATM-based. The ITU-T Q.2630.2 standard, AAL
type 2 signalling protocol - Capability Set 2, is chosen for ALCAP protocol.
For Iub and Iur interfaces, ALCAP is specified in 3GPP TS 25.426. For Iu interface, ALCAP is specified in 3GPP
TS 25.414.
Protocol dependencies
* STC: Signalling Transport Converter
SSCOP: the SAAL sublayer that transports ALCAP signaling messages.
SSCF-NNI, MTP3b: additional layers applicable only for Iur and Iu interfaces.
Anti-replay is a sub protocol of IPsec which is part of Internet Engineering Task Force (IETF). The main goal of
anti-replay is to avoid hackers injecting or making changes in packets that travel from a source to a destination.
Anti-replay protocol uses a unidirectional security association in order to establish a secure connection between two
nodes in the network. Once a secure connection is established, anti-replay protocol will use a sequence number or a
counter. When the source sends a message it adds a sequence number to its packet starting at 0 and increments
everytime it sends another message. The other end, which is the destination, receives the message and keeps a
history of the number and shifts it as the new number. If the next message has a lower number the destination will
drop the packet, and if the number is larger than the previous one it keeps and shifts it as the new number and so

[1] Szigeti, Tim; 9794,, CCIE No., Hattingh, Christina (2005). End-to-end QoS network design : Quality of service in LANs, WANs, and VPNs.
Indianapolis, IN: Cisco Press. pp. 732. ISBN 1-58705-176-1.
[2] Lee, Donald C. (1999). Enhanced IP services for Cisco networks. Indianapolis, IN, USA: Cisco Press. pp. 386. ISBN 1-57870-106-6.
Any-source multicast
Any-source multicast (ASM) is the more traditional form of multicast where you can have multiple senders on the
same group/channel, as opposed to source-specific multicast where a single particular source is specified.
Apache Wave
Apache Wave
Apache Wave
Original author(s) Google
Developer(s) Apache Software Foundation, Google
Initial release May 27, 2009
Platform Cross-platform
Type Web application/protocol
Apache License (only Google Wave Federation Prototype Server
and ConsoleClient
http:/ / wave. google. com
Apache Wave is a software framework centered on online real-time collaborative editing, originally developed by
Google as Google Wave.
It was first announced at the Google I/O conference on May 27, 2009.

Wave is a web-based computing platform and communications protocol, designed to merge key features of media
like e-mail, instant messaging, wikis, and social networking.
Communications using the system can be
synchronous and/or asynchronous, depending on the preference of individual users. Software extensions provide
contextual spelling/grammar checking, automated translation among 40 languages,
and numerous other features.
Initially released only to developers, a preview release of Google Wave was extended to 100,000 users in September
2009, each allowed to invite additional users. Google accepted most requests submitted starting November 29, 2009,
soon after the September extended release of the technical preview. On May 19, 2010, Google Wave was released to
the general public.
On August 4, 2010, Google announced the suspension of stand-alone Wave development and the intent of
maintaining the web site at least for the remainder of the year.
Development was handed over to the Apache
Software Foundation which started to develop a server based product called Wave in a box


Origin of name
The science fiction television series Firefly provided the inspiration for the project's name.
In the series, a wave is
an electronic communication, often consisting of a video call or video message.
During the developer preview, a
number of references were made to the series, such as Lars Rasmussen replying to a message with "shiny", a word
commonly used in the series to mean cool or good, and the crash message of Wave being a popular quotation from
the series: "Curse your sudden but inevitable betrayal!"

Another common error message, "Everything's shiny,
Cap'n. Not to fret!" is a quote from Kaylee Frye in the 2005 motion-picture Firefly continuation, Serenity, and it is
matched with a sign declaring that "This wave is experiencing some turbulence and might explode. If you don't want
to explode..." which is another reference to the opening of the film.
During an event in Amsterdam, Netherlands,
it became apparent that the 60-strong team that was currently
working on Wave in Sydney, Australia, use Joss Whedon-related references to describe, among others, the sandbox
version of Wave, called Dollhouse after the TV-series by Firefly producer Joss Whedon, which was aired on Fox in
the U.S. The development of external extensions is codenamed "Serenity", after the spaceship used in Firefly and
Apache Wave
Open source
Google released most of the source code as open source software,
allowing the public to develop its features
through extensions.
Google allowed third-parties to build their own Wave services (be it private or commercial)
because it wanted the Wave protocol to replace the e-mail protocol.


Initially, Google was the only Wave
service provider, but it was hoped that other service providers would launch their own Wave services, possibly
designing their own unique web-based clients as is common with many email service providers. The possibility also
existed for native Wave clients to be made, as demonstrated by Google with their CLI-based console client.
Google released initial open-source components of Wave:
1. the operational transformation (OT) code,
2. the underlying wave model, and
3. a basic client/server prototype that uses the wave protocol
In addition, Google provided some detail about later phases of the open-source release:
1. wave model code that is a simplified version of Google's production code and is tied to the OT code; this code
will evolve into the shared code base that Google will use and expects that others will too
2. a testing and verification suite for people who want to do their own implementation (for example, for porting the
code to other languages)
Reception and end of development
During the initial launch of Google Wave, invitations were widely sought by users, and were sold on auction
Those receiving invitations and trialing it could not communicate with their contacts on their regular email
accounts. Unfortuitously, the initial spread of Wave was very restricted.
Google Wave still received positive press coverage for its potential uses.

On August 4, 2010, however,
Google announced that Wave would no longer be developed as a stand-alone product, due to lack of interest.
Google later clarified that the Wave service would be available indefinitely until Google Docs was capable of
accessing saved waves
A response to the news of the end of development came from supporting Wave users in the form of a website.
Since Google's announcement in early August, the website has recorded over 49,000 supporter registrations urging
Google Wave's continuation.
The disappointment and frustration of Wave's premature discontinuation was not limited to its fan base. The team
leader of the Google Wave development group, Lars Rasmussen, a talented software developer who had already
headed the development of Google Maps and had presented Google Wave to the world for the first time at the
Google I/O launch
, quit Google for rival Facebook shortly after the announcement that it would be

Apache Wave
Google Wave was accepted by the Apache Foundation's Incubator program under the project name Apache Wave.
The Google Wave Developer blog was updated with news of the change on December 6, 2010.
A Wave Proposal
page with details on the projects goals was created on the Apache Foundation's Incubator Wiki.
Google Wave was a new Internet communications platform. It was written in Java using OpenJDK and its web
interface used the Google Web Toolkit. Google Wave works like previous messaging systems such as email and
Usenet, but instead of sending a message along with its entire thread of previous messages, or requiring all responses
to be stored in each user's inbox for context, message documents (referred to as waves) that contain complete threads
Apache Wave
of multimedia messages (blips) are perpetually stored on a central server. Waves are shared with collaborators who
can be added or removed from the wave at any point during a wave's existence.
Waves, described by Google as "equal parts conversation and document", are hosted XML documents that allow
seamless and low latency concurrent modifications.
Any participant of a wave can reply anywhere within the
message, edit any part of the wave, and add participants at any point in the process. Each edit/reply is a blip and
users can reply to individual blips within waves. Recipients are notified of changes/replies in all waves in which they
are active and, upon opening a wave, may review those changes in chronological order. In addition, waves are live.
All replies/edits are visible in real-time, letter-by-letter, as they are typed by the other collaborators. Multiple
participants may edit a single wave simultaneously in Google Wave. Thus, waves can function not only as e-mails
and threaded conversations but also as an instant messaging service when many participants are online at the same
time. A wave may repeatedly shift roles between e-mail and instant messaging depending on the number of users
editing it concurrently. The ability to show messages as they are typed can be disabled, similar to conventional
instant messaging.
The ability to modify a wave at any location lets users create collaborative documents, edited in a manner akin to
wikis. Waves can easily link to other waves. It is in many respects a more advanced forum.
A wave can be read
and known to exist by only one person, or by two or more. It can also be public, available for reading and writing to
everyone on the Wave.
The history of each wave is stored within it. Collaborators may use a playback feature in Google Wave to observe
the order in which a wave was edited, blips that were added, and who was responsible for what in the wave.

history may also be searched by a user to view and/or modify specific changes, such as specific kinds of changes or
messages from a single user.
Google will stop wave services soon, it has already put an end to the development activities."Wave has not seen the
user adoption we would have liked," Senior Vice President Urs Holzle said in the blog post. "We don't plan to
continue developing Wave as a standalone product, but we will maintain the site, at least through the end of the year,
and extend the technology for use in other Google projects."
Extension programming interface
Google Wave is extensible through an application programming interface (API). It provides extensions in the form
of Gadgets and Robots, and is embeddable by dropping interactive windows into a given wave on external sites, such
as blog sites.

The last version of robots API is 2.0.
Google Wave also supports extension installers, which bundle back-end elements (robots and gadgets) and front-end
user interface elements into an integrated package. Users may install extensions directly within the Wave client using
an extension installer.
Apache Wave
Google Wave extensions are add-ins that may be installed on Google Wave to enhance its functionality. They may
be Internet bots (robots) to automate common tasks, or gadgets to extend or change user interaction features, e.g.,
posting blips on microblog feeds or providing RSVP recording mechanisms.


Over 150 Google Wave extensions have been developed either in the form of Gadgets or Robots.
A robot is an automated participant on a wave. They read the contents of a wave in which it participates, modify the
wave's contents, add or remove participants, and create new blips and new waves. Robots perform actions in
response to events. For example, a robot might publish the contents of a wave to a public blog site and update the
wave with user comments.
Robots may be added as participants to the Wave itself (they may appear as a contact person in the wave). In theory,
a robot can be added anywhere a human participant can be involved.
Gadget extensions are applications that run within the wave, and to which all participants have access. Robots and
Gadgets can be used together, but they generally serve different purposes. A gadget is an application users could
participate with, many of which are built on Google’s OpenSocial platform. A good comparison would be iGoogle
gadgets or Facebook applications.
The gadget is triggered based on the user action. They can be best described as applications installed on a mobile
phone. For example, a wave might include a sudoku gadget that lets the wave participants compete to see who can
solve the puzzle first.
Gadgets may be added to individual waves and all the participants share and interact with the gadget.
Federation Protocol
Google Wave provides federation using an extension of XMPP, the open Wave Federation Protocol. Being an open
protocol, anyone can use it to build a custom Wave system and become a wave provider.
The use of an open
protocol is intended to parallel the openness and ease of adoption of the e-mail protocol and, like e-mail, allow
communication regardless of provider. Google hopes that waves may replace e-mail as the dominant form of Internet


In this way, Google intends to be only one of many wave providers.


It can also
be used as a supplement to e-mail, instant messaging, FTP, etc.
A key feature of the protocol is that waves are stored on the service provider's servers instead of being sent between
users. Waves are federated; copies of waves and wavelets are distributed by the wave provider of the originating user
to the providers of all other participants in a particular wave or wavelet so all participants have immediate access to
up-to-date content. The originating wave server is responsible for hosting, processing, and concurrency control of

The protocol allows private reply wavelets within parent waves, where other participants have no
access or knowledge of them.

Security for the communications is provided via Transport Layer Security authentication, and encrypted connections
and waves/wavelets are identified uniquely by a service provider's domain name and ID strings. User-data is not
federated, that is, not shared with other wave providers.
Apache Wave
Adoption of Wave Protocol and Wave Federation Protocol
Besides Apache Wave itself, there are other open-source variants of servers and clients with different percentage of
Wave Federation and Wave Protocol support, like PyOfWave.
Wave also has been adopted for corporate applications by Novell for Novell Pulse,
and by SAP for Cloudave.
Compatible third-party servers
The following servers are compatible with the Google Wave protocol:
• PyOfWave formerly known as PyGoWave. Is an ongoing open-source initiative in creating easy customizable
and independent Wave Protocol server and clients written with help of Python, Javascript and last HTML5
• PyGoWave is a first open-source implementation of Wave Protocol server and web client, first released before
Google Wave became open-sourced, written mainly in Python. Now seems to be obsolete.

• Novell Vibe formerly known as Novell Pulse
• SAP StreamWork SAP Streamwork is a collaboration decision making service

• WaveLook Server a wave protocol server that integrates with the desktop client
Compatible third-party clients
The following desktop clients are compatible with the Google Wave protocol:
• Wavelook a Wave desktop client that integrates with Microsoft Outlook
[1] http:/ / code.google. com/ p/ wave-protocol/
[2] http:/ / code.google. com/ p/ wave-protocol/wiki/ ConsoleClient
[3] http:/ / wave.google. com/
[4] Google (2009). "Google Wave Overview". "[A] new web application for real-time communication and collaboration."
[5] TechCrunch (May 28, 2009): Google Wave Drips With Ambition. A New Communication Platform For A New Web. (http:// www.
techcrunch.com/2009/ 05/ 28/ google-wave-drips-with-ambition-can-it-fulfill-googles-grand-web-vision/)
[6] "I/O Conference Google Wave Keynote" (http:// www. youtube. com/ watch?v=v_UyVmITiYQ). Google. .
[7] "About Google Wave" (http:// wave. google. com/ help/ wave/ about.html). Google. .
[8] "Google Wave Developer Blog" (http:/ / googlewavedev.blogspot. com/ 2009/ 05/ introducing-google-wave-apis-what-can.html). Google. .
[9] Shankland, Stephen. (2010-05-19) Google Wave: Now open to the public | Deep Tech – CNET News (http:// news. cnet. com/
8301-30685_3-20005394-264. html). News.cnet.com. Retrieved on 2010-12-14.
[10] Official Google Blog: Update on Google Wave (http:// googleblog. blogspot.com/ 2010/ 08/ update-on-google-wave.html).
Googleblog.blogspot.com (2010-04-08). Retrieved on 2010-12-14.
[11] http:/ / www. waveprotocol. org/wave-in-a-box
[12] Meyer, David. (2010-09-03) Google puts open-source Wave in a 'box' | Application Development | ZDNet UK (http:// www. zdnet. co. uk/
news/application-development/2010/ 09/ 03/ google-puts-open-source-wave-in-a-box-40089999/). Zdnet.co.uk. Retrieved on 2010-12-14.
[13] Google Wave inte ute ur leken (http:// www. idg. se/ 2. 1085/ 1. 355483/ google-wave-inte-ute-ur-leken). IDG.se. Retrieved on 2010-12-14.
[14] Murphy, David. (1970-01-01) Google Spins Wave Into 'Wave in a Box' for Third-Party Use | News & Opinion (http:// www. pcmag.com/
article2/ 0,2817,2368730,00.asp). PCMag.com. Retrieved on 2010-12-14.
[15] Cochrane, Nate (2009-05-29). "Opinion: Google's wave drowns the bling in Microsoft's Bing" (http:// www.itnews. com.au/ News/
104396,opinion-googles-wave-drowns-the-bling-in-microsofts-bing.aspx). IT News Australia. . Retrieved 2009-06-03.
[16] Originally said by Wash at 6:36, in Serenity; Firefly: The Complete Series (Blu-ray), 2008, 20th Century Fox.
[17] Rottmann, Ralf (October 30, 2009). "Google Wave to be opened for federation today!" (http:// thenextweb.com/ appetite/ 2009/ 10/ 30/
breaking-google-wave-opened-federation-today-host/ ). The Next Web. .
[18] Google Wave Federation Architecture – Google Wave Federation Protocol (http:// www.waveprotocol.org/whitepapers/
google-wave-architecture). Waveprotocol.org. Retrieved on 2010-12-14.
[19] Google Wave Client-Server Protocol – Google Wave Federation Protocol (http:// www. waveprotocol.org/whitepapers/
internal-client-server-protocol). Waveprotocol.org. Retrieved on 2010-12-14.
[20] "Google Wave Federation Protocol and Open Source Updates" (http:// groups. google. com/ group/wave-protocol/browse_thread/ thread/
618ff4e9ef477e80?pli=1). Google. .
Apache Wave
[21] "Google Wave Federation Protocol and Open Source Updates" (http:// googlewavedev.blogspot. com/ 2009/ 07/
google-wave-federation-protocol-and.html). Google. .
[22] Google Wave Invite Selling for $70 on eBay (http:// mashable. com/ 2009/ 09/ 30/ google-wave-invite/)
[23] Google Wave to get its own App Store (Engadget) (http:/ / www. engadget.com/ 2009/ 10/ 27/ google-wave-to-have-its-own-app-store/)
[24] CNET Predictions for 2010 (http:// asia. cnet. com/ blogs/ tokyo-shift/post. htm?id=63015591)
[25] ZDNet on GW's death (http:/ / www.zdnet. com/ blog/ google/ how-will-google-wave-be-reincarnated/2344)
[26] http:/ / www. google. com/ support/ wave/ bin/ answer. py?answer=1083134
[27] '"Save Google Wave" Site Forms' (http:// www.webpronews.com/ topnews/ 2010/ 08/ 09/ save-google-wave-site-forms)
[28] Save Google Wave! (http:// www.savegooglewave. com). Save Google Wave!. Retrieved on 2011-05-14.
[29] (http:// en.wikipedia. org/ wiki/ Lars_Rasmussen_(software_developer))
[30] Hutcheon, Stephen: Why I quit Google to join Facebook: Lars Rasmussen (http:// www.smh. com.au/ technology/ biz-tech/
why-i-quit-google-to-join-facebook-lars-rasmussen-20101101-1799q. html), The Sydney Morning Herald, 1 November 2010.
[31] North, Alex. (2010-12-06) Google Wave Developer Blog: Introducing Apache Wave (http:// googlewavedev.blogspot. com/ 2010/ 12/
introducing-apache-wave.html). Googlewavedev.blogspot.com. Retrieved on 2010-12-14.
[32] WaveProposal – Incubator Wiki (http:// wiki. apache. org/ incubator/WaveProposal). Wiki.apache.org (2010-11-24). Retrieved on
[33] Google Wave Operational Transformation – Google Wave Federation Protocol (http:// www. waveprotocol.org/ whitepapers/
operational-transform). Waveprotocol.org. Retrieved on 2010-12-14.
[34] Google Wave Review (http:// variableghz.com/ 2009/ 10/ google-wave-review/). VariableGHz (2009-10-13). Retrieved on 2010-12-14.
[35] "Google Wave API – Google Code" (http:/ / code. google.com/ apis/ wave/ ). Google. .
[36] "Introducing Robots API v2: The Rise of Active Robots" (http:/ / googlewavedev.blogspot. com/ 2010/ 03/
introducing-robots-api-v2-rise-of. html). Google. .
[37] Google Wave Samples Gallery (http:// wave-samples-gallery. appspot. com/ ). Wave-samples-gallery.appspot.com. Retrieved on
[38] "Google Wave Federation Protocol" (http:// www. waveprotocol. org/). Google. .
[39] Novell Vibe cloud service (http:// www.novell. com/ products/ pulse/ ). Novell.com. Retrieved on 2010-12-14.
[40] Elliott, Timo. (2009-10-19) SAP’s Gravity Prototype: Business Collaboration Using Google Wave (http:/ / www.cloudave. com/ link/
sap-gravity-prototype-business-collaboration-using-google-wave). Cloudave.com. Retrieved on 2010-12-14.
[41] PyOfWave on GitHub (https:// github. com/ alcinnz/ pyofwave). Retrieved on 2011-04-12.
[42] About auf PyGoWave Blog (http:// pygowave. net/ blog/ ?page_id=2). Pygowave.net. Retrieved on 2010-12-14.
[43] Want Google Wave Now? PyGoWave’s the Next Best Thing (http:// mashable. com/ 2009/ 07/ 26/ pygowave-google-wave/)
[44] Novell Vibe (http:// www.novell. com/ promo/ vibe. html). Novell.com (2009-12-31). Retrieved on 2010-12-14.
[45] Williams, Alex. (2010-05-17) SAP StreamWork Integrates With Google Wave – ReadWriteCloud (http:/ / www.readwriteweb.com/ cloud/
2010/05/ sap-streamworks-integrates-wit.php). Readwriteweb.com. Retrieved on 2010-12-14.
[46] How It Works | SAP® StreamWork™ (http:/ / www. sapstreamwork. com/ how-it-works/). Sapstreamwork.com. Retrieved on 2010-12-14.
[47] WaveLook Server – Wave Server for Enterprise (http:// wavelook.com/ server.html). Wavelook.com. Retrieved on 2010-12-14.
[48] WaveLook (http:// wavelook. com/ ). WaveLook. Retrieved on 2010-12-14.
External links
• Google Wave (http:// wave. google. com/ )
• Google Wave API (http:/ / code. google.com/ apis/ wave/ )
• Google Wave Developer Blog (http:/ / googlewavedev. blogspot. com/ )
• Full Video of the Developer Preview at Google IO (http:// www.youtube. com/ watch?v=v_UyVmITiYQ)
(80mins) on YouTube
• Google Wave overview video (http:/ / www. youtube. com/ watch?v=p6pgxLaDdQw) (7:52 mins) on YouTube
• Google Wave Federation Protocol Home Page (http:// www.waveprotocol.org/)
AppleTalk Echo Protocol
AppleTalk Echo Protocol
AEP (AppleTalk Echo Protocol) is a transport layer protocol in the AppleTalk protocol suite designed to test the
reachability of network nodes. AEP generates packets to be sent to the network node and is identified in the Type
field of a packet as an AEP packet. The packet is first passed to the source DDP. After it is identified as an AEP
packet, it is forwarded to the node where the packet is examined by the DDP at the destination. After the packet is
identified as an AEP packet, the packet is then copied and a field in the packet is altered to create an AEP reply
packet, and is then returned to the source node.
Application Exchange
Application Exchange (APEX) was an early proposal to the IETF of a standard protocol for instant messaging. It
was based on XML, but is no longer being considered for use. Today, SIP and SIMPLE, and XMPP are currently
being discussed for use as an instant messaging protocol. Proponents of APEX have now mostly put their support
behind XMPP as it is also based on XML.
Archie search engine
Archie is a tool for indexing FTP archives, allowing people to find specific files. It is considered to be the first
Internet search engine.
The original implementation was written in 1990 by Alan Emtage, Bill Heelan, and J. Peter
Deutsch, then students at McGill University in Montreal.
History and name
The earliest versions of archie simply contacted a list of FTP archives on a regular basis (contacting each roughly
once a month, so as not to waste too much resources of the remote servers) and requested a listing. These listings
were stored in local files to be searched using the Unix grep command. Later, more efficient front- and back-ends
were developed, and the system spread from a local tool, to a network-wide resource, and a popular service available
from multiple sites around the Internet. The collected data would be exchanged between the neighbouring Archie
servers. The servers could be accessed in multiple ways: using a local client (such as archie or xarchie); telneting to
a server directly; sending queries by electronic mail; and later via a World Wide Web interface.
The name derives from the word "archive" without the v. Alan Emtage has said that contrary to popular belief, there
was no association with the Archie Comics and that he despised them.
A legacy Archie server is still maintained active for historic purposes in Poland at University of Warsaw's
Interdisciplinary Centre for Mathematical and Computational Modelling.
Archie search engine
[1] "The First Search Engine, Archie" (http:// www.isrl. uiuc. edu/ ~chip/ projects/ timeline/ 1990archie.htm). . Retrieved 2007-05-26.
[2] BBC Radio 4 - Saturday Live (http:// www.bbc. co. uk/ programmes/b00nmz7x), 7 November 2009
External links
• Last surviving Archie web interface (http:// archie.icm. edu. pl/ archie-adv_eng.html)
Further reading
Archie—A Darwinian Development Process. Peter Deutsch. IEEE Internet computing, January/February 2000,
4(1):69-71. Part of Millennial Forecasts, doi:10.1109/4236.815849 (http:// dx. doi.org/10. 1109/ 4236. 815849).
Architecture for Control Networks
Architecture for Control Networks (ACN) is a suite of network protocols for theatrical control being developed by
Entertainment Services and Technology Association (ESTA). The first official release is formally referred to as
ANSI E1.17 - 2006 - Entertainment Technology - Architecture for Control Networks.
It may replace DMX as the control protocol for lighting systems and will be used for controlling more complex
devices like video playback servers (media servers) and audio mixers and has been proposed as the sole or primary
transport for HD-MIDI. The protocol is designed to be layered on top of UDP/IP and therefore will run over
standard, inexpensive Ethernet and 802.11 (Wi-Fi) network links.
ACN relies on UDP in order to pass its messages. Where reliability is required, the Session Data Transport sub
protocol allows semi-reliability of only the latest value for a particular "channel".
In practice
ACN will require a number of new technologies in order to implement it compared to the DMX512 standard. ACN
requires the use of multicast Ethernet, so in larger networks, a switch that is IGMP snooping compatible will greatly
improve performance.
Protocol architecture
ACN defines a number of sub protocols. These protocols all follow the TLV style Protocol Data Units (PDU).
These can be nested in predefined hierarchy.
The Protocols defined in ANSI E1.17 are:
• Root Layer Protocol for UDP
• Session Data Transport Protocol (SDT)
• Device Management Protocol (DMP)
There is also an XML description language which defines properties of the devices which is called the Device
Description Language.
Architecture for Control Networks
Interoperability profiles
ACN is not closed in application. The protocol may be further defined via interoperability profiles which will extend
various layers of the ACN stack, or define how elements of the ACN architecture must be used in a particular
situation to achieve interoperability. For example, by providing specific values for timing parameters to be used in a
particular network environment.
E1.31 (Streaming DMX over ACN) is supported on Linux (ARM; i386, x86-64), and Macintosh (PowerPC; i386,
x86-64) by the Open Lighting Architecture
There is currently an OpenACN implementation project in progress which is hosted by SourceForge. This will
provide open source library implementation which is intended to be portable to a variety of platforms from small
embedded devices, to Windows and POSIX conformant operating systems.
External links
• Open Lighting Architecture
• ACN information
• ESTA's Technical Standards Program
• OpenACN home page
[1] http:/ / opendmx.net/ index. php/ OLA
[2] http:/ / engarts.com/ acn/
[3] http:/ / www. esta. org/tsp/ working_groups/CP/ projs. html
[4] http:// www. openacn. org/
Asynchronous Layered Coding
Asynchronous Layered Coding
Asynchronous Layered Coding is an Internet protocol of the IETF specified in RFC 3450
and described as a
massively scalable reliable content delivery protocol. It was adopted as an experimental protocol in December 2002
and still is as of January 2006.
Asynchronous Layered Coding (ALC) is a massively scalable reliable content delivery protocol, for multiple rate
congestion controlled reliable content delivery. The protocol is specifically designed to provide massive scalability
using IP multicast as the underlying network service. Massive scalability in this context means the number of
concurrent receivers for an object is potentially in the millions, the aggregate size of objects to be delivered in a
session ranges from hundreds of kilobytes to hundreds of gigabytes, each receiver can initiate reception of an object
asynchronously, the reception rate of each receiver in the session is the maximum fair bandwidth available between
that receiver and the sender, and all of this can be supported using a single sender.
Because ALC is focused on reliable content delivery, the goal is to deliver objects as quickly as possible to each
receiver while at the same time remaining network friendly to competing traffic. Thus, the congestion control used in
conjunction with ALC should strive to maximize use of available bandwidth between receivers and the sender while
at the same time backing off aggressively in the face of competing traffic.
The sender side of ALC consists of generating packets based on objects to be delivered within the session and
sending the appropriately formatted packets at the appropriate rates to the channels associated with the session. The
receiver side of ALC consists of joining appropriate channels associated with the session, performing congestion
control by adjusting the set of joined channels associated with the session in response to detected congestion, and
using the packets to reliably reconstruct objects. All information flow in an ALC session is in the form of data
packets sent by a single sender to channels that receivers join to receive data.
ALC does specify the Session Description needed by receivers before they join a session, but the mechanisms by
which receivers obtain this required information is outside the scope of ALC. An application that uses ALC may
require that receivers report statistics on their reception experience back to the sender, but the mechanisms by which
receivers report back statistics is outside the scope of ALC. In general, ALC is designed to be a minimal protocol
instantiation that provides reliable content delivery without unnecessary limitations to the scalability of the basic
• Tampere University of Technology MAD/TUT
• TZI Papageno
[1] http:/ / www. rfc-archive.org/getrfc.php?rfc=3450
[2] http:// mad.cs. tut. fi/
[3] https:// prj.tzi.org/cgi-bin/ trac.cgi/ wiki/ Papageno
[4] http:// planete-bcast.inrialpes. fr/rubrique.php3?id_rubrique=2
Bidirectional Forwarding Detection
Bidirectional Forwarding Detection
Bidirectional Forwarding Detection (BFD) is a network protocol used to detect faults between two forwarding
engines connected by a link. It provides low-overhead detection of faults even on physical media that don't support
failure detection of any kind, such as Ethernet, virtual circuits, tunnels and MPLS Label Switched Paths.
BFD establishes a session between two endpoints over a particular link. If more than one link exists between two
systems, multiple BFD sessions may be established to monitor each one of them. The session is established with a
three-way handshake, and is torn down the same way. Authentication may be enabled on the session. A choice of
simple password, MD5 or SHA1 authentication is available.
BFD does not have a discovery mechanism; sessions must be explicitly configured between endpoints. BFD may be
used on many different underlying transport mechanisms and layers, and operates independently of all of these.
Therefore, it needs to be encapsulated by whatever transport it uses. For example, monitoring MPLS LSPs involves
piggybacking session establishment on LSP-Ping packets. Protocols that support some form of adjacency setup, such
as OSPF or IS-IS, may also be used to bootstrap a BFD session. These protocols may then use BFD to receive faster
notification of failing links than would normally be possible using the protocol's own keepalive mechanism.
A session may operate in one of two modes: asynchronous mode and demand mode. In asynchronous mode, both
endpoints periodically send Hello packets to each other. If a number of those packets are not received, the session is
considered down.
In demand mode, no Hello packets are exchanged after the session is established; it is assumed that the endpoints
have another way to verify connectivity to each other, perhaps on the underlying physical layer. However, either host
may still send Hello packets if needed.
Regardless of which mode is in use, either endpoint may also initiate an Echo function. When this function is active,
a stream of Echo packets is sent, and the other endpoint then sends these back to the sender via its forwarding plane.
This is used to test the forwarding path on the remote system.
In June 2010, the BFD protocol standardization process is the RFC stage. RFC 5880 defines the BFD protocol,
detecting MPLS LSP failure, using BFD to monitor connectivity across multiple network hops, and using BFD for
IPv4 and IPv6. BFD's operation in conjunction with Open Shortest Path First (OSPF) and IS-IS protocols has also
been outlined in RFC 5881.
[1] RFC 5880, Bidirectional Forwarding Detection, D. Katz, D. Ward (June 2010)
[2] RFC 5881, BFD for IPv4 and IPv6 (Single Hop), D. Katz, D. Ward (June 2010)
Bidirectional Forwarding Detection
External links
• IETF BFD Working Group (http:// www.ietf.org/ html. charters/bfd-charter.html)
• BFD presentation by Juniper Networks (http:/ / www.ripe.net/ ripe/ meetings/ ripe-48/presentations/
• RFC 5880
• BFD white paper from IP Infusion (http:/ / www.ipinfusion. com/ whitepapers/ whitepaper-form.
• NetworkWorld article: Reducing Link Failure Detection Time with BFD (http:/ / www.networkworld.com/
community/ node/ 23380)
BIND method
The BIND method is an extension to WebDAV whose purpose is to create new access paths to existing resources. It
is defined by RFC 5842.
binkp is a protocol for transferring FidoNet mail over reliable connections.
Application of the Protocol
Historically, Fidonet traffic was transferred mainly over serial (RS-232) modem connections which might not have
an error correction layer. These dial-up-oriented protocols for transferring Fidonet traffic like EMSI
or Zmodem
had to implement error-recovery. When the members of Fidonet started to use TCP/IP to transfer Fidonet traffic, this
error-recovery overhead became unnecessary. Assuming that the connection is reliable makes it possible to eliminate
error-checking and unnecessary synchronization steps, achieving both ease of implementation and improved
performance. The major advantage of binkp vs EMSI and Zmodem is achieved over connections with large delays
and low bandwidth.
IANA (Internet Assigned Numbers Authority) has registered the port number 24554 for binkp when used over
TCP/IP connections.
• In 1996, Dima Maloff released the first draft of the protocol specification and the first mailer, binkd, that
supported the new protocol.
• In 1997, Argus
mailer began to support the binkp protocol.
• In 1999, Dima Maloff, Nick Soveiko and Maxim Masiutin submitted the protocol specification to the Fidonet
Technical Standards Committee (FTSC), which published the document as Fidonet Standards Proposal
• In 2005, FTSC assigned the Fidonet Technical Standard (FTS) status to the binkp protocol, and split the
specification into four separate documents: Binkp/1.0 Protocol specification (FTS-1026), Binkp/1.0 optional
protocol extension CRAM (FTS-1027), Binkp protocol extension Non-reliable Mode (FTS-1028), and Binkp
optional protocol extension Dataframe Compression (FTS-1029).
External links
• binkp specification (FSP-1011), published in 1999
[1] http:/ / www. ftsc. org/docs/ fsc-0056. 001
[2] http:/ / www. ritlabs. com/ argus
[3] http:// www. ritlabs. com/ binkp/
Boot Service Discovery Protocol
Boot Service Discovery Protocol (BSDP) is an Apple-developed, standards-conforming extension of DHCP
. It
allows Macintosh computers to boot from bootable images on a network instead of local storage media such as CD,
DVD, or hard disk. The DHCP options used are the "vendor-specific information" option (number 41, also called
"vendor encapsulated options") and "vendor class identifier" option (number 60). There are three versions of BSDP,
though usually version 1.0 is used. All versions enable a client to choose from several bootable images offered by a
server. The reference implementation
of BSDP is Darwin's BOOTP server, which is part of Mac OS's NetBoot
Contents of DHCP Vendor Class Identifier
The DHCP server and client send a vendor class option that contains an ASCII-encoded string with three parts
delimited by a / character. The first part is AAPLBSDPC, which advertises BSDP capability. The second part is the
client's architecture ("ppc" or "i386"). The third part is a system identifier. For example, an Intel-based iMac sends
as its vendor class.
Contents of DHCP Vendor Encapsulated Options
The main communication takes place through the DHCP vendor encapsulated options, which contains one or more
concatenated fields. Each field consists of:
Byte Position Content
0 Type of field
1 Length n of field
2 to n-2 Data
The following table describes the possible field types. All numeric fields are interpreted as unsigned and Big Endian
Boot Service Discovery Protocol
Type Meaning Data type
1 Message Type 8 Bit int
• 0x00: none
• 0x01: LIST
• 0x02: SELECT
• 0x03: error
2 BSDP Version
16 Bit int
• 0x0000: Version 0.0
• 0x0100: Version 1.0
• 0x0101: Version 1.1
3 Server Identifier IP address of the server, one byte per component: c0 a8 64 01 represents
4 Server Priority 16 Bit int
5 Port for Response 16 Bit int
6 "boot image list
7 ID of Standard
Boot Image
32 Bit int
(According to Apple's documentation
, the boot image ID can range up to 65535. This comprises 16 bits; however,
32 bits are reserved. In all observed IDs, the most significant 16 bits are always 1000 0001 0000 0000 (0x8100), which
probably indicates the type and version of the operating system to be booted.)
8 ID of Selected
Boot Image
32 Bit int
9 List of Boot
10 "netboot 1.0
11 Error List for
Image Attribute
128 "shadow mount
String (URL)
Here is possible to specify a network-accessible mount where data will be written after a successful boot. If this field is
not specified and no storage medium is available locally on the client, then the boot process for Mac OS X is aborted.
Officially, Mac OS X only supports AFP shadow mount paths. However, NFS may be used after a modifying of the
startup files of the system.
129 "shadow file path" String (URL)
130 "machine name"
(Name of system
to boot?)
The following example illustrates the construction of the Vendor Encapsulated Option:
0000 01 01 02 08 04 81 00 07 e5 82 0a 4e 65 74 42 6f 6f ........ ..NetBoo
0010 74 30 30 31 t001
The first field here, 01 01 02, means that the packet is a BSDP "SELECT" message. The 01 declares that field
specifies the BSDP Message Type. The next 01 indicates that the field contents are one byte long — 02 is the code
for "SELECT".
The following 08 04 81 00 07 e5 means that the boot image with the ID 2164262885 is selected.
Boot Service Discovery Protocol
Finally, 82 0a 4e 65 74 42 6f 6f 74 30 30 31 means that a string with 0x0a = 10 characters, namely "NetBoot001", is
the name of the system to boot.
• BSDP documentation
from Apple's bootpd
• several conversations captured with Wireshark
• network captures
from https:// www. math. ohio-state. edu/ wiki/ administration/ macosx/ netboot/ intel
• Source code of Darwin's BOOTP server, http:/ / www.opensource.apple.com/ darwinsource/ tarballs/ apsl/
bootp-133. 8. tar. gz
[1] "NetBoot 2.0: Boot Service Discovery Protocol (BSDP)" (http:/ / opensource.apple. com/ source/ bootp/ bootp-198.1/ Documentation/
BSDP.doc) (DOC). Apple Inc. 2003-12-08. . Retrieved 2010-07-22.
[2] http:// www. opensource. apple. com/ darwinsource/tarballs/ apsl/ bootp-133.8.tar. gz
[3] http:/ / support. apple. com/ kb/ HT3115
[4] http:/ / opensource. apple. com/ source/ bootp/ bootp-198.1/ Documentation/ BSDP. doc
[5] http:/ / www. math. ohio-state. edu/ ~mccune/ pub/ imac_duo_netboot. tcpdump. gz
Bootstrap Protocol
In computer networking, the Bootstrap Protocol, or BOOTP, is a network protocol used by a network client to
obtain an IP address from a configuration server. The BOOTP protocol was originally defined in RFC 951.
BOOTP is usually used during the bootstrap process when a computer is starting up. A BOOTP configuration server
assigns an IP address to each client from a pool of addresses. BOOTP uses the User Datagram Protocol (UDP) as a
transport on IPv4 networks only.
Historically, BOOTP has also been used for Unix-like diskless workstations to obtain the network location of their
boot image in addition to an IP address, and also by enterprises to roll out a pre-configured client (e.g., Windows)
installation to newly installed PCs.
Originally requiring the use of a boot floppy disk to establish the initial network connection, manufacturers of
network cards later embedded the protocol in the BIOS of the interface cards as well as system boards with on-board
network adapters, thus allowing direct network booting.
Recently, users with an interest in diskless stand-alone media center PCs have shown new interest in this method of
booting a Windows operating system.
The Dynamic Host Configuration Protocol (DHCP) is a more advanced protocol for the same purpose and has
superseded the use of BOOTP. Most DHCP servers also function as BOOTP servers.
The BOOTP protocol was first defined in RFC 951 as a replacement for the Reverse Address Resolution Protocol
RARP, published in RFC 903 in June 1984. The primary motivation for replacing RARP with BOOTP is that RARP
was a data link layer protocol. This made implementation difficult on many server platforms, and required that a
server be present on each individual IP subnet. BOOTP introduced the innovation of a relay agent, which allowed
BOOTP packets to be forwarded from the local network using standard IP routing, so that one central BOOTP server
could serve hosts on many subnets.
Bootstrap Protocol
Related RFCs
BOOTP Related RFCs
Note that grayed out RFCs are obsolete
RFC # Title Date Obsolete and Update Information
Reclassifying Dynamic Host Configuration Protocol version
4 (DHCPv4) Options
Nov-04 Updates RFC 2132
DHCP Options and BOOTP Vendor Extensions Mar-97 Obsoletes RFC 1533, Updated by RFC 3442, RFC 3942, RFC
4361, RFC 4833, RFC 5494
Clarifications and Extensions for the Bootstrap Protocol Oct-93 Obsoletes RFC 1532, Updates RFC 951
Interoperation Between DHCP and BOOTP Oct-93
DHCP Options and BOOTP Vendor Extensions Oct-93 Obsoletes RFC 1497, RFC 1395, RFC 1084, RFC 1048,
Obsoleted by RFC 2132
Clarifications and Extensions for the Bootstrap Protocol Oct-93 Obsoleted by RFC 1542, Updates RFC 951
BOOTP Vendor Information Extensions Aug-93 Obsoletes RFC 1395, RFC 1084, RFC 1048, Obsoleted by RFC
1533, Updates RFC 951
BOOTP Vendor Information Extensions Jan-93 Obsoletes RFC 1084, RFC 1048, Obsoleted by RFC 1497, RFC
1533, Updates RFC 951
BOOTP vendor information extensions Dec-88 Obsoletes RFC 1048, Obsoleted by RFC 1395, RFC 1497, RFC
BOOTP vendor information extensions Feb-88 Obsoleted by RFC 1084, RFC 1395, RFC 1497, RFC 1533
Bootstrap Protocol Sep-85 Updated by RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC
[1] Personal Computer World, Feb 2005, pg 156 'Putting the Boot in'
[2] Bill Croft; John Gilmore (September 1985). "RFC 951 - Bootstrap Protocol" (http:// tools. ietf. org/html/ rfc951#section-6). Network
Working Group. .
External links
• BOOTP Sequence Diagram (http:// www. eventhelix. com/ RealtimeMantra/ Networking/ Bootp. pdf) (PDF)
• Multicast BOOTP for configuring a network device from a workstation (http:// mbootp. sourceforge.net/ )
Border Gateway Multicast Protocol
Border Gateway Multicast Protocol
The Border Gateway Multicast Protocol (BGMP) is IETF on-going project in an attempt to design a true
inter-domain multicast routing protocol. BGMP should be able to scale in order to operate in the global Internet.
External links
• RFC 3913: Border Gateway Multicast Protocol] BGMP Protocol Specification. September 2004.
• Border Gateway Multicast Protocol IETF charter
• BGMP (Border-Gateway Multicast Protocol) Homepage
• Border Gateway Multicast Protocol
[1] http:/ / www. ietf.org/ html. charters/OLD/ bgmp-charter.html
[2] http:// netweb.usc. edu/ bgmp/
[3] http:// www. cs. ucl. ac. uk/ staff/jon/ mmbook/ book/ node80. html
Border Gateway Protocol
The Border Gateway Protocol (BGP) is the protocol backing the core routing decisions on the Internet. It
maintains a table of IP networks or 'prefixes' which designate network reachability among autonomous systems
(AS). It is described as a path vector protocol. BGP does not use traditional Interior Gateway Protocol (IGP) metrics,
but makes routing decisions based on path, network policies and/or rulesets. For this reason, it is more appropriately
termed a reachability protocol rather than routing protocol.
BGP was created to replace the Exterior Gateway Protocol (EGP) protocol to allow fully decentralized routing in
order to transition from the core ARPAnet model to a decentralized system that included the NSFNET backbone and
its associated regional networks. This allowed the Internet to become a truly decentralized system. Since 1994,
version four of the BGP has been in use on the Internet. All previous versions are now obsolete. The major
enhancement in version 4 was support of Classless Inter-Domain Routing and use of route aggregation to decrease
the size of routing tables. Since January 2006, version 4 is codified in RFC 4271, which went through more than 20
drafts based on the earlier RFC 1771 version 4. RFC 4271 version corrected a number of errors, clarified ambiguities
and brought the RFC much closer to industry practices.
Most Internet service providers must use BGP to establish routing between one another (especially if they are
multihomed). Therefore, even though most Internet users do not use it directly, BGP is one of the most important
protocols of the Internet. Compare this with Signaling System 7 (SS7), which is the inter-provider core call setup
protocol on the PSTN. Very large private IP networks use BGP internally. An example would be the joining of a
number of large OSPF (Open Shortest Path First) networks where OSPF by itself would not scale to size. Another
reason to use BGP is multihoming a network for better redundancy either to multiple access points of a single ISP
(RFC 1998) or to multiple ISPs.
Border Gateway Protocol
BGP neighbors, peers are established by manual configuration between routers to create a TCP session on port 179.
A BGP speaker will periodically send 19-byte keep-alive messages to maintain the connection (every 60 seconds by
default). Among routing protocols, BGP is unique in using TCP as its transport protocol.
When BGP runs inside an autonomous system (AS), it is referred to as Internal BGP (IBGP or Interior Border
Gateway Protocol). When it runs between autonomous systems, it is called External BGP (EBGP or Exterior Border
Gateway Protocol). Routers on the boundary of one AS exchanging information with another AS are called border or
edge routers. In the Cisco operating system, IBGP routes have an administrative distance of 200, which is less
preferred than either external BGP or any interior routing protocol. Other router implementations also prefer EBGP
to IGPs, and IGPs to IBGP.
Extensions negotiation
During the OPEN BGP speakers can negotiate
optional capabilities of the session, including multiprotocol
extensions and various recovery modes. If the multiprotocol extensions to BGP
are negotiated at the time of
creation, the BGP speaker can prefix the Network Layer Reachability Information (NLRI) it advertises with an
address family prefix. These families include the IPv4 (default), IPv6, IPv4/IPv6 Virtual Private Networks and
multicast BGP. Increasingly, BGP is used as a generalized signaling protocol to carry information about routes that
may not be part of the global Internet, such as VPNs.
Finite-state machine
BGP state machine
In order to make decisions in its
operations with other BGP peers, a
BGP peer uses a simple finite state
machine (FSM) that consists of six
states: Idle; Connect; Active;
OpenSent; OpenConfirm; and
Established. For each peer-to-peer
session, a BGP implementation
maintains a state variable that tracks
which of these six states the session is
in. The BGP protocol defines the
messages that each peer should
exchange in order to change the
session from one state to another. The
first state is the “Idle” state. In the “Idle” state, BGP initializes all resources, refuses all inbound BGP connection
attempts and initiates a TCP connection to the peer. The second state is “Connect”. In the “Connect” state, the router
waits for the TCP connection to complete and transitions to the "OpenSent" state if successful. If unsuccessful, it
resets the ConnectRetry timer and transitions to the "Active" state upon expiration. In the "Active" state, the router
resets the ConnectRetry timer to zero and returns to the "Connect" state. In the "OpenSent" state, the router sends an
Open message and waits for one in return. Keepalive messages are exchanged and, upon successful receipt, the
router is placed into the “Established” state. In the “Established” state, the router can send/receive: Keepalive;
Update; and Notification messages to/from its peer.
• Idle State:
• Refuse all incoming BGP connections
• Start event triggers the initialization of resources for the BGP process.
Border Gateway Protocol
• Initiates a TCP connection with its configured BGP peer.
• Listens for a TCP connection from its peer.
• Changes its state to Connect.
• If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to
the Idle state. Some of the reasons why a router does not progress from the Idle state are:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• Peer address configured incorrectly on either router.
• AS number configured incorrectly on either router .
• Connect State:
• Waits for successful TCP negotiation with peer.
• BGP does not spend much time in this state if the TCP session has been successfully established.
• Sends Open message to peer and changes state to OpenSent.
• If an error occurs, BGP moves to the Active state. Some reasons for the error are:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• Peer address configured incorrectly on either router.
• AS number configured incorrectly on either router.
• Active State:
• If the router was unable to establish a successful TCP session, then it ends up in the Active state.
• BGP FSM will try to restart another TCP session with the peer and, if successful, then it will send an Open
message to the peer.
• If it is unsuccessful again, the FSM is reset to the Idle state.
• Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for
this include:
• TCP port 179 is not open.
• A random TCP port over 1023 is not open.
• BGP configuration error.
• Network congestion.
• Flapping network interface.
• OpenSent State:
• BGP FSM listens for an Open message from its peer.
• Once the message has been received, the router checks the validity of the Open message.
• If there is an error it is because one of the fields in the Open message doesn’t match between the peers, e.g.
BGP version mismatch, MD5 password mismatch, the peering router expects a different My AS. The router
will then send a Notification message to the peer indicating why the error occurred.
• If there is no error, a Keepalive message is sent, various timers are set and the state is changed to
• OpenConfirm State:
• The peer is listening for a Keepalive message from its peer.
• If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions
to the Established state.
• If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions
back to the Idle state.
• Established State:
Border Gateway Protocol
• In this state, the peers send Update messages to exchange information about each route being advertised to the
BGP peer.
• If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions
back to the Idle state.
• If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions
back to the Idle state.
Basic BGP updates
Once a BGP session is running, the BGP speakers exchange UPDATE messages about destinations to which the
speaker offers connectivity. In the protocol, the basic CIDR route description is called Network Layer Reachability
Information (NLRI). NLRI includes the expected destination prefix, prefix length, path of autonomous systems to
the destination and next hop in attributes, which can carry a wide range of additional information that affects the
acceptance policy of the receiving router. BGP speakers incrementally announce new NLRI to which they offer
reachability, but also announce withdrawals of prefixes to which the speaker no longer offers connectivity.
BGP router connectivity and learning routes
In the simplest arrangement all routers within a single AS and participating in BGP routing must be configured in a
full mesh: each router must be configured as peer to every other router. This causes scaling problems, since the
number of required connections grows quadratically with the number of routers involved. To alleviate the problem,
BGP implements two options: route reflectors (RFC 4456) and confederations (RFC 5065). The following discussion
of basic UPDATE processing assumes a full IBGP mesh.
Basic update processing
A given BGP router may accept NLRI in UPDATEs from multiple neighbors and advertise NLRI to the same, or a
different set, of neighbors. Conceptually, BGP maintains its own "master" routing table, called the Loc-RIB (Local
Routing Information Base), separate from the main routing table of the router. For each neighbor, the BGP process
maintains a conceptual Adj-RIB-In (Adjacent Routing Information Base, Incoming) containing the NLRI received
from the neighbor, and a conceptual Adj-RIB-Out (Outgoing) for NLRI to be sent to the neighbor.
Conceptual, in the preceding paragraph, means that the physical storage and structure of these various tables are
decided by the implementer of the BGP code. Their structure is not visible to other BGP routers, although they
usually can be interrogated with management commands on the local router. It is quite common, for example, to
store the two Adj-RIBs and the Loc-RIB together in the same data structure, with additional information attached to
the RIB entries. The additional information tells the BGP process such things as whether individual entries belong in
the Adj-RIBs for specific neighbors, whether the per-neighbor route selection process made received policies eligible
for the Loc-RIB, and whether Loc-RIB entries are eligible to be submitted to the local router's routing table
management process.
By eligible to be submitted, BGP will submit the routes that it considers best to the main routing table process.
Depending on the implementation of that process, the BGP route is not necessarily selected. For example, a directly
connected prefix, learned from the router's own hardware, is usually most preferred. As long as that directly
connected route's interface is active, the BGP route to the destination will not be put into the routing table. Once the
interface goes down, and there are no more preferred routes, the Loc-RIB route would be installed in the main
routing table. Until recently, it was a common mistake to say BGP carries policies. BGP actually carried the
information with which rules inside BGP-speaking routers could make policy decisions. Some of the information
carried that is explicitly intended to be used in policy decisions are communities and multi-exit discriminators
Border Gateway Protocol
Route selection
The BGP standard specifies a number of decision factors, more than are used by any other common routing process,
for selecting NLRI (Network Layer Reachability Information) to go into the Loc-RIB (Routing Information Base).
The first decision point for evaluating NLRI is that its next-hop attribute must be reachable (or resolvable). Another
way of saying the next-hop must be reachable is that there must be an active route, already in the main routing table
of the router, to the prefix in which the next-hop address is located.
Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide
which routes conceptually should go into the Adj-RIB-In. The neighbor could send several possible routes to a
destination, but the first level of preference is at the neighbor level. Only one route to each destination will be
installed in the conceptual Adj-RIB-In. This process will also delete, from the Adj-RIB-In, any routes that are
withdrawn by the neighbor.
Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's new routes are
preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is withdrawn by a neighbor, and
there is no other route to that destination, the route is removed from the Loc-RIB, and no longer sent, by BGP, to the
main routing table manager. If the router does not have a route to that destination from any non-BGP source, the
withdrawn route will be removed from the main routing table.
Per-neighbor decisions
After verifying that the next hop is reachable, if the route comes from an internal (i.e. IBGP) peer, the first rule to
apply according to the standard is to examine the LOCAL_PREF attribute. If there are several IBGP routes from the
neighbor, the one with the highest LOCAL_PREF is selected unless there are several routes with the same
LOCAL_PREF. In the latter case the route selection process moves to the next tie breaker. While LOCAL_PREF is
the first rule in the standard, once reachability of the NEXT_HOP is verified, Cisco and several other vendors first
consider a decision factor called WEIGHT which is local to the router (i.e. not transmitted by BGP). The route with
the highest WEIGHT is preferred.
LOCAL_PREF, WEIGHT, and other criteria can be manipulated by local configuration and software capabilities.
Such manipulation is outside the scope of the standard but is commonly used. For example the COMMUNITY
attribute (see below) is not directly used by the BGP selection process. The BGP neighbor process however can have
a rule to set LOCAL_PREFERENCE or another factor based on a manually programmed rule to set the attribute if
the COMMUNITY value matches some pattern matching criterion. If the route was learned from an external peer the
per-neighbor BGP process computes a LOCAL_PREFERENCE value from local policy rules and then compares the
LOCAL_PREFERENCE of all routes from the neighbor.
At the per-neighbor level - ignoring implementation-specific policy modifiers - the order of tie breaking rules is:
1. Prefer the route with the shortest AS_PATH. An AS_PATH is the set of AS numbers that must be traversed to
reach the advertised destination. AS1-AS2-AS3 is shorter than AS4-AS5-AS6-AS7.
2. Prefer routes with the lowest value of their ORIGIN attribute.
3. Prefer routes with the lowest MULTI_EXIT_DISC (multi-exit discriminator or MED) value.
Before the most recent edition of the BGP standard, if an UPDATE had no MULTI_EXIT_DISC value, several
implementations created a MED with the least possible value. The current standard however specifies that missing
MEDs are to be treated as the highest possible value. Since the current rule may cause different behavior than the
vendor interpretations, BGP implementations that used the nonstandard default value have a configuration feature
that allows the old or standard rule to be selected.
Border Gateway Protocol
Decision factors at the Loc-RIB level
Once candidate routes are received from neighbors, the Loc-RIB software applies additional tie-breakers to routes to
the same destination.
1. If at least one route was learned from an external neighbor (i.e., the route was learned from EBGP), drop all
routes learned from IBGP.
2. Prefer the route with the lowest interior cost to the NEXT_HOP, according to the main Routing Table. If two
neighbors advertised the same route, but one neighbor is reachable via a low-bitrate link and the other by a
high-bitrate link, and the interior routing protocol calculates lowest cost based on highest bitrate, the route
through the high-bitrate link would be preferred and other routes dropped.
If there is more than one route still tied at this point, several BGP implementations offer a configurable option to
load-share among the routes, accepting all (or all up to some number).
1. Prefer the route learned from the BGP speaker with the numerically lowest BGP identifier
2. Prefer the route learned from the BGP speaker with the lowest peer IP address
BGP communities are attribute tags that can be applied to incoming or outgoing prefixes to achieve some common
goal (RFC 1997). While it is common to say that BGP allows an administrator to set policies on how prefixes are
handled by ISPs, this is generally not possible, strictly speaking. For instance, BGP natively has no concept to allow
one AS to tell another AS to restrict advertisement of a prefix to only North American peering customers. Instead, an
ISP generally publishes a list of well-known or proprietary communities with a description for each one, which
essentially becomes an agreement of how prefixes are to be treated. Examples of common communities include local
preference adjustments, geographic or peer type restrictions, DoS avoidance (black holing), and AS prepending
options. An ISP might state that any routes received from customers with community XXX:500 will be advertised to
all peers (default) while community XXX:501 will restrict advertisement to North America. The customer simply
adjusts their configuration to include the correct community(ies) for each route, and the ISP is responsible for
controlling who the prefix is advertised to. The end user has no technical ability to enforce correct actions being
taken by the ISP, though problems in this area are generally rare and accidental.
It is a common tactic for end customers to use BGP communities (usually ASN:70,80,90,100) to control the local
preference the ISP assigns to advertised routes instead of using MED (the effect is similar). It should also be noted
that the community attribute is transitive, but communities applied by the customer very rarely become propagated
outside the next-hop AS.
Extended communities
The BGP Extended Community Attribute was added in 2006 in order to extend the range of such attributes and to
provide a community attribute structuring by means of a type field. The extended format consists of one or two
octets for the type field followed by seven or six octets for the respective community attribute content. The definition
of this Extended Community Attribute is documented in RFC 4360. The IANA administers the registry for BGP
Extended Communities Types.
The Extended Communities Attribute itself is a transitive optional BGP attribute.
However, a bit in the type field within the attribute decides whether the encoded extended community is of a
transitive or non-transitive nature. The IANA registry therefore provides different number ranges for the attribute
types. Due to the extended attribute range, its usage can be manifold. RFC 4360 exemplarly defines the "Two-Octet
AS Specific Extended Community", the "IPv4 Address Specific Extended Community", the "Opaque Extended
Community", the "Route Target Community" and the "Route Origin Community". A number of BGP QoS drafts
also use this Extended Community Attribute structure for inter-domain QoS signalling.
Border Gateway Protocol
Uses of multi-exit discriminators
MEDs, defined in the main BGP standard, were originally intended to show to another neighbor AS the advertising
AS's preference as to which of several links are preferred for inbound traffic. Another application of MEDs is to
advertise the value, typically based on delay, of multiple AS that have presence at an IXP, that they impose to send
traffic to some destination.
BGP problems and mitigation
Internal BGP scalability
An autonomous system with internal BGP (IBGP) must have all of its IBGP peers connect to each other in a full
mesh (where everyone speaks to everyone directly). This full-mesh configuration requires that each router maintain a
session to every other router. In large networks, this number of sessions may degrade performance of routers, due
either to a lack of memory, or too much CPU process requirements.
Route reflectors and confederations both reduce the number of IBGP peers to each router and thus reduce processing
overhead. Route reflectors are a pure performance-enhancing technique, while confederations also can be used to
implement more fine-grained policy.
Route reflectors
reduce the number of connections required in an AS. A single router (or two for redundancy) can
be made a route reflector: other routers in the AS need only be configured as peers to them.
Confederations are sets of autonomous systems. In common practice,
only one of the confederation AS numbers is
seen by the Internet as a whole. Confederations are used in very large networks where a large AS can be configured
to encompass smaller more manageable internal ASs.
Confederations can be used in conjunction with route reflectors. Both confederations and route reflectors can be
subject to persistent oscillation unless specific design rules, affecting both BGP and the interior routing protocol, are
However, these alternatives can introduce problems of their own, including the following:
• route oscillation
• sub-optimal routing
• increase of BGP convergence time
Additionally, route reflectors and BGP confederations were not designed to ease BGP router configuration.
Nevertheless, these are common tools for experienced BGP network architects. These tools may be combined, for
example, as a hierarchy of route reflectors.
The routing tables managed by a BGP implementation are adjusted continually to reflect actual changes in the
network, such as links breaking and being restored or routers going down and coming back up. In the network as a
whole it is normal for these changes to happen almost continuously, but for any particular router or link changes are
supposed to be relatively infrequent. If a router is misconfigured or mismanaged then it may get into a rapid cycle
between down and up states. This pattern of repeated withdrawal and reannouncement, known as route flapping, can
cause excessive activity in all the other routers that know about the broken link, as the same route is continuously
injected and withdrawn from the routing tables. The BGP design is such that delivery of traffic may not function
while routes are being updated. On the Internet, a BGP routing change may cause outages for several minutes.
A feature known as route flap damping (RFC 2439
) is built into many BGP implementations in an attempt to
mitigate the effects of route flapping. Without damping the excessive activity can cause a heavy processing load on
routers, which may in turn delay updates on other routes, and so affect overall routing stability. With damping, a
route's flapping is exponentially decayed. At the first instance when a route becomes unavailable and quickly
Border Gateway Protocol
reappears, damping does not take effect, so as to maintain the normal fail-over times of BGP. At the second
occurrence, BGP shuns that prefix for a certain length of time; subsequent occurrences are timed out exponentially.
After the abnormalities have ceased and a suitable length of time has passed for the offending route, prefixes can be
reinstated and its slate wiped clean. Damping can also mitigate denial of service attacks; damping timings are highly
However, subsequent research has shown that flap damping can actually lengthen convergence times in some cases,
and can cause interruptions in connectivity even when links are not flapping.

Moreover, as backbone links
and router processors have become faster, some network architects have suggested that flap damping may not be as
important as it used to be, since changes to the routing table can be absorbed much faster by routers. This has led the
RIPE Route Working Group to write that "with the current implementations of BGP flap damping, the application of
flap damping in ISP networks is NOT recommended. ... If flap damping is implemented, the ISP operating that
network will cause side-effects to their customers and the Internet users of their customers' content and services ... .
These side-effects would quite likely be worse than the impact caused by simply not running flap damping at all."
[13] Improving stability without the problems of flap damping is the subject of current research.[14]
Routing table growth
BGP table growth on the Internet.
Number of AS on the Internet.
One of the largest problems faced by BGP, and indeed the Internet
infrastructure as a whole, is the growth of the Internet routing table. If
the global routing table grows to the point where some older, less
capable, routers cannot cope with the memory requirements or the
CPU load of maintaining the table, these routers will cease to be
effective gateways between the parts of the Internet they connect. In
addition, and perhaps even more importantly, larger routing tables take
longer to stabilize (see above) after a major connectivity change,
leaving network service unreliable, or even unavailable, in the interim.
Until late 2001, the global routing table was growing exponentially,
threatening an eventual widespread breakdown of connectivity. In an
attempt to prevent this, ISPs cooperated in keeping the global routing
table as small as possible, by using Classless Inter-Domain Routing
(CIDR) and route aggregation. While this slowed the growth of the
routing table to a linear process for several years, with the expanded
demand for multihoming by end user networks the growth was once
again exponential by the middle of 2004. As of April 2010, the routing
table has in excess of 310,000 entries.
Route summarization is often used to improve aggregation of the BGP
global routing table, thereby reducing the necessary table size in
routers of an AS. Consider AS1 has been allocated the big address
space of, this would be counted as one route in the table,
but due to customer requirement or traffic engineering purposes, AS1 wants to announce smaller, more specific
routes of, and The prefix does not have any hosts so
AS1 does not announce a specific route This all counts as AS1 announcing four routes.
AS2 will see the 4 routes from AS1 (,, and and it is up
to the routing policy of AS2 to decide whether or not to take a copy of the four routes or, as overlaps
all the other specific routes, to just store the summary,
Border Gateway Protocol
If AS2 wants to send data to prefix, it will be sent to the routers of AS1 on route At
AS1's router, it will either be dropped or a destination unreachable ICMP message will be sent back, depending on
the configuration of AS1's routers.
If AS1 later decides to drop the route, leaving, and,
AS1 will drop the number of routes it announces to three. AS2 will see the three routes, and depending on the
routing policy of AS2, it will store a copy of the three routes, or aggregate the prefix's and to, thereby reducing the number of routes AS2 stores to only two: and
If AS2 wants to send data to prefix, it will be dropped or a destination unreachable ICMP message
will be sent back at the routers of AS2 (not AS1 as before), because would not be in the routing
Load-balancing problem
Another factor causing this growth of the routing table is the need for load balancing of multi-homed networks. It is
not a trivial task to balance the inbound traffic to a multi-homed network across its multiple inbound paths, due to
limitation of the BGP route selection process. For a multi-homed network, if it announces the same network blocks
across all of its BGP peers, the result may be that one or several of its inbound links become congested while the
other links remain under-utilized, because external networks all picked that set of congested paths as optimal. Like
most other routing protocols, the BGP protocol does not detect congestion.
To work around this problem, BGP administrators of that multihomed network may divide a large continuous IP
address block into smaller blocks, and tweak the route announcement to make different blocks look optimal on
different paths, so that external networks will choose a different path to reach different blocks of that multi-homed
network. Such cases will increase the number of routes as seen on the global BGP table.
Requirements of a router for use of BGP for Internet and
backbone-of-backbones purposes
Routers, especially small ones intended for Small Office/Home Office (SOHO) use, may not include BGP software.
Some SOHO routers simply are not capable of running BGP using BGP routing tables of any size. Other commercial
routers may need a specific software executable image that contains BGP, or a license that enables it. Open source
packages that run BGP include GNU Zebra, Quagga, OpenBGPD, BIRD, XORP and Vyatta. Devices marketed as
Layer 3 switches are less likely to support BGP than devices marketed as routers, but high-end Layer 3 Switches
usually can run BGP.
Products marketed as switches may or may not have a size limitation on BGP tables, such as 20,000 routes, far
smaller than a full Internet table plus internal routes. These devices, however, may be perfectly reasonable and useful
when used for BGP routing of some smaller part of the network, such as a confederation-AS representing one of
several smaller enterprises that are linked, by a BGP backbone of backbones, or a small enterprise that announces
routes to an ISP but only accepts a default route and perhaps a small number of aggregated routes.
A BGP router used only for a network with a single point of entry to the Internet may have a much smaller routing
table size (and hence RAM and CPU requirement) than a multihomed network. Even simple multihoming can have
modest routing table size. See RFC 4098 for vendor-independent performance parameters for single BGP router
convergence in the control plane. The actual amount of memory required in a BGP router depends on the amount of
BGP information exchanged with other BGP speakers, and the way in which the particular router stores BGP
information. The router may have to keep more than one copy of a route, so it can manage different policies for route
advertising and acceptance to a specific neighboring AS. The term view is often used for these different policy
relationships on a running router.
Border Gateway Protocol
If one router implementation takes more memory per route than another implementation, this may be a legitimate
design choice, trading processing speed against memory. A full BGP table as of April 2010 is in excess of 310,000
prefixes. Large ISPs may add another 50% for internal and customer routes. Again depending on implementation,
separate tables may be kept for each view of a different peer AS.
Free and open source implementations of BGP
• Bird Internet routing daemon, a GPL routing package for Unix-like systems.
• GNU Zebra, a GPL routing suite supporting BGP4.
• OpenBGPD, a BSD licensed implementation by the OpenBSD team.
• Quagga, a fork of GNU Zebra for Unix-like systems.
• XORP, the eXtensible Open Router Platform, a BSD licensed suite of routing protocols.
, a C# software library implementing BGP
BGP simulators
• BGPviz
, a Flash application that presents a graphical visualization of BGP routes and updates for any real AS
on the Internet
• SSFnet
, SSFnet network simulator includes a BGP implementation developed by BJ Premore
, a BGP simulator able to perform large-scale simulation trying to model the ASes of the Internet or
modelling ASes as large as Tier-1.
• BGP++
, a patch integrating GNU Zebra software on ns-2 and GTNetS network simulators
• ns-BGP
, a BGP extension for ns-2 simulator based on the SSFnet implementation
• NetViews
, a Java application that monitors and visualizes BGP activity in real time.
Test equipment
Systems for testing BGP conformance, load or stress performance come from vendors such as:
• Ixia
• Spirent Communications
• Agilent Technologies
[1] Capabilities Advertisement with BGP-4 (http:/ / www.ietf.org/ rfc/rfc2842.txt), RFC 2842, R. Chandra & J. Scudder,May 2000
[2] Multiprotocol Extensions for BGP-4 (http:/ / www.ietf.org/ rfc/rfc2858.txt), RFC 2858, T. Bates et al.,June 2000
[3] BGP/MPLS VPNs. (http:/ / www.ietf.org/rfc/rfc2547.txt), RFC 2547, E. Rosen and Y. Rekhter,April 2004
[4] IANA registry for BGP Extended Communities Types (http:/ / www.iana.org/ assignments/ bgp-extended-communities), IANA,2008
[5] IETF drafts on BGP signalled QoS (http:// www.bgp-qos.org/ forum/viewforum.php?f=6), Thomas Knoll,2008
[6] BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) (http:/ / www.ietf.org/rfc/rfc4456.txt), RFC 4456, T. Bates et
al., April 2006
[7] Autonomous System Confederations for BGP (http:/ / www.ietf. org/rfc/rfc5065.txt), RFC 5065, P. Traina et al., February 2001
[8] Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (http:/ / www. ietf.org/ rfc/rfc3345.txt), RFC 3345, D. McPherson
et al., August 2002
[9] Terminology for Benchmarking BGP Device Convergence in the Control Plane (http:/ / www.ietf.org/rfc/rfc4098.txt), RFC 4098, H.
Berkowitz et al., June 2005
[10] http:/ / www. ietf.org/ rfc/rfc2439.txt
[11] Route Flap Damping Exacerbates Internet Routing Convergence (http:/ / www. sigcomm.org/ sigcomm2002/ papers/ routedampening.pdf)
[12] Zhang, Beichuan; Pei Dan, Daniel Massey, Lixia Zhang (June 2005). "Timer Interaction in Route Flap Damping" (http:// www. cs. arizona.
edu/ ~bzhang/ paper/ 05-icdcs-dtimer.pdf). IEEE 25th International Conference on Distributed Computing Systems. . Retrieved 2006-09-26.
"We show that the current damping design leads to the intended behavior only under persistent route flapping. When the number of flaps is
small, the global routing dynamics deviates significantly from the expected behavior with a longer convergence delay."
[13] http:/ / www. ripe.net/ docs/ routeflap-damping.html
Border Gateway Protocol
[14] http:/ / tools. ietf.org/internet-drafts/draft-li-bgp-stability-01.txt
[15] BGP Routing Table Analysis Reports (http:/ / bgp. potaroo.net)
[16] http:// wiki.ucis. nl/ VNE
[17] http:// www. ris. ripe.net/ bgpviz/
[18] http:// www. ssfnet. org/homePage. html
[19] http:/ / cbgp.info.ucl. ac. be
[20] Modeling the routing of an Autonomous System with C-BGP (http:// www.info. ucl.ac.be/ ~bqu/ downloads/ quoitin-ieee-network-2005.
[21] http:// www. ece. gatech. edu/ research/ labs/ MANIACS/ BGP+ + /
[22] http:/ / www. ensc. sfu. ca/ ~ljilja/ cnl/ projects/ BGP/
[23] http:// netlab.cs. memphis. edu/ projects_netviews. html
Further reading
• Chapter "Border Gateway Protocol (BGP)" (http:// docwiki. cisco. com/ wiki/ Border_Gateway_Protocol) in the
Cisco "IOS Technology Handbook"
External links
• Cyclops (http:/ / cyclops. cs. ucla.edu/ ) A BGP network audit tool (prefix hijack, route leakage) by UCLA
• Codenomicon Defensics for BGP (http:// www.codenomicon. com/ products/ bgp. shtml), a test automation
framework for BGP Fuzzing and robustness testing
• LinkRank (http:// linkrank.cs. ucla.edu/ ) A tool for BGP routing visualization by University of California, Los
• A look at fuzzing BGP for security testing (http:/ / www.breakingpointsystems. com/ community/ blog/
• BGP Routing Resources (http:/ / www. bgp4. as/ ) (includes a dedicated section on BGP & ISP Core Security
(http:// www. bgp4. as/ security))
• BGP table statistics (http:/ / bgp. potaroo.net/ )
• ASNumber Firefox Extension (http:// www. asnumber. networx.ch/ ) showing the AS number and additional
information of the website currently open
• RIPE Routing Information Service (http:/ / www.ripe.net/ ris/ index. html) collecting over 550 IPv4 and IPv6
BGP feeds at 14 sites around the world
• RIS Looking Glass (http:/ / www. ris. ripe.net/ cgi-bin/ lg/index. cgi) into the Default Free Routing zone of the
• RISwhois (http:/ / www. ripe.net/ projects/ ris/ tools/ riswhois. html) providing IPv4/IPv6 Address to BGP AS
Origin Mapping
• RIS BGPlay (http:// www. ris. ripe.net/ bgplay/ ) BGP routing visualization tool by Università degli Studi Roma
• Linux Magazine: Demystifying BGP (http:/ / www.linux-mag.com/ 2003-05/ bgp_01.html) (Good, Detailed
BGP explanation; requires registration)
• BGP config generator (http:// www. oriontechnologysolutions. com/ administration/ basic-bgp-config-generator/
) Free web-based tool to generate a Cisco/Quagga BGP configuration
• Some important BGP RFCs
• RFC 4271, A Border Gateway Protocol 4 (BGP-4)
• RFC 4456, BGP Route Reflection - An Alternative to Full Mesh Internal BGP (IBGP)
• RFC 4278, Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the
BGP-4 Specification
• RFC 4277, Experience with the BGP-4 Protocol
• RFC 4276, BGP-4 Implementation Report
Border Gateway Protocol
• RFC 4275, BGP-4 MIB Implementation Survey
• RFC 4274, BGP-4 Protocol Analysis
• RFC 4273, Definitions of Managed Objects for BGP-4
• RFC 4272, BGP Security Vulnerabilities Analysis
• RFC 3392, Capabilities Advertisement with BGP-4
• RFC 5065, Autonomous System Confederations for BGP
• RFC 2918, Route Refresh Capability for BGP-4
• RFC 1772, Application of the Border Gateway Protocol in the Internet Protocol (BGP-4) using SMIv2
• RFC 4893, BGP Support for Four-octet AS Number Space
• RFC 2439, BGP Route Flap Damping
• RFC 4760, Multiprotocol Extensions for BGP-4
• Obsolete RFCs
• RFC 2796, Obsolete - BGP Route Reflection - An Alternative to Full Mesh IBGP
• RFC 3065, Obsolete - Autonomous System Confederations for BGP
• RFC 1965, Obsolete - Autonomous System Confederations for BGP
• RFC 1771, Obsolete - A Border Gateway Protocol 4 (BGP-4)
• RFC 1657, Obsolete - Definitions of Managed Objects for the Fourth Version of the Border Gateway
• RFC 1655, Obsolete - Application of the Border Gateway Protocol in the Internet
• RFC 1654, Obsolete - A Border Gateway Protocol 4 (BGP-4)
• RFC 1105, Obsolete - Border Gateway Protocol (BGP)
• RFC 2858, Obsolete - Multiprotocol Extensions for BGP-4
• BGP Interactions at Router Startup Described as a Sequence Diagram (http:// www.eventhelix. com/
RealtimeMantra/ Networking/bgp_startup. pdf) (PDF)
• BGP Protocol Service Level Traffic Variations [[Mu Dynamics (http:// www.mudynamics. com/ products/
protocol. html)]]
• BGP Route Reflection Troubleshooting (http:/ / blog. ipexpert.com/ 2009/ 12/ 21/
bgp-route-reflection- -troubleshooting/)
Bridging Systems Interface
Bridging Systems Interface
Bridging Systems Interface is a standard protocol for communicating with physical interfaces which attach analog
or digital voice radios to digital data networks—known as 'Radio over IP'--to make easier the use of remote radios by
local users, and the sharing of radios by multiple users, in the service of improving emergency communications
interoperability. The standard is promulgated by the SAFECOM program in the US Department of Homeland
Security's Office for Interoperability and Compatibility, specifically, the VoIP Working Group [1].
Technical Details
The working group has broken down the problem of moving public safety communications audio over data (usually
TCP/IP) networks into 5 specific interface points:
• Radio System Interface – an interface that enables VoIP communication to radio system infrastructure
• Dispatch Interface – an interface to a dispatch console
• End Unit (Software Device) Interface – an interface that allows a network-connected computing device to
connect into a radio system using a software implementation
• Radio Site Interface – an interface to a base station or similar device
• Bridging Systems Enhanced Interface – additional functions of the BSI Core Profile, an interface between
bridging or gateway devices
To quote the working group's pseudo-RFC standards proposal [2]:
A bridging system is a device that enables voice communication among disparate radio frequencies, systems,
or technologies. The disparate devices connected via a bridging device may include land mobile radios, analog
phones, mobile phones, IP telephones, and personal computers; however, this is not an exhaustive list of
connective devices. The interface through which bridging systems communicate with each other is the
Bridging Systems Interface (BSI).
This interface is based on SIP, the Session Initiation Protocol, and the document provides standardized mappings
between that protocol and the actual functions that are provided by individual radio hardware, whatever those might
[1] http:/ / www. safecomprogram.gov/ SAFECOM/ currentprojects/voip/
[2] http:/ / www. safecomprogram.gov/ NR/ rdonlyres/ 451E8E25-9206-46DC-88CE-12C8858FE61C/0/
BridgingSystemsInterfaceCoreProfile11_FINAL. pdf
BSDRadius is open source RADIUS server targeted for use in Voice over IP (VoIP) applications. While there are
quite large number of Radius servers (including free) available in the world, little number of them (if any) are
developed with VoIP specific needs in mind. Typical VoIP RADIUS server should be able to take high amount of
AAA requests in short time periods, handle large databases, and respond timely to prevent time-outs and request
retransmission cases. Most commonly used VoIP protocols (SIP and H.323) use small number of Authentication
methods (e.g. CHAP and Digest), and this can allow reduce processing overhead and code size of server.
The server is released under the BSD license.
BSDRadius uses very nice and graceful library - pyrad - for lower level operations such as parsing attribute
dictionaries and building accounting and authorization packets. Due to extensive use of Python, BSDradius is as
portable as Python is. There should not be any problem using it on any distribution of Linux or any flavour of BSD
(FreeBSD, OpenBSD, NetBSD). It is theoretically also possible to run it on Windows, although there are no plans to
do it.
Webstuff is opensource library released under BSD license. It exists as separate project from BSDRadius and is
intended for use in enterprise level Python based applications. Webstuff is created for using it within networked
environment. It also contains simple but powerful web application framework for rapid building of web applications.
Webstuff contains also bunch of useful utilities for configuration file parsing, easier logging, operations with
database, session management etc. As from BSDRadius 0.7.0 webstuff is bundled within distribution package of
BSDRadius. You can safely use BSDRadius with bundled webstuff togeather with standalone version of this library
because bundled version appears as part of BSDRadius instead of separate package.
• RADIUS - compliant AAA (Authentication, Authorization, Accounting) server
• Various database engines: MySQL, PostgreSQL (support for Oracle is under development)
• CHAP-password authentication for H.323
• Digest authentication for SIP
• Vendor specific dictionary files (Cisco, Quintum). Works with other NASes, supporting Cisco style VSAs:
GnuGK gatekeeper, Mera MVTS (including SIP-HIT module), Nextone.
• Very easy to use custom module interface
• Comfortable framework for building RADIUS applications
• Logging of received, failed and rejected requests to separate files for easier later processing
• Storing RADIUS server client data into database. It may be very helpful in large setup environment.
• Platform independent
• Ready to use CLI RADIUS client
External links
• www.bsdradius.org
- official project home page
[1] http:/ / www. bsdradius. org
CA/Browser Forum
CA/Browser Forum
The Certification Authority Browser Forum, also known as CA/Browser Forum, is a voluntary consortium of
certification authorities and browser industry leaders that created the SSL certificates, and vendors of Internet
browser software and other applications.
In 2007, the CA/Browser Forum published “Guidelines For The Issuance And Management Of Extended Validation
(EV) Certificates”. The EV SSL standard improves security for Internet transactions and creates a more intuitive
method of displaying secure sites to Internet users. In order for Certification Authorities to issue EV SSL
Certificates, they must be audited for compliance with the Forum's EV Guidelines
In April 2011, the CA/Browser Forum released a new draft "Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates”
for public consultation. The intent is that all browser and relying
party application software developers will incorporate the Baseline Requirements into their accreditation and
approval schemes as requirements for all applicants who request that a self-signed root certificate be embedded as a
trust anchor. This would extend common standards for issuing SSL/TLS certificates beyound EV to include all
Domain-validated (DV) and Organisation-validation (OV/IV) certificates.
In 2005 Melih Abdulhayoglu organized
and arranged the first meeting of CA/Browser Forum. The first meeting
was held in the hotel Club Quarters Downtown New York. This forum was then registered and started during
December, 2005, in Scottsdale, Arizona with the main objective to enable secure connections between users and
As of February, 2009, the CA/Browser Forum included Certificate Authority members, as many as 32, and 6 Internet
Browser Software Vendors. The Information Security Committee of the American Bar Association Section of
Science & Technology, Law and the Canadian Institute of Chartered Accountants have participated in developing
the standards for Extended Validation SSL certificate procedures and standards. CA/Browser Forum is interested in
tackling EV code signing next
It is a great step forward in establishing verified identity for websites considers MSDN in its blog post
. Also,
Microsoft's vision is that the backbone of an Internet identity system is composed of Extended Validation SSL
Certificates intimately integrated with the users' browsing experience
The tougher certificates, coupled with browser developments
, could help fight phishing, which threatens the multi
billion dollar online retail market.
[1] CA/Browser Extended Validation Guidelines (http:/ / cabforum.org/ EV_Certificate_Guidelines.pdf)
[2] "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (http:// cabforum.org/
Baseline_Requirements_Draft_30b. pdf/)
[3] eWeek Article about Origins of CA/Browser Forum and EV SSL (http:// www.eweek.com/ c/ a/ Security/
How-Can-We-Improve-Code-Signing/ )
[4] Verisign Blog Post - CA/Browser Forum is interested in tackling EV code signing next (https:// blogs. verisign.com/ ssl-blog/
[5] Extended Validation Guidelines v1 Released (http:// blogs. msdn. com/ ie/ archive/2007/ 06/ 12/ extended-validation-guidelines-v1-released.
[6] Microsoft information on EV in IE7 (http:/ / www.microsoft.com/ windows/ products/winfamily/ ie/ ev/ default.mspx)
[7] CNet News - Browsers to get sturdier padlocks (http:/ / news. cnet.com/ Browsers-to-get-sturdier-padlocks/2100-1029_3-5989633.html)
CA/Browser Forum
External links
• CA/Browser Forum Website (http:/ / www. cabforum.org/)
• CAs approved for EV in Microsoft IE7 (http:// support. microsoft. com/ kb/ 931125)
• Microsoft's Internet Identity Technology Gets Certified (http:/ / news. softpedia. com/ news/
Calendaring Extensions to WebDAV, or CalDAV, is an Internet standard allowing a client to access scheduling
information on a remote server. It extends WebDAV (HTTP-based protocol for data manipulation) specification and
uses iCalendar format for the data. The protocol is defined by RFC 4791. It allows multiple client access to the same
information thus allowing cooperative planning and information sharing. Many server and client applications support
the protocol.
The CalDAV specification was first published in 2003 as an Internet Draft submitted to the Internet Engineering
Task Force (IETF). In March 2007, the CalDAV specification was described in the RFC 4791. CalDAV is designed
for implementation by any collaborative software, client or server, that needs to maintain, access or share collections
of events. It is developed as an open standard to foster interoperability between software from different
The architecture of CalDAV (partially inherited from the underlying specifications) organizes the data (events, tasks,
free-busy info, notes) in directories (collections), where multiple items (resources) reside. The resources and
collections can be accessed by one or more users, using standard HTTP and DAV semantics to detect conflicting
changes, or to provide locking.
For access control the concept of ACLs are used, so each operation (view, edit, delete etc.) can be denied or granted
per user. Therefore the specification requires that CalDAV servers must support "WebDAV Access Control
Protocol" (RFC 3744). The calendar resources must use iCalendar format, which allows the server to understand and
process the data. Parsing the iCalendar items is necessary, because the server has to support a number of
calendaring-specific operations such as doing free-busy time reports and expansion of recurring events. With this
functionality, a user may synchronize his or her own calendar to a CalDAV server, and share it among multiple
devices or with other users. The protocol also supports non-personal calendars, such as calendars for sites or
• On August 7, 2006, Apple Computer announced that Mac OS X 10.5 "Leopard" would include iCal 3.0, an
application that supports the CalDAV access and scheduling standards.
Mac OS X Server 10.5 Leopard
includes iCal Server, which implements the CalDAV access and scheduling protocols.
. The iCal Server has
been released under an open source license as the Darwin Calendar Server.
On March 17, 2009, Apple
Computer announced that CalDAV would be included in the iPhone 3.0 SDK.
• DAViCal is an open source calendaring server that uses the CalDAV format compatible with multiple calendaring
• dotCal, a calendar web app
• Fabasoft Folio Cloud
• Zimbra
• Oracle Beehive, a unified communication and collaboration software solution, supports a number of open
standards including CalDAV
. This allows Beehive to work with a number of calendaring clients including
Apple iCal, Mozilla Lightning, and Mozilla Sunbird
• Google Calendar supports CalDAV using iCal 3.x
and Mozilla Sunbird 0.8+
• Yahoo! Calendar supports CalDAV using iCal 3.x
• The Mozilla Calendar Project applications (Lightning, a plugin for Thunderbird and Sunbird, a standalone
version) also support CalDAV calendars. Other freely available client software include Evolution, Mulberry,
Chandler and eM Client.
• Synchronica, a developer of mobile push email and synchronization solutions announced that their Synchronica
Mobile Gateway and Synchronica Mobile Backup products are both fully compatible with the CalDAV standard,
allowing compatibility across a wide range of calendar applications.
• Tryton, an Open source platform for business solution, supports CalDAV server since version 1.4
• Atmail provides a complete client & server Calendaring solution - Based on the CalDAV protocol, Atmail
provides a complete, full server implementation, and support for a wide range of desktop clients and mobile
• Kerio Connect (formerly Kerio MailServer) - supports CalDAV since version 6.5
• Bedework (formerly UWCalendar)
• SabreDAV, a WebDAV framework for PHP, supports CalDAV since version 1.2
• RadiCALe, a CALDEV server in Python (programming language)
• CalDAV-Sync provides event synchronization via CalDAV for Android devices
[1] iCal (http:/ / www. apple. com/ macosx/ what-is-macosx/ mail-ical-address-book.html) at Apple Mac OS 10.5.
[2] iCal Server (http:/ / www.apple. com/ server/macosx/ features/ical-server.html), Apple Mac OS 10.5.
[3] Calendar Server (http:// trac. calendarserver.org/projects/ calendarserver), Darwin.
[4] DAViCal (http:// www.davical. org/ ), DAViCal CalDAV Server
[5] (http:// www. dotCal. com), dotCal
[6] Oracle Beehive Collaboration Platform (http:// www. oracle. com/ technology/ products/ beehive/ platform.html), Support for CalDAV
[7] Oracle Beehive CalDAV Clients (http:// download. oracle.com/ docs/ cd/ E14897_01/ bh.100/ e14833/ services.htm#CJADAABA), Oracle
Beehive 1.5
[8] Google Calendar (http://www. google.com/ support/ calendar/ bin/ answer.py?answer=99355), CalDAV support using iCal.
[9] Introduction to CalDAV Support (http:// www. google. com/ support/ calendar/ bin/ answer.py?answer=99357)
[10] Yahoo! Calendar (http:// help. yahoo. com/ l/ us/ yahoo/ calendar/ yahoocalendar/sync/ sync-01.html), What is CalDAV sync?
[11] Calendaring Extensions to WebDAV (CalDAV) (http:/ / www.synchronica.com/ products/ caldav.html), Synchronica.
[12] Tryton News (http:/ / news. tryton. org/2009/ 10/ tryton-14-is-available.html), Tryton
[13] SabreDAV Download (http:/ / code. google. com/ p/ sabredav/ ), SabreDAV
[14] Radicale (http:/ / www. radicale. org/)
[15] CalDAV-Sync (http:// dmfs. org/ caldav/ )
External links
• RFC 2616 – HTTP
• RFC 3744 – WebDAV Access Control Protocol
• RFC 4791 – CalDAV
• RFC 4918 – WebDAV
• RFC 5545 – iCalendar
• RFC 5546 – iTIP
• CalDAV Resource Site (http:/ / caldav. calconnect. org/)
• CalConnect, The Calendaring and Scheduling Consortium (http:/ / www.calconnect. org/)
• WebDAV Resources (http:/ / webdav. org/)
CardDAV is an address book client/server protocol designed to allow users to access and share contact data on a
The CardDAV protocol is being developed by the IETF and is currently an internet draft.
CardDAV is based on
WebDAV, which is based on HTTP and it uses vCard for contact data.
The following products have an implementation of CardDAV:
• Apple Address Book Server.

• Apple Address Book in Mac OS X v10.6 "Snow Leopard".
• Apple iOS, starting from iOS 4.
• Atmail supports a complete CardDAV client via the Webmail interface
• DAViCal supports CardDAV from version
• eM Client

• SOGo Connector

• Kerio Connect

• Zimbra 6 allows access to its address book via CardDAV.
• KDE/Trinity Software Compilation 3.5.12 features CardDAV client support via the libcarddav library. It is
available for use by Kaddressbook, which is part of KDE/Trinity's Kontact PIM suite.
• libcarddav provides full featured CardDAV client support to application developers. It utilizes libcurl for low
level operations, and is licensed under the GPL.
• KDE Software Compilation 4.5 will feature CardDAV client support, due in August 2010. It will be available for
use by Kaddressbook, which is part of Kontact PIM suite. It will be provided by Akonadi: a PIM server which
will also make the data available to other applications.
• ServiceM8 provides access to client address book via CardDAV.
• CardDAV-Sync provides contact synchronization via CardDAV for Android devices
• CommuniGate Pro supports CardDav protocol.
[1] CardDAV Resources (http:/ / carddav.calconnect. org/ index.html), CalConnect, , retrieved April 10, 2010
[2] CardDAV: Related Standards (http:// carddav.calconnect. org/ standards.html), CalConnect, , retrieved April 11, 2010
[3] Implementations: CardDAV Servers (http:// carddav.calconnect.org/ implementations/ servers.html), CalConnect, , retrieved April 10, 2010
[4] Mac OS X Server: Address Book Server (http:/ / www.apple.com/ server/macosx/ features/addressbook-server.html), Apple Inc, , retrieved
April 10, 2010
[5] Implementations: CardDAV Clients (http:// carddav. calconnect.org/implementations/ clients. html), CalConnect, , retrieved April 10, 2010
[6] Eran Dilger, Daniel (June 25, 2010), iPhone 4 and iOS vs. Android: desktop and cloud services (http:/ / www.appleinsider.com/ articles/ 10/
06/25/ iphone_4_and_ios_vs_android_desktop_and_cloud_services. html& page=3), AppleInsider, , retrieved July 24, 2010
[7] Atmail Client: CardDAV interface (http:// atmail. com/ webmail-client/ address-book/ ), Atmail, , retrieved May 26, 2010
[8] DAViCal release (http:// freshmeat.net/ projects/ davical/ releases/ 322141), Freshmeat, , retrieved September 24, 2010
[9] eM Client: Features (http:/ / www.emclient. com/ features), eM Client, , retrieved April 10, 2010
[10] SOGo Overview (http:// www.sogo. nu/ about/ overview. html), Inverse Inc, , retrieved July 24, 2010
[11] Kerio Connect (http:/ / www.kerio. com), Kerio Technologies, , retrieved April 10, 2010
[12] Yoon Lee, Jong (September 25, 2009), Zimbra Server: CardDAV server (http:/ / bugzilla.zimbra.com/ show_bug. cgi?id=22008#c25),
Zimbra/VMWare Inc, , retrieved April 24, 2010
[13] Trinity Desktop Environment (http:/ / trinity. pearsoncomputing. net/ ), Timothy Pearson/Trinity Project, , retrieved July 23, 2010
[14] Trinity Related Projects: libcarddav (http:// trinity.pearsoncomputing. net/ related_projects/ libcarddav), Timothy Pearson/Trinity Project, ,
retrieved July 23, 2010
[15] Koenig, Tobias (February 4, 2010), CalDAV/CardDAV/GroupDAV Support for Akonadi (http:// tokoe-kde. blogspot. com/ 2010/ 02/
caldavcarddavgroupdav-support-for.html), Blogspot, , retrieved April 24, 2010
[16] Ford, Ben (August 27, 2010), ServiceM8 now supports CardDAV (http:// servicem8.com/ blog/ 2010/ 08/
servicem8-now-supports-carddav/ ), ServiceM8, , retrieved August 27, 2010
[17] CardDAV-Sync (http:// dmfs. org/carddav/ ), dmfs, , retrieved March 6, 2011
[18] {{citation | url=http:// www. communigate. com/ cgatepro/WebDAV. html#CardDAV | CommuniGate Pro support of CardDav | first= |
last= | publisher= | date= | accessdate=Apr 21, 2011
External links
• The Internet Engineering Task Force (IETF) (http:// www.ietf.org/ )
• CardDAV Resources (http:/ / carddav.calconnect.org/ )
CCSO Nameserver
CCSO Nameserver
A CCSO name-server or Ph protocol was an early form of database search on the web. In its most common form it
was used to look up information such as phone numbers and e-mail addresses.
Today this service has been largely
replaced by LDAP. It was used mainly in the early-to-middle 1990s.
The name-server was developed by Steve
Dorner at the University of Illinois at Urbana-Champaign.
The name-server directories were frequently organized in Gopher hierarchies. The tools "Ph" and "Qi" were the two
components of the system: Ph was a client that queried the Qi server.
The Ph protocol was formally defined by RFC 2378 in September 1998. However the memo issued at this time
references its prior use for an unspecified period of time before this date.
It defines sixteen keywords that can be
used on the server side to define record properties. It also defines how clients should access records on the server and
what responses the server should give. Ph sever communication takes place on TCP port 105.
Command Structure
All commands and response are initially assumed to be in US-ASCII encoding for historical reasons unless the client
explicitly asks for 8-bit(ISO-8859-1) encoding. As a result only characters between 0x20 and 0x7f are initial sent by
the server in raw form. Other characters if present in entries will be escaped using the RFC 2045 defined
"Quoted-Printable" encoding. The initial request from the client is a text base keyword optionally followed by one or
more parameters as defined in the RFC 2378. The server then responds to the request. The following example
response to a status request is provided by the RFC memo.
C: status
S: 100:Qi server $Revision: 1.6 $
S: 100:Ph passwords may be obtained at CCSO Accounting,
S: 100:1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday.
S: 100:Be sure to bring your U of I ID card.
S: 200:Database ready
Each command defined by the RFC 2378 memo consists of a keyword followed as needed by one or more
parameters or key words. They can be separated by spaces tabs or the end of the line. Each line must be terminated
in CRLF style.
The following are a few of the commands:
This command takes no parameters and simply asks the server to report its status as above.
Returns information such as server version mail domain and who to contact about password issues and
authentication methods.
fields [field ...]
List all available entry fields on the server or only those of the specified name or names.
id information
CCSO Nameserver
Causes the server to log the specified information as the current user id without login.
set [option[=value] ...]
Sets the specified option on the server to value. If used without parameters it lists the current server settings.
login [alias]
This is the actual login/logout commands for the server here the alias must be the users Ph alias. Logging in allows a
user to change their own entry and view certain fields in it flag for restricted access.
answer encrypted-response
clear cleartext-password
The client normally uses one of these to send the password information after the login command is sent.
One or more of these will be recognized by the server as an end of session command closing the connection.
As distributed, the nameserver was backed by a flat file database. In the early 1990s, Indiana University software
developer Larry Hughes implemented a version of Qi (called "Phd") that was written in perl and backed by a
relational database. That code was distributed under an open source license for several years prior to the university's
transition to LDAP.
[1] "ph (cso nameserver) Frequently Asked Questions (FAQ)" (http:// www. faqs.org/faqs/ ph-faq/). . Retrieved 2007-05-12.
[2] "Ph and Gopher" (http:/ / groups. google.com/ group/ comp. infosystems. gopher/ browse_frm/thread/ eef4cfbdbc862afe/
9cbc3e3690b8fb4e?lnk=st& q="cso+ nameserver"& rnum=19&hl=en#9cbc3e3690b8fb4e). . Retrieved 2007-09-18.
[3] "RFC 2378 - The CCSO Nameserver (Ph) Architecture" (http:/ / www.faqs.org/rfcs/rfc2378.html). . Retrieved 2007-07-14.
Certificate Management over CMS
Certificate Management over CMS
CMC (Certificate Management over CMS)
family: unknown
field of application : certificate management
newest version: RFC 5272
application CMC CMC
transport TCP
Internet IP (IPv4, IPv6)
link Ethernet Token
FDDI ...
proposed standard: RFC 5272
obsolete standard: RFC 2797
The Certificate Management over CMS (CMC) is an internet standard by the IETF, defining transport mechanisms
for the Cryptographic Message Syntax (CMS). It is defined in RFC 5272, its transport mechanisms in RFC 5273. It
is one of two protocols utilizing the Certificate Request Message Format (CRMF), described in RFC 4211, with the
other protocol being the Certificate Management Protocol (CMP).
Certificate Management Protocol
CMP (Certificate Management Protocol)
family: unknown
field of application : certificate management
newest version: cmp2000(2)
OID of the newest version:
TCP/UDP port: 829 (pkix-3-ca-ra)
application CMP CMP
transport TCP
Internet IP (IPv4, IPv6)
link Ethernet Token
FDDI ...
proposed standard: RFC 4210 (CMP, 2005)
obsolete standard: RFC 2510 (CMP, 1999)
Certificate Management Protocol
The Certificate Management Protocol (CMP) is an Internet protocol used for obtaining X.509 digital certificates in
a public key infrastructure (PKI). It is described in RFC 4210 and is one of two protocols so far to use the Certificate
Request Message Format (CRMF), described in RFC 4211, with the other protocol being Certificate Management
over CMS (CMC), described in RFC 5273. An obsolete version of CMP is described in RFC 2510, the respective
CRMF version in RFC 2511.
CMP messages are encoded in ASN.1, using the DER method and usually encapsulated in HTTP.
PKI Entities
A certificate authority (CA), issuing the certificates, acts as the server in a PKI using CMP. One of the clients,
obtaining their digital certificates by means of this protocol is called end entity (EE). None or any number of
registration authorities (RA), can be used to mediate between the EEs and the CA.
An EE can utilize CMP to obtain certificates from the CA. This can be done through an "initial
registration/certification", a "key pair update" or a "certificate update" message sequence. By means of a revocation
request it can also get one of its own certificates revoked. Using a "cross-certification request" a CA can get a
certificate signed by another CA. In case an EE has lost its private key and it is stored by the CA, it might be
recovered by requesting a "key pair recovery".
Several means of transportation are foreseen for conveying CMP messages:
• Encapsulated in a HTTP message.
• TCP or any other reliable, connection-oriented transport protocol.
• As a file, e.g. over FTP or SCP.
• By E-Mail, using the MIME encoding standard.
The Content-Type used is application/pkixcmp; older versions of the draft used application/pkixcmp-poll,
application/x-pkixcmp or application/x-pkixcmp-poll.
• The library cryptlib provides CMP support.
• EJBCA, a CA, implements a subset
of the CMP functions.
• OpenSSL is capable of producing and parsing CMP messages, using an additional patch.
[1] draft-ietf-pkix-cmp-transport-protocols - Internet X.509 Public Key Infrastructure - Transport Protocols for CMP (latest version) (http://
tools.ietf.org/html/ draft-ietf-pkix-cmp-transport-protocols)
[2] EJBCA - The J2EE Certificate Authority (http:// ejbca. sourceforge.net/ features.html)
[3] CMP for OpenSSL, Sourceforge Project page (https:// sourceforge.net/ projects/ cmpforopenssl/ )
Challenge-handshake authentication protocol
Challenge-handshake authentication protocol
In computing, the Challenge-Handshake Authentication Protocol (CHAP) authenticates a user or network host to
an authenticating entity. That entity may be, for example, an Internet service provider.
CHAP provides protection against playback attack by the peer through the use of an incrementally changing
identifier and of a variable challenge-value. CHAP requires that both the client and server know the plaintext of the
secret, although it is never sent over the network.
Microsoft has implemented a variant of the Challenge-handshake authentication protocol, called MS-CHAP, which
does not require either peer to know the plaintext.
Working Cycle
CHAP is an authentication scheme used by Point to Point Protocol (PPP) servers to validate the identity of remote
clients. CHAP periodically verifies the identity of the client by using a three-way handshake. This happens at the
time of establishing the initial link, and may happen again at any time afterwards. The verification is based on a
shared secret (such as the client user's password).
1. After the completion of the link establishment phase, the authenticator sends a "challenge" message to the peer.
2. The peer responds with a value calculated using a one-way hash function on the challenge and the secret
3. The authenticator checks the response against its own calculation of the expected hash value. If the values match,
the authenticator acknowledges the authentication; otherwise it should terminate the connection.
4. At random intervals the authenticator sends a new challenge to the peer and repeats steps 1 through 3.
CHAP Packets
Description 1 byte 1 byte 2 bytes 1 byte Variable variable
Challenge Code = 1 ID Length Challenge length Challenge value Name
Response Code = 2 ID Length Response Length Response value Name
Success Code = 3 ID Length Message
Failure Code = 4 ID Length Message
• RFC 1994
Character Generator Protocol
Character Generator Protocol
The Character Generator Protocol (CHARGEN) is a service of the Internet Protocol Suite defined in RFC 864 in
1983 by Jon Postel. It is intended for testing, debugging, and measurement purposes.
A host may connect to a server that supports the Character Generator Protocol on either Transmission Control
Protocol (TCP) or User Datagram Protocol (UDP) port number 19. Upon opening a TCP connection, the server starts
sending arbitrary characters to the connecting host and continues until the host closes the connection. In the UDP
implementation of the protocol, the server sends a UDP datagram containing a random number (between 0 and 512)
of characters every time it receives a datagram from the connecting host. Any data received by the server is
Inetd implementation
On most UNIX-like operating systems a CHARGEN server is built into the inetd (or xinetd) daemon. The
CHARGEN service is usually not enabled by default. It may be enabled by adding the following lines to the file
/etc/inetd.conf and telling inetd to reload its configuration:
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
The CHARGEN service may be used as a source of a byte-stream for debugging TCP network code for proper
bounds checking and buffer management. It may also be a source of generic payload for bandwidth measurement
and/or QoS fine-tuning. Although consideration must be given if hardware compression is active, as the output from
the CHARGEN service is easily and efficiently compressed. This compression can cause bandwidth tests to report
the size of the data after decompression, instead of the actual amount of data which passed the wire.
Sample session
A typical CHARGEN service session looks like this: The user connects to the host using a telnet client. The user
receives a stream of bytes. Although the specific format of the output is not prescribed by RFC 864, the
recommended pattern (and a de-facto standard) is shifted lines of 72 ASCII characters repeating.
$ telnet localhost chargen
Connected to localhost.
Escape character is '^]'.
Character Generator Protocol
telnet> quit
Connection closed.
This continues until the TCP connection is closed as shown in the trace by ending the telnet session.
The service was used maliciously to crash MS DNS servers running Microsoft Windows NT 4.0 by piping the
arbitrary characters straight into the DNS server listening port (telnet ntbox 19 | telnet ntbox 53).
However, the
attack was presumably a symptom of improper buffer management on the part of Microsoft's DNS service and not
directly related to the CHARGEN service.
[1] "Access Violation in Dns.exe Caused by Malicious Telnet Attack" (http:/ / support.microsoft.com/ kb/ 169461). Support.microsoft.com.
2006-11-01. . Retrieved 2009-05-31.
Cipher suite
A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC)
algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS)
or Secure Sockets Layer (SSL) network protocol.
The structure and use of the cipher suite concept is defined in the documents that define the protocol (RFC 5246
standard for TLS version 1.2). A reference for named cipher suites is provided in RFC 2434, the TLS Cipher Suite
When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this
handshake, a client hello (ClientHello) and a server hello (ServerHello) message is passed. (RFC 5246, p. 37) First,
the client sends a cipher suite list, a list of the cipher suites that it supports, in order of preference. Then the server
replies with the cipher suite that it has selected from the client cipher suite list. (RFC 5246, p. 40) In order to test
which TLS ciphers that a server supports an SSL/TLS Scanner may be used.
Cipher suite
Detailed description
Each named cipher suite defines a key exchange algorithm, a bulk encryption algorithm, a message authentication
code (MAC) algorithm, and a pseudorandom function (PRF). (RFC 5246, p. 40)
• The key exchange algorithm is used to determine if and how the client and server will authenticate during the
handshake. (RFC 5246, p. 47).
• The bulk encryption algorithm is used to encrypt the message stream. It also includes the key size and the
lengths of explicit and implicit initialization vectors (cryptographic nonces). (RFC 5246, p. 17)
• The message authentication code (MAC) algorithm is used to create the message digest, a cryptographic hash of
each block of the message stream. (RFC 5246, p. 17)
• The pseudorandom function (PRF) is used to create the master secret, a 48-byte secret shared between the two
peers in the connection. The master secret is used as a source of entropy when creating session keys, such as the
one used to create the MAC. (RFC 5246, p. 16-17, 26)

Examples of algorithms used
key exchange
RSA, Diffie-Hellman, ECDH, SRP, PSK
bulk ciphers
RC4, Triple DES, AES, IDEA, DES, or Camellia. In older versions of SSL, RC2 was also used.
message authentication
for TLS, a Hash-based Message Authentication Code using MD5 or one of the SHA hash functions is used.
For SSL, SHA, MD5, MD4, and MD2 are used.
Programming references
Programatically, a cipher suite is referred to as:
CipherSuite cipher_suites
a list of the cryptographic options supported by the client (RFC 5246, p. 41)
CipherSuite cipher_suite
the cipher suite selected by the server and revealed in the ServerHello message (RFC 5246, p. 42-43, 64)
[1] "CipherSuites and CipherSpecs" (http:/ / publib. boulder. ibm. com/ infocenter/wmqv6/v6r0/ index.jsp?topic=/ com.ibm. mq. csqzas. doc/
sy10700_. htm). IBM. . Retrieved 20 November 2009.
[2] "Cipher Suites in Schannel" (http:// msdn. microsoft. com/ en-us/ library/aa374757(VS.85).aspx). Microsoft MSDN. . Retrieved 20
November 2009.
RFC 5246 standard for TLS version 1.2
TLS Cipher Suite Registry (http:/ / www. iana. org/ assignments/ tls-parameters/ tls-parameters.
xhtml#tls-parameters-3) at IANA (http:// www.iana. org)
Cisco WAAS
Cisco WAAS
Cisco Wide Area Application Services (WAAS) is technology that optimizes the performance of TCP-based
applications operating in a Wide Area Network (WAN) environment while preserving and strengthening branch
security. WAAS combines WAN optimization, optimization of the Transport Control Protocol (TCP), Data
Redundancy Elimination (DRE, also known as deduplication) and application protocol acceleration in a single a
network-attached appliance or router-integrated module form factor.
The distributed ADS market was about 4 years old in 2004 when Cisco acquired Actona Technologies. The
acquisition gave Cisco basic wide-area file services (WAFS) techniques. Since then Cisco has been busy integrating
the technology and making several extensions. Cisco calls the resulting software Wide Area Application Services
(WAAS). WAAS delivers a combination of TCP optimization, proxy services, and byte-level and file caching. It
runs on Wide Area Application Engine (WAE) hardware platforms, including standalone appliances and network
modules (NME) for the Cisco Integrated Services Routers (ISRs).
Notably, Cisco was the first to provide a WAN optimization system that was transparent to the network. This was
accomplished by preserving IP packet header details, including IP addresses, and TCP port numbers, which have
been deemed important for intermediary devices and services to function properly. Examples of devices that could
be impacted by packet header obfuscation include firewalls, routers, intrusion detection and prevention systems, and
general quality of service (QoS) techniques. Other providers of this technology have consequently provided solutions
to solving this problem as well.
WAN optimization appliances have traditionally limited IT when it comes to maintaining functions such as security,
Quality of Service, visibility, and monitoring end-to-end transactions because they tend to cause problems for most
network monitoring devices and tools. By design, WAN Optimization “confuses” performance monitoring systems
by changing packet header data.

Latest Release
Cisco's latest WAAS software release, announced at the 2010 Cisco Networkers conference, is version 4.3.1.
Open Source
• Traffic Squeezer
• WANProxy
• Riverbed Steelhead
• Blue Coat ProxySG
• Silver Peak NX, VX & VRX
• Juniper WXC
• Citrix Branch Repeater
Cisco WAAS
[1] The impact of WAN Optimization on TCP Applications (http:// www.networkperformancedaily.com/ 2007/ 07/
[2] Tracking the optimized WAN (http:// www.networkperformancedaily.com/ 2007/ 07/ tracking_the_optimized_wan_net_1.html#more)
[3] http:/ / www. trafficsqueezer.org/
[4] http:/ / wanproxy.org/
• Cisco WAAS product page (http:/ / www. cisco. com/ en/ US/ products/ ps5680/ Products_Sub_Category_Home.
• Making your apps faster, Cisco-style (http:// www.networkworld.com/ supp/ 2007/ ndc4/
• WAAS up with Cisco's WAN Optimization Initiative? (http:/ / www.networkperformancedaily.com/ 2006/ 12/
waas_up_with_ciscos_wan_optimi_1. html)
• NetQoS partners with Cisco WAAS to develop application response time reporting for WAN optimization (http:/
/www. pcdistrict. com/
Common Address Redundancy Protocol
The Common Address Redundancy Protocol or CARP is a protocol which allows multiple hosts on the same local
network to share a set of IP addresses. Its primary purpose is to provide failover redundancy, especially when used
with firewalls and routers. In some configurations CARP can also provide load balancing functionality. It is a free,
non patent-encumbered alternative to Cisco's HSRP, implemented mostly in BSD operating systems.
If there is a single computer running a packet filter, and it goes down, the networks on either side of the packet filter
can no longer communicate with each other, or they communicate without any packet filtering. If, however, there are
two computers running a packet filter, running CARP, then if one fails, the other will take over, and computers on
either side of the packet filter will not be aware of the failure, so operation will continue as normal. In order to make
sure the new master operates the same as the old one, pfsyncd is used to synchronize packet filter states.
Principle of redundancy
A group of hosts using CARP is called a "group of redundancy". The group of redundancy allocates itself an IP
address which is shared or divided among the members of the group. Within this group, a host is designated as
"Master". The other members are called "slaves". The main host is that which "takes" the IP address. It answers any
traffic or ARP request brought to the attention of this address. Each host can belong to several groups of redundancy.
Each host must have a second unique IP address.
A common use of CARP is the creation of a group of redundant firewalls. The virtual IP address allotted to the group
of redundancy is indicated as the address of the default router on the computers behind this group of firewalls. If the
main firewall breaks down or is disconnected from the network, the virtual IP address will be taken by one of the
firewall slaves and the service availability will not be interrupted.
Common Address Redundancy Protocol
In the late 1990s IETF began working on a solution to the problem of shared IPs. In 1997, Cisco informed them that
this was already covered by Cisco patents. In 1998, Cisco told them it was covered by their patent of HSRP (Hot
Standby Router Protocol). Nonetheless, IETF continued work on VRRP (Virtual Router Redundancy Protocol).
After some debate, people decided it was alright to allow patented material in a standard, as long as it was available
under RAND (Reasonable and Non-Discriminatory) Licensing terms. Because VRRP fixed problems with the HSRP
protocol, Cisco began using VRRP instead, while still claiming it as its own.
Cisco informed the OpenBSD developers they would enforce their patent of HSRP. This may have been related to
their lawsuit with Alcatel. Thus, a free implementation of VRRP could not be made. OpenBSD developers started
CARP as an alternative to the patented VRRP, as the "reasonable and non-discriminatory" licensing terms
necessarily excluded open-source implementations. To avoid infringing the HSRP patent, they ensured their idea for
CARP was fundamentally different. Because of OpenBSD's focus on security, CARP was designed with security in
mind, and is designed to use cryptography. It became available
, completely for free, in October 2003. It was
integrated into FreeBSD and released initially with FreeBSD 5.4 in May 2005
. It has since been integrated into
No official internet protocol number
From OpenBSD.org:
As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet
protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had
failed to go through an official standards organization. Consequently we were forced to choose a
protocol number which would not conflict with anything else of value, and decided to place CARP at IP
protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these
decisions, but they declined to reply.
IP protocol numbers at the time when the above request was made were allocated by IANA according to the rules in
RFC 2780, i.e., under the "IESG Approval" or "Standards Action" process (with "Expert Review" being a third
option that was not applicable to this request). Both of these processes require a textual specification describing the
protocol for which a protocol number is requested, which did not exist for CARP. The OpenBSD implementation is
the closest thing to a formal specification of the protocol, but source code - especially source code licensed under
specific terms - is not the same as a textual technical specification. No technical specification was submitted for
CARP, and IANA declined the request.
The incompatible Cisco/IETF VRRP also uses IP protocol 112, having been assigned it by IANA.
[1] http:/ / marc.info/ ?l=openbsd-misc& m=106642790513590
[2] FreeBSD 5.4 i386 release notes (http:// www. freebsd.org/ releases/ 5.4R/ relnotes-i386.html#NET-PROTO), retrieved 2010-01-06
External links
• OpenBSD's carp(4) man page (http:// www. openbsd. org/cgi-bin/man. cgi?query=carp&sektion=4)
• FreeBSD's carp(4) man page (http:/ / www. freebsd.org/ cgi/ man.cgi?query=carp&sektion=4)
• Firewall Failover with pfsync and CARP (http:/ / www.countersiege. com/ doc/ pfsync-carp/)
• UCARP: an userland CARP implementation (http:/ / ucarp. org/)
• NetBSD port of CARP (http:// www. netbsd. org/changes/ 2006.html#carp-support)
• FreeBSD port of CARP (http:// people. freebsd. org/~mlaier/CARP/ )
Common Address Redundancy Protocol
• The OpenBSD song 3.5: "CARP License" and "Redundancy must be free" (http:/ / www.openbsd. org/ lyrics.
Common Indexing Protocol
The Common Indexing Protocol (CIP) was an attempt in the IETF working group FIND during the mid-1990s to
define a protocol for exchanging index information between directory services.
In the X.500 Directory model, searches scoped near the root of the tree (e.g. at a particular country) were
problematic to implement, as potentially hundreds or thousands of directory servers would need to be contacted in
order to handle that query.
The indexes contained summaries or subsets of information about individuals and organizations represented in a
white pages schema. By merging subsets of information from multiple sources, it was hoped that an index server
holding that subset could be able to process a query more efficiently by chaining it only to some of the sources: those
sources which did not hold information would not be contacted. For example, if a server holding the base entry for a
particular country were provided with a list of names of all the people in all the entries in that country subtree, then
that server would be able to process a query searching for a person with a particular name by only chaining it to
those servers which held data about such a person.
The protocol evolved from earlier work developing WHOIS++, and was intended to be capable of interconnecting
services from both the evolving WHOIS and LDAP activities.
This protocol has not seen much recent deployment, as WHOIS and LDAP environments have followed separate
evolution paths. WHOIS deployments are typically in domain name registrars, and its data management issues have
been addressed through specifications for domain name registry interconnection such as CRISP. In contrast,
enterprises that manage employee, customer or student identity data in an LDAP directory have looked to federation
protocols for interconnection between organizations.
• RFC 2651 The Architecture of the Common Indexing Protocol (CIP)
• RFC 2652 MIME Object Definitions for the Common Indexing Protocol (CIP)
• RFC 2653 CIP Transport Protocols
• RFC 2654 A Tagged Index Object for use in the Common Indexing Protocol
• RFC 2655 CIP Index Object Format for SOIF Objects
• RFC 2656 Registration Procedures for SOIF Template Types
• RFC 2657 LDAPv2 Client vs the Index Mesh
Common Open Policy Service
Common Open Policy Service
The Common Open Policy Service (COPS) Protocol is part of the internet protocol suite as defined by the IETF's
RFC 2748. COPS specifies a simple client/server model for supporting policy control over Quality of Service (QoS)
signaling protocols (e.g. RSVP). Policies are stored on servers, and acted upon by Policy Decision Points (PDP), and
are enforced on clients, also known as Policy Enforcement Points (PEP). There are two models of COPS: The
Outsourcing Model and the Provisioning Model, considered from the view of the client or PEP.
The Outsourcing Model is the simplest COPS implementation. In this model, all policies are stored at the PDP.
Whenever the PEP needs to make a decision, it sends all relevant information to the PDP. The PDP analyzes the
information, makes the decision, and relays it to the PEP. The PEP then simply enforces the decision.
In the Provisioning Model, see RFC 3084 COPS Usage for Policy Provisioning (COPS-PR), the PEP reports its
decision-making capabilities to the PDP. The PDP then downloads relevant policies on to the PEP. The PEP can then
make its own decisions based on these policies. The Provisioning Model uses the Policy Information Base as a
repository of the policies.
Internet Draft introduces QoS extensions to the protocol for Multi-Access environment.
See [2] for links to some COPS implementations.
[1] http:/ / vesuvio. ipv6. cselt. it/ internet-drafts/draft-carrozzo-aaa-cops-maid-00.txt
[2] http:/ / www-staff.it. uts. edu.au/ ~simmonds/ BB. htm
Compiled Wireless Markup Language
For the USA radio station, see WMLC.
In networking for mobile devices, WMLC is a format for the efficient transmission of WML web pages over
Wireless Application Protocol (WAP). Its primary purpose is to compress (or rather tokenise) a WML page for
transport over low-bandwidth internet connections such as GPRS/2G.
WMLC is apparently synonymous with Wireless Application Protocol Binary XML (WBXML).
WMLC is most efficient for pages that contain frequently repeated strings of characters. Commonly used phrases
such as "www." and "http://www." are tokenised and replaced with a single byte just before transmission and then
re-inserted at the destination.
WMLC has an added advantage that the data can be progressively decoded unlike some compression algorithms that
require all of the data to be available before decompression begins. As soon as the first few bytes of WMLC data are
available, the WAP browser can start creating the page, this means the user can see the page being constructed as it
is downloaded.
Content type is application/vnd.wap.wmlc
Compiled Wireless Markup Language
[1] http:/ / www. iana. org/assignments/ media-types/ application/ vnd-wap-wmlc
Computer port (software)
For other uses of "port", see port (disambiguation).
In computer programming, port has a wide range of meanings.
A software port (usually just called a 'port') is a virtual/logical data connection that can be used by programmes to
exchange data directly, instead of going through a file or other temporary storage location. The most common of
these are TCP and UDP ports, which are used to exchange data between computers on the Internet.
In Flow-based programming, a 'port' is a (named) point of contact between a process and a connection.
I/O or machine port mechanism
For Input or Output (I/O) operations, nearly all processor families use memory-mapped I/O—the same assembly
instructions are used for both memory access and hardware I/O. However, Intel microprocessors use port-mapped
I/O—they have a completely separate set of assembly instructions (IN, INS, OUT, and OUTS) that are used
specifically for hardware I/O. These instructions figure out which hardware device to communicate with using the
concept of an I/O port or machine port. These ports are numbered based on which hardware device they refer to.
These hardware I/O ports are in a completely different address space from normal memory.
Intel microprocessors generally allow one octet (8-bit byte or word) to be sent or received during each instruction.
The hardware device decides how to interpret data sent to it and what data to send to the processor. For example, a
common use is to ask a hardware device which byte (in a data transfer) it will be sending next.
Some I/O ports are connected with "peripheral" devices outside the CPU itself, but inside the computer case. Other
I/O ports are connected to "peripheral" external devices outside the computer case using some Computer port
Conch (SSH)
Conch (SSH)
For other uses of the term see Conch (disambiguation)
Conch is an implementation of the secure shell (SSH) protocol written in the Python programming language. SSH is
a protocol designed to allow remote access to shells and commands. Conch can be used to implement both the client
and server sides of this protocol.
By using a high-level language like Python, Conch avoids a whole class of potential security problems that
implementations such as OpenSSH have to deal with. Additionally, Conch uses the Twisted networking framework
to offset the need for forking or threading, resulting in a performance boost and reducing memory usage.
Conch was developed by Paul Swartz. It is interoperable with OpenSSH. Conch can be used with Unix/Linux
systems and with Microsoft Windows. It is available as part of the Twisted framework.
[1] The Conch website (http:/ / twistedmatrix. com/ projects/ conch/ ) URL retrieved April 5, 2006
External links
• The Twisted website (http:// twistedmatrix. com/ ) URL retrieved April 5, 2006
Connection-oriented protocol
A connection-oriented networking protocol is one that establishes a communication session, then delivers a stream of
data in the same order as it was sent. It may be a circuit switched connection, or a virtual circuit connection in a
packet switched network. In the latter case, it identifies traffic flows by some connection identifier rather than by
explicitly listing source and destination addresses. Typically, this connection identifier is a small integer (10 bits for
Frame Relay, 24 for ATM, for example). This makes network switches substantially faster (as routing tables are just
simple look-up tables, and are trivial to implement in hardware). The impact is so great, in fact, that even
characteristically connectionless protocols, such as IP traffic, are being tagged with connection-oriented header
prefixes (e.g., as with MPLS, or IPv6's built-in Flow ID field). Example of a connection-oriented protocol at the
transport layer is the TCP protocol.
Connection-oriented protocols are not necessarily reliable protocols. ATM and Frame Relay, for example, are both
examples of a connection-oriented, unreliable protocol. There are also reliable connectionless protocols as well, such
as AX.25 when it passes data in I-frames. But this combination is rare, and reliable-connectionless is uncommon in
commercial and academic networks.
Connection-oriented protocols handle real-time traffic substantially more efficiently than connectionless protocols,
which is why ATM has yet to be replaced with Ethernet for carrying real-time, isochronous traffic streams,
especially in heavily aggregated networks like backbones, where the motto "bandwidth is cheap" fails to deliver on
its promise. Experience has also shown that over-provisioning bandwidth does not resolve all quality of service
issues. Hence, (10-)gigabit Ethernet is not expected to replace ATM at this time.
Some connection-oriented protocols have been designed or altered to accommodate both connection-oriented and
connectionless data.
Connection-oriented protocol
List of connection-oriented protocols
• Connection-oriented Ethernet
• Frame Relay
[1] Ramos-Escano et al. (2005-06-02). "US Patent Application Publication 2005/0117529 A1" (http:// www.google. com/
patents?id=hzKUAAAAEBAJ). . Retrieved 2008-05-19.
Connectionless protocol
In telecommunications, connectionless describes communication between two network end points in which a
message can be sent from one end point to another without prior arrangement. The device at one end of the
communication transmits data addressed to the other, without first ensuring that the recipient is available and ready
to receive the data. Some protocols allow for error correction by requested retransmission. Internet Protocol (IP) and
User Datagram Protocol (UDP) are connectionless protocols.
Connectionless protocols are also described as stateless because the endpoints have no protocol-defined way to
remember where they are in a "conversation" of message exchanges.
List of connectionless protocols
• Hypertext Transfer Protocol
• IP (internet layer, can also be used for connections)
Constrained Shortest Path First
Constrained Shortest Path First
Constrained Shortest Path First (CSPF) is an extension of shortest path algorithms. The path computed using
CSPF is a shortest path fulfilling a set of constraints. It simply means that it runs shortest path algorithm after
pruning those links that violate a given set of constraints. A constraint could be minimum bandwidth required per
link (also known as bandwidth guaranteed constraint), end-to-end delay, maximum number of links traversed,
include/exclude nodes. CSPF is widely used in MPLS Traffic Engineering. The routing using CSPF is known as
Constraint Based Routing (CBR).
The path computed using CSPF could be exactly same as that of computed from OSPF and IS-IS, or it could be
completely different depending on the set of constraints to be met.
Example with bandwidth constraint
Consider the network to the right, where a route has to be computed from router-1 to the router-3 satisfying
bandwidth constrained of x- units, and link cost for each link is based on hop-count (i.e., 1).
An Example network
If x = 50 units then CSPF will give path 1
→ 2 → 3.
If x = 55 units then CSPF will give path 1
→ 4 → 5 → 3.
If x = 90 units then CSPF will give path 1
→ 4 → 5 → 6 → 3.
In all of these cases OSPF and IS-IS will
result in path 1 → 2 → 3.
However, if the link costs in this topology
are different, CSPF may accordingly
determine a different path. For example,
suppose that as before, hop count is used as
link cost for all links but 1 → 2 and 2 → 3,
for which the cost is 4. In this case:
If x = 50 units then CSPF will give path 1
→ 2 → 3.
If x = 55 units then CSPF will give path 1 → 4 → 5 → 3.
If x = 90 units then CSPF will give path 1 → 4 → 5 → 6 → 3.
• Ziegelmann, Mark (2007). Constrained Shortest Path and Related Problems. Constrained Network Optimization
. VDM Verlag Dr. Müller. ISBN 978-3-8364-4633-4.
[1] http:/ / d-nb.info/ 987067745
Cookie exchange
Cookie exchange
The cookie exchange in IPsec comes under the Oakley protocol, which is a protocol of key management. The cookie
exchange requires that each side send a pseudorandomnumber, the cookie, in the initial message, which the other
side acknowledges. This acknowledgement must be repeated in the first message of the Diffie-Hellman key
exchange. If the source address was forged, the opponent gets no answer. Thus, an opponent can only force a user to
generate acknowledgements and not to perform the Diffie-Hellman calculation. Note that "cookies" in the sense of
IPsec are unrelated to HTTP cookies used by web browsers.
The recommended method for creating the cookie is to perform a fast hash (eg. MD5) over the IP source and
destination addresses, the UDP source and destination ports, and a locally generated secret value.
Cross Registry Information Service Protocol
The Cross Registry Information Service Protocol, or CRISP, is a computer network communications protocol
which has been in development by a working group at the Internet Engineering Task Force since 2004. It is meant
partially as a successor to the WHOIS protocol, extending it to a notion of "labels" instead of only working on
domain names and IP addresses.
CRISP can be used to look up authoritative information about a label, such as which organisation owns a given IP
block. It defines mechanisms for routing queries and replies to the appropriate CRISP servers, and query types are
extensible through the use of XML to encode all transported data.
The iris.arpa second-level domain name is reserved for CRISP.
External links
• Cross Registry Information Service Protocol (crisp) Charter
[1] http:/ / www. ietf.org/ wg/ concluded/ crisp
Data Validation and Certification Server
Data Validation and Certification Server
Data Validation and Certification Server (DVCS) is a public key infrastructure or PKI service providing data
validation services, asserting correctness of digitally signed documents, validity of public key certificates and
possession or existence of data.
In practical applications DVCS also helps solve problems with interoperability (numerous digital signature formats)
and security of typical office environments.
External links
• RFC 3029 "Internet X.509 Public Key Infrastructure: Data Validation and Certification Server Protocols"
[1] http:/ / tools. ietf.org/html/ rfc3029
Datagram Congestion Control Protocol
The Datagram Congestion Control Protocol (DCCP) is an experimental message-oriented Transport Layer
protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN),
congestion control, and feature negotiation. DCCP was published as RFC 4340, a proposed standard, by the IETF in
March, 2006. RFC 4336 provides an introduction. Linux had an implementation of DCCP first released in Linux
kernel version 2.6.14 (released October 28, 2005).
DCCP provides a way to gain access to congestion control mechanisms without having to implement them at the
Application layer. It allows for flow-based semantics like in Transmission Control Protocol (TCP), but does not
provide reliable in-order delivery. Sequenced delivery within multiple streams as in the Stream Control Transmission
Protocol (SCTP) is not available in DCCP.
DCCP is useful for applications with timing constraints on the delivery of data that may become useless to the
receiver if reliable in-order delivery combined with network congestion avoidance is used. Such applications include
streaming media, Multiplayer online games and Internet telephony. Primary feature of these applications is that old
messages quickly become stale so that getting new messages is preferred to resending lost messages. Currently such
applications have often either settled for TCP or used User Datagram Protocol (UDP) and implemented their own
congestion control mechanisms, or have no congestion control at all.
While being useful for these applications, DCCP can also be positioned as a general congestion control mechanism
for UDP-based applications, by adding, as needed, a mechanism for reliable and/or in-order delivery on the top of
UDP/DCCP. In this context, DCCP allows the use of different, but generally TCP-friendly congestion control
A DCCP connection contains acknowledgment traffic as well as data traffic. Acknowledgments inform a sender
whether its packets arrived, and whether they were marked by Explicit Congestion Notification (ECN). Acks are
transmitted as reliably as the congestion control mechanism in use requires, possibly completely reliably.
DCCP has the option for very long (48-bit) sequence numbers corresponding to a packet ID, rather than a byte ID as
in TCP. The long length of the sequence numbers is intended to guard against "some blind attacks, such as the
injection of DCCP-Resets into the connection."
Datagram Congestion Control Protocol
DCCP implementations
As of June 2008, at least two DCCP implementations are actively maintained. The Linux kernel implementation was
first available in Linux release 2.6.14.
The dccp-tp implementation is optimized for portability.
[1] RFC 4340 section 7.6 (http:/ / tools. ietf.org/html/ rfc4340#section-7.6)
[2] Linux Foundation (http:/ / www. linuxfoundation.org/en/ Net:DCCP)
[3] dccp-tp implementation (http:// www.phelan-4.com/ dccp-tp/ )
External links
• IETF Datagram Congestion Control Protocol (dccp) Charter (http:// www.ietf.org/html. charters/ dccp-charter.
Protocol Specifications
• RFC 4340 - Datagram Congestion Control Protocol
• RFC 5595 - The Datagram Congestion Control Protocol (DCCP) Service Codes
• RFC 5596 - DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
• RFC 5762 - RTP and the DCCP
• RFC 5238 - Datagram Transport Layer Security (DTLS) over DCCP
• RFC 5643 - Quick-Start for the DCCP
Congestion Control IDs
• RFC 4341 - Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control
• RFC 4342 - Profile for DCCP Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
• RFC 4828 - Profile for DCCP Congestion Control ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)
Other Information
• RFC 4336 - Problem Statement for the Datagram Congestion Control Protocol (DCCP)
• DCCP page from one of DCCP authors (http:/ / www.read.cs. ucla.edu/ dccp/ )
• DCCP support in Linux (http:/ / www. linuxfoundation.org/en/ Net:DCCP)
• Linux gets DCCP (http:/ / lwn. net/ Articles/ 149756/ )
Datagram Transport Layer Security
Datagram Transport Layer Security
In information technology, the Datagram Transport Layer Security (DTLS) protocol provides communications
privacy for datagram protocols. DTLS allows datagram-based applications to communicate in a way that is designed
to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented TLS
protocol and is intended to provide similar security guarantees. The datagram semantics of the underlying transport
are preserved by the DTLS protocol — the application will not suffer from the delays associated with stream
protocols, but will have to deal with packet reordering, loss of datagram and data larger than a datagram packet size.
DTLS is defined in RFC 4347 for use with UDP encapsulation and in RFC 5238 for use with DCCP encapsulation.
External links
• The IETF TLS Workgroup
• The Design and Implementation of Datagram TLS
• SSLBlackbox
- components for Windows and .NET software development with support for DTLS
• AnyConnect
- popular VPN Client that uses TLS and DTLS
• yaSSL.com
- SSL/TLS implementation with support for DTLS in version 1.0.3
• libsystools
- a TLS/DTLS open source library for Windows/Linux using OpenSSL.
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed
under the GFDL.
[1] http:/ / www. ietf.org/ html. charters/tls-charter.html
[2] http:/ / crypto.stanford. edu/ ~nagendra/papers/ dtls. pdf
[3] http:/ / www. eldos. com/ sbb/ desc-ssl. php
[4] http:/ / www. cisco. com/ en/ US/ products/ ps8411/ tsd_products_support_series_home. html
[5] http:/ / www. yassl. com
[6] http:// libsystools. sourceforge.net
Daytime Protocol
Daytime Protocol
The Daytime Protocol is a service in the Internet Protocol Suite, defined in 1983 in RFC 867. It is intended for
testing and measurement purposes in computer networks.
A host may connect to a server that supports the Daytime Protocol on either Transmission Control Protocol (TCP) or
User Datagram Protocol (UDP) port 13. The server returns an ASCII character string of the current date and time in
an unspecified format.
Inetd implementation
On UNIX-like operating systems a daytime server is usually built into the inetd (or xinetd) daemon. The service is
usually not enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf
and telling inetd to reload its configuration:
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
An example output may be:
Tuesday, February 22, 1982 18:45:59-PST
External links
• RFC 867
• List of NIST time servers supporting this protocol
[1] http:/ / tf.nist. gov/ tf-cgi/servers. cgi#
DCE Distributed File System
DCE Distributed File System
The DCE Distributed File System (DCE/DFS)
is the remote file access protocol used with the Distributed
Computing Environment. It was based on the AFS Version 3.0 protocol that was developed commercially by
Transarc Corporation. AFS Version 3.0 was in turn based on the Andrew File System Version 2.0 protocol (also
used by the Coda disconnected file system) originally developed at Carnegie Mellon University.
DCE/DFS consisted of multiple cooperative components that provided a network file system with strong file system
semantics, attempting to mimic the behavior of POSIX local file systems while taking advantage of performance
optimizations when possible. A DCE/DFS client system utilized a locally managed cache that would contain copies
(or regions) of the original file. The client system would coordinate with a server system where the original copy of
the file was stored to ensure that multiple clients accessing the same file would re-fetch a cached copy of the file data
when the original file had changed.
The advantage of this approach is that it provided very good performance even over slow network connections
because most of the file access was actually done to the local cached regions of the file. If the server failed, the client
could continue making changes to the file locally, storing it back to the server when it became available again.
DCE/DFS also divorced the concept of logical units of management (Filesets) from the underlying volume on which
the fileset was stored. In doing this it allowed administrative control of the location for the fileset in a manner that
was transparent to the end user. To support this and other advanced DCE/DFS features, a local journaling file system
(DCE/LFS also known as Episode) was developed to provide the full range of support options.
IBM has not maintained it since 2005: http:// www-306.ibm. com/ software/stormgmt/ dfs/
IBM was working on a replacement for DCE/DFS called ADFS
(Advanced Distributed File System). One major
goal of this project was to decouple DFS from the complexities of DCE's cell directory services (CDS) and security
services (secd). Another key feature would have been the elimination of enctype limitations associated with
DCE/RPC. No public mention of this effort has been made since 2005, leading many to believe the project has been
[1] "File Systems in a Distributed Computing Environment" (http:/ / www. opengroup.org/dce/ info/ papers/ osf-o-wp8-0990-2.ps), Open
Software Foundation, July 1991
[2] http:// www. ibm. com/ developerworks/linux/ library/l-plam/ ?S_TACT=105AGX52&S_CMP=cn-a-l
External links
• DCE Official Web Site (http:// www. opengroup.org/dce/ ).
• Some DCE Papers Available On-Line (http:/ / www.opengroup.org/dce/ info/ papers/ ).
• IBM DFS home (http:/ / www-306.ibm. com/ software/ stormgmt/dfs/ )
Default-free zone
Default-free zone
In the context of Internet routing, the default-free zone (DFZ) refers to the collection of all Internet autonomous
systems that do not require a default route to route a packet to any destination. Conceptually, DFZ routers have a
"complete" BGP table, sometimes referred to as the Internet routing table, global routing table or global BGP
table, but, realistically, the widespread use of route filtering and the rapid rate of change in Internet routing ensure
that no router anywhere has an absolutely complete view of all routes, and any such routing table would, in any case,
look different from the perspective of different routers, even if a stable view could be achieved.
Highly Connected Autonomous Systems and Routers
The Weekly Routing Reports
used by the ISP community come from the Asia-Pacific Network Information
Centre (APNIC) router in Tokyo, which is a well-connected router that has as good a view of the Internet as any
other single router. For serious routing research, however, routing information will be captured at multiple
well-connected sites, including high-traffic ISPs (see the "skitter core") below.
As of June 30, 2007, there were 224622 routes seen by the APNIC router. These came from 25577 autonomous
systems, of which only 74 were transit-only and 22272 were stub/origin-only. 3305 autonomous systems provided
some level of transit.
The obsolete idea of an "Internet core"
The term "default-free zone" is sometimes confused with an "Internet core" or internet backbone, but there has been
no true "core" since before the Border Gateway Protocol (BGP) was introduced. In pre-Internet days, when the
Exterior Gateway Protocol (EGP) was the exterior routing protocol, it indeed could be assumed there was a single
Internet core.
That concept, however, has been obsolete for a long time. At best, today's definition of the Internet core is statistical,
with the "skitter core" being some number of AS with the greatest traffic according to the CAIDA skitter
. The CAIDA measurements are constantly updated.
Information at Internet Exchange Points
Large Internet Exchange Points (IXP)—in that they typically include full routes as seen by multiple ISPs, as well as
customer routes, in their exchange fabric—are extremely good places to assess global Internet routing
Before the current commercial Internet evolved, the NSFNET, which interconnected five US government funded
supercomputer centers, could have been considered the high-speed Internet core. Four IXPs supported NSFNET, but
these IXPs evolved into a model where commercial traffic could meet there. While it is slightly difficult to point to a
precise endpoint, NSF funding for transmission ceased by 1998.
Customer, non-ISP Participation in the DFZ
It's quite common practice, in a multihomed but stub (i.e., non-transit) autonomous system
, for the BGP-speaking
router(s) to take "full routes" from the various ISPs to which the AS is multihomed. Especially if there is more than
one router connected to the same ISP, a common practice, it will receive more routes that are in the DFZ. Here's the
reasoning: when you have two routers connected to a major ISP such as Sprint, France Telecom or Qwest, that
provider has a number of customer AS connected to it. The optimal route to those customer AS are important to the
ISP itself, but also tells one customer AS which specific router has the best path to the other customer. The "full
routes", or properly "full routes plus customer routes", coming to a customer router makes that customer router part
of the DFZ, but certainly not part of the current concept of the "skitter core".
Default-free zone
[1] Weekly Routing Report (http:/ / thyme. apnic. net), Routing Analysis Role Account
[2] CAIDA "skitter core" (http:/ / www.caida. org/research/topology/ as_core_network/ ), Cooperative Association for Internet Data
Analysis,April 2005
[3] Resilience Characteristics of the Internet Backbone Routing Infrastructure (http:/ / www.arbornetworks.com/ downloads/ research58/
CSE-TR-368-98.ps), C. Labovitz et al.,1998
[4] Guidelines for creation, selection, and registration of an Autonomous System (AS) (http:// www.ietf.org/rfc/rfc1930.txt), RFC1930, J.
Hawkinson & T. Bates,March 1996
Diameter (protocol)
Diameter is an authentication, authorization and accounting protocol for computer networks, and a successor to
Diameter Applications extend the base protocol by adding new commands and/or attributes, such as those for use of
the Extensible Authentication Protocol (EAP).
Comparison with RADIUS
The name is a pun on the RADIUS protocol, which is the predecessor (a diameter is twice the radius). Diameter is
not directly backwards compatible, but provides an upgrade path for RADIUS. The main differences are as follows:
• Reliable transport protocols (TCP or SCTP, not UDP)
• Network or transport layer security (IPsec or TLS)
• Transition support for RADIUS, although Diameter is not fully compatible with RADIUS
• Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8 bits)
• Client–server protocol, with exception of supporting some server-initiated messages as well
• Both stateful and stateless models can be used
• Dynamic discovery of peers (using DNS SRV and NAPTR)
• Capability negotiation
• Supports application layer acknowledgements, defines failover methods and state machines (RFC 3539)
• Error notification
• Better roaming support
• More easily extended; new commands and attributes can be defined
• Aligned on 32-bit boundaries
• Basic support for user-sessions and accounting
A Diameter Application is not a software application, but a protocol based on the Diameter base protocol (defined in
RFC 3588). Each application is defined by an application identifier and can add new command codes and/or new
mandatory AVPs. Adding a new optional AVP does not require a new application.
Examples of Diameter applications:
• Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
• Diameter Network Access Server Application (NASREQ, RFC 4005)
• Diameter Extensible Authentication Protocol Application (RFC 4072)
• Diameter Credit-Control Application (DCCA, RFC 4006)
• Diameter Session Initiation Protocol Application (RFC 4740)
• Various applications in the 3GPP IP Multimedia Subsystem
Diameter (protocol)
Both the HSS and the SLF communicate using the Diameter protocol.
(Generic Bootstrapping Architecture): Bootstrapping Server Function
The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn and Ping Pan in 1998 to provide a
Authentication, Authorization, and Accounting (AAA) framework that could overcome the limitations of RADIUS.
RADIUS had issues with reliability, scalability, security and flexibility. RADIUS cannot effectively deal well with
remote access, IP mobility and policy control. The Diameter protocol defines a policy protocol used by clients to
perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services.
Like RADIUS, Diameter provides AAA functionality, but in addition it is made more reliable by using TCP and
SCTP instead of UDP. The Diameter protocol is further enhanced by the development of the 3rd Generation
Partnership Project (3GPP) IP Multimedia Subsystem (IMS). The Cx, Dh, Dx, Rf, Ro, and Sh interfaces are
supported by Diameter applications.
Through the use of extensions, the protocol was designed to be extensible to
support Proxies, Brokers, Strong Security, Mobile-IP, Network Access Servers (NASREQ), Accounting and
Resource Management.
Protocol description
The Diameter base protocol is defined by RFC 3588, and defines the minimum requirements for an AAA protocol.
Diameter Applications can extend the base protocol, by adding new commands and/or attributes. Diameter security
is provided by IPSEC or TLS, both well-regarded protocols. The IANA has assigned TCP and SCTP port number
3868 to Diameter.
Packet format
The packet consists of a Diameter header and a variable number of Attribute-Value Pairs, or AVPs, for encapsulating
information relevant to the Diameter message.
Diameter Header
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 version message length
32 R P E T command code
64 application ID
96 hop-by-hop ID
128 end-to-end ID
The 'R'(Request) bit, If set, the message is a request. If cleared, the message is an answer.
The 'P'(Proxiable) Bit, If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be
locally processed.
The 'E'(Error) bit, If set, the message contains a protocol error, and the message will not conform to the ABNF
described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit
MUST NOT be set in request messages.
Diameter (protocol)
The 'T'( Potentially re-transmitted message) bit , This flag is set after a link failover procedure, to aid the removal of
duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate
due to a link failure.
Each command is assigned a command code, which is used for both Requests and Answers.
Command-Name Abbr. Code
AA-Request AAR 265
AA-Answer AAA 265
Diameter-EAP-Request DER 268
Diameter-EAP-Answer DEA 268
Abort-Session-Request ASR 274
Abort-Session-Answer ASA 274
Accounting-Request ACR 271
Accounting-Answer ACA 271
Credit-Control-Request CCR 272
Credit-Control-Answer CCA 272
Capabilities-Exchange-Request CER 257
Capabilities-Exchange-Answer CEA 257
Device-Watchdog-Request DWR 280
Device-Watchdog-Answer DWA 280
Disconnect-Peer-Request DPR 282
Disconnect-Peer-Answer DPA 282
Re-Auth-Request RAR 258
Re-Auth-Answer RAA 258
Session-Termination-Request STR 275
Session-Termination-Answer STA 275
User-Authorization-Request UAR 300
User-Authorization-Answer UAA 300
Server-Assignment-Request SAR 301
Server-Assignment-Answer SAA 301
Location-Info-Request LIR 302
Location-Info-Answer LIA 302
Multimedia-Auth-Request MAR 303
Multimedia-Auth-Answer MAA 303
Registration-Termination-Request RTR 304
Registration-Termination-Answer RTA 304
Push-Profile-Request PPR 305
Push-Profile-Answer PPA 305
User-Data-Request UDR 306
Diameter (protocol)
User-Data-Answer UDA 306
Profile-Update-Request PUR 307
Profile-Update-Answer PUA 307
Subscribe-Notifications-Request SNR 308
Subscribe-Notifications-Answer SNA 308
Push-Notification-Request PNR 309
Push-Notification-Answer PNA 309
Bootstrapping-Info-Request BIR 310
Bootstrapping-Info-Answer BIA 310
Message-Process-Request MPR 311
Message-Process-Answer MPA 311
Attribute-Value Pairs (AVP)
AVP Header
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 AVP code
32 V M P AVP length
64 vendor ID (optional)
For simplicity, 'V' Bit Means Vendor Specific; 'M' Bit means Mandatory; 'P' Bit means Protected.
The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP
header. When set the AVP Code belongs to the specific vendor code address space.
The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M'
bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is
unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with
unrecognized AVPs.
The 'P' bit indicates the need for encryption for end-to-end security.
Diameter (protocol)
Attribute-Name Code Data Type
Acct-Interim-Interval 85 Unsigned32
Accounting-Realtime-Required 483 Enumerated
Acct-Multi-Session-Id 50 UTF8String
Accounting-Record-Number 485 Unsigned32
Accounting-Record-Type 480 Enumerated
Accounting-Session-Id 44 OctetString
Accounting-Sub-Session-Id 287 Unsigned64
Acct-Application-Id 259 Unsigned32
Auth-Application-Id 258 Unsigned32
Auth-Request-Type 274 Enumerated
Authorization-Lifetime 291 Unsigned32
Auth-Grace-Period 276 Unsigned32
Auth-Session-State 277 Enumerated
Re-Auth-Request-Type 285 Enumerated
Class 25 OctetString
Destination-Host 293 DiamIdent
Destination-Realm 283 DiamIdent
Disconnect-Cause 273 Enumerated
E2E-Sequence 300 Grouped
Error-Message 281 UTF8String
Error-Reporting-Host 294 DiamIdent
Event-Timestamp 55 Time
Experimental-Result 297 Grouped
Experimental-Result-Code 298 Unsigned32
Failed-AVP 279 Grouped
Firmware-Revision 267 Unsigned32
Host-IP-Address 257 Address
Inband-Security-Id 299 Unsigned32
Multi-Round-Time-Out 272 Unsigned32
Origin-Host 264 DiamIdent
Origin-Realm 296 DiamIdent
Origin-State-Id 278 Unsigned32
Product-Name 269 UTF8String
Proxy-Host 280 DiamIdent
Proxy-Info 284 Grouped
Proxy-State 33 OctetString
Redirect-Host 292 DiamURI
Redirect-Host-Usage 261 Enumerated
Diameter (protocol)
Redirect-Max-Cache-Time 262 Unsigned32
Result-Code 268 Unsigned32
Route-Record 282 DiamIdent
Session-Id 263 UTF8String
Session-Timeout 27 Unsigned32
Session-Binding 270 Unsigned32
Session-Server-Failover 271 Enumerated
Supported-Vendor-Id 265 Unsigned32
Termination-Cause 295 Enumerated
User-Name 1 UTF8String
Vendor-Id 266 Unsigned32
Vendor-Specific-Application-Id 260 Grouped
State machines
The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages.
This is part of the basic protocol functionality and all stacks should support it and as such abstract from the
connectivity related operations.
Peer State Machine Part 1 Peer State Machine Part 2
Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The
RFC 3588 defines an authorization and an accounting state machine.
Authorization State
Machines (Client)
Diameter Authorization
State Machines (Server)
Accounting State
Machines (Client)
Diameter Accounting State
Machines (Server)
Diameter (protocol)
Message flows
The communication between two diameter peers starts the
establishment of a transport connection (TCP or SCTP). The initiator
then sends a Capabilities-Exchange-Request (CER) to the other peer,
which responds with a Capabilities-Exchange-Answer (CEA). After
that, TLS (Transport Layer Security) may optionally be negotiated.
The connection is then ready for exchanging application messages.
If no messages have been exchanged for some time either side may
send a Device-Watchdog-Request (DWR) and the other peer must
respond with Device-Watchdog-Answer.
Either side may terminate the communication by sending a
Disconnect-Peer-Request (DPR) which the other peer must respond to
with Disconnect-Peer-Answer. After that the transport connection can
be disconnected.
The Diameter protocol is currently defined in the following IETF
RFCs: Obsolete RFCs are indicated with strikethrough text.
# Title Date
Related article Obsoleted
Diameter Base Protocol. September
Diameter Command Codes for Third Generation Partnership Project
(3GPP) Release 5.
Diameter Mobile IPv4 Application. August 2005.
Diameter Network Access Server Application August 2005.
Diameter Credit-Control Application. August 2005. Diameter Credit-Control
Diameter Extensible Authentication Protocol (EAP) Application. August 2005.
Diameter Session Initiation Protocol (SIP) Application. M. November
Diameter Policy Processing Application. March 2008.
Diameter ITU-T Rw Policy Enforcement Interface Application. March 2009.
Diameter Mobile IPv6: Support for Network Access Server to
Diameter Server Interaction.
Diameter Command Code Registration for the Third Generation
Partnership Project (3GPP) Evolved Packet System (EPS).
April 2009. -
Diameter (protocol)
Quality of Service Parameters for Usage with Diameter. August 2009.
[1] Pat R. Calhoun, Glen Zorn and Ping Pan (2001-02). "DIAMETER Framework Document" (http:// tools. ietf.org/html/
draft-calhoun-diameter-framework-09). IETF. . Retrieved 2009-04-30.
[2] Naman Mehta (2009-03-20). "Introduction to Diameter Protocol - What is Diameter Protocol?" (http:// blogs.sun. com/ naman/ entry/
introduction_to_diameter_protocol). Sun Microsystems. . Retrieved 2009-04-30.
External links
• freeDiameter, open-source implementation of Diameter Base Protocol and Extensions (http:// freediameter.net)
• Diameter Blog - Everything about the Diameter protocol (http:/ / diameterprotocol.blogspot. com/ )
• Introduction to Diameter - Get the next generation AAA protocol (http:/ / www.ibm. com/ developerworks/
wireless/ library/wi-diameter/)
• Cisco page outlining differences between RADIUS and DIAMETER (http:/ / www.cisco. com/ en/ US/ products/
ps6638/ products_data_sheet09186a00804fe332.html)
• Diameter: next generation’s AAA protocol (http:// urn.kb. se/ resolve?urn=urn:nbn:se:liu:diva-1195) Paper about
Diameter by Håkan Ventura
• Diameter protocol discussion group (http:/ / www.linkedin. com/ groups?gid=1787697& trk=myg_ugrp_ovr)
Diameter protocol discussion group
• The Open IMS Core JavaDiameterPeer (http:// www.openimscore. org/docs/ JavaDiameterPeer/main. html)
The Open IMS Core JavaDiameterPeer
Diameter Credit-Control Application
Diameter Credit-Control Application, is a networking protocol for Diameter application used to implement
real-time credit-control for a variety of end user services.
It is an IETF standard defined in RFC 4006.
The purpose of the diameter credit control application is to provide a framework for real-time charging, primarily
meant for the communication between gateways/control-points and the back-end account/balance systems.
The application specifies methods for:
• Quota management (Reserve, Reauthorize, Abandon)
• Simple Debit/Credit
• Balance checks
• Price inquiries
The diameter credit control application does not specify which type units are bought/used and which items are
charged. This is left to the service context that have to be specified separately, as is some of the semantics.
Examples of units used/bought:
• Time
• Upload/Download bytes
• SMS (Text Messages)
Examples of items charged:
Diameter Credit-Control Application
• Money
• Points
• Units (eg. if the balance is kept in the same units as what is being used)
Diameter credit control also specifies how to handle the fairly complex issue of multiple unit types used/charged
against a single user balance. For instance, a user may pay for both online time and download bytes but has only a
single account balance.
Command Codes
In order to support Credit Control via Diameter, there are two Diameter messages, the CCR (Credit Control Request)
and the CCA (Credit Control Answer). Command Code for CCR/CCA is 272, as defined in RFC 4006
For quota management the client sends CCR to the server requesting units and reporting consumption. The server
grants units and charges the user. For simple debit/credit the client sends a CCR asking the server to credit/debit the
user's account. For price inquiries the client ask the server what the price for a unit is, and the server responds with
the price.
Message flows
The message flows are in general driven by the control-point asking for units and the server granting them. The
message may also be generated by other diameter applications, such as NASREQ (RFC4005) for sessions that are
The following diagram shows a simplified message flow for a session using quota grants.
The client starts by requesting 10 units from the server. The server
verifies that the user/subscriber has enough balance for it. In this
example the server grants the client all the units it requested. if the
subscriber had had insufficient balance it could have granted less units
or rejected it completely.
When or before the subscriber session has used the granted units the
client sends an update to the server telling it how many units have been
used and how many it would like granted this time. The client is
allowed to request units before the previous grant is completely used,
in order to avoid suspending the subscriber session while talking to the
server. In this example the client sends the request when 7 units of the
10 previously granted units have been used; and ask for 10 more units, which the server grants. The server can use
the used-units count for debiting the subscriber balance (granting units does not indicate that they will be used. The
Used-Units AVP contains the actual usage). It is also possible for the server to tell the client how long the grant is
valid, in which case the client is expected to send an update when the grant timer expires.
There can be many update messages during a session.
Finally, the subscriber has ended the session, and the client sends a termination message to the server containing the
last Used-Units. The server can use the termination message to clear any related reservations made in the back-end
balance management system. If the subscriber did not terminate the session himself but instead depleted his balance
then the server would have responded earlier with reject to an update message, possibly telling the
client/control-point to redirect traffic (this normally only makes sense for HTTP/WAP traffic).
Diameter Credit-Control Application
AVP matrix
AVPs for new command codes
The new Command codes, CCA and CCR, may require some AVPs as indicated below. Bold AVPs are new to
Command Code
Attribute Name CCR CCA
Acct-Multi-Session-Id 0-1 0-1
Auth-Application-Id 1 1
CC-Correlation-Id 0-1 0
CC-Session-Failover 0 0-1
CC-Request-Number 1 1
CC-Request-Type 1 1
CC-Sub-Session-Id 0-1 0-1
Check-Balance-Result 0 0-1
Cost-Information 0 0-1
Credit-Control-Failure-Handling 0 0-1
Destination-Host 0-1 0
Destination-Realm 1 0
Direct-Debiting-Failure-Handling 0 0-1
Event-Timestamp 0-1 0-1
Failed-AVP 0 0+
Final-Unit-Indication 0 0-1
Granted-Service-Unit 0 0-1
Multiple-Services-Credit-Control 0+ 0+
Multiple-Services-Indicator 0-1 0
Origin-Host 1 1
Origin-Realm 1 1
Origin-State-Id 0-1 0-1
Proxy-Info 0+ 0+
Redirect-Host 0 0+
Redirect-Host-Usage 0 0-1
Redirect-Max-Cache-Time 0 0-1
Requested-Action 0-1 0
Requested-Service-Unit 0-1 0
Route-Record 0+ 0+
Result-Code 0 1
Service-Context-Id 1 0
Service-Identifier 0-1 0
Service-Parameter-Info 0+ 0
Diameter Credit-Control Application
Session-Id 1 1
Subscription-Id 0+ 0
Termination-Cause 0-1 0
User-Equipment-Info 0-1 0
Used-Service-Unit 0+ 0
User-Name 0-1 0-1
Validity-Time 0 0-1
New AVPs for base protocol command codes
Command Code
Attribute Name RAR RAA
CC-Sub-Session-Id 0-1 0-1
G-S-U-Pool-Identifier 0-1 0-1
Service-Identifier 0-1 0-1
Rating-Group 0-1 0-1
The table uses the following symbols:
• 0 The AVP MUST NOT be present in the message
• 0+ Zero or more instances of the AVP MAY be present in the message
• 0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there is more
than one instance of the AVP
• 1 One instance of the AVP MUST be present in the message
• 1+ At least one instance of the AVP MUST be present in the message
Related standards
• 3GPP Telecommunication management - Charging management - Diameter charging applications.
• RFC 4005 - Diameter Network Access Server Application.
External links
• Diameter Credit-Control Application DCCA
• 3GPP Telecommunication management - Charging management - Diameter charging applications 3GPP 32.299
[1] http:/ / tools. ietf.org/html/ rfc4006
[2] http:// www. 3gpp. org/ftp/ Specs/ html-info/32299. htm
DICT is a dictionary network protocol created by the DICT Development Group
. It is described by RFC 2229. Its
goal is to surpass the Webster protocol and to allow clients to access more dictionaries during use. Dict servers and
clients use TCP port 2628.
Resources for free dictionaries from DICT protocol servers
• A repository of source files for the DICT Development group's dict protocol server (with a few sample
dictionaries) is available at ftp:// ftp.dict. org/dict/
Dictionaries of English
• Webster's Revised Unabridged Dictionary (1913)
• Oxford Advanced Learners' dictionary
• Free On-line Dictionary of Computing
• V.E.R.A.
— Virtual Entity of Relevant Acronyms which are used in the field of computing
• Hitchcock's Bible Names Dictionary
• WordNet
• Jargon File
• The Devil's Dictionary (1911)
• Elements database
• The U.S. Gazetteer
(1990 Census)
• CIA World Factbook
• Easton's Bible Dictionary (1897)
• Moby Thesaurus
• Bouvier's Law Dictionary, Revised 6th Ed (1856)
Combined, they make up the Free Internet Lexicon and Encyclopedia
Bilingual dictionaries
• FREELANG Dictionary
• Freedict currently provides a collection of roughly 70 translating dictionaries, as xml source files with the data,
mostly accompanied by databases generated from the xml files in the format used by DICT servers and clients.
These are available from the Freedict project section at SourceForge
• English-French dictionary
• Mueller's English-Russian dictionary
• Big English-Russian Dictionary
• Lingvo English-Russian and Russian-English dictionaries are not free, but when purchased, can easily be
converted into DICT format
DICT servers
• dictd (the standard server made by the DICT Development Group)
• GNU Dico
• JDictd
-- a Java-based DICT server implementation (abandoned)
• DictD++
-- modern powerful server written in C++ with heavy usage of STL and boost
DICT file format
The standard dictd server made by the DICT Development Group uses a special DICT file format, although other
dictd servers (such as GNU Dico) may optionally use other file formats.
Dictionaries in the standard DICT file format are made up of two files, a .index file and a .dict file (or .dict.dz if
compressed). These files are not usually written manually but are compiled by a program called dictfmt. For
example, the Unix command:
dictfmt --utf8 --allchars -s "My Dictionary" -j mydict < mydict.txt
will compile a Unicode-compatible DICT file called mydict, with heading My Dictionary, from mydict.txt which is
in Jargon File format i.e.:
:word1:definition 1
:word2:definition 2
Once the dictionary file has been produced, installing it in the server is normally a matter of typing something like:
mv mydict.dict mydict.index /usr/share/dictd/
/usr/sbin/dictdconfig --write
/etc/init.d/dictd restart
DICT clients
A dictd server can be used from Telnet. For example, to connect to the DICT server on localhost, on a Unix system
one can normally type:
telnet localhost dict
and then enter the command "help" to see the available commands. The standard dictd package also provides a "dict"
command for command-line use.
More sophisticated DICT clients include:
• Kdict, comes with KDE
• KTranslator, KDE dictionary
• gnome-dictionary, comes with GNOME
• StarDict
• sdcv
• dictem
, for the Emacs text editor
• dict.org's own client (part of the dictd package)
• GNU dico's own client (part of the dico package)
• Mozdev.org's 'dict'
, a Firefox/Mozilla extension
• OmniDictionary, for Mac OS X
• Dictionary, an application included with Mac OS X. Online dictionaries can be accessed by setting it as the helper
for 'dict://' URI schemes.
• MaemoDict
, for the Nokia 770
• Fantasdic
• ZopeDictDB
for Zope
from Pentila
• cURL
• OKDict
, an OpenOffice.org extension
• dictc (DICT Client)
, client for Windows written in Delphi.
There are also programs that read the DICT file format directly. For example, S60Dict
is a dictionary program
for Symbian Series 60 that uses DICT dictionaries. Additionally, some DICT clients, such as Fantasdic, are also
capable of reading the DICT format directly.
DICT converters
• [19] converts between various dictionary formats using pluggable codec architecture.
• Linguae Software
is able to convert from/to wb, dict (stardict and dictd) csv, xdxf, txt, ini and ling (native) file
formats, Linux, Windows and Mac OSX.
In order to efficiently store dictionary data, dictzip, an extension to the gzip compression format (also the name of
the utility) can be used to compress a .dict file. Dictzip compresses file in chunks and stores the chunk index in the
gzip file header, thus allowing random access to the data.
[1] http:/ / www. dict. org/
[2] http:/ / www. dict. org/links. html
[3] http:/ / www. delorie.com/ gnu/ docs/ vera/vera. html
[4] http:// www. census. gov/ cgi-bin/ gazetteer
[5] http:/ / www. dict. org/file. html
[6] http:// sourceforge.net/ projects/ freedict/files/
[7] http:// www. gnu. org/software/ dico/
[8] http:// www. informatik.uni-leipzig.de/ ~duc/ Java/ JDictd/
[9] http:/ / www. ndl. kiev. ua/ content/ dictd/
[10] http:/ / sourceforge.net/ projects/ dictem
[11] http:// dict.mozdev. org/
[12] http:/ / garage.maemo. org/projects/ maemodict/
[13] http:// www. pentila. com/ produits/ zopedictdb-product/
[14] http:/ / www. zope. org
[15] http:/ / www. pentila. com
[16] http:/ / www. kilargo.com/ en/ products/ okdict
[17] http:/ / sourceforge.net/ projects/ dictc/
[18] http:// users. forthnet.gr/ ath/ kgiannak/ S60Dict. html
[19] http:/ / sourceforge.net/ projects/ xdxf/files/ Converter_%20many%20to%20many/
[20] http:/ / linguae.stalikez. info/
External links
• RFC 2229 — Definition of the DICT server protocol
• dict.org (http:// www. dict. org) DICT Development Group. A WWW interface to several freely available on-line
• A collection of free dictionaries in DICT format at the XDXF SourceForge page (http:// sourceforge.net/
projects/ xdxf/files/ dicts-dictd/ 001/ )
• DICT protocol server list (http:// luetzschena-stahmeln. de/ dictd/ index. php)
Directory Assistance Service
The Directory Assistance Service (DAS) is an obsolete protocol and service for accessing X.500 directory services.
DAS was intended to provide a lightweight means for clients to access X.500 directory services via a split-Directory
User Agent model. Here the Directory User Agent (DUA) (the directory client) is split into a Directory Assistance
(DA) client and a Directory Assistant. The directory user would interact with the DA-client, the DA-Client would
communicate with the Directory Assistant using the DA protocol, and the Directory Assistant would communicate
with the Directory Service using the X.500 Directory Access Protocol (DAP). That is, the Directory Assistant is a
Directory Assistance protocol to DAP gateway. This design allows the DA-client to access the directory without
requiring it to support the cumbersome Open Systems Interconnection protocol stack.
The Directory Assistance Service was created in 1990 by Marshall T. Rose while at Performance Systems
International, Inc., and formally specified in RFC 1202 (published in 1991).
These and related efforts, such as DIXIE, lead to the development of the Lightweight Directory Access Protocol.
LDAP replaced the Directory Assistance Service.
Directory information tree
Directory information tree
A directory information tree (DIT) is data represented in a hierarchical tree-like structure consisting of the
Distinguished Names (DNs) of directory service entries.
Both the X.500 protocols and the Lightweight Directory Access Protocol (LDAP) use directory information trees as
their fundamental data structure.
Typically, an X.500 or LDAP deployment for a single organization will have a directory information tree that
consists of two parts:
• a top level name structure for the name of the organization itself
• a representation of the data model structure within the organization
Top level naming
The top levels of a directory information tree frequently represent political and geographic divisions.
The original assumption of X.500 was that all directory servers would be interconnected to form a single, global
namespace. The entries at the top level of the tree corresponded to countries, identified by their ISO 3166 two letter
country code. The entries subordinate to a country's entry would correspond to states or provinces, and national
organizations. The naming system for a particular country was determined by that country's national standards body
or telecommunications provider.
A limitation of the original directory information tree structure was the assumption that applications searching for an
entry in a particular organization would navigate the directory tree by first browsing to the particular country where
that organization was based, then to the region where that organization was based, then locate the entry for the
organization itself, and then search within that organization for the entry in question. The desire to support searching
more broadly for an individual person when all the particulars of that person's location or organization were not
known led to experiments in directory deployment and interconnection, such as the Common Indexing Protocol.
Today, most LDAP deployments, and in particular Active Directory deployments, are not interconnected into a
single global naming space, and do not use national country codes as the basis for naming. Instead, these
deployments follow a directory structure which at the top level mirrors that of the Domain Name System, as
described by RFC 2247. For example, the entry for an organization with domain name "example.com" would have a
distinguished name of "dc=example, dc=com", and all entries in that organization's directory information tree would
contain that distinguished name suffix.
Organizational structure
The elements of an organization represented in the directory (e.g., people, roles, or devices) in a DIT may be
modeled by a variety of techniques. The determining factors include:
• requirements of the applications which will be searching and updating the directory
• the requirement to provide a unique name for each entry
• the desire for stability of the directory structure
• the desire for human-readability of the Distinguished Names of entries in the directory
• the ease of importing data into the directory from existing databases and other directories
Early deployments of X.500 within corporations and institutions with entries representing the employees of those
organizations often used a DIT structure which mirrored the organizational structure, with organizational unit entries
corresponding to departments or divisions of the organization. The relative distinguished names of the entries for
employees were often formed from the common names of the individual employees. An example DN of an early
X.500/LDAP deployment might be "cn=Joe Bloggs, ou=Marketing, ou=Operations, o=Example Corporation, st=CA,
Directory information tree
c=US". The disadvantage of this approach is that it when the organizational structure is changed, or if employees
change their legal name, it can require the moving or renaming of entries in the directory, which adds both
complexity and overhead and can also upset applications not designed to deal gracefully with such moves.
Today, many large deployments of X.500 or LDAP use a single, flat namespace for the entries, and choose to name
the entries for individuals based on a relative distinguished name that is an organizationally-assigned identifier, such
as a username or an employee number. Today, a DN might resemble "uid=00003,ou=People, dc=example, dc=com".
The advantage of this structure is that entries need not be moved even when employees change their name, or are
transferred to different departments. These changes can be effected through just an attribute modification, and
applications which may be using the DN as a unique identifier (e.g. in a database) do not need to be touched.
Discard Protocol
The Discard Protocol is a service in the Internet Protocol Suite defined in RFC 863. It is intended for testing,
debugging, and measurement purposes.
A host may send data to a host that supports the Discard Protocol on either Transmission Control Protocol (TCP) or
User Datagram Protocol (UDP) port number 9. The data sent to the server is simply discarded. No response is
Inetd implementation
On most UNIX-like operating systems a discard server is built into the inetd (or xinetd) daemon. The discard service
is usually not enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf
and reloading the configuration:
discard stream tcp nowait root internal
discard dgram udp wait root internal
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed
to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of
payload sent.
External links
• RFC 348, The Discard process
• RFC 863, The Discard protocol
DIXIE is an obsolete protocol for accessing X.500 directory services. DIXIE was intended to provide a lightweight
means for clients to access X.500 directory services. DIXIE allowed TCP/IP clients to connect a DIXIE-to-DAP
gateway which would provide access to the X.500 Directory Service. This design allows the client to access the
directory without requiring it to support the cumbersome Open Systems Interconnection protocol stack.
DIXIE was created in 1990 at the University of Michigan by Tim Howes, Mark Smith, and Bryan Beecher. DIXIE
was formally specified in RFC 1249, published in 1991. The university offered a completed UNIX implementation
of the protocol, including a DIXIE server, an application development library, and DIXIE clients. A DIXIE client for
Apple Macintosh was also provided.
These efforts led to the development of the Lightweight Directory Access Protocol. LDAP replaced DIXIE.
When created, the acronym DIXIE did not stand for anything, however later it become known to stand for Directory
Interface to X.500 Implemented Efficiently.
Domain Name System
The Domain Name System (DNS) is a hierarchical naming system built on a distributed database for computers,
services, or any resource connected to the Internet or a private network. Most importantly, it translates domain
names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of
locating and addressing these devices worldwide.
An often-used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by
translating human-friendly computer hostnames into IP addresses. For example, the domain name
www.example.com translates to the addresses (IPv4) and 2620:0:2d0:200::10 (IPv6).
The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a
meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW)
hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing
arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP
addresses such as (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). Users take
advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without
having to know how the computer actually locates them.
The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP
addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be
responsible for their particular domains, and in turn can assign other authoritative name servers for their
sub-domains. This mechanism has made the DNS distributed and fault tolerant and has helped avoid the need for a
single central register to be continually consulted and updated.
In general, the Domain Name System also stores other types of information, such as the list of mail servers that
accept email for a given Internet domain. By providing a worldwide, distributed keyword-based redirection service,
the Domain Name System is an essential component of the functionality of the Internet.
Other identifiers such as RFID tags, UPCs, International characters in email addresses and host names, and a variety
of other identifiers could all potentially use DNS.

The Domain Name System also specifies the technical functionality of this database service. It defines the DNS
protocol, a detailed definition of the data structures and communication exchanges used in DNS, as part of the
Internet Protocol Suite.
Domain Name System
The Internet maintains two principal namespaces, the domain name hierarchy
and the Internet Protocol (IP)
address system.
The Domain Name System maintains the domain namespace and provides translation services
between these two namespaces. Internet name servers and a communication protocol implement the Domain Name
A DNS name server is a server that stores the DNS records for a domain name, such as address (A)
records, name server (NS) records, and mail exchanger (MX) records (see also list of DNS record types); a DNS
name server responds with answers to queries against its database.
The practice of using a name as a humanly more meaningful abstraction of a host's numerical address on the network
dates back to the ARPANET era. Before the DNS was invented in 1983, each computer on the network retrieved a
file called HOSTS.TXT from a computer at SRI (now SRI International).

The HOSTS.TXT file mapped names
to numerical addresses. A hosts file still exists on most modern operating systems by default and generally contains a
mapping of the IP address to "localhost". Many operating systems use name resolution logic that allows
the administrator to configure selection priorities for available name resolution methods.
The rapid growth of the network made a centrally maintained, hand-crafted HOSTS.TXT file unsustainable; it
became necessary to implement a more scalable system capable of automatically disseminating the requisite
At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and wrote the first
implementation. The original specifications were published by the Internet Engineering Task Force in RFC 882 and
RFC 883, which were superseded in November 1987 by RFC 1034
and RFC 1035.
Several additional Request
for Comments have proposed various extensions to the core DNS protocols.
In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou—wrote the first
Unix implementation, called The Berkeley Internet Name Domain (BIND) Server.
In 1985, Kevin Dunlap of DEC
significantly re-wrote the DNS implementation. Mike Karels, Phil Almquist, and Paul Vixie have maintained BIND
since then. BIND was ported to the Windows NT platform in the early 1990s.
BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in use on the
With the heavy use and resulting scrutiny of its open-source code, as well as increasingly more
sophisticated attack methods, many security flaws were discovered in BIND. This contributed to the development of
a number of alternative name server and resolver programs. BIND version 9 was written from scratch and now has a
security record comparable to other modern DNS software.
Domain Name System
Domain name space
The domain name space consists of a tree of domain names. Each node or leaf in the tree has zero or more resource
records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the
root zone. A DNS zone may consist of only one domain, or may comprise many domains and sub-domains,
depending on the administrative authority delegated to the manager.
The hierarchical domain name system, organized into zones, each served by a name
Administrative responsibility over any
zone may be divided by creating
additional zones. Authority is said to
be delegated for a portion of the old
space, usually in form of sub-domains,
to another nameserver and
administrative entity. The old zone
ceases to be authoritative for the new
Domain name syntax
The definitive descriptions of the rules
for forming domain names appear in
RFC 1035, RFC 1123, and RFC 2181.
A domain name consists of one or
more parts, technically called labels,
that are conventionally concatenated,
and delimited by dots, such as
• The right-most label conveys the top-level domain; for example, the domain name www.example.com
belongs to the top-level domain com.
• The hierarchy of domains descends from right to left; each label to the left specifies a subdivision, or subdomain
of the domain to the right. For example: the label example specifies a subdomain of the com domain, and
www is a sub domain of example.com. This tree of subdivisions may have up to 127 levels.
• Each label may contain up to 63 characters. The full domain name may not exceed a total length of 253 characters
in its external dotted-label specification.
In the internal binary representation of the DNS the maximum length
requires 255 octets of storage.
In practice, some domain registries may have shorter limits.
• DNS names may technically consist of any character representable in an octet. However, the allowed formulation
of domain names in the DNS root zone, and most other sub domains, uses a preferred format and character set.
The characters allowed in a label are a subset of the ASCII character set, and includes the characters a through z,
A through Z, digits 0 through 9, and the hyphen. This rule is known as the LDH rule (letters, digits, hyphen).
Domain names are interpreted in case-independent manner. Labels may not start or end with a hyphen.
• A hostname is a domain name that has at least one IP address associated. For example, the domain names
www.example.com and example.com are also hostnames, whereas the com domain is not.
Domain Name System
Internationalized domain names
The permitted character set of the DNS prevented the representation of names and words of many languages in their
native alphabets or scripts. ICANN has approved the Internationalizing Domain Names in Applications (IDNA)
system, which maps Unicode strings into the valid DNS character set using Punycode. In 2009 ICANN approved the
installation of IDN country code top-level domains. In addition, many registries of the existing top-level domain
names (TLD)s have adopted IDNA.
Name servers
The Domain Name System is maintained by a distributed database system, which uses the client-server model. The
nodes of this database are the name servers. Each domain has at least one authoritative DNS server that publishes
information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is
served by the root nameservers, the servers to query when looking up (resolving) a TLD.
Authoritative name server
An authoritative name server is a name server that gives answers that have been configured by an original source,
for example, the domain administrator or by dynamic DNS methods, in contrast to answers that were obtained via a
regular DNS query to another name server. An authoritative-only name server only returns answers to queries about
domain names that have been specifically configured by the administrator.
An authoritative name server can either be a master server or a slave server. A master server is a server that stores
the original (master) copies of all zone records. A slave server uses an automatic updating mechanism of the DNS
protocol in communication with its master to maintain an identical copy of the master records.
Every DNS zone must be assigned a set of authoritative name servers that are installed in NS records in the parent
When domain names are registered with a domain name registrar their installation at the domain registry of a top
level domain requires the assignment of a primary name server and at least one secondary name server. The
requirement of multiple name servers aims to make the domain still functional even if one name server becomes
inaccessible or inoperable.
The designation of a primary name server is solely determined by the priority given to
the domain name registrar. For this purpose generally only the fully qualified domain name of the name server is
required, unless the servers are contained in the registered domain, in which case the corresponding IP address is
needed as well.
Primary name servers are often master name servers, while secondary name server may be implemented as slave
An authoritative server indicates its status of supplying definitive answers, deemed authoritative, by setting a
software flag (a protocol structure bit), called the Authoritative Answer (AA) bit in its responses.
This flag is
usually reproduced prominently in the output of DNS administration query tools (such as dig) to indicate that the
responding name server is an authority for the domain name in question.
Domain Name System
Recursive and caching name server
In principle, authoritative name servers are sufficient for the operation of the Internet. However, with only
authoritative name servers operating, every DNS query must start with recursive queries at the root zone of the
Domain Name System and each user system must implement resolver software capable of recursive operation.
To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the
Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in
the configuration (time-to-live) of the domain name record in question. Typically, such caching DNS servers, also
called DNS caches, also implement the recursive algorithm necessary to resolve a given name starting with the DNS
root through to the authoritative name servers of the queried domain. With this function implemented in the name
server, user applications gain efficiency in design and operation.
The combination of DNS caching and recursive functions in a name server is not mandatory; the functions can be
implemented independently in servers for special purposes.
Internet service providers typically provide recursive and caching name servers for their customers. In addition,
many home networking routers implement DNS caches and recursors to improve efficiency in the local network.
DNS resolvers
The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that
ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP
A DNS query may be either a non-recursive query or a recursive query:
• A non-recursive query is one in which the DNS server provides a record for a domain for which it is authoritative
itself, or it provides a partial result without querying other servers.
• A recursive query is one for which the DNS server will fully answer the query (or give an error) by querying
other name servers as needed. DNS servers are not required to support recursive queries.
The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use of recursive service
using bits in the query headers.
Resolving usually entails iterating through several name servers to find the needed information. However, some
resolvers function more simply by communicating only with a single name server. These simple resolvers (called
"stub resolvers") rely on a recursive name server to perform the work of finding information for them.
Address resolution mechanism
Domain name resolvers determine the appropriate domain name servers responsible for the domain name in question
by a sequence of queries starting with the right-most (top-level) domain label.
A DNS recursor consults three nameservers to resolve the address www.wikipedia.org.
The process entails:
1. A network host is configured with
an initial cache (so called hints) of
the known addresses of the root
nameservers. Such a hint file is
updated periodically by an
administrator from a reliable source.
Domain Name System
2. A query to one of the root servers to find the server authoritative for the top-level domain.
3. A query to the obtained TLD server for the address of a DNS server authoritative for the second-level domain.
4. Repetition of the previous step to process each domain name label in sequence, until the final step which returns
the IP address of the host sought.
The diagram illustrates this process for the host www.wikipedia.org.
The mechanism in this simple form would place a large operating burden on the root servers, with every search for
an address starting by querying one of them. Being as critical as they are to the overall function of the system, such
heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is
used in DNS servers to overcome this problem, and as a result, root nameservers actually are involved with very
little of the total traffic.
Circular dependencies and glue records
Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name
server must issue another DNS request to find out the IP address of the server to which it has been referred. If the
name given in the delegation is a subdomain of the domain for which the delegation is being provided, there is a
circular dependency. In this case the nameserver providing the delegation must also provide one or more IP
addresses for the authoritative nameserver mentioned in the delegation. This information is called glue. The
delegating name server provides this glue in the form of records in the additional section of the DNS response, and
provides the delegation in the answer section of the response.
For example, if the authoritative name server for example.org is ns1.example.org, a computer trying to
resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in example.org,
this requires resolving example.org first, which presents a circular dependency. To break the dependency, the
nameserver for the org top level domain includes glue along with the delegation for example.org. The glue
records are address records that provide IP addresses for ns1.example.org. The resolver uses one or more of
these IP addresses to query one of domain's authoritative servers, which allows it to complete the DNS query.
Record caching
Because of the large volume of requests generated DNS for the public Internet, the designers wished to provide a
mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for
caching of records for a period of time after an answer. This entails the local recording and subsequent consultation
of the copy instead of initiating a new request upstream. The time for which a resolver caches a DNS response is
determined by a value called the time to live (TTL) associated with every record. The TTL is set by the administrator
of the DNS server handing out the authoritative response. The period of validity may vary from just seconds to days
or even weeks.
As a noteworthy consequence of this distributed and caching architecture, changes to DNS records do not propagate
throughout the network immediately, but require all caches to expire and refresh after the TTL. RFC 1912 conveys
basic rules for determining appropriate TTL values.
Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or no caching at all.
Negative caching, i.e. the caching of the fact of non-existence of a record, is determined by name servers
authoritative for a zone which must include the Start of Authority (SOA) record when reporting no data of the
requested type exists. The value of the MINIMUM field of the SOA record and the TTL of the SOA itself is used to
establish the TTL for the negative answer.
Domain Name System
Reverse lookup
A reverse lookup is a query of the DNS for domain names when the IP address is known. Multiple domain names
may be associated with an IP address. The DNS stores IP addresses in the form of domain names as specially
formatted names in pointer (PTR) records within the infrastructure top-level domain arpa. For IPv4, the domain is
in-addr.arpa. For IPv6, the reverse lookup domain is ip6.arpa. The IP address is represented as a name in
reverse-ordered octet representation for IPv4, and reverse-ordered nibble representation for IPv6.
When performing a reverse lookup, the DNS client converts the address into these formats, and then queries the
name for a PTR record following the delegation chain as for any DNS query. For example, the IPv4 address is represented as a DNS name as The DNS resolver begins
by querying the root servers, which point to ARIN's servers for the 208.in-addr.arpa zone. From there the
Wikimedia servers are assigned for 152.80.208.in-addr.arpa, and the PTR lookup completes by querying
the wikimedia nameserver for, which results in an authoritative response.
Client lookup
DNS resolution sequence
Users generally do not communicate
directly with a DNS resolver. Instead
DNS resolution takes place
transparently in applications programs
such as web browsers, e-mail clients,
and other Internet applications. When
an application makes a request that
requires a domain name lookup, such
programs send a resolution request to
the DNS resolver in the local operating
system, which in turn handles the communications required.
The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can
provide the answer to the request, the resolver will return the value in the cache to the program that made the request.
If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers.
In the case of most home users, the Internet service provider to which the machine connects will usually supply this
DNS server: such a user will either have configured that server's address manually or allowed DHCP to set it;
however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers
point to separately maintained nameservers of the organization. In any event, the name server thus queried will
follow the process outlined above, until it either successfully finds a result or does not. It then returns its results to
the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the
result back to the software which initiated the request.
Broken resolvers
An additional level of complexity emerges when resolvers violate the rules of the DNS protocol. A number of large
ISPs have configured their DNS servers to violate rules (presumably to allow them to run on less-expensive
hardware than a fully compliant resolver), such as by disobeying TTLs, or by indicating that a domain name does not
exist just because one of its name servers does not respond.
As a final level of complexity, some applications (such as web-browsers) also have their own DNS cache, in order to
reduce the use of the DNS resolver library itself. This practice can add extra difficulty when debugging DNS issues,
as it obscures the freshness of data, and/or what data comes from which cache. These caches typically use very short
caching times—on the order of one minute.
Domain Name System
Internet Explorer represents a notable exception: versions up to IE 3.x cache DNS records for 24 hours by default.
Internet Explorer 4.x and later versions (up to IE 8) decrease the default time out value to half an hour, which may be
changed in corresponding registry keys.
Other applications
The system outlined above provides a somewhat simplified scenario. The Domain Name System includes several
other functions:
• Hostnames and IP addresses do not necessarily match on a one-to-one basis. Multiple hostnames may correspond
to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites.
Alternatively a single hostname may correspond to many IP addresses: this can facilitate fault tolerance and load
distribution, and also allows a site to move physical location seamlessly.
• There are many uses of DNS besides translating names to IP addresses. For instance, Mail transfer agents use
DNS to find out where to deliver e-mail for a particular address. The domain to mail exchanger mapping provided
by MX records accommodates another layer of fault tolerance and load distribution on top of the name to IP
address mapping.
• E-mail Blacklists: The DNS system is used for efficient storage and distribution of IP addresses of blacklisted
e-mail hosts. The usual method is putting the IP address of the subject host into the sub-domain of a higher level
domain name, and resolve that name to different records to indicate a positive or a negative. A hypothetical
example using blacklist.example,
• is blacklisted => Creates and resolves to
• is not => is not found, or default to
• E-mail servers can then query blacklist.example through the DNS mechanism to find out if a specific host
connecting to them is in the blacklist. Today many of such blacklists, either free or subscription-based, are
available mainly for use by email administrators and anti-spam software.
• Software Updates: many anti-virus and commercial software now use the DNS system to store version numbers
of the latest software updates so client computers do not need to connect to the update servers every time. For
these types of applications, the cache time of the DNS records are usually shorter.
• Sender Policy Framework and DomainKeys, instead of creating their own record types, were designed to take
advantage of another DNS record type, the TXT record.
• To provide resilience in the event of computer failure, multiple DNS servers are usually provided for coverage of
each domain, and at the top level, thirteen very powerful root servers exist, with additional "copies" of several of
them distributed worldwide via Anycast.
• Dynamic DNS (sometimes called DDNS) allows clients to update their DNS entry as their IP address changes, as
it does, for example, when moving between ISPs or mobile hot spots.
Protocol details
DNS primarily uses User Datagram Protocol (UDP) on port number 53 to serve requests.
DNS queries consist of a
single UDP request from the client followed by a single UDP reply from the server. The Transmission Control
Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some
operating systems, such as HP-UX, are known to have resolver implementations that use TCP for all queries, even
when UDP would suffice.
Domain Name System
DNS resource records
A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.),
an expiration time limit, a class, and some type-specific data. Resource records of the same type define a resource
record set. The order of resource records in a set, returned by a resolver to an application, is undefined, but often
servers implement round-robin ordering to achieve load balancing. DNSSEC, however, works on complete resource
record sets in a canonical order.
When sent over an IP network, all records use the common format specified in RFC 1035:
RR (Resource record) fields
Field Description Length (octets)
NAME Name of the node to which this record pertains (variable)
TYPE Type of RR in numeric form (e.g. 15 for MX RRs) 2
CLASS Class code 2
Count of seconds that the RR stays valid (The maximum is 2
-1, which is about 68 years.)
RDLENGTH Length of RDATA field 2
RDATA Additional RR-specific data (variable)
NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label
compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the
current domain name.
TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the A
record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can
answer lookups on a DNS zone, and the MX record specifies the mail server used to handle mail for a domain
specified in an e-mail address (see also List of DNS record types).
RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for
MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types
must not (RFC 3597).
The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers,
or IP addresses. In addition, the classes Chaos (CN) and Hesiod (HS) exist.
Each class is an independent name
space with potentially different delegations of DNS zones.
In addition to resource records defined in a zone file, the domain name system also defines several request types that
are used only in communication with other DNS nodes (on the wire), such as when performing zone transfers
(AXFR/IXFR) or for EDNS (OPT).
Wildcard DNS records
The domain name system supports wildcard domain names which are names that start with the asterisk label, '*',
e.g., *.example.

DNS records belonging to wildcard domain names specify rules for generating resource
records within a single DNS zone by substituting whole labels with matching components of the query name,
including any specified descendants. For example, in the DNS zone x.example, the following configuration specifies
that all subdomains (including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The
records for a.x.example are needed to specify the mail exchanger. As this has the result of excluding this domain
name and its subdomains from the wildcard matches, all subdomains of a.x.example must be defined in a separate
wildcard statement.
Domain Name System
The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete
and resulted in misinterpretations by implementers.
Protocol extensions
The original DNS protocol had limited provisions for extension with new features. In 1999, Paul Vixie published in
RFC 2671 an extension mechanism, called Extension mechanisms for DNS (EDNS) that introduced optional
protocol elements without increasing overhead when not in use. This was accomplished through the OPT
pseudo-resource record that only exists in wire transmissions of the protocol, but not in any zone files. Initial
extensions were also suggested (EDNS0), such as increasing the DNS message size in UDP datagrams.
Dynamic zone updates
Dynamic DNS updates use the UPDATE DNS opcode to add or remove resource records dynamically from a zone
data base maintained on an authoritative DNS server. The feature is described in RFC 2136. This facility is useful to
register network clients into the DNS when they boot or become otherwise available on the network. Since a booting
client may be assigned a different IP address each time from a DHCP server, it is not possible to provide static DNS
assignments for such clients.
Security issues
DNS was not originally designed with security in mind, and thus has a number of security issues.
One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received
authentic information when, in reality, it has not.
DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; the Domain Name
System Security Extensions (DNSSEC) modifies DNS to add support for cryptographically signed responses. There
are various extensions to support securing zone transfer information as well.
Even with encryption, a DNS server could become compromised by a virus (or for that matter a disgruntled
employee) that would cause IP addresses of that server to be redirected to a malicious address with a long TTL. This
could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data.
This would require manual purging of all affected DNS caches as required by the long TTL (up to 68 years).
Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and "paypa1.com"
are different names, yet users may be unable to tell the difference when the user's typeface (font) does not clearly
differentiate the letter l and the numeral 1. This problem is more serious in systems that support internationalized
domain names, since many character codes in ISO 10646, may appear identical on typical computer screens. This
vulnerability is occasionally exploited in phishing.
Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.
Domain name registration
The right to use a domain name is delegated by domain name registrars which are accredited by the Internet
Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and
number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced
technically by an administrative organization, operating a registry. A registry is responsible for maintaining the
database of names registered within the TLD it administers. The registry receives registration information from each
domain name registrar authorized to assign names in the corresponding TLD and publishes the information using a
special service, the whois protocol.
Domain Name System
ICANN publishes the complete list of TLD registries and domain name registrars. Registrant information associated
with domain names is maintained in an online database accessible with the WHOIS service. For most of the more
than 240 country code top-level domains (ccTLDs), the domain registries maintain the WHOIS (Registrant, name
servers, expiration dates, etc.) information. For instance, DENIC, Germany NIC, holds the DE domain data. Since
about 2001, most gTLD registries have adopted this so-called thick registry approach, i.e. keeping the WHOIS data
in central registries instead of registrar databases.
For COM and NET domain names, a thin registry model is used: the domain registry (e.g. VeriSign) holds basic
WHOIS (registrar and name servers, etc.) data. One can find the detailed WHOIS (registrant, name servers, expiry
dates, etc.) at the registrars.
Some domain name registries, often called network information centers (NIC), also function as registrars to
end-users. The major generic top-level domain registries, such as for the COM, NET, ORG, INFO domains, use a
registry-registrar model consisting of many domain name registrars

In this method of management, the
registry only manages the domain name database and the relationship with the registrars. The registrants (users of a
domain name) are customers of the registrar, in some cases through additional layers of resellers.
Internet standards
The Domain Name System is defined by Request for Comments (RFC) documents published by the Internet
Engineering Task Force (Internet standards). The following is a list of RFCs that define the DNS protocol.
• RFC 920, Domain Requirements – Specified original top-level domains
• RFC 1032, Domain Administrators Guide
• RFC 1033, Domain Administrators Operations Guide
• RFC 1034, Domain Names - Concepts and Facilities
• RFC 1035, Domain Names - Implementation and Specification
• RFC 1101, DNS Encodings of Network Names and Other Types
• RFC 1123, Requirements for Internet Hosts—Application and Support
• RFC 1178, Choosing a Name for Your Computer (FYI 5)
• RFC 1183, New DNS RR Definitions
• RFC 1591, Domain Name System Structure and Delegation (Informational)
• RFC 1912, Common DNS Operational and Configuration Errors
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2100, The Naming of Hosts (Informational)
• RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181, Clarifications to the DNS Specification
• RFC 2182, Selection and Operation of Secondary DNS Servers
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
• RFC 2671, Extension Mechanisms for DNS (EDNS0)
• RFC 2672, Non-Terminal DNS Name Redirection
• RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3225, Indicating Resolver Support of DNSSEC
• RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
• RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592, The Role of Wildcards in the Domain Name System
Domain Name System
• RFC 4635, HMAC SHA TSIG Algorithm Identifiers
• RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
• RFC 5001, DNS Name Server Identifier (NSID) Option
• RFC 5395, Domain Name System (DNS) IANA Considerations (BCP 42)
• RFC 5452, Measures for Making DNS More Resilient against Forged Answers
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
• RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
• RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
• RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
• RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale
• RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
• RFC 4033, DNS Security Introduction and Requirements
• RFC 4034, Resource Records for the DNS Security Extensions
• RFC 4035, Protocol Modifications for the DNS Security Extensions
• RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol
• RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
[1] Mockapetris, Paul (2004-01-02). "Letting DNS Loose" (http:// www.circleid.com/ posts/ letting_dns_loose/ ). CircleID. . "RFID tags, UPC
codes, International characters in email addresses and host names, and a variety of other identifiers could all go into DNS [...] — it's ready to
carry arbitrary identifiers."
[2] Mockapetris, Paul (April 1989). "RFC 1101: DNS Encoding of Network Names and Other Types". p. 1. "The DNS is extensible and can be
used for a virtually unlimited number of data types, name spaces, etc."
[3] RFC 1034, Domain Names - Concepts and Facilities, P. Mockapetris, The Internet Society (November 1987)
[4] RFC 781, Internet Protocol - DARPA Internet Program Protocol Specification, Information Sciences Institute, J. Postel (Ed.), The Internet
Society (September 1981)
[5] RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The Internet Society (November 1987)
[6] RFC 3467, Role of the Domain Name System (DNS), J.C. Klensin, J. Klensin (February 2003)
[7] Cricket Liu, Paul Albitz (2006). DNS and BIND (http:/ / oreilly.com/ catalog/ 9780596100575) (5th ed.). O'Reilly. p. 3. .
[8] Douglas Brian Terry, Mark Painter, David W. Riggle and Songnian Zhou, The Berkeley Internet Name Domain Server (http:// www.eecs.
berkeley. edu/ Pubs/ TechRpts/ 1984/ 5957. html), Proceedings USENIX Summer Conference, Salt Lake City, Utah, June 1984, pages 23–31.
[9] "DNS Server Survey" (http:/ / mydns. bboy. net/ survey/ ). .
[10] RFC 2181, Clarifications to the DNS Specification, R. Elz, R. Bush (July 1997)
[11] RFC 3696, Application Techniques for Checking and Transformation of Names, J.C. Klensin, J. Klensin
[12] "Name Server definition at techterms.com" (http:// www. techterms.com/ definition/nameserver). .
[13] "Providers ignoring DNS TTL ?" (http:// ask. slashdot. org/article. pl?sid=05/ 04/ 18/ 198259). Slashdot. 2005. . Retrieved 2009-01-03.
[14] "How Internet Explorer uses the cache for DNS host entries" (http:// support. microsoft.com/ default.aspx?scid=KB;en-us;263558).
Microsoft Corporation. 2004. . Retrieved 2010-07-25.
[15] RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), Section 3
[16] RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), p. 11
Domain Name System
[17] RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
[18] APWG. "Global Phishing Survey: Domain Name Use and Trends in 1H2010." 10/15/2010 apwg.org (http:/ / www.apwg.org/reports/
[19] ICANN accredited registrars (http:// www. icann. org/ registrars/accredited-list.html)
[20] VeriSign COM and NET registry (http:/ / www. verisign. com/ information-services/naming-services/ com-net-registry/page_002166.
External links
• Vixie, Paul (2007-05-04). "DNS Complexity – Although it contains just a few simple rules, DNS has grown into
an enormously complex system." (http:/ / www. acmqueue. com/ modules. php?name=Content& pa=showpage&
pid=481). ACM Queue.
• Zytrax.com (http:// www. zytrax.com/ books/ dns/ ), Open Source Guide – DNS for Rocket Scientists, an on-line
• Domain Name System (http:/ / www. microsoft.com/ dns) on Microsoft TechNet
ltg:Muižvuordu sistema
Domain Name System Security Extensions
The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF)
specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on
Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin
authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or
The original design of the Domain Name System (DNS) did not include security; instead it was designed to be a
scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security,
while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS
and how DNSSEC responds to those threats.
DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS
cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is
able to check if the information is identical (correct and complete) to the information on the authoritative DNS
server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other
information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398
describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a
worldwide public key infrastructure for email.
DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not
encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit
(because signature checking allows the use of potentially untrustworthy parties). Other standards (not DNSSEC) are
used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in IETF RFC
4367, some users and developers make false assumptions about DNS names, such as assuming that a company's
common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can
only authenticate that the data is truly from or not available from the domain owner.
The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC
4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535
has become obsolete.
Domain Name System Security Extensions
It is widely believed
that securing the DNS is critically important for securing the Internet as a whole, but
deployment of DNSSEC specifically has been hampered by several difficulties:
• The need to design a backward-compatible standard that can scale to the size of the Internet
• Prevention of "zone enumeration" (see below) where desired
• Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
• Disagreement among implementers over who should own the top-level domain root keys
• Overcoming the perceived complexity of DNSSEC and DNSSEC deployment
Some of these problems are in the process of being resolved, and deployment in various domains is in progress.
How it works
DNSSEC works by digitally signing these records for DNS lookup using public-key cryptography. The correct
DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root
zone which is the trusted third party.
DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types
were created or adapted to use with DNSSEC:
• DS
When DNSSEC is used, each answer to a DNS lookup will contain an RRSIG DNS record, in addition to the record
type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital
signature can be verified by locating the correct public key found in a DNSKEY record. The DS record is used in the
authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for
robust resistance against spoofing.
DNSSEC was designed to be extensible so that as attacks are discovered against existing algorithms, new ones can
be introduced in a backward-compatible fashion. As of this writing (July 2009), the following security algorithms are
defined that are most often used:
Algorithm Field Algorithm Source
0 Reserved RFC 4034
8 RSA/SHA-256 RFC 5702
10 RSA/SHA-512
12 GOST R 34.10-2001 RFC 5933
Domain Name System Security Extensions
The lookup procedure
From the results of a DNS lookup, a security-aware DNS resolver can determine if the answer it received was secure,
or if it was otherwise insecure and the authoritative name server for the domain being queried doesn't support
DNSSEC or if there is some sort of error. The lookup procedure is different for recursive name servers such as those
of many ISPs, and for stub resolvers such as those included by default in mainstream operating systems.
Recursive name servers
Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS zone) can be used to verify
a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. Say that a
recursive resolver such as an ISP name server wants to get the IP addresses (A record and/or AAAA records) of the
domain "www.example.com".
1. The process starts when a security-aware resolver sets the "DO" flag bit in a DNS query. Since the DO bit is in
the extended flag bits defined by EDNS, all DNSSEC transactions must support EDNS. EDNS support is also
needed to allow for the much larger packet sizes that DNSSEC transactions require.
2. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the
answer is correct. Ideally, the security-aware resolver would start with verifying the DS and DNSKEY records at
the DNS root. Then it would use the DS records for the "com" top level domain found at the root to verify the
DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example.com"
subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record
found in the "example.com" zone. Finally, it would verify the RRSIG record found in the answer for the A
records for "www.example.com".
There are several exceptions to the above example.
First, if "example.com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not
be a DS record for "example.com" in the "com" zone. If there is a DS record for "example.com", but no RRSIG
record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC
information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that
stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error.
Next, it may be that there is not a domain name named "www.example.com", in which case instead of returning a
RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure"
records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG
records, which can be verified as above.
Finally, it may be that the "example.com" zone implements DNSSEC, but either the "com" zone or the root zone do
not, creating an "island of security" which needs to be validated in some other way. As of 15 July 2010, deployment
of DNSSEC to root is completed.
The .com domain was signed with valid security keys and the secure delegation
was added to the root zone on 1 April 2011.
Stub resolvers
Stub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS
resolution to a recursive name server."
For the stub resolver to place any real reliance on DNSSEC services, the
stub resolver must trust both the recursive name servers in question and the communication channels between itself
and those name servers, using methods such as SIG(0), TSIG, or IPSec.
A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in
the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data
in the Answer and Authority sections of the response."
It can also potentially perform its own signature validation
by setting the Checking Disabled (CD) bit in its query messages.
Domain Name System Security Extensions
Trust anchors and authentication chains
To be able to prove that a DNS answer is correct, you need to know at least one key or DS record that is correct from
sources other than the DNS. These starting points are known as trust anchors and are typically obtained with the
operating system or via some other trusted source. When DNSSEC was originally designed, it was thought that the
only trust anchor that would be needed was for the DNS root. The root anchors were first published on 15
An authentication chain is a series of linked DS and DNSKEY records, starting with a trust anchor to the
authoritative name server for the domain in question. Without a complete authentication chain, an answer to a DNS
lookup cannot be securely authenticated.
Signatures and zone signing
To limit replay attacks, there are not only the normal DNS TTL values for caching purposes, but additional
timestamps in RRSIG records to limit the validity of a signature. Unlike TTL values which are relative to when the
records were sent, the timestamps are absolute. This means that all security-aware DNS resolvers must have clocks
that are fairly closely in sync, say to within a few minutes.
These timestamps imply that a zone must regularly be re-signed and re-distributed to secondary servers, or the
signatures will be rejected by validating resolvers.
Key management
DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust
In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out
new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time
to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is
safe to assume that the caching of records using the old keys have expired, the old DNSKEY records can be deleted.
This process is more complicated for things such as the keys to trust anchors, such as at the root, which may require
an update of the operating system.
Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for
each. First, there are Key Signing Keys (KSK) which are used to sign other DNSKEY records. Second, there are
Zone Signing Keys (ZSK) which are used to sign other records. Since the ZSKs are under complete control and use
by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much
shorter than KSKs and still offer the same level of protection, but reducing the size of the RRSIG/DNSKEY records.
When a new KSK is created, the DS record must be transferred to the parent zone and published there. The DS
records use a message digest of the KSK instead of the complete key in order to keep the size of the records small.
This is helpful for zones such as the .com domain, which are very large. The procedure to update DS keys in the
parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone.
DNS is a critical and fundamental Internet service, yet in 1990 Steve Bellovin discovered serious security flaws in it.
Research into securing it began, and dramatically increased when his paper was made public in 1995.
The initial
RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised
(and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based
on RFC 2535.
Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by
2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often
Domain Name System Security Extensions
get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out-of-sync data
could have the effect of a serious self-created denial of service. The original DNSSEC required a complex
six-message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all
of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for
the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ".com"
zone changed its public key, it would have to send 22 million records (because it would need to update all of the
signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet.
The IETF fundamentally modified DNSSEC, which is called DNSSEC-bis when necessary to distinguish it from the
original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to
provide an additional level of indirection at delegation points between a parent and child zone. In the new approach,
when a child's master public key changes, instead of having to have six messages for every record in the child, there
is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one
master public key for each child; this is much more practical. This means that a little data is pushed to the parent,
instead of massive amounts of data being exchanged between the parent and children. This does mean that clients
have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires
two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of
signatures verified for other types of RRsets). Most view this as a small price to pay, since it changes DNSSEC so it
is more practical to deploy.
Zone enumeration issue, controversy, and NSEC3
Although the goal of DNSSEC is to increase security, DNSSEC as defined in RFCs 4033 through 4035 introduces a
new problem that many believe is a new security vulnerability: the zone enumeration (aka zone walking) issue.
DNSSEC forces the exposure of information that by normal DNS best practice is kept private. NSEC3 (RFC 5155)
was developed to address this issue; it was released in March 2008. NSEC3 mitigates, but does not eliminate, zone
enumeration, since it is possible to exhaustively search the set of all possible names in a zone.
Why DNS zone data is normally kept private
When the DNS protocol was designed, it was not intended to be a repository for hidden information. However, since
the DNS does house information about the internals of a network related to a given domain, many view the contents
of their DNS database as private. In particular, DNS systems are typically configured so that most users are not
allowed to retrieve the entire list of names or other information in a zone. Such a list would greatly aid attackers,
since that list can give them important information about what machines exist. Some administrators even put system
type and configuration information into their DNS databases which is even more valuable to an attacker. The widely
used book DNS and BIND (4th edition) by Albitz and Liu explains it this way:
Arguably even more important than controlling who can query your name server is ensuring that only your
real slave name servers can transfer zones from your name server. Users on remote hosts can only look up
records (e.g., addresses) for domain names they already know, one at a time. It's the difference between letting
random folks call your company's switchboard and ask for John Q. Cubicle's phone number [versus] sending
them a copy of your corporate phone directory.
In addition, the information from an enumerated zone can be used as a key for multiple WHOIS queries; this would
reveal registrant data which many registries are under strict legal obligations to protect under various contracts.
It is unclear whether DNSSEC is legal to deploy at all in many countries, unless such lists can be kept private.
DENIC has stated that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and other
European countries have similar privacy laws forbidding the public release of certain kinds of information.
Domain Name System Security Extensions
DNSSEC reveals zone data
Unfortunately, DNSSEC's original design required that the entire list of zone names be revealed to all. As stated in
RFC 4033,
DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC
chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name
along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in
sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an
attacker to map network hosts or other resources by enumerating the contents of a zone.
There is an "obvious" solution, called a split-horizon DNS, which is how DNS without DNSSEC is sometimes
deployed — but this approach does not work well with DNSSEC. In the "split-horizon DNS" approach, the DNS
server denies the existence of names to some clients, and provides correct information to other clients. However,
since DNSSEC information is cryptographically signed as authoritative, an attacker could request the signed "does
not exist" record, then retransmit the record to cause a denial of service. DNSSEC fundamentally changes DNS so it
can provide authoritative information; thus, it does not work well with methods based on providing false information
to some users. Research has produced recommendations to properly combine these two DNS features.
The reason DNSSEC introduced this problem is because it must be able to report when a name is not found. DNS
servers supporting DNSSEC must be able to sign that not-found report — otherwise a not-found report could be
easily spoofed. Yet for security reasons the signing key should not be online. As a result, DNSSEC was designed to
report a signed message that reports that a given range of names does not exist, which can be signed ahead-of-time
offline. Unfortunately, this information is enough for an attacker to gain much more information than would have
been available to them otherwise — it is enough to enable an attacker to quickly gather all the names in a zone, and
then through targeted queries on the names to reconstruct all or most of a zone's data.
As noted earlier, DNSSEC could be used as the basis for a worldwide public key infrastructure for email addresses,
by using DNS to serve email certificates and DNSSEC to validate them. However, this DNSSEC issue makes this
unlikely for most organizations, at least if used directly. As RFC 4398 states, "If an organization chooses to issue
certificates for its employees, placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC) is in
use, it is possible for someone to enumerate all employees of the organization. This is usually not considered
desirable, for the same reason that enterprise phone listings are not often publicly published and are even marked
Initial Reaction
Many of the participants on the IETF DNS Extensions working group originally stated that zone enumeration was
not a significant problem, arguing that the DNS data was—or should be—public. However, registrars and many
large organizations told the working group members that DNSSEC as currently defined was unacceptable, and that
they would not or legally could not deploy it.
On-line Signing
One approach to preventing zone enumeration was codified in RFC 4470. Instead of signing the not-found responses
in advance, a not-found response is generated for each query. For example, if a query is received for
'b.example.com', instead of serving a previously signed response saying there are no names between 'a.example.com'
and 'mail.example.com', which reveals the existence of 'mail.example.com', the response might be that 'there are no
names between b.example.com and ba.example.com'. If the next query asks about 'ba.example.com', the response
might be 'there are no names between ba.example.com and baa.example.com'. This makes enumerating the entire
zone impractical.
Domain Name System Security Extensions
This approach has some disadvantages. It requires a signing key to be kept on-line and accessible to each DNS
server. Many zone signing keys are kept on-line anyway to support automatic resigning or dynamic zone updates,
but these functions are needed only on a single master DNS server, while to support on-line signing the zone signing
key must be kept on each authoritative DNS server. Some authoritative servers must be accessible from the Internet
and ideally these will be widely dispersed, making it difficult to keep the keys under control. Care is also required to
prevent an attacker flooding the DNS server with requests for bogus names, denying service to legitimate users.
After deliberation, an extension was developed: "DNSSEC Hashed Authenticated Denial of Existence" (informally
called "NSEC3"). In this approach, DNSSEC-aware servers can choose to send an "NSEC3" record instead of an
NSEC record when a record is not found. The NSEC3 record is signed, but instead of including the name directly
(which would enable zone enumeration), the NSEC3 record includes a cryptographically hashed value of the name.
The NSEC3 record includes both a hash after a number of iterations and an optional salt, both of which reduce the
effectiveness of pre-computed dictionary attacks. Salting increases the number of dictionaries necessary for an
attack, while additional hash iterations increase the cost of computing each dictionary.
In March 2008, NSEC3 was formally defined in RFC 5155.
The Internet is critical infrastructure, yet its operation depends on the fundamentally insecure DNS. Thus, there is
strong incentive to secure DNS, and deploying DNSSEC is generally considered to be a critical part of that effort.
For example, the U.S. National Strategy to Secure Cyberspace specifically identified the need to secure DNS.
Widescale deployment of DNSSEC could resolve many other security problems as well, such as secure key
distribution for e-mail addresses.
However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was only
formally defined in an RFC in March 2008, and it is not yet widely deployed.
DNSSEC deployment in large-scale networks is also challenging. Ozment and Schechter observe that DNSSEC (and
other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate
benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs (as
is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level of a DNS hierarchy, but it must
be widely available in a zone before many others will want to adopt it. DNS servers must be updated with software
that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP-using client
must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver
must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC.
DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC-signed responses are
far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP fragments, but
many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP instead. Yet many
current TCP implementations store a great deal of data for each TCP connection; heavily loaded servers can run out
of resources simply trying to respond to a larger number of (possibly bogus) DNSSEC requests. Some protocol
extensions, such as TCP Cookie Transactions, have been developed to reduce this loading.
To address these
challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many
Domain Name System Security Extensions
Early deployments
Early adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Puerto Rico (.pr) and Sweden (.se), who use
DNSSEC for their country code top-level domains;
RIPE NCC, who have signed all the reverse (in-addr.arpa)
that are delegated to it from the Internet Assigned Numbers Authority (IANA).
ARIN is also signing their reverse
TDC was the first ISP to implement this feature in Sweden.
IANA has been publicly testing a sample signed root
since June 2007.
VeriSign was running a pilot project to allow .com and .net domains to register themselves to do DNSSEC NSEC3
experiments, as noted above.
A wide variety of pilot projects and experiments are and have been performed. dnssec.net
maintains a list of such
projects. There is also a Google Map of World Wide DNSSEC Deployment
On February 24, 2009, VeriSign announced that they would deploy DNSSEC across all their top level domains
(.com, .net, etc.) within 24 months.
On June 2, 2009, the Public Interest Registry signed the .org zone.
The Public Internet Registry also detailed on
September 26, 2008, that the first phase, involving large registrars it has a strong working relationship with ("friends
and family") will be the first to be able to sign their domains, beginning "early 2009".
On June 23, 2010, 13
registrars were listed as offering DNSSEC records for .ORG domains.
On November 16, 2009, VeriSign said a significant outstanding Internet security vulnerability will be closed for the
.com and .net domains by the first quarter of 2011, after delays caused by technical aspects of the
Deployment at the DNS root
DNSSEC was first deployed at the root level on July 15, 2010.
This is expected to greatly simplify the
deployment of DNSSEC resolvers, since the root trust anchor can be used to validate any DNSSEC zone that has a
complete chain of trust from the root. Since the chain of trust must be traced back to a trusted root without
interruption in order to validate, trust anchors must still be configured for secure zones if any of the zones above
them are not secure. For example if the zone "signed.example.org" was secured but the "example.org"-zone was not,
then, even though the ".org"-zone and the root are signed a trust anchor has to be deployed in order to validate the
Political issues surrounding signing the root have been a continuous concern, primarily about some central issues:
• Other countries are concerned about U.S. control over the Internet, and may reject any centralized keying for this
• Some governments might try to ban DNSSEC-backed encryption key distribution.
In September 2008, ICANN and VeriSign each published implementation proposals
and in October, the National
Telecommunications and Information Administration (NTIA) asked the public for comments.
It is unclear if the
comments received affected the design of the final deployment plan.
On June 3, 2009, the National Institute of Standards and Technology (NIST) announced plans to sign the root by the
end of 2009, in conjunction with ICANN, VeriSign and the NTIA.
On October 6, 2009, at the 59th RIPE Conference meeting, ICANN and VeriSign announced the planned
deployment timeline for deploying DNSSEC within the root zone.
At the meeting it was announced that it would
be incrementally deployed to one root name server a month, starting on December 1, 2009, with the final root name
server serving a DNSSEC signed zone on July 1, 2010, and the root zone will be signed with a RSA/SHA256
During the incremental roll-out period the root zone will serve a Deliberately Unvalidatable Root
Zone (DURZ) that uses dummy keys, with the final DNSKEY record not being distributed until July 1, 2010.
Domain Name System Security Extensions
This means the keys that were used to sign the zone use are deliberately unverifiable; the reason for this deployment
was to monitor changes in traffic patterns caused by the larger responses to queries requesting DNSSEC resource
The .org top-level domain is expected to implement DNSSEC in June 2010, followed by .com, .net, and .edu later in
2010 and 2011.
Country code top-level domains will be able to deposit keys starting in May 2010.
On January 25, 2010, the L (ell) root server began serving a Deliberately Unvalidatable Root Zone (DURZ). The
zone uses signatures of a SHA-2 (SHA-256) hash created using the RSA algorithm, as defined in RFC 5702.

As of May 2010, all thirteen root servers have begun serving the DURZ.
On July 15, 2010, the first root full
production DNSSEC root zone was signed, with the SOA serial 2010071501. Root trust anchors are available from
Deployment of alternative trust anchors to the DNS root
Due to delays with signing the root, there have been several proposed and deployed alternative trust anchors.
1. The IKS Jena has been running an alternative trust anchor system called the "DLV registry" since January 19,
It uses DLV records (a renamed DS record) that can be looked up by querying
<domainname>.dnssec.iks-jena.de. This is a spidering registry which aims to get as much validation as
2. The Internet Systems Consortium has been running an alternative trust anchor system called the "DLV registry"
since March 27, 2006.
It uses DLV records (a renamed DS record) that can be looked up by querying
<domainname>.dlv.isc.org. Support for the ISC DLV registry has been supported in BIND since version 9.3.3.
3. Samuel Weiler proposed an alternative trust anchor using TA records in April 2004,
but this proposal has yet
to be implemented.
4. ICANN announced an Interim Trust Anchor Repository on February 17, 2009.
This system will use DS
records, but will only be available to top level domains.
DNSSEC deployment initiative by the U.S. federal government
The Science and Technology Directorate of the U.S. Department of Homeland Security (DHS) sponsors the
"DNSSEC Deployment Initiative". This initiative encourages "all sectors to voluntarily adopt security measures that
will improve security of the Internet's naming infrastructure, as part of a global, cooperative effort that involves
many nations and organizations in the public and private sectors." DHS also funds efforts to mature DNSSEC and
get it deployed inside the U.S. federal government.
It was reported
that on March 30, 2007, the U.S. Department of Homeland Security proposed "to have the key to
sign the DNS root zone solidly in the hands of the US government." However no U.S. Government officials were
present in the meeting room and the comment that sparked the article was made by another party. DHS later

on why they believe others jumped to the false conclusion that the U.S. Government had made
such a proposal: "The U.S. Department of Homeland Security is funding the development of a technical plan for
implementing DNSSec, and last October distributed an initial draft of it to a long list of international experts for
comments. The draft lays out a series of options for who could be the holder, or "operator," of the Root Zone Key,
essentially boiling down to a governmental agency or a contractor. "Nowhere in the document do we make any
proposal about the identity of the Root Key Operator," said Maughan, the cyber-security research and development
manager for Homeland Security."
Domain Name System Security Extensions
DNSSEC deployment in the U.S. federal government
The National Institute of Standards and Technology (NIST) published NIST Special Publication 800-81 Secure
Domain Name System (DNS) Deployment Guide on May 16, 2006, with guidance on how to deploy DNSSEC.
NIST intended to release new DNSSEC Federal Information Security Management Act (FISMA) requirements in
NIST SP800-53-R1, referencing this deployment guide. U.S. agencies would then have had one year after final
publication of NIST SP800-53-R1 to meet these new FISMA requirements.
However, at the time NSEC3 had not
been completed. NIST had suggested using split domains, a technique that is known to be possible but is difficult to
deploy correctly, and has the security weaknesses noted above.
On 22 August 2008, the Office of Management and Budget (OMB) released a memorandum requiring U.S. Federal
Agencies to deploy DNSSEC across .gov sites; the .gov root must be signed by January 2009, and all subdomains
under .gov must be signed by December 2009.
While the memo focuses on .gov sites, the U.S. Defense
Information Systems Agency says it intends to meet OMB DNSSEC requirements in the .mil (U.S. military) domain
as well. NetworkWorld's Carolyn Duffy Marsan stated that DNSSEC "hasn't been widely deployed because it suffers
from a classic chicken-and-egg dilemma... with the OMB mandate, it appears the egg is cracking."
DNSSEC deployment by ISPs
Several ISPs have started to deploy DNSSEC-validating DNS recursive resolvers. Comcast became the first major
ISP to do so in the United States on October 18, 2010.

DNSSEC deployment requires software on the server and client side. Some of the tools that support DNSSEC
• Windows 7 and Windows Server 2008 R2 include a "security-aware" stub resolver that is able to differentiate
between secure and non-secure responses by a recursive name server.

• BIND, the most popular DNS name server (which includes dig). Version 9.3 implemented the newer DNSSEC-bis
(DS records) although it did not support NSEC3 records. BIND 9.6 was released in December 2008 and has full
support for NSEC3 records.
• Drill
is a DNSSEC-enabled dig-like tool bundled with ldns
• Drill extension for Firefox
adds to Mozilla Firefox the ability to determine if a domain can be verified using
• DNSSEC-Tools
aims at providing easy to use tools for helping all types of administrators and users make use
of DNSSEC. It offers tools for administrators of Authoritative Zones
, Authoritative Server
, and Recursive
as well as a library and tools for Application Developers
and existing patches for extending
common applications
• Zone Key Tool
is a software designed to ease the maintenance of DNSSEC aware zones. It's primarily
designed for environments with a small to medium number of zones and provides a full automatic zone signing
key rollover as well as automatic resigning of the zone.
• Unbound
is a DNS name server that was written from the ground up to be designed around DNSSEC
• GbDns
is a compact, easy-to-install DNSSEC name server for Microsoft Windows.
• mysqlBind The GPL OSS for DNS ASPs now supports DNSSEC.
• OpenDNSSEC is a designated DNSSEC signer tool using PKCS#11 to interface with Hardware Security
• SecSpider
tracks DNSSEC deployment, monitors zones, and provides a list of observed public keys.
• DNSViz
and DNSSEC Analyzer
are Web-based tools to visualize the DNSSEC authentication chain of a
Domain Name System Security Extensions
• DNSSEC Validator
is a Mozilla Firefox addon for visualization of DNSSEC status of the visited domain
or DNS Secure Hidden Master is an open-source tool to automatize DNSSEC supported zones
provisioning process.
[1] Interview with Dan Kaminsky on DNSSEC (25 Jun 2009) Kaminsky interview: DNSSEC addresses cross-organizational trust and security
(http:// searchsecurity. techtarget. com/ news/ interview/0,289202,sid14_gci1360143,00. html)
[2] "Domain Name System Security (DNSSEC) Algorithm Numbers" (http:// www.iana. org/ assignments/ dns-sec-alg-numbers/
dns-sec-alg-numbers.xhtml). IANA. 2010-07-12. . Retrieved 2010-07-17.
[3] http:// www. root-dnssec. org/
[4] http:/ / www. v3. co. uk/ v3-uk/news/ 2039287/ verisign-adds-dnssec-com-domain-boost-online-security/
[5] RFC 4033: DNS Security Introduction and Requirements (http:// tools. ietf.org/html/ rfc4033#section-7). The Internet Society. March 2005.
p. 11. . "Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution
to a recursive name server.". An earlier definition was given in an earlier RFC: Robert Braden (October 1989). RFC 1123 - Requirements for
Internet Hosts -- Application and Support (http:/ / tools. ietf.org/ html/ rfc1123#page-74). IETF (Internet Engineering Task Force). p. 74. . "A
"stub resolver" relies on the services of a recursive name server [...]".
[6] RFC 4033: DNS Security Introduction and Requirements (http:// tools. ietf.org/html/ rfc4033#page-12). The Internet Society. March 2005.
p. 12. .
[7] root-anchors (https:/ / data. iana. org/root-anchors/)
[8] "Using the Domain Name System for System Break-Ins" (http:// citeseer. ist. psu.edu/ bellovin95using. html) by Steve Bellovin, 1995
[9] Breaking DNSSEC (http:/ / cr. yp. to/ talks/ 2009. 08. 10/ slides. pdf) Daniel J. Bernstein, 2009
[10] Albitz, Paul; Cricket Liu (April 2001). DNS and BIND (http:/ / oreilly.com/ catalog/ 9780596001582/ ) (4e. ed.). O'Reilly Media, Inc..
ISBN 9780596001582. .
[11] Split-View DNSSEC Operational Practices (http:// tools. ietf.org/ html/ draft-krishnaswamy-dnsop-dnssec-split-view)
[12] U.S. National Strategy to Secure Cyberspace (http:// georgewbush-whitehouse.archives. gov/ pcipb/ cyberspace_strategy. pdf), p. 30
February 2003
[13] Metzger, Perry, William Allen Simpson, and Paul Vixie. "Improving TCP security with robust cookies" (http:/ / www.usenix. org/
publications/ login/ 2009-12/openpdfs/ metzger.pdf). Usenix. . Retrieved 2009-12-17.
[14] Electronic Privacy Information Center (EPIC) (May 27, 2008). DNSSEC (http:// epic. org/ privacy/dnssec/ )
[15] RIPE NCC DNSSEC Policy (http:// www.ripe.net/ docs/ ripe-359.html)
[16] ARIN DNSSEC Deployment Plan (https:/ / www.arin. net/ resources/ dnssec/ )
[17] https:/ / ns. iana.org/ dnssec/ status. html
[18] http:/ / www. dnssec. net/ projects
[19] http:// maps. google. com/ maps?q=Google%20Map%20of%20World%20Wide%20DNSSEC%20Deployment
[20] VeriSign: We will support DNS security in 2011 (http:// www.networkworld.com/ news/ 2009/ 022409-verisign-dns-security.
[21] .ORG is the first open TLD signed with DNSSEC (http:/ / pir.org/index.php?db=content/ News& tbl=Press& id=25)
[22] Sean Michael Kerner. ".ORG the Most Secure Domain?" (http:/ / www.internetnews.com/ security/ article.php/ 3774131).
www.internetnews.com. . Retrieved 2008-09-27.
[23] ".ORG Registrar List — with DNSSEC enabled at the top" (http:/ / www.pir.org/get/ registrars?order=field_dnssec_value&sort=desc). .
Retrieved 2010-06-23.
[24] VeriSign: Major internet security update by 2011 (http:/ / news. zdnet.co. uk/ security/ 0,1000000189,39877966,00.htm)
[25] "Root DNSSEC Status Update, 2010-07-16" (http:/ / www. root-dnssec.org/ 2010/07/ 16/ status-update-2010-07-16/). 16 July 2010. .
[26] Singel, Ryan (October 8, 2006). "Feds Start Moving on Net Security Hole" (http:// blog. wired.com/ 27bstroke6/ 2008/ 10/ feds-take-step.
html). Wired News (CondéNet). . Retrieved 2008-10-09.
[27] National Telecommunications and Information Administration, U.S. Department of Commerce (October 9, 2008). "Press Release: NTIA
Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System" (http:/ / www.ntia. doc.gov/
press/2008/ DNSSEC_081009.html). Press release. . Retrieved 2008-10-09.
[28] National Institute of Standards and Technology (3 June 2009). "Commerce Department to Work with ICANN and VeriSign to Enhance the
Security and Stability of the Internet's Domain Name and Addressing System" (http:/ / www.nist.gov/ public_affairs/releases/
dnssec_060309.html). Press release. .
[29] "DNSSEC for the Root Zone" (http:// www.ripe.net/ ripe/ meetings/ ripe-59/presentations/ abley-dnssec-root-zone.pdf). .
[30] Hutchinson, James (6 May 2010). ICANN, Verisign place last puzzle pieces in DNSSEC saga (http:// www. networkworld.com/ news/
2010/050610-icann-verisign-place-last-puzzle.html?hpg1=bn). NetworkWorld. .
[31] "DNSSEC to become standard on .ORG domains by end of June" (http:// www.thetechherald. com/ article.php/ 201010/ 5366/
DNSSEC-to-become-standard-on-ORG-domains-by-end-of-June). . Retrieved 2010-03-24.
Domain Name System Security Extensions
[32] More security for root DNS servers (http:// www.h-online.com/ security/ news/ item/ More-security-for-root-DNS-servers-962569.html)
Heise Online, 24 March 2010
[33] "DNSSEC Root Zone High Level Technical Architecture" (http:// www.root-dnssec.org/wp-content/ uploads/ 2010/ 06/
draft-icann-dnssec-arch-v1dot4. pdf). .
[34] RFC 5702, §2.1. "RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number
[35] RFC 5702, §3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8."
[36] https:// data.iana. org/root-anchors/
[37] dns-wg archive: Signed zones list (http:// www.ripe.net/ ripe/ maillists/ archives/ dns-wg/ 2006/ msg00053. html)
[38] Good practices guide for deploying DNSSEC, p. 25 (http:/ / www.enisa. europa.eu/ act/ res/ technologies/ tech/ gpgdnssec/ at_download/
[39] ISC Launches DLV registry to kick off worldwide DNSSEC deployment (https:/ / www.isc. org/node/ 62)
[40] Deploying DNSSEC Without a Signed Root (http:// www. watson. org/~weiler/INI1999-19.pdf)
[41] Interim Trust Anchor Repository (https:/ / itar. iana. org/)
[42] Department of Homeland and Security wants master key for DNS (http:// www.heise.de/ english/ newsticker/ news/ 87655) Heise News,
30 March 2007
[43] Analysis: of Owning the keys to the Internet (http:// www.upi. com/ Security_Terrorism/Analysis/ 2007/ 04/ 12/
analysis_owning_the_keys_to_the_internet/) UPI, April 21, 2007
[44] UPI Analysis: Owning the keys to the Internet (http:// www.mail-archive.com/ osint@yahoogroups. com/ msg39697.html) March 24,
2011 - First link is dead, this is believed to be the same content
[45] DNSSEC Deployment Initiative Newsletter - Volume 1, Number 2 (http:// www. dnssec-deployment.org/ news/ dnssecthismonth/
200606-dnssecthismonth/), June 2006
[46] Memorandum For Chief Information Officers (http:// www.whitehouse. gov/omb/ memoranda/ fy2008/m08-23. pdf) Executive Office Of
The President — Office Of Management And Budget, 22 August 2008
[47] Feds tighten security on .gov (http:// www.networkworld.com/ news/ 2008/ 092208-government-web-security.html) Network World, 22
September 2008
[48] Comcast Blog - DNS Security Rollout Begins (http:/ / blog. comcast. com/ 2010/10/ dns-security-rollout-begins.html), October 18, 2010
[49] Comcast DNSSEC Public Service Announcement Video (http:// www.dnssec. comcast. net/ dnssec-video. htm), October 18, 2010
[50] Seshadri, Shyam (11 November 2008). "DNSSEC on Windows 7 DNS client" (http:/ / blogs. technet.com/ sseshad/ archive/ 2008/ 11/ 11/
dnssec-on-windows-7-dns-client.aspx). Port 53. Microsoft. .
[51] DNSSEC in Windows Server (https:// www.dns-oarc. net/ files/ workshop-2006/Microsoft-DNSSEC. pdf)
[52] http:/ / www. nlnetlabs. nl/ projects/ drill/
[53] http:/ / www. nlnetlabs. nl/ projects/ ldns/
[54] http:/ / www. nlnetlabs. nl/ projects/ drill/drill_extension. html
[55] http:/ / www. dnssec-tools. org/
[56] http:// www. dnssec-tools. org/ wiki/ index. php/ Authoritative_Zone_Administrator
[57] http:// www. dnssec-tools. org/ wiki/ index. php/ Authoritative_Server
[58] http:// www. dnssec-tools. org/ wiki/ index. php/ Recursive_Server
[59] http:// www. dnssec-tools. org/ wiki/ index. php/ DNSSEC_Application_Development
[60] http:// www. dnssec-tools. org/ wiki/ index. php/ DNSSEC_Applications
[61] http:// www. hznet. de/ dns/ zkt/
[62] http:/ / www. unbound. net/
[63] http:/ / www. george-barwood.pwp. blueyonder. co. uk/ DnsServer/
[64] http:/ / secspider. cs. ucla. edu/
[65] http:// dnsviz. net/
[66] http:/ / dnssec-analyzer. verisignlabs. com
[67] http:// www. dnssec-validator. cz/
[68] http:/ / registro.br/ dnsshim/
Domain Name System Security Extensions
External links
Organizations / Websites
• DNSSEC (http:// www. dnssec. net/ ) - DNSSEC information site: DNSSEC.net
• DNSEXT (http:// www. ietf.org/html. charters/ dnsext-charter.html) DNS Extensions IETF Working Group
• CircleID - News and Opinions on all DNSSEC related issues (http:/ / www.circleid.com/ topics/ dnssec/ )
• DNSSEC-Tools Project (http:// www. dnssec-tools. org)
• DNSSEC Deployment Coordination Initiative (http:// www.dnssec-deployment. org)
• DNSSEC Deployment Team (http:// www. root-dnssec. org)
• RFC 2535 Domain Name System Security Extensions
• RFC 3833 A Threat Analysis of the Domain Name System
• RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
• RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
• RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
• RFC 4398 Storing Certificates in the Domain Name System (DNS)
• RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
• RFC 4641 DNSSEC Operational Practices
• RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
Other documents
• A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions (http:// www.circleid.com/ posts/
dnssec_deployment_and_dns_security_extensions/ ) by Geoff Huston
• "Using the Domain Name System for System Break-Ins" (http:// www.cs. columbia. edu/ ~smb/ papers/
dnshack.pdf) by Steve Bellovin, 1995
• A short timeline of DNSSEC (http:// www. nlnetlabs. nl/ dnssec/ history. html) by Miek Gieben
• Enabling secure name resolution using DNSSEC for various applications (http:// wiki.archlinux.org/index. php/
• DNSSEC Howto (http:/ / www.nlnetlabs. nl/ dnssec_howto/ ) by Olaf Kolkman (RIPE NCC/NLnet Labs)
• Howto secure your (reverse) Zone (http:// www.hznet. de/ dns/ dnssec-decix050916. pdf) by Holger Zuleger
• Easier Email Security is on the Way? (http:/ / www.dwheeler.com/ essays/ easy-email-sec. html)
• "DNSSEC and the Zone Enumeration" by Marcos Sanz (http:// www.denic. de/ fileadmin/Domains/ DNSSEC/
zone-enumeration. pdf)
• NIST Special Publication (SP) 800-81, Secure Domain Name System (DNS) Deployment Guide (http:// csrc.
nist. gov/ publications/ nistpubs/ ), May 2006
• Bootstrapping the Adoption of Internet Security Protocols (http:// weis2006. econinfosec. org/docs/ 46. pdf),
Andy Ozment and Stuart E. Schechter, June 26–28, 2006
• DNSSEC BRIEFING and Root Zone Signing (Part I) (http:// ccnso. icann. org/workinggroups/
ccnso-iana-wg-dnssec-paper-04feb08. pdf), ccTLD paper on DNSSEC by ccNSO, February 2008
• U.S. National Strategy to Secure Cyberspace (http:/ / georgewbush-whitehouse. archives. gov/ pcipb/
cyberspace_strategy.pdf), February 2003
• Cybertelecom :: DNS Security & USG Policy (http:// www. cybertelecom.org/dns/ security. htm)
• SecSpider Tool for Tracking DNSSEC Deployment (http:// secspider. cs.ucla. edu)
• Plea to sign the root (http:/ / stfr.org)
Domain Name System Security Extensions
• DNSSEC in 6 Minutes by Alan Clegg, Internet Systems Consortium (http:/ / alan.clegg. com/ files/
DNSSEC_in_6_minutes.pdf) (PDF-Datei; 315 kB)
DVB-IPTV is an open DVB standard that enables Audio/Video services to be delivered to and through the home via
Internet Protocol networking. DVB-IPTV was formerly known as DVB-IPI.
External links
• DVB Standards & BlueBooks
[1] http:/ / www. dvb. org/
[2] http:/ / www. dvb. org/technology/ standards/
Echo Protocol
The Echo Protocol is a service in the Internet Protocol Suite defined in RFC 862. It was originally proposed for
testing and measurement of round-trip times in IP networks.
A host may connect to a server that supports the Echo Protocol using the Transmission Control Protocol (TCP) or the
User Datagram Protocol (UDP) on the well-known port number 7. The server sends back a copy of the identical data
it received.
Inetd implementation
On UNIX-like operating systems an echo server is built into the inetd daemon. The echo service is usually not
enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf and telling
inetd to reload its configuration:
echo stream tcp nowait root internal
echo dgram udp wait root internal
External links
• RFC 347 Echo Process
• RFC 862 Echo Protocol
Endpoint Handlespace Redundancy Protocol
Endpoint Handlespace Redundancy Protocol
The Endpoint Handlespace Redundancy Protocol is used by the Reliable server pooling (RSerPool) framework
for the communication between Pool Registrars to maintain and synchronize a handlespace.
It is allocated on the application layer like the Aggregate Server Access Protocol. It is a work in progress within the
External links
• Thomas Dreibholz's Reliable Server Pooling (RSerPool) Page
• IETF RSerPool Working Group
• Endpoint Handlespace Redundancy Protocol (ENRP)
• Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
• Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
• Reliable Server Pooling Policies
[1] http:/ / tools. ietf.org/html/ rfc5353
Ephemeral port
An ephemeral (short-lived) port is a transport protocol port for Internet Protocol (IP) communications allocated
automatically from a predefined range by the TCP/IP stack software.
It is typically used by the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or the Stream
Control Transmission Protocol (SCTP) as port for the client end of a client–server communication when the
application does not bind the socket to a specific port number, or by a server application to free up a well-known
service listening port and establish a service connection to the client host. The allocations are temporary and only
valid for the duration of the communication session. After completion of the communication session, the ports
become available for reuse, although most implementations may simply increment the last used port number until the
ephemeral port range is exhausted.
The IANA suggests 49152 to 65535 as "dynamic and/or private ports".
Many Linux kernels use 32768 to 61000. The file system path /proc/sys/net/ipv4/ip_local_port_range contains the
range in use.
FreeBSD uses the IANA port range since release 4.6. Previous versions, including the Berkeley Software
Distribution (BSD), use ports 1024 through 4999 as ephemeral ports, though it is often desirable to increase this
Microsoft Windows operating systems through Server 2003 use the range 1025 to 5000 as ephemeral ports.
Windows Vista, Windows 7, and Server 2008 use the IANA range.
Ephemeral port
[1] See IANA port number assignments (http:/ / www.iana. org/assignments/ port-numbers)
[2] Microsoft Windows Technet Library (http:/ / technet. microsoft.com/ en-us/ library/bb878133. aspx)
[3] KB Article 929851 (http:/ / support. microsoft. com/ kb/ 929851/ )
External links
• The Ephemeral Port Range (http:// www. ncftp.com/ ncftpd/ doc/ misc/ ephemeral_ports. html) at NcFTP.com
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed
under the GFDL.
Extensible Name Service
eXtensible Name Service (often shortened to XNS) is an open protocol for universal addressing and automated data
exchange. It is an XML-based digital identity architecture.
The development of XML in 1998 led to the XNS project, and the establishment of an international non-profit
governance organization, XNS Public Trust Organization (XNSORG), in early 2000.
In 2002, the XNS specifications were contributed by XNSORG to OASIS, where they became part of the XRI
(Extensible Resource Identifier) and XDI (XRI Data Interchange) Technical Committees. Together these two
standards, XRI and XDI, form the basis for the formation of the Dataweb.
XNSORG has since evolved into XDI.ORG, and now offers community-based XRI/XDI infrastructure.
External links
[1] http:/ / www. xns. org/
[2] http:// www. xdi. org/
Exterior Gateway Protocol
Exterior Gateway Protocol
The Exterior Gateway Protocol (EGP) is a now obsolete routing protocol for the Internet originally specified in
1982 by Eric C. Rosen of Bolt, Beranek and Newman, and David L. Mills. It was first described in RFC 827 and
formally specified in RFC 904 (1984). Not to be confused with EGPs in general (of which EGP and Border Gateway
Protocol (BGP) are examples), EGP is a simple reachability protocol, and, unlike modern distance-vector and
path-vector protocols, it is limited to tree-like topologies.
During the early days of the Internet, EGP version 3 (EGP3) was used to interconnect autonomous systems.
Currently, BGP version 4 is the accepted standard for Internet routing and has essentially replaced the more limited
External links
• TCP/IP Exterior Gateway Protocol (EGP)
EGP Overview by The TCP/IP Guide
[1] http:/ / www. tcpipguide. com/ free/t_TCPIPExteriorGatewayProtocolEGP.htm
External Data Representation
External Data Representation (XDR) is an IETF standard from 1995. It allows data to be wrapped in an
architecture independent manner allowing data to be transferred between heterogeneous computer systems.
Converting from the local representation to XDR is called encoding. Converting from XDR to the local
representation is called decoding. XDR is implemented as a software library of functions which is portable between
different operating systems and is also independent of the transport layer.
The XDR data format is in use by many systems, including:
• Network File System (protocol)
• NDMP Network Data Managerment Protocol
• Open Network Computing Remote Procedure Call
• EMC's NetWorker backup software (in its newer releases)
• NetCDF (a scientific data format)
• The R language and environment for statistical computing
• High Level Architecture (simulation)
• The HTTP-NG Binary Wire Protocol
• The SpiderMonkey JavaScript engine, to serialize/deserialize compiled JavaScript code
• The Ganglia distributed monitoring system
• The sFlow network monitoring standard
• The libvirt virtualization library, API and UI
• The Firebird (database server) for Remote Binary Wire Protocol
External Data Representation
XDR data types
• boolean
• int - 32 bit integer
• unsigned int - unsigned 32 bit integer
• hyper - 64 bit integer
• unsigned hyper - unsigned 64 bit integer
• IEEE float
• IEEE double
• quadruple (new in RFC1832)
• enumeration
• structure
• string
• fixed length array
• variable length array
• union - discriminated union
• fixed length opaque data
• variable length opaque data
• void - zero byte quantity
• optional - Optional data is notated similarly to C pointers, but is represented as the data type "pointed to" with a
boolean "present or not" flag.
XDR uses a base unit of 4 bytes. Thus smaller data types still occupy four bytes each after encoding. Variable-length
types like string and opaque are padded to a total divisible by four bytes.
External links
The XDR standard exists in three different versions in the following RFC's:
• RFC 4506 2006 This document makes no technical changes to RFC 1832 and is published for the purposes of
noting IANA considerations, augmenting security considerations, and distinguishing normative from informative
• RFC 1832 1995 version. Added Quadruple precision floating point to RFC 1014.
• RFC 1014 Original 1987 version.
• Cisco's XDR: Technical Notes
• jsxdrapi.c
, the main source file of SpiderMonkey that uses XDR
• xdr.cpp
main xdr source file used in Firebird remote protocol
• http:/ / www. cs. rpi.edu/ ~hollingd/ netprog/notes/ xdr/xdr. pdf
• The GNU Libc implementation of rpcgen, the XDR parser.
• Mu Dynamics Research Labs racc grammar for XDR
• IvmaiAsn ASN1/ECN/XDR Tools
(a collection of tools containing an XDR/RPC-to-ASN.1 converter)
External Data Representation
[1] http:/ / www. cisco. com/ en/ US/ docs/ ios/ sw_upgrades/ interlink/ r2_0/rpc_pr/rpxdesc.html
[2] http:// lxr.mozilla. org/ seamonkey/ source/ js/ src/ jsxdrapi. c
[3] http:// firebird.svn. sourceforge.net/ viewvc/ firebird/firebird/trunk/src/ remote/ xdr.cpp?revision=51496& view=markup
[4] http:// sources. redhat.com/ cgi-bin/ cvsweb. cgi/ libc/ sunrpc/ ?cvsroot=glibc
[5] http:// labs. mudynamics. com/ 2008/ 03/ 24/ ruby-xdr-parser/
[6] http:// ivmaiasn. sourceforge.net/
FAST TCP (also written "FastTCP") is a TCP congestion avoidance algorithm especially targeted at long-distance,
high latency links, developed at the Netlab
, California Institute of Technology and now being commercialized by
. It is compatible with existing TCP algorithms, requiring modification only to the computer which is
sending data.
The name FAST is a recursive acronym for FAST AQM Scalable TCP, where AQM stands for Active Queue
Management, and TCP stands for Transmission Control Protocol.
Principles of operation
The role of congestion control is to moderate the rate at which data is transmitted, according to the capacity of the
network and the rate at which other users are transmitting. Like TCP Vegas, FAST TCP

uses queueing delay
instead of loss probability as a congestion signal.
Most current congestion control algorithms detect congestion and slow down when they discover that packets are
being dropped, so that the average sending rate depends on the loss probability. This has two drawbacks. First, low
loss probabilities are required to sustain high data rates; in the case of TCP Reno, very low loss probabilities are
required, but even new congestion avoidance algorithms such as H-TCP, BIC TCP and HSTCP require loss rates
lower than those provided by most wireless wide area networks. Moreover, packet loss only provides a single bit of
information about the congestion level, whereas delay is a continuous quantity and in principle provides more
information about the network.
A FAST TCP flow seeks to maintain a constant number of packets in queues throughout the network. The number of
packets in queues is estimated by measuring the difference between the observed round trip time (RTT) and the base
RTT, defined as the round trip time when there is no queueing. The base RTT is estimated as the minimum observed
RTT for the connection. If too few packets are queued, the sending rate is increased, while if too many are queued,
the rate is decreased. In this respect, it is a direct descendant of TCP Vegas.
The difference between TCP Vegas and FAST TCP lies in the way in which the rate is adjusted when the number of
packets stored is too small or large. TCP Vegas makes fixed size adjustments to the rate, independent of how far the
current rate is from the target rate. FAST TCP makes larger steps when the system is further from equilibrium and
smaller steps near equilibrium. This improves the speed of convergence and the stability.
Strengths and weaknesses
Delay-based algorithms can, in principle, maintain a constant window size, avoiding the oscillations inherent in
loss-based algorithms. However, they also detect congestion earlier than loss-based algorithms, since delay
corresponds to partially filled buffers, while loss results from totally filled buffers. This can be either a strength or a
weakness. If the only protocol used in a network is delay-based, then the inefficiency of loss can be avoided;
however, if loss-based and delay-based protocols share the network,
then delay-based algorithms tend to be less
aggressive. This can be overcome by suitable choice of parameters, leading to complex interactions studied by Tang
et al.
Delay measurements are also subject to jitter as a result of operating system scheduling, or bus contention.
Whether the strengths or weaknesses prevail is not clear, and depends in large part on the particular scenario.
Intellectual property
Unlike most TCP congestion avoidance algorithms, FAST TCP is protected by several patents.

Instead of
seeking standardization by the IETF, the inventors of FAST, notably Steven Low and Cheng Jin, are seeking to
commercialize it through the company FastSoft
. Currently FastSoft sells a 1-Unit rack appliance which can be
deployed at the sender-side with no other software or hardware modifications needed on either end.
[1] http:/ / netlab.caltech. edu/
[2] http:/ / www. fastsoft. com
[3] Wei, David X.; Jin, Cheng; Low, Steven H. and Hegde, Sanjay (2006). "FAST TCP: motivation, architecture, algorithms, performance"
(http:// netlab.caltech. edu/ pub/ papers/ FAST-ToN-final-060209.pdf). IEEE/ACM Trans. on Networking 14 (6): 1246–1259.
doi:10.1109/TNET.2006.886335. .
[4] Jin, Cheng; Wei, David X.; Low, Steven H.; Buhrmaster, G.; Bunn, J.; Choe, D. H.; Cottrell, R. L. A.; Doyle, J. C.; Feng, W.; Martin, O.;
Newman, H. Paganini, F.; Ravot, S.; Singh, S. (2005). "FAST TCP: from theory to experiments" (http:/ / netlab.caltech.edu/ pub/ papers/
fast-network05.pdf). IEEE Network 19 (1): 4–11. doi:10.1109/MNET.2005.1383434. .
[5] Tang, Ao; Wang, Jiantao; Low, Steven H. and Chiang, Mung (March 2005). Network Equilibrium of heterogeneous congestion control
protocols (http:// netlab. caltech. edu/ pub/ papers/ multiprotocol-infocom05.pdf). Miami, FL. .
[6] Jin, Cheng; Low, Steven H.; Wei, Xiaoliang (2005-01-27). "Method and apparatus for network congestion control" (http:// appft1. uspto.
gov/ netacgi/ nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1& u=/ netahtml/ PTO/search-bool.html& r=2&f=G&l=50& co1=AND&
d=PG01&s1=jin. IN.& s2=low. IN. & OS=IN/jin+ AND+IN/ low& RS=IN/jin+ AND+IN/ low). United States Patent & Trademark
Office. . Retrieved 2006-11-05.
[7] Jin, Cheng; Low, Steven H.; Wei, David X.; Wydrowski, Bartek; Tang, Ao; Choe, Hyojeong (2006-03-09). "Method and apparatus for
network congestion control using queue control and one-way delay measurements" (http:/ / appft1. uspto. gov/ netacgi/
nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1& u=/ netahtml/ PTO/search-bool.html& r=1&f=G&l=50& co1=AND& d=PG01&s1=jin.
IN.&s2=low. IN.& OS=IN/jin+ AND+IN/ low& RS=IN/jin+ AND+ IN/low). United States Patent & Trademark Office. . Retrieved
External links
• FAST (http://netlab. caltech. edu/ FAST/) Home Page.
• Supercomputing 2005 Bandwidth Challenge (http:/ / ultralight.caltech. edu/ web-site/ sc05/ html/ index. html)
• FastSoft home page (http:// www. fastsoft. com)
Fibre Channel over IP
Fibre Channel over IP
Fibre Channel over IP (FCIP or FC/IP, also known as Fibre Channel tunneling or storage tunneling), is an
Internet Protocol (IP)-based storage networking technology developed by the Internet Engineering Task Force
(IETF) and defined in RFC 3821. FCIP mechanisms enable the transmission of Fibre Channel (FC) information by
tunneling data between storage area network (SAN) facilities over IP networks; this capacity facilitates data sharing
over a geographically distributed enterprise. FCIP is among the key technologies expected to help bring about rapid
development of the storage area network market by increasing the capabilities and performance of storage data
An FCIP Entity functions to forward Fibre Channel frames after encapsulating them and viewed from an IP Network
perspective, these entities are peers that communicate using TCP/IP.
Similar protocols
A competing technology to FCIP is known as iFCP. It used routing instead of tunneling to enable connectivity of
Fibre Channel networks over IP.
Another method, iSCSI, generates SCSI codes from user requests and encapsulates the data into TCP/IP packets for
transmission over an IP network. Intended to link geographically distributed SANs, FCIP can only be used in
conjunction with Fibre Channel technology; in comparison, iSCSI can run over existing IP networks. SAN
connectivity, through methods such as FCIP and iSCSI, offers benefits over the traditional point-to-point
connections of earlier data storage systems, such as higher performance, availability, and fault-tolerance. A number
of vendors, including Bloombase Technologies, Brocade Communications Systems, Cisco Systems, Nortel, QLogic,
SANRAD, and Lucent introduced FCIP-based products (such as switches and routers).
External links
• RFC 3821 - Fibre Channel Over TCP/IP (FCIP)
File eXchange Protocol
File eXchange Protocol
File eXchange Protocol (FXP) and (FXSP) is a method of data transfer which uses FTP to transfer data from one
remote server to another (inter-server) without routing this data through the client's connection. Conventional FTP
involves a single server and a single client; all data transmission is done between these two. In the FXP session, a
client maintains a standard FTP connection to two servers, and can direct either server to connect to the other to
initiate a data transfer. The advantage of using FXP over FTP is evident when a high-bandwidth server demands
resources from another high-bandwidth server, but only a low-bandwidth client, such as a network administrator
working away from location, has the authority to access the resources on both servers.
Enabling FXP support can make a server vulnerable to an exploit known as FTP bounce. As a result of this, FTP
server software often has FXP disabled by default.
FXP over SSL
Some FTP Servers such as glFTPd, cuftpd, RaidenFTPD, drftpd, and wzdftpd support negotiation of a secure data
channel between two servers using either of the FTP protocol extension commands; CPSV or SSCN. This normally
works by the client issuing CPSV in lieu of the PASV command - or by sending SSCN prior to PASV transfers -,
which instructs the server to create either a SSL or TLS connection. However, both methods - CPSV and SSCN - are
susceptible to Man-in-the-Middle attacks, since the two FTP servers do not verify each other's SSL certificates.
SSCN was first introduced by RaidenFTPD and SmartFTP in 2003 and has been widely adopted now.
Although FXP is often considered a distinct protocol, it is in fact merely an extension of the FTP protocol and is
specified in RFC 959:
User-PI - Server A (Dest) User-PI - Server B (Source)
------------------ ------------------
C->A : Connect C->B : Connect
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
B->A : Connect to HOST-A, PORT-a
This "protocol" is standardized as a subset of RFC 0959 by the IETF as:
• RFC 959 File Transfer Protocol (FTP). J. Postel, J. Reynolds. Oct-1985. This obsoleted the preceding RFC 765
and earlier FTP RFCs back to the original RFC 114.
File Transfer Protocol
File Transfer Protocol
File Transfer Protocol (FTP) is a standard network protocol used to copy a file from one host to another over a
TCP-based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and
data connections between the client and server.
FTP users may authenticate themselves using a clear-text sign-in
protocol but can connect anonymously if the server is configured to allow it.
The first FTP client applications were interactive command-line tools, implementing standard commands and syntax.
Graphical user interface clients have since been developed for many of the popular desktop operating systems in use

The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114
on 16 April 1971, before TCP and IP even existed.
It was and later replaced by RFC 765 (June 1980) and RFC 959
(October 1985), the current specification.
Several proposed standards amend RFC 959, for example RFC 2228
(June 1997) proposes security extensions and RFC 2428 (September 1998) adds support for IPv6 and defines a new
type of passive mode.
Protocol overview
The protocol is specified in RFC 959,
which is summarized below.
FTP operates on the application layer of the OSI model, and is used to transfer files using TCP/IP.
In order to do
this an FTP server needs to be running and waiting for incoming requests.
The client computer is then able to
communicate with the server on port 21.

This connection, called the control connection,
remains open for the
duration of the session, with a second connection, called the data connection,

either opened by the server from
its port 20 to a negotiated client port (active mode) or opened by the client from an arbitrary port to a negotiated
server port (passive mode) as required to transfer file data.

The control connection is used for session
administration (i.e., commands, identification, passwords)
exchanged between the client and server using a
telnet-like protocol. For example "RETR filename" would transfer the specified file from the server to the client. Due
to this two-port structure, FTP is considered an out-of-band, as opposed to an in-band protocol such as HTTP.
The server responds on the control connection with three digit status codes in ASCII with an optional text message,
for example "200" (or "200 OK.") means that the last command was successful. The numbers represent the code
number and the optional text represent explanations (e.g., <OK>) or needed parameters (e.g., <Need account for
storing file>).
A file transfer in progress over the data connection can be aborted using an interrupt message sent
over the control connection.
FTP can be run in active or passive mode, which determine how the data connection is established.
In active mode,
the client sends the server the IP address and port number on which the client will listen, and the server initiates the
TCP connection.
In situations where the client is behind a firewall and unable to accept incoming TCP
connections, passive mode may be used. In this mode the client sends a PASV command to the server and receives
an IP address and port number in return.

The client uses these to open the data connection to the server.
modes were updated in September 1998 to add support for IPv6. Other changes were made to passive mode at that
time, making it extended passive mode.
While transferring data over the network, four data representations can be used


• ASCII mode: used for text. Data is converted, if needed, from the sending host's character representation to "8-bit
ASCII" before transmission, and (again, if necessary) to the receiving host's character representation. As a
consequence, this mode is inappropriate for files that contain data other than plain text.
File Transfer Protocol
• Image mode (commonly called Binary mode): the sending machine sends each file byte for byte, and the recipient
stores the bytestream as it receives it. (Image mode support has been recommended for all implementations of
• EBCDIC mode: use for plain text between hosts using the EBCDIC character set. This mode is otherwise like
ASCII mode.
• Local mode: Allows two computers with identical setups to send data in a proprietary format without the need to
convert it to ASCII
For text files, different format control and record structure options are provided. These features were designed to
facilitate files containing Telnet or ASA formatting.
Data transfer can be done in any of three modes

• Stream mode: Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all
processing is left up to TCP. No End-of-file indicator is needed, unless the data is divided into records.
• Block mode: FTP breaks the data into several blocks (block header, byte count, and data field) and then passes it
on to TCP.
• Compressed mode: Data is compressed using a single algorithm (usually run-length encoding).
FTP login utilizes a normal username/password scheme for granting access.
The username is sent to the server
using the USER command, and the password is sent using the PASS command.
If the information provided by the
client is accepted by the server, the server will send a greeting to the client and the session will be open.
If the
server supports it, users may log in without providing login credentials. The server will also limit access for that
session based on what the user is authorized.
FTP and Trivial FTP are very similar protocols. FTP is the more complex version of the two.
It provides more
features and is session-oriented.
FTP is also more commonly used and is typically simpler to use.
essentially a "stripped down" version, with fewer commands and capabilities. It is designed to be used for cases
where simplicity and small file-size is important.
Another significant difference between the two is that FTP relies
on TCP, whereas TFTP instead uses UDP, rendering it connectionless and therefore less reliable.
FTP was not designed to be a secure protocol—especially by today's standards—and has many security
In May 1999, the authors of RFC 2577 enumerated the following flaws:
• Bounce attacks
• Spoof attacks
• Brute force attacks
• Packet capture (sniffing)
• Username protection
• Port stealing
FTP was not designed to encrypt its traffic; all transmissions are in clear text, and user names, passwords, commands
and data can be easily read by anyone able to perform packet capture (sniffing) on the network.

This problem
is common to many Internet Protocol specifications (such as SMTP, Telnet, POP and IMAP) designed prior to the
creation of encryption mechanisms such as TLS or SSL.
A common solution to this problem is use of the "secure",
TLS-protected versions of the insecure protocols (e.g. FTPS for FTP, TelnetS for Telnet, etc.) or selection of a
different, more secure protocol that can handle the job, such as the SFTP/SCP tools included with most
File Transfer Protocol
implementations of the Secure Shell protocol.
Anonymous FTP
A host that provides an FTP service may additionally provide anonymous FTP access.
Users typically log into the
service with an 'anonymous' account when prompted for user name. Although users are commonly asked to send
their email address in lieu of a password,
no verification is actually performed on the supplied data;.
Many FTP
hosts whose purpose is to provide software updates will provide anonymous logins.
Examples of anonymous FTP
servers can be found here
Remote FTP or FTPmail
Where FTP access is restricted, a remote FTP (or FTPmail) service can be used to circumvent the problem. An
e-mail containing the FTP commands to be performed is sent to a remote FTP server, which is a mail server that
parses the incoming e-mail, executes the FTP commands, and sends back an e-mail with any downloaded files as an
attachment. Obviously this is less flexible than an FTP client, as it is not possible to view directories interactively or
to modify commands, and there can also be problems with large file attachments in the response not getting through
mail servers. The service was used when some users' only internet access was via email through gateways such as a
BBS or online service. As most internet users these days have ready access to FTP, this procedure is no longer in
everyday use.
Web browser support
Most common web browsers can retrieve files hosted on FTP servers, although they may not support protocol
extensions such as FTPS.

When an FTP—rather than HTTP—URL is supplied, the accessible contents of the
remote server is presented in a manner similar to that used for other Web content. A full-featured FTP client can be
run within Firefox in the form of an extension called FireFTP [15]
FTP URL syntax is described in RFC1738,
taking the form:
(The bracketed parts are optional.) For example:
ftp:// public. ftp-servers.example. com/ mydirectory/myfile. txt
ftp:/ / user001:secretpassword@private. ftp-servers.example. com/ mydirectory/myfile.txt
More details on specifying a user name and password may be found in the browsers' documentation, such as, for
example, Firefox
and Internet Explorer
By default, most web browsers use passive (PASV) mode, which more easily traverses end-user firewalls.
File Transfer Protocol
NAT and firewall traversal
FTP normally transfers data by having the server connect back to the client, after the PORT command is sent by the
client. This is problematic for both NATs and firewalls, which do not allow connections from the Internet towards
internal hosts.
For NATs, an additional complication is the representation of the IP addresses and port number in
the PORT command refer to the internal host's IP address and port, rather than the public IP address and port of the
There are two approaches to this problem. One is that the FTP client and FTP server use the PASV command, which
causes the data connection to be established from the FTP client to the server.
This is widely used by modern FTP
clients. Another approach is for the NAT to alter the values of the PORT command, using an application-level
gateway for this purpose.
Secure FTP
There are several methods of securely transferring files that have been called "Secure FTP" at one point or another.
FTPS (explicit)
Explicit FTPS is an extension to the FTP standard that allows clients to request that the FTP session be encrypted.
This is done by sending the "AUTH TLS" command. The server has the option of allowing or denying connections
that do not request TLS. This protocol extension is defined in the proposed standard: RFC 4217
FTPS (implicit)
Implicit FTPS is deprecated standard for FTP that required the use of a SSL or TLS connection. It was specified to
use different ports than plain FTP.
SFTP, the "SSH File Transfer Protocol," is not related to FTP except that it also transfers files and has a similar
command set for users.
FTP over SSH (not SFTP)
FTP over SSH (not SFTP) refers to the practice of tunneling a normal FTP session over an SSH connection.
Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly
difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial
client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at
either end will set up new TCP connections (data channels), which bypass the SSH connection, and thus have no
confidentiality, integrity protection, etc.
Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, and monitor
and rewrite FTP control channel messages and autonomously open new forwardings for FTP data channels. Version
3 of SSH Communications Security's software suite, the GPL licensed FONC
, and Co:Z FTPSSH Proxy
three software packages that support this mode.
FTP over SSH is sometimes referred to as secure FTP; this should not be confused with other methods of securing
FTP, such as with SSL/TLS (FTPS). Other methods of transferring files using SSH that are not related to FTP
include SFTP and SCP; in each of these, the entire conversation (credentials and data) is always protected by the
SSH protocol.
File Transfer Protocol
List of FTP commands
Below is a list of FTP commands that may be sent to an FTP server, including all commands that are standardized
in RFC 959 by the IETF. All commands below are RFC 959 based unless stated otherwise. Note that most
command-line FTP clients present their own set of commands to users. For example, GET is the common user
command to download a file instead of the raw command RETR.
Command RFC Description
ABOR Abort an active file transfer.
ACCT Account information.
ADAT RFC 2228 Authentication/Security Data
ALLO Allocate sufficient disk space to receive a file.
APPE Append.
AUTH RFC 2228 Authentication/Security Mechanism
CCC RFC 2228 Clear Command Channel
CDUP Change to Parent Directory.
CONF RFC 2228 Confidentiality Protection Command
CWD Change working directory.
DELE Delete file.
ENC RFC 2228 Privacy Protected Channel
EPRT RFC 2428 Specifies an extended address and port to which the server should connect.
EPSV RFC 2428 Enter extended passive mode.
FEAT RFC 2389 Get the feature list implemented by the server.
LANG RFC 2640 Language Negotiation
LIST Returns information of a file or directory if specified, else information of the current working directory is returned.
LPRT RFC 1639 Specifies a long address and port to which the server should connect.
LPSV RFC 1639 Enter long passive mode.
MDTM RFC 3659 Return the last-modified time of a specified file.
MIC RFC 2228 Integrity Protected Command
MKD Make directory.
MLSD RFC 3659 Lists the contents of a directory if a directory is named.
MLST RFC 3659 Provides data about exactly the object named on its command line, and no others.
MODE Sets the transfer mode (Stream, Block, or Compressed).
NLST Returns a list of file names in a specified directory.
NOOP No operation (dummy packet; used mostly on keepalives).
OPTS RFC 2389 Select options for a feature.
PASS Authentication password.
PASV Enter passive mode.
PBSZ RFC 2228 Protection Buffer Size
PORT Specifies an address and port to which the server should connect.
PROT RFC 2228 Data Channel Protection Level.
File Transfer Protocol
PWD Print working directory. Returns the current directory of the host.
QUIT Disconnect.
REIN Re initializes the connection.
REST Restart transfer from the specified point.
RETR Transfer a copy of the file
RMD Remove a directory.
RNFR Rename from.
RNTO Rename to.
SITE Sends site specific commands to remote server.
SIZE RFC 3659 Return the size of a file.
SMNT Mount file structure.
STAT Returns the current status.
STOR Accept the data and to store the data as a file at the server site
STOU Store file uniquely.
STRU Set file transfer structure.
SYST Return system type.
TYPE Sets the transfer mode (ASCII/Binary).
USER Authentication username.
• List of FTP server return codes - in response to commands from a client, the FTP server returns reply codes
[1] Forouzan, B.A. (2000). TCP/IP: Protocol Suite. 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
[2] Kozierok, Charles M. (2005). The TCP/IP Guide v3.0, Retrieved From: http:// www.tcpipguide.com/ free/
[3] Dean, Tamara (2010). Network+ Guide to Networks. Delmar. pp. 168–171.
[4] Clark, M.P. (2003). Data Networks IP and the Internet. 1st ed. West Sussex, England: John Wiley & Sons Ltd.
[5] Postel, J., & Reynolds. J. (October 1985). RFC 959 (http:// www.ietf.org/ rfc/rfc0959.txt). In The Internet Engineering Task Force.
[6] Parker, Don, (September 2005). Understanding the FTP Protocol. Retrieved from http:/ / www.windowsnetworking.com/ articles_tutorials/
[7] Active FTP vs. Passive FTP, a Definitive Explanation. Retrieved from http:// slacksite. com/ other/ ftp.html
[8] Kurose, J.F. & Ross, K.W. (2010). Computer Networking. 5th ed. Boston, MA: Pearson Education, Inc.
[9] Allman, M. & Metz, C. & Ostermann, S. (September 1998). RFC 2428 (http:// www.ietf.org/rfc/rfc2428.txt). In The Internet Engineering
Task Force.
[10] Securing FTP using SSH. Retrieved from http:/ / www.nurdletech.com/ ftp.html
[11] Allman, M. & Ostermann, S. (May 1999). RFC 2577. In The Internet Engineering Task Force. Retrieved from http:// www.ietf.org/ rfc/
[12] Deutsch, P. & Emtage, A. & Marine, A. (May 1994). RFC 1635. In The Internet Engineering Task Force. Retrieved from http:// www. ietf.
org/ rfc/rfc1635.txt
[13] http:/ / www. ftp-sites. org/
[14] Matthews, J. (2005). Computer Networking: Internet Protocols in Action. 1st ed. Danvers, MA: John Wiley & Sons Inc.
[15] https:/ / addons. mozilla. org/ en-US/firefox/addon/ 684/
[16] Berners-Lee, T. & Masinter, L. & McCahill, M. (December 1994). RFC 1738. In The Internet Engineering Task Force. Retrieved from http:/
/ www. ietf.org/rfc/rfc1738.txt
[17] http:// support. mozilla. com/ en-US/kb/ Accessing+ FTP+servers#FTP_servers_that_require_a_username_and_password
[18] http:// support. microsoft.com/ kb/ 135975
[19] Gleason, Mike, (2005), The File Transfer Protocol and Your Firewall/NAT. Retrieved from http:// www.ncftp.com/ ncftpd/ doc/ misc/
ftp_and_firewalls. html
[20] http:// tools. ietf.org/html/ rfc4217
File Transfer Protocol
[21] http:/ / fonc.sourceforge.net/
[22] http:/ / dovetail.com/ products/ ftpsshproxy. html
Further reading
• RFC 959 – (Standard) File Transfer Protocol (FTP). J. Postel, J. Reynolds. October 1985.
• RFC 1579 – (Informational) Firewall-Friendly FTP.
• RFC 2228 – (Proposed Standard) FTP Security Extensions.
• RFC 2389 – (Proposed Standard) Feature negotiation mechanism for the File Transfer Protocol. August 1998.
• RFC 2428 – (Proposed Standard) Extensions for IPv6, NAT, and Extended passive mode. September 1998.
• RFC 2640 – (Proposed Standard) Internationalization of the File Transfer Protocol.
• RFC 3659 – (Proposed Standard) Extensions to FTP. P.Hethmon. March 2007.
• RFC 5797 – (Proposed Standard) FTP Command and Extension Registry. March 2010.
• RFC 697 - CWD Command of FTP
• RFC 959 - File Transfer Protocol (FTP)
• RFC 1639 - FTP Operation Over Big Address Records (FOOBAR)
• RFC 2228 - FTP Security Extensions
• RFC 2389 - Feature negotiation mechanism for the File Transfer Protocol
• RFC 2428 - FTP Extensions for IPv6 and NATs
• RFC 2640 - Internationalization of the File Transfer Protocol
• RFC 3659 - Extensions to FTP
• RFC 5797 - FTP Command and Extension Registry
External links
• FTP Reviewed (http:// pintday. org/whitepapers/ ftp-review.shtml) — a review of the protocol notably from a
security standpoint, pintday.org
• Raw FTP command list (http:/ / www. nsftools. com/ tips/ RawFTP.htm), nsftools.com
• FTP Sequence Diagram (http:// www. eventhelix. com/ RealtimeMantra/ Networking/FTP.pdf) (in PDF format),
• FTP Server Connectivity Test (http:/ / www. infobyip.com/ ftptest. php), infobyip.com
• IANA FTP Commands and Extensions registry (http:/ / www.iana. org/ assignments/ ftp-commands-extensions/
ftp-commands-extensions.xhtml) - The official registry of FTP Commands and Extensions
• Raw FTP command list (http:/ / www. nsftools. com/ tips/ RawFTP.htm)
• Basic FTP simulation (http:/ / www. visualland. net/ view.php?cid=1163& protocol=FTP&title=1. FTP Basics&
Files2U (F2U) is a proprietary application layer protocol, based on TCP/IP. F2U combines various application layer
protocols including HTTP, FTP and SMTP to offer a single system to transfer large files through the internet. F2U
protocol is used by an application server called Files2U. The new generation of F2U can also use UDP at the
Transport layer. The use of UDP packets overcomes latency issues and packet loss. Forward Error Correction built
into the new version of F2U protocol allows for dropped packets or reordering of packets. This makes it extremely
useful to transfer large files where network conditions are poor. Files2U is deployed worldwide in various
government, military and commercial instances. APIs are available on F2U to develop custom applications or
alternatively use Files2U application for web-based file transfers.
Objectives of F2U
The objective of F2U as outlined by its specifications are the following:
1. Promote easy sharing of large files
2. Be seamless to the end user
3. Provide enhanced security and authentication
4. Be firewall and proxy friendly
History and Development of F2U
Files2U has been developed independently by various groups that managed to combine the versatility of FTP, the
easy of use of HTTP and the availability of SMTP. The combining of three protocols into one has led to a single
protocol that can handle large file transfers in a secure and easy manner. The new generation of F2U protocol
supports UDP at the Transport layer as well as TCP. TCP has an inherent quality control mechanism that allows for
packet ordering and minor packet loss (up to 2%). This inherent mechanism works well in wired networks but when
network conditions are poor such as intercontinental transfers or wireless networks, TCP’s effective throughput is
low. UDP on the other hand works well in such network conditions, but doesn’t compensate for actual lost packets.
To over come this issue of packet loss, F2U supports forward error correction. This offers a fast protocol with no call
back channel where packets can be dropped or rearranged without significant loss to the speed at which data is
F2U and Web-Browsers
F2U protocol is supported by most new web-browsers including Internet Explorer v4.0 and above. The F2U system
also needs a JVM to operate.
Security and Encryption
F2U protocol can be deployed using an SSL certificate. This allows F2U to wrap over HTTP. If an SSL certificate is
used then the transmission is carried encrypted over HTTPs. This adds a slight overhead (5%) over the traffic data
but offers encryption at an industry-standard level. If the new generation of F2U is used, then UDP packets are
encrypted using Digital Fountain’s Raptor Codes. At the application level, Files2U application supports further
authentication and authorization procedures that guarantee delivery to the recipient.
Shortcomings and criticism
The blending of three application protocols to comprise a single application system has led to overhead in the packet
size. With an overhead of 3–5%, the overall transfer of data is slightly inefficient with F2U protocol. At the
application level, Files2U supports reporting and logging. However this has been criticized for not being verbose
Finger protocol
In computer networking, the Name/Finger protocol and the Finger user information protocol are simple network
protocols for the exchange of human-oriented status and user information.
Name/Finger protocol
The Name/Finger protocol, written by David Zimmerman, is based on Request for comments document RFC 742
(December 1977) as an interface to the name and finger programs that provide status reports on a particular
computer system or a particular person at network sites. The finger program was written in 1971 by Les Earnest who
created the program to solve the need of users who wanted information on other users of the network. Information on
who is logged-in was useful to check the availability of a person to meet. This was probably the earliest form of
presence information for remote network users.
Prior to the finger program, the only way to get this information was with a who program that showed IDs and
terminal line numbers for logged-in users. Earnest named his program after the idea that people would run their
fingers down the who list to find what they were looking for.
Finger user information protocol
The finger daemon runs on TCP port 79. The client will (in the case of remote hosts) open a connection to port 79.
An RUIP (Remote User Information Program) becomes available on the remote end of the connection to process the
request. The local host sends the RUIP a one line query based upon the Finger query specification, and waits for the
RUIP to respond. The RUIP receives and processes the query, returns an answer, then initiates the close of the
connection. The local host receives the answer and the close signal, then proceeds closing its end of the connection.
The Finger user information protocol is based on RFC 1288 (The Finger User Information Protocol, December
1991). Typically the server side of the protocol is implemented by a program fingerd (for finger daemon), while
the client side is implemented by the name and finger programs which are supposed to return a friendly,
human-oriented status report on either the system at the moment or a particular person in depth. There is no required
format, and the protocol consists mostly of specifying a single command line.
The program would supply information such as whether a user is currently logged-on, e-mail address, full name etc.
As well as standard user information, finger displays the contents of the .project and .plan files in the user's
home directory. Often this file (maintained by the user) contains either useful information about the user's current
activities, similar to micro-blogging, or alternatively all manner of humor.
Finger protocol
Security concerns
Supplying such detailed information as e-mail addresses and full names was considered acceptable and convenient in
the early days of networking, but later was considered questionable for privacy and security reasons. Finger
information has been frequently used by hackers as a way to initiate a social engineering attack on a company's
computer security system. By using a finger client to get a list of a company's employee names, email addresses,
phone numbers, and so on, a cracker can telephone or email someone at a company requesting information while
posing as another employee. The finger daemon has also had several exploitable security holes which crackers have
used to break into systems. The Morris worm exploited an overflow vulnerability in fingerd (among others) to
spread. The finger protocol is also incompatible with Network Address Translation (NAT) from the private network
address ranges (e.g. that are used by the majority of home and office workstations that connect to the
Internet through routers or firewalls.
For these reasons, while finger was widely used during the early days of Internet, by the late 1990s the vast majority
of sites on the internet no longer offered the service.
Application support
It is implemented on Unix, Unix-like systems, and current versions of Windows. Other software has finger support:
• ELinks
• Minuet
[1] Colbath, Sean (20 Feb, 90). "eb20.023931.13825@cs.rochester.edu Origins of the finger command (news:1990F)". lt.folklore.computers
alt.folklore.computers (news:a). (Web link) (http://groups. google. com/ groups?selm=1990Feb20.023931. 13825@cs. rochester.edu).
Retrieved 2008-10-21.
External links
• RFC 742 (December 1977)
• RFC 1288 (December 1991)
• Mail from Les Earnest explaining the origin of finger (http:// www.djmnet. org/lore/finger-origin.txt)
• Linux finger command (http:/ / manpages. debian. net/ cgi-bin/man. cgi?query=finger)
• History of the Finger protocol by Rajiv Shah (http:/ / www.rajivshah. com/ Case_Studies/ Finger/Finger. htm)
• Microsoft TechNet Finger article (http:// technet. microsoft.com/ en-us/ library/bb490908. aspx)
First Hop Redundancy Protocols
First Hop Redundancy Protocols
A First Hop Redundancy Protocol (FHRP) is a computer networking protocol which is designed to protect the
default gateway used on a subnetwork by allowing two or more routers to provide backup for that address; in the
event of failure of the/an active router, the backup router will take over the address, usually within a few seconds. In
practice, such protocols can also be used to protect other services operating on a single IP address, not just routers.
Examples of such protocols include (in approximate order of creation):
• Hot Standby Router Protocol (HSRP) - Cisco's initial, proprietary standard
• Virtual Router Redundancy Protocol (VRRP) - an open standard protocol
• Common Address Redundancy Protocol (CARP) - free, (patent) unencumbered alternative to Cisco's HSRP
• Extreme Standby Router Protocol (ESRP) - Extreme Networks' proprietary standard with fast failover and also
layer 2 protection
• Gateway Load Balancing Protocol (GLBP) - a more recent proprietary standard from Cisco that permits load
balancing as well as redundancy
FLIP (Fast-Local-Internet-Protocol)
The Fast-Local-Internet-Protocol is a Suite of Internet Protocols, which provide transparency, security and
network management. (Tanenbaum et al., Vrije Universiteit Amsterdam)
Forward-confirmed reverse DNS
FCrDNS, or forward-confirmed reverse DNS, or full-circle reverse DNS, is a situation where a given IP address
has forward (name-to-address) and reverse (address-to-name) DNS entries that match each other. The process of
checking this is as follows (outlined in RFC 1912, especially section 2.1):
1. First a reverse DNS lookup (PTR query) is performed on the IP address, which returns a list of zero or more PTR
2. For each domain name returned in the PTR query results, a regular 'forward' DNS lookup (type A query) is then
performed on that domain name.
3. Any A or AAAA record returned by the query is then compared against the original IP address, and if there is a
match, then the FCrDNS check passes. Example:
DNS query type PTR on --> returns PTR-record="hostname.example.com" (1 result)
DNS query type A on "hostname.example.com" --> returns A-record= (1 result)
Matches original IP address, therefore check passes
Network verity
A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner
of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is
strong enough that it can be used for whitelisting purposes because spammers and phishers can not usually by-pass
this verification when they use zombie computers to forge the domains. It is considered good practice in general that
all rDNS should be forward confirmed. This is especially true for the IP addresses used by email servers to help
prevent outgoing email from being wrongly rejected as spam.
Forward-confirmed reverse DNS
A FCrDNS verification can also establish that the network owner and the domain owner both have at least a very
basic understanding of the RFCs and can correctly configure things. That is, they have followed the instructions in
RFC 1033 on "Adding a host". There is a statistical correlation between machines that send spam and machines that
fail FCrDNS checks, but correlation does not imply causation and many network owners simply can not configure
the rDNS because their upstream providers either can't or won't delegate the rDNS..
However, zombie computers infected with spambots will not be able to fake the reverse DNS to make it match. The
main reason behind the correlation between spamming machines and failing FCrDNS is that it generally cannot be
faked or overridden by a spambot infested machine, and thus this check is very effective in controlling spam,
underwritten and justified by supporting RFCs.
Common DNS misconfigurations are outlined in RFC 1912, of particular note is section 2.1 that states, under the
heading "Inconsistent, Missing or Bad Data", "Make sure your PTR and A records match." Those ISPs that will not
or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of RFCs being
contravened when communicating with hosts that do follow the RFC guidelines. From a technical perspective
reverse DNS is trivial to implement correctly and there is no reason not to implement it for hosts providing regular
internet services. ISPs that cannot or will not provide reverse DNS ultimately will be limiting the ability of their
client base to use internet services they provide effectively and securely.
• Most e-mail mail transfer agents (server software) use a FCrDNS verification and if there is a valid domain name,
put it into the "Received:" trace header field.
• Some e-mail mail transfer agents will perform FCrDNS verification on the domain name given on the SMTP
HELO and EHLO commands. This can violate RFC 2821 and so e-mail is usually not rejected by default.
• The Sender Policy Framework e-mail anti-forgery system uses a FCrDNS check in its "ptr:" mechanism.
• Some e-mail spam filters will use FCrDNS checks to try to detect forged domain names or for whitelisting
purposes, for example, RFC 5451.
• SpamCop uses the FCrDNS check, which sometimes causes problems for SpamCop users who are also customers
of internet service providers who do not provide properly matching DNS and rDNS records for their mail servers.
[1] [2]
• Some FTP, Telnet and TCP Wrapper servers will perform FCrDNS checks.
• Some IRC Servers perform FCrDNS checks to prevent abuse.
External links
• Considerations for the use of DNS Reverse Mapping
(Internet draft)
• Forward Confirmed RDNS testing tool
• IPv4/IPv6 FCrDNS check tool
[1] http:/ / forum.spamcop. net/ forums/ index. php?act=findpost&pid=36027
[2] http:/ / forum.spamcop. net/ forums/ index. php?act=findpost&pid=41615
[3] http:/ / tools. ietf.org/html/ draft-ietf-dnsop-reverse-mapping-considerations
[4] http:// ipadmin.junkemailfilter.com/ rdns. php
[5] http:// multirbl.valli. org/
GENA stands for General Event Notification Architecture.
GENA Base defines an HTTP notification architecture that transmits notifications between HTTP resources. An
HTTP resource could be any object which might need to send or receive a notification, for example a distribution
list, buddy list, print job, etc. It was defined in Internet-Draft draft-cohen-gena-p-base-01.txt (now expired).
GENA Base Client to Arbiter provides for the ability to send and receive notifications using HTTP over TCP/IP
and administratively scoped unreliable multicast UDP. Provisions are made for the use of intermediary arbiters,
called subscription arbiters, which handle routing notifications to their intended destination. It was defined in http://
tools. ietf.org/html/ draft-cohen-gena-client'' (now expired).
During July 13-14 1998 the University of California Irvine convened WISEN: the Workshop on Internet-Scale Event
Notification. This event brought together a number of experts of various fields and included a presentation on GENA
by Josh Cohen of Microsoft. Delegates showcased their event notification architectures and haggled over
requirements of the same. Josh's final slide includes the bullet points "GENA is being implemented by Microsoft
Products" and "Our wish is to collaborate to agree on a standard. GENA or other, we will comply."
Interest in event notification appears to have waned after 1998 as participants were unable to come to common
definitions of what is required for the definition of notification services and protocols. GENA was briefly considered
for use in the Internet Printing Protocol but found a niche as part of the Universal Plug and Play (UPnP) architecture.
Internet Drafts
• July 9, 1998
Client to Arbiter
• June 24, 1999
• September 6, 2000
External links
[1] http:/ / tools. ietf.org/html/ draft-cohen-gena-p-base
[2] http:// tools. ietf.org/html/ draft-cohen-gena-client
[3] http:// www. upnp. org/download/ draft-cohen-gena-client-01.txt
[4] http:/ / www. isr. uci. edu/ events/ twist/ wisen98/
A 'geo' URI is a URI scheme defined by the Internet Engineering Task Force's RFC 5870 (published 8 June 2010)
a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional coordinate reference system in a compact,
simple, human-readable, and protocol-independent way.
The current revision of the vCard specification
supports 'geo' URIs in a vCard's "GEO" property, and the GeoSMS
standard uses 'geo' URIs for geotagging SMS messages.
A 'geo' URI is not to be confused with the site GeoUrl
(which implements ICBM address).
A simple 'geo' URI might look like:
where the two numerical values represent latitude and longitude respectively,
and are separated by a comma.
If a
third comma-separated value is present, it represents altitude.
The 'geo' URI also allows for an optional
"uncertainty" value, separated by a semicolon, representing the uncertainty of the location in meters, and is described
using the "u" URI parameter.
A 'geo' URI with an uncertainty parameter looks as follows:
A 'geo' URI may, for example, be included on a web page, as HTML:
<a href="geo:37.786971,-122.399677;u=35">Wikimedia Headquarters</a>
so that a 'geo' URI-aware user agent such as a web browser could launch the user's chosen mapping service; or it
could be used in an Atom feed or other XML file.
Coordinate reference systems
The default coordinate reference system (CRS) used is the World Geodetic System 1984 (WGS-84),
for planet
Earth although other CRS, once defined, may be specified, using the "crs" URI parameter,
also separated by a
semicolon. Such CRSs may include both other terrestrial systems and those for non-terrestrial coordinates such as
those on the Moon or Mars.
A 'geo' URI for a hypothetical lunar CRS created in 2011 might be:
The order in which the semicolon-separated parameters occur is not significant,
and 'crs' parameter values are
so the above example is exactly equivalent to:
[1] "RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI)" (http:// tools. ietf.org/ html/ rfc5870). Internet
Engineering Task Force. 2010-06-08. . Retrieved 9 June 2010.
[2] "draft-ietf-vcarddav-vcardrev-11 - vCard Format Specification, section-6.5.2" (http:// tools. ietf.org/ html/
draft-ietf-vcarddav-vcardrev-11#section-6.5. 2). IETF. . Retrieved 10 June 2010.
[3] Geourl.org (http:// geourl. org/)
[4] RFC 5870, section 8.3
External links
• RFC5870 (http:/ / tools.ietf. org/html/ rfc5870)
• Geo URI (http:// geouri. org/)
Genealogy Network Transfer Protocol (GNTP)
Type of format Genealogy peer-to-peer
The Genealogy Network Transfer Protocol (GNTP) is an unfinished protocol for a peer-to-peer genealogy
network that was not completed because of resource constraints. The idea was to allow genealogists to share
GEDCOM files in much the same way that music and other files are distributed on other peer-to-peer networks.
• C. C. Albrecht, D. Dean, R. B. Jackson, S. W. Liddle, and R. D. Meservy. A Peer-To-Peer Network Protocol for
Genealogical Data. In Proceedings of the First Family History Technology Workshop, pages 19–23, Provo, Utah,
April 2001.
• Genealogy Network Transfer Protocol (GNTP Version 1.0)
- E-Business Center - Brigham Young University
(Protocol Version 0.75)Last Updated: February 6, 2002 Conan Albrecht
• A Peer-To-Peer Network Protocol for Genealogical Data
- Conan C. Albrecht, Douglas Dean, Robert B.
Jackson, Stephen W. Liddle, and Raymond D. Meservy (E-Business Center Marriott School of Management)
Brigham Young University
• Enabling the Distributed Family Tree
- by Hilton Campbell
Archived Website on Wayback
• SourceForge.net: Project Info - Genealogy Network Transfer Protocol
- From 2005
• GNTP - The Worldwide Genealogy Network
- From 2002
[1] Genealogy P2P (http:// www.ancestrylibrary.com/ learn/ library/article. aspx?article=7360) - Genealogical Computing 4/1/2002
[2] http:/ / web.archive. org/web/ 20020809135842/ genealogy. byu. edu/ GNTP-Protocol.html
[3] http:/ / www. fht.byu. edu/ prev_workshops/ workshop01/ final/ Albrecht.pdf
[4] http:// www. dftproject.org/blog/ wp-content/ uploads/ 2006/ 11/ thesis-proposal. pdf
[5] http:/ / web.archive. org/web/ 20050507140636/ http:/ / sourceforge.net/ projects/ gntp/
[6] http:/ / web.archive. org/web/ 20020525061244/ http:/ / genealogy.byu.edu/
Gopher (protocol)
Gopher (protocol)
The Gopher protocol English pronunciation: /ˈɡoʊfər/ is a TCP/IP Application layer protocol designed for distributing,
searching, and retrieving documents over the Internet. Strongly oriented towards a menu-document design, the
Gopher protocol was a predecessor of (and later, an alternative to) the World Wide Web.
The protocol offers some features not natively supported by the Web and imposes a much stronger hierarchy on
information stored on it. Its text menu interface is well-suited to computing environments that rely heavily on remote
text-oriented computer terminals, which were still common at the time of its creation in 1991, and the simplicity of
its protocol facilitated a wide variety of client implementations.
Although largely supplanted by the Web in the years following, the Gopher protocol is still in use by enthusiasts, and
a small population of actively-maintained servers remains.
The original Gopher system was released in late spring of 1991 by Mark McCahill, Farhad Anklesaria, Paul Lindner,
Daniel Torrey, and Bob Alberti of the University of Minnesota.
Its central goals were, as stated in RFC 1436:
• A file-like hierarchical arrangement that would be familiar to users
• A simple syntax
• A system that can be created quickly and inexpensively
• Extending the file system metaphor, such as searches
Gopher combines document hierarchies with collections of services, including WAIS, the Archie and Veronica
search engines, and gateways to other information systems such as FTP and Usenet.
The general interest in Campus-Wide Information Systems (CWISs)
in higher education at the time, and the ease
with which a Gopher server could be set up to create an instant CWIS with links to other sites' online directories and
resources were the factors contributing to Gopher's rapid adoption. By 1992, the standard method of locating
someone's e-mail address was to find their organization's CCSO nameserver entry in Gopher, and query the
The name was coined by Anklesaria
as a play off of several meanings of the word "gopher." The University of
Minnesota mascot is the gopher,
a gofer (same sound) is an assistant who "goes for" things, and a gopher burrows
through the ground to reach a desired location.
The World Wide Web was in its infancy in 1991, and Gopher services quickly became established. By the late
1990s, Gopher had largely ceased expanding. Several factors contributed to Gopher's stagnation:
• In February 1993, the University of Minnesota announced that it would charge licensing fees for the use of its
implementation of the Gopher server.
As a consequence of this, some users were concerned that a licensing fee
would also be charged for independent implementations.

In contrast, no such limitation has ever been
imposed on the World Wide Web. The University of Minnesota later re-licensed its Gopher software under the
• Gopher client functionality was quickly duplicated by early Web browsers, such as Mosaic, which subsumed the
protocol as part of their functions.
• Gopher has a more rigid structure compared to the free-form HTML of the Web. With Gopher, every document
has a defined format and type, and the typical user navigates through a single server-defined menu system to get
to a particular document. This can be quite different from the way a typical user might traverse documents on the
Gopher (protocol)
Availability of Gopher today
Gopher remains in active use by its enthusiasts, and there have been attempts to revive the use of Gopher on modern
platforms and mobile devices. One such attempt is The Overbite Project
, which hosts various browser extensions
and modern clients.
As of 2010, there are approximately 150 gopher servers indexed by Veronica-2,
reflecting a slow growth from
2007 when there were fewer than 100,
although many are infrequently updated. A handful of new servers are set
up every year by hobbyists — over 50 have been set up and added to Floodgap's list since 1999.
A snapshot of
Gopherspace as it was in 2007 was circulated on BitTorrent and is still available.
Due to the simplicity of the
Gopher protocol, setting up new servers or adding Gopher support to browsers is often done in a tongue in cheek
way, principally on April Fools' Day.

Native Gopher support
Mozilla Firefox 3.7 displaying the top-level menu of the Floodgap
gopher server
Browser Currently
Internet Explorer No
1 6.0 RTM
IE 6 requires registry patch to re-enable.
Always uses port
Internet Explorer
for Mac
5.2.3 PowerPC-only
Mozilla Firefox Addon
0 3.6
Always uses port 70. Built-in support dropped from Firefox 4.0
can be added back with OverbiteFF
SeaMonkey Yes
1.0 current
Always uses port 70. Compatible with OverbiteFF
. Built-in
support dropped from SeaMonkey 2.1 onwards.
Camino Yes 1.0 current Always uses port 70.
Classilla Yes
9.0 current Hardcoded to port 70 from 9.0-9.2; whitelisted ports from
OmniWeb Yes
5.9.2 (April
First WebKit Browser to support Gopher

Epiphany No 2.26.3 Disabled after switch to WebKit
Gopher (protocol)
Galeon Yes current
Konqueror Plugin
K-Meleon Yes current
Lynx Yes current Complete support
Build option
Safari No never
Opera No never Opera 9.0 includes a proxy capability
Google Chrome No
An extension to automatically forward to Gopher proxies
Line Mode
1.1 (January
libwww Yes
1.0c (December
current libwww is an API for internet applications
Pavuk Yes ? current Pavuk is a web mirror (recursive download) software
lftp Yes ? current lftp is a command-line file transfer program
cURL Yes
7.21.2 (October
current cURL is a command-line file transfer utility
NetSurf No Under development, based on the cURL fetcher.
Browsers that do not natively support Gopher can still access servers using one of the available Gopher to HTTP
Gopher support was disabled in Internet Explorer versions 5 and 6 for Windows in June 2002 by a patch meant to fix
a security vulnerability in the browser's Gopher protocol handler; however, it can be re-enabled by editing the
Windows registry. In Internet Explorer 7, Gopher support was removed on the WinINET level.
Gopher browser plugins
For Mozilla Firefox and SeaMonkey, OverbiteFF
extends Gopher browsing and supports Firefox 4. It includes
support for accessing Gopher servers not on port 70 using a whitelist and for CSO/ph queries, and allows versions of
Firefox and SeaMonkey that do not support Gopher natively to access Gopher servers. Plugins are also available for
and a proxy-based extension for Google Chrome.
Gopher clients for mobile devices
Some have suggested that the bandwidth-sparing simple interface of Gopher would be a good match for mobile
phones and Personal digital assistants (PDAs),
but so far, mobile adaptations of HTML and XML and other
simplified content have proven more popular. The PyGopherd server provides a built-in WML front-end to Gopher
sites served with it. An application for Android 1.5+
is in development and was released in alpha stage.
A Java
ME client is also available for compatible devices.
Other Gopher clients
Gopher was at its height of popularity during a time when there were still many equally competing computer
architectures and operating systems. As such, there are several Gopher clients available for Acorn RISC OS,
AmigaOS, Atari MiNT, CMS, DOS, classic Mac OS, MVS, NeXT, OS/2 Warp, most UNIX-like operating systems,
VMS, Windows 3.x, and Windows 9x. GopherVR was a client designed for 3D visualization, and there is even a
Gopher client MOO object. The majority of these clients are hard coded to work on TCP port 70.
Gopher (protocol)
Gopher to HTTP gateways
Users of Web browsers that have incomplete or no support for Gopher can access content on Gopher servers via a
server gateway or proxy server that converts Gopher menus into HTML; known proxies are the Floodgap Public
proxy, Gopher Proxy
, and the WikkaGopher
proxy. Similarly, certain server packages such as
GN and PyGopherd have built-in Gopher to HTTP interfaces. Squid Proxy
software gateways any gopher:// URL
to HTTP content, enabling any browser or web agent to access gopher content easily.
Gopher characteristics
As part of its design goals, Gopher functions and appears much like a mountable read-only global network file
system (and software, such as gopherfs, is available that can actually mount a Gopher server as a FUSE resource). At
a minimum, whatever a person can do with data files on a CD-ROM, they can do on Gopher.
A Gopher system consists of a series of hierarchical hyperlinkable menus. The choice of menu items and titles is
controlled by the administrator of the server.
The top level menu of a Gopher server. Selecting the "Fun and
Games" menu item...
... takes the user to the "Fun and Games" menu.
Similar to a file on a Web server, a file on a Gopher
server can be linked to as a menu item from any other
Gopher server. Many servers take advantage of this
inter-server linking to provide a directory of other
servers that the user can access.
Technical details
The Gopher protocol was first described in RFC 1436.
IANA has assigned TCP port 70 to the Gopher
The protocol is simple to negotiate, making it possible
to browse without using a client. A standard gopher
session may therefore appear as follows:
1CIA World Factbook /Archives/mirrors/textfiles.com/politics/CIA gopher.quux.org 70
0Jargon 4.2.0 /Reference/Jargon 4.2.0 gopher.quux.org 70 +
1Online Libraries /Reference/Online Libraries gopher.quux.org 70 +
1RFCs: Internet Standards /Computers/Standards and Specs/RFC gopher.quux.org 70
1U.S. Gazetteer /Reference/U.S. Gazetteer gopher.quux.org 70 +
Gopher (protocol)
iThis file contains information on United States fake (NULL) 0
icities, counties, and geographical areas. It has fake (NULL) 0
ilatitude/longitude, population, land and water area, fake (NULL) 0
iand ZIP codes. fake (NULL) 0
i fake (NULL) 0
iTo search for a city, enter the city's name. To search fake (NULL) 0
ifor a county, use the name plus County -- for instance, fake (NULL) 0
iDallas County. fake (NULL) 0
Here, the client has established a TCP connection with the server on port 70, the standard gopher port. The client
then sends a string followed by a carriage return followed by a line feed (a "CR + LF" sequence). This is the
selector, which identifies the document to be retrieved. If the item selector were an empty line, the default directory
would be selected. The server then replies with the requested item and closes the connection. According to the
protocol, before the connection is closed, the server should send a full-stop (i.e., a period character) on a line by
itself. However, as is the case here, not all servers conform to this part of the protocol and the server may close the
connection without returning the final full-stop.
In this example, the item sent back is a gopher menu, a directory consisting of a sequence of lines each of which
describes an item that can be retrieved. Most clients will display these as hypertext links, and so allow the user to
navigate through gopherspace by following the links.
All lines in a gopher menu are terminated by "CR + LF", and consist of five fields: the item type as the very first
character (see below), the display string (i.e., the description text to display), a selector (i.e., a file-system
pathname), host name (i.e., the domain name of the server on which the item resides), and port (i.e., the port
number used by that server). The item type and display string are joined without a space; the other fields are
separated by the tab character.
Because of the simplicity of the Gopher protocol, tools such as netcat make it possible to download Gopher content
easily from the command line:
echo jacks/jack.exe | nc gopher.example.org 70 > jack.exe
The protocol is also supported by cURL as of 7.21.2-DEV.
Gopher item types
Item types are described in gopher menus by a single number or (case specific) letter and act as hints to the client to
tell it how to handle a specific media type in a menu, analogous to a MIME type. Every client necessarily must
understand itemtypes 0 and 1. All known clients understand item types 0 through 9, g, and s, and all but the very
oldest also understand file-types h and i.
• 0 = plain text file
• 1 = directory menu listing
• 2 = CSO search query
• 3 = error message
• 4 = BinHex encoded text file
• 5 = binary archive file
• 6 = UUEncoded text file
• 7 = search engine query
• 8 = telnet session pointer
• 9 = binary file
• g = GIF image
• h = HTML file
Gopher (protocol)
• i = informational message
• I = Image file of unspecified format. Client decides how to display. Often used for JPEG images.
• s = Audio file format, primarily a WAV file
• T = tn3270 session pointer
A list of additional file-type definitions has continued to evolve over time, with some clients supporting them and
others not. As such, many servers assign the generic 9 to every binary file, hoping that the client's computer will be
able to correctly process the file.
URL links
Historically, to create a link to a Web server, "GET /" was used as a pseudo-selector to simulate an HTTP client
request. John Goerzen created an addition
to the Gopher protocol, commonly referred to as "URL links", that
allows links to any protocol that supports URLs. For example, to create a link to http:/ / gopher. quux. org/, the item
type is "h", the display string is the title of the link, the item selector is "URL:http://gopher.quux.org/", and the
domain and port are that of the originating Gopher server (so that clients that do not support URL links will query
the server and receive an HTML redirection page).
Related technology
The master Gopherspace search engine is Veronica. Veronica offers a keyword search of all the public Internet
Gopher server menu titles. A Veronica search produces a menu of Gopher items, each of which is a direct pointer to
a Gopher data source. Individual Gopher servers may also use localized search engines specific to their content such
as Jughead and Jugtail.
GopherVR is a 3D virtual reality variant of the original Gopher system.
Gopher server software
Because the protocol is trivial to implement in a basic fashion, there are many server packages still available, and
some are still maintained.
• Aftershock
— written in Java.
• Bucktooth — modern gopher server written in Perl.
• [gopher://gopher.r-36.net/1/geomyidae.gph Geomyidae] — written in C. Public domain
• GN
• GoFish
• [gopher://gophernicus.org/1/software/gophernicus/server/ Gophernicus] — Linux, BSD License.
• gophrier
- An open source gopher server written in C
• [gopher://zzo38computer.cjb.net/1gophserv GOPHSERV] — cross-platform, GPLv3, FreeBASIC.
• [gopher://gopher.pcrpg.org Gopher Cannon] — Windows (Win32/Win64), freeware, written in .NET 3.5
• [gopher://gopher.sacrideo.us/1goscher Goscher] — written in Scheme.
• [gopher://gopher.viste-family.net/1/grumpy Grumpy] — Linux, GPLv3, written in FreeBASIC.
• [gopher://port70.net/1mgod mgod]
• PyGopherd — modern gopher+ server written in Python.
• PyGS
• [gopher://gopher.viste-family.net/1/projects/motsognir/ Motsognir open-source gopher server]
Gopher (protocol)
[1] December, John; Randall, Neil (1994). The World Wide Web unleashed. Sams Publishing. p. 20. ISBN 1575210401.
[2] Google Groups archive of bit.listserv.cwis-l discussion (http:/ / groups. google. com/ group/bit.listserv. cwis-l/ browse_frm/thread/
11db689fbe802834/bc8a60ab89926a4b?lnk=st& q=cwis+ gopher&rnum=482&hl=en#bc8a60ab89926a4b)
[3] Google Groups archive of comp.infosystems.gopher discussion (http:// groups. google. com/ group/comp. infosystems. gopher/ browse_frm/
thread/eef4cfbdbc862afe/9cbc3e3690b8fb4e?lnk=st&q="cso+ nameserver"& rnum=19&hl=en#9cbc3e3690b8fb4e)
[4] Mark McCahill, Farhad Anklesaria (in English) (Flash). "Smart Solutions: Internet Gopher" (http:// mediamill. cla. umn.edu/ mediamill/
display/ 69597). Minneapolis: University of Minnesota Media Mill. Event occurs at 2:40. . McCahill credits Anklesaria with naming Gopher
[5] "Gophersports.com - Official Web Site of University of Minnesota Athletics" (http:// www.gophersports.com/ ). . Retrieved August 17,
[6] http:// www. funet.fi/ pub/ vms/ networking/ gopher/gopher-software-licensing-policy.ancient
[7] Google Groups (http:// groups. google. com/ groups?selm=1mj6cb$6gm@pith. uoregon.edu)
[8] http:/ / groups. google. com/ groups?selm=36e4c2f1. 10244576@nntp. best. ix.netcom.com
[9] gopher://www.michaeleshun.4t.com
[10] http:/ / gopher.floodgap. com/ overbite/
[11] gopher://gopher.floodgap.com/0/v2/vstat
[12] Kaiser, Cameron (2007-03-19). "Down the Gopher Hole" (http:// db. tidbits. com/ article/8909). TidBITS. . Retrieved 2007-03-23.
[13] gopher://gopher.floodgap.com/1/new
[14] A freely downloadable BitTorrent file containing an archive of all available Gopherspace content as of 2007 and an interview with the
creators of Gopher. (http:// changelog. complete. org/archives/ 1466-download-a-piece-of-internet-history)
[15] http:// www. omnigroup.com/ applications/ omniweb/ releasenotes/
[16] gopher://gopher.floodgap.com/1/new "Service note for 1 April 2009—This isn't a joke server, guys, we've been running for 10 years!"
[17] "Microsoft Security Bulletin MS02-047" (http:/ / www.microsoft.com/ technet/security/ bulletin/MS02-047. mspx). Microsoft.
2003-02-28. . Retrieved 2007-03-23.
[18] "Bug 388195 - Remove gopher protocol support for Firefox" (https:// bugzilla. mozilla.org/show_bug. cgi?id=388195). . Retrieved
[19] https:// addons. mozilla. org/ en-US/firefox/addon/ overbiteff/
[20] "FOR IMMEDIATE RELEASE: OmniWeb 5.9.2 now includes Gopher support!" (http:// blog.omnigroup. com/ 2009/ 04/ 01/
for-immediate-release-omniweb-592-now-includes-gopher-support/ ). OmniGroup. 2009-04-01. . Retrieved 2009-04-03.
[21] "A comprehensive list of changes for each version of OmniWeb" (http:// www.omnigroup.com/ applications/ omniweb/ releasenotes/ ).
OmniGroup. 2009-04-01. . Retrieved 2009-04-03.
[22] http:/ / kgopher.berlios. de/
[23] Fonseca, Jonas (24 December 2004). "elinks-users ANNOUNCE ELinks-0.10.0 (Thelma)" (http:// linuxfromscratch.org/pipermail/
elinks-users/ 2004-December/000785. html). Linux from scratch. . Retrieved 22 May 2010.
[24] "Release Notes for Internet Explorer 7" (http:/ / msdn2. microsoft.com/ en-us/ ie/ aa740486.aspx). Microsoft. 2006. . Retrieved
[25] "kio_gopher - Gopher kioslave" (http:/ / kgopher.berlios. de/ ). . Retrieved 21 August 2010.
[26] "The Overbite Project" (http:// gopher. floodgap.com/ overbite/ ). Floodgap. . Retrieved 25 July 2010.
[27] Wired News: Gopher: Underground Technology (http:// www.wired.com/ news/ technology/ 0,1282,62988,00. html)
[28] Paul, Ryan (6 July 2010). "Overbite Project brings Gopher protocol to Android" (http:/ / arstechnica.com/ open-source/ news/ 2010/ 07/
overbite-project-brings-gopher-protocol-to-android. ars?utm_source=rss& utm_medium=rss& utm_campaign=rss). Ars Technica. . Retrieved
25 July 2010.
[29] "Software/PocketGopher" (http:/ / felix. plesoianu. ro/ index.php/ page:Software:PocketGopher). . Retrieved 21 August 2010.
[30] http:/ / gopher.floodgap. com/ gopher/
[31] http:// gopherproxy.org
[32] http:/ / www. pongonova. org/gopherwiki
[33] http:// www. squid-cache. org
[34] "Curl: Re: Gopher patches for cURL (includes test suite)" (http:/ /curl. haxx. se/ mail/ lib-2010-08/0339. html). . Retrieved 25 August
[35] http:/ / gopher.quux. org/ Archives/ Mailing%20Lists/ gopher/ gopher.2002-02|/MBOX-MESSAGE/ 34
[36] http:/ / aftershock.sourceforge.net/
[37] http:/ / freshmeat.net/ projects/ gn/
[38] http:// gofish. sourceforge.net/
[39] http:/ / gophrier.tuxfamily.org/
[40] http:/ / gurno.com/ dru/ ?q=node/153
Gopher (protocol)
External links
• List of all public Gopher servers (http:// gopher.floodgap.com/ gopher/ gw?a=gopher:// gopher. floodgap.com/
1/ world) (proxied link)
• [gopher://gopher.docfile.org/1/world/monitoring/uptime List of public Gopher server uptimes] (gopher link)
(HTTP link) (http:// gopher.docfile. org/world/monitoring/uptime)
• An announcement of Gopher on the Usenet Oct 8 1991 (http:/ / groups. google.com/ group/comp. sys. mac.
announce/ msg/ 24ad9de8dcfd6e4b)
• Why is Gopher Still Relevant? (http:// gopher.floodgap. com/ overbite/relevance.html) A position statement on
Gopher's survival.
• An article published by the technology discussion site "Ars Technica", about the Gopher community of
enthusiasts nowadays (http:/ / arstechnica. com/ tech-policy/ news/ 2009/ 11/
• Sites inspired by gopher: Spencer Hunter's Homepage — Example of a Gopher emulation in HTML, online since
1995. Under the "About this gopher and myself" directory is the author's own Gopher manifesto, "Why gopher is
superior to the Web." (http:/ / www. u. arizona.edu/ ~shunter); A community server for the Collier County, FL
(Naples, FL) area whose fast web interface is inspired by Gopher. It is also an example of a Gopher emulation in
HTML (http:/ / retro.naplesplus. us)
• IANA Port Number allocations (http:// www. iana. org/assignments/ port-numbers)
• RFC 1436 — The Internet Gopher Protocol (a distributed document search and retrieval protocol)
• RFC 1580 — Guide to Network Resource Tools
• RFC 1689 — Networked Information Retrieval: Tools and Groups
• RFC 1738 — Uniform Resource Locators (URL)
• RFC 1808 — Relative Uniform Resource Locators
• RFC 2396 — Uniform Resource Identifiers (URI): Generic Syntax
• RFC 4266 — The gopher URI Scheme
GPRP,or Global Position Routing Protocol is an Internet Routing Protocol like IPv4 and IPv6, which uses the
spatial position, as determined by GPS, of each host on the network to establish routes to any other host. It is
intended to supplement, and ultimately replace traditional Internet Routing protocols. It requires the cooperation of
many luminal-speed (such as radio or fiber optic) hosts to route packets in the most efficient way: a straight line.
The protocol consists of mainly the same concepts as IPv4, removing the abstraction layer of the routing table and IP
address with a simpler model that attempts to send packets in as close to a straight line as possible. Since this change
introduces physical constraints on the geometry of the network, special techniques are implemented to overcome
problems such as dead zones.
The project began as a submission to a 2008 Google contest by Ted Coffman, with the goals of democracizing the
Internet and doing away with the need for ISPs, which are vulnerable to regulation by world governments. When no
interest was generated, the idea was submitted to the Reddit.com
Internet community. With very little feedback on
Reddit, nothing was done with the concept for over two years. In January 2011 Coffman decided to move forward
with development due to the recent surge in open platform smart phones that have both Wi-Fi and GPS built right in,
which Coffman sees as a perfect medium for a widespread implementation of GPRP.
As of January 2011, a GPRP C++ class is being developed and tested by Ted Coffman.
Comparison to IPv4
To maintain backward-compatibility with the current Internet framework, IPv4 gateways are discovered using
similar techniques to DNS lookups.
Many of the traditional IPv4 concepts can be considered as their physical forms in GPRP:
• IP Address - Now the spatial coordinates of the host (as determined by GPS). If the host is stationary, the
coordinates can be programmed in, akin to a static IP address.
• Subnet Mask - Now a sphere around the host, the size of which is determined by the most distant host that can be
reached directly.
• Default Gateway - This concept is dropped completely, replaced with case-by-case routing using hosts that are as
close to a straight line toward the destination as available.
• DHCP - This concept is dropped.
• Other traditional IPv4 methods not mentioned do not change.
[1] http:/ / www. reddit.com/ r/ technology/ comments/ 900yq/ using_gps_to_mesh_route_the_planet/
GroupDAV is a computer protocol used to connect Open Source groupware clients with Open Source groupware
servers. It is a lightweight protocol whose primary design goal is to be as simple as possible to implement, focusing
more on real world issues with open source applications than on an extremely extensive command set. It is based on
a subset of WebDAV.
Client side GroupDAV implementations exist for KDE Kontact, Novell Evolution, Thunderbird and Outlook, work
on the Mozilla Calendar Project is in progress. Servers include OpenGroupware.org, SOGo, the Citadel system and
eGroupWare. In addition every WebDAV (and therefore CalDAV/CardDAV) server is implicitly a GroupDAV v2
GroupDAV's relationship to CalDAV varies from developer to developer. Some of the earliest implementors
intended it as a protocol complementary to the CalDAV effort, because CalDAV provides more extensive operations
on calendar folders. Others have positioned GroupDAV as the leading protocol, citing CalDAV's excessive
complexity as a source of interoperability bugs. This dichotomy is likely to become irrelevant in the future, however,
as it is straightforward for a server to simultaneously support both protocols.
External links
• http:/ / www. groupdav.org/
Handle System
The Handle System is a technology specification for assigning, managing, and resolving persistent identifiers for
digital objects and other resources on the Internet. The protocols specified enable a distributed computer system to
store identifiers (names, or handles), of digital resources and resolve those handles into the information necessary to
locate, access, and otherwise make use of the resources. That information can be changed as needed to reflect the
current state and/or location of the identified resource without changing the handle.
The Handle System was developed by Bob Kahn, co-inventor of the TCP/IP protocols that underlie the operation of
the Internet
, with support from the Defense Advanced Research Projects Agency DARPA at the Corporation for
National Research Initiatives (CNRI)
, which continues to develop and manage it. The Handle System is currently
in use in several applications
The Handle System enables management of objects as first class entities, rather than as packets of bits with
dependency on other attributes such as locations. It emerged as part of a wider Framework for Distributed Digital
Object Services
but has been used in independent applications. The system is designed to be scalable
to very
large numbers of entities without performance degradation, to allow distributed administration, and to enable
resolution to multiple pieces of current data (each of which may be separately managed). It also has further optional
features such as public key infrastructure capability to enable trust applications.
Resolution is the process in which an identifier is the input request to a network service to receive in return a specific
output of one or more pieces of current information (state data) related to the identified entity: e.g., a location (URL).
The Domain Name System resolves domain names meaningful to humans into numerical IP addresses (locations of
file servers). The Handle System is compatible with DNS but does not necessarily require it, unlike persistent
identifiers such as PURLs or ARKs which utilise domain names and are therefore ultimately constrained by them.
Other significant differences include the administrative Granularity possible with the Handle System (administrators
can be different for each handle, and there can also be more than one per handle) and the option for extensible
multiple data types to be assigned
Handle System
DNS has well-recognised problems of security and updating which suggest that it will not be sufficient to assume
that existing DNS technology can simply be adapted to deal with new requirements. By explicitly separating names
from all associated data, including location, the Handle System addresses a key requirement of future internet
architecture: "it is possible to separate the ideas of location and identity, both of which are represented by the IP
address in today's Internet, ... the resulting architecture facilitates mobility as well as solving other problems with
today's network".
The Handle System is defined in informational RFCs 3650
, 3651
and 3652
of the Internet Engineering
Task Force (IETF); it includes an open set of protocols, a namespace, and a reference implementation of the
protocols. Handles resolve to typed data. Documentation, software, and related information is provided by CNRI on
a dedicated web site
. Each handle may have its own administrator(s) and administration of these handles can be
done in a distributed environment. The name-to-value bindings may also be secured, both via signatures to verify the
data and via challenge response to verify the transmission of the data, allowing handles to be used in trust
management applications. The syntax of the handle encompasses any Unicode character and leaves the string
construction to the assigner (thereby allowing inclusion of existing identifier strings if desired).
Implementation of the Handle System consists of Local Handle Services, each of which is made up of one or more
sites that provide the servers that store specific handles. The Global Handle Registry¨ is a unique Local Handle
Service which stores information on the prefixes (also known as naming authorities) within the Handle System and
can be queried to find out where specific handles are stored on other Local Handle Services within this distributed
Handles can be used natively, or expressed as Uniform Resource Names (URNs) or Uniform Resource Identifiers
(URIs). Although the Handle System is not currently a registered stand-alone implementation of URI or URN, it is a
part of the info URI
specification, RFC 4452
. Handles may also be expressed as Uniform Resource Locators
(URLS), by the use of a http proxy server
The Handle System web site provides a series of implementation tools, notably the HANDLE.NET Software
HANDLE.NET Client Libraries
. Handle clients can be embedded in end user software (e.g., a web browser) or
in server software (e.g., a web server) and extensions are already available for Adobe Acrobat
and Firefox
Handle client software libraries are available in both C and Java. Some applications have developed specific add-on
tools, e.g., for the DOI System
The interoperable network of distributed handle resolver servers (also known as the Proxy Server System) are linked
through a Global Resolver (which is one logical entity though physically decentralised and mirrored). Users of
Handle System technology obtain a handle prefix created in the Global Handle Registry¨
. The Global Handle
Registry maintains and resolves the prefixes of locally-maintained handle services. Any local handle service can,
therefore, resolve any handle through the Global Resolver.
Handles (identifiers) are passed by a client, as a query of the naming authority/prefix, to the Handle System's Global
Handle Registry (GHR). The GHR responds by sending the client the location information for the relevant Local
Handle Service (which may consist of multiple servers in multiple sites); a query is then sent to the relevant server
within the Local Handle Service. The Local Handle Service returns the information needed to acquire the resource,
e.g., a URL which can then be turned into an HTTP re-direct. (Note: if the client already has information on the
appropriate LHS to query, the initial query to GHR is omitted)
Though the original model from which the Handle System derives dealt with management of digital objects, the
Handle System does not mandate any particular model of relationships between the identified entities, nor is it
Handle System
limited to identifying only digital objects: non-digital entities may be represented as a corresponding digital object
for the purposes of digital object management. Some care is needed in the definition of such objects and how they
relate to non-digital entities; there are established models that can aid in such definitions (e.g., Functional
Requirements for Bibliographic Records (FRBR), CIDOC CRM, and indecs content model. Some applications have
found it helpful to marry such a framework to the handle application: for example, the Advanced Distributed
Learning (ADL) Initiative
brings together Handle System application with existing standards for distributed
learning content, using a Shareable Content Object Reference Model (SCORM)
, and the Digital Object Identifier
(DOI) system implementation of the Handle System has adopted it together with the indecs framework to deal with
semantic interoperability.
The Handle System also makes explicit the importance of organizational commitment to a persistent identifier
scheme, but does not mandate one model for ensuring such commitment. Individual applications may choose to
establish their own sets of rules and social infrastructure to ensure persistence (e.g., when used in the DSpace
application, and the DOI application
Design principles
The Handle system is designed to meet the following requirements to contribute to persistence

The identifier string:
• is not based on any changeable attributes of the entity (location, ownership, or any other attribute that may change
without changing the referent’s identity);
• is opaque (preferably a ‘dumb number’: a well known pattern invites assumptions that may be misleading, and
meaningful semantics may not translate across languages and may cause trademark conflicts);
• is unique within the system (to avoid collisions and referential uncertainty);
• has optional, but nice to have, features that should be supported (human-readable,cut-and-paste-able, embeddable;
fits common systems, e.g., URI specification).
The identifier resolution mechanism:
• is reliable (using redundancy, no single points of failure, and fast enough to not appear broken);
• is scalable (higher loads simply managed with more computers);
• is flexible (can adapt to changing computing environments; useful to new applications):
• is trusted (both resolution and administration have technical trust methods; an operating organization is
committed to the long term);
• builds on open architecture (encouraging the leverage efforts of a community in building applications on the
• is transparent (users need not know the infrastructure details).
Among the objects that are currently identified by handles are journal articles, technical reports, books, theses and
dissertations, government documents, metadata, distributed learning content, and data sets. Handles are being used in
digital watermarking applications, GRID applications, repositories, and more. Although individual users may
download and use the HANDLE.NET software independently, many users have found it beneficial to collaborate in
developing applications in a federation, using common policy or additional technology to provide shared services.
As one of the first persistent identifier schemes, the Handle System has been widely adopted by public and private
institutions and proven over several years. (See Paradigm, Persistent identifiers
Handle System applications may use handles as simple persistent identifiers (as most commonly used, to resolve to
the current URL of an object), or may choose to take advantage of other features. Its support for the simultaneous
return as output of multiple pieces of current information related to the object, in defined data structures, enables
Handle System
priorities to be established for the order in which the multiple resolutions will be used. Handles can, therefore,
resolve to different digital versions of the same content, to mirror sites, or to different business models (pay vs. free,
secure vs. open, public vs. private). They can also resolve to different digital versions of differing content, such as a
mix of objects required for a distance-learning course.
There are over 1,000 handle services running today, located in 51 countries, on 6 continents; over 750 of them run at
universities and libraries. Handle services are being run by user federations, national laboratories, universities,
computing centers, libraries (national and local), government agencies, contractors, corporations, and research
groups. Major publishers use the Handle System for persistent identification of commercially traded and Open
Access content through its implementation with the Digital Object Identifier (DOI) system.
The number of prefixes, which allow users to assign handles, is growing and passed 212,000 in 2009. There are four
top-level Global Handle Registry servers that receive (on average) 68 million resolution requests per month. Proxy
servers known to CNRI, passing requests to the system on the Web, receive (on average) 50 million resolution
requests per month. (Statistics from Handle Quick Facts
CNRI and ITU (International Telecommunication Union) recently entered into an agreement to collaborate on use of
the Handle System (and the Digital Object Architecture more generally) and are working on the specific details of
that collaboration; in April 2009 ITU listed the Handle System as an "emerging trend"
Licences and use policy
Handle System, HANDLE.NET and Global Handle Registry are trademarks of the Corporation for National
Research Initiatives (CNRI), a non-profit research and development corporation in the USA. The Handle System is
the subject of patents by CNRI, which licenses its Handle System technology through a public license
, similar to
an open source license, in order to enable broader use of the technology. Handle System infrastructure is supported
by prefix registration and service fees, with the majority coming from single prefix holders. The largest current
single contributor is the International DOI Foundation. The Public License allows commercial and non-commercial
use at low cost of both its patented technology and the reference implementation of the software, and allows the
software to be freely embedded in other systems and products. A Service Agreement
is also available for users
who intend to provide identifier and/or resolution services using the Handle System technology under the Handle
System public license.
Related technologies
The Handle System is the first piece of a long-term digital object architecture. In January 2010 CNRI released its
general-purpose Digital Object Repository software
, which comprises the second major component of this
architecture. More information
about the release, including protocol specification, source code and ready-to-use
system, clients and utilities, is available
. The third and final piece, the Digital Object Registry, will be released
The continued use and evolution of the Handle System is in no way dependent on these other components, but those
already using Handles may find them useful in small or large ways and both are, or soon will be, freely available
under an open source style license.
Handle System
[1] http:/ / www. cnri.reston. va. us/ what_is_internet. html
[2] http:/ / www. cnri.reston. va. us
[3] http:// www. handle. net/ apps. html
[4] http:/ / www. cnri.reston. va. us/ k-w. html
[5] http:/ / www. handle. net/ scalability. html
[6] http:/ / www. handle. net/ overviews/ types. html
[7] Clark, D., Sollin, K. et al., (2003) New Arch: Future Generation Internet Architecture. Rome, NY: DoD (http:/ / www.isi.edu/ newarch/
[8] http:/ / www. rfc-editor.org/rfc/rfc3650.txt
[9] http:/ / www. rfc-editor.org/rfc/rfc3651.txt
[10] http:/ / www. rfc-editor.org/rfc/rfc3652.txt
[11] http:/ / www. handle. net
[12] http:/ / info-uri.info/ registry/docs/ misc/ faq.html
[13] http:/ / www. rfc-editor.org/rfc/rfc4452.txt
[14] http:/ / www. handle. net/ proxy.html
[15] http:// www. handle. net/ download. html
[16] http:/ / www. handle. net/ client_download. html
[17] http:// www. handle. net/ hs-tools/ adobe/
[18] http:/ / www. handle. net/ hstools/ extensions/ firefox_hdlclient.html
[19] http:// www. doi. org/tools. html
[20] http:/ / www. handle. net/ introduction.html
[21] http:// www. adlnet. gov/
[22] http:/ / www. adlnet. gov/ scorm/ index. aspx
[23] http:/ / www. doi. org
[24] Handle System Fundamentals, www.handle.net (http:/ / www.handle.net/ documentation. html)
[25] "Identifier Systems in Network Architecture", Laurence Lannom, CNRI. Video of presentation (or presentation PDF only) from the Digital
Motion Picture Metadata Symposium, Science & Technology Council, Academy of Motion Picture Arts & Sciences, 11 June 2009 (http:/ /
www.oscars. org/science-technology/ council/ projects/ metadata-symposium/ webcasts. html)
[26] http:// www. paradigm.ac. uk/ workbook/metadata/ pids-handle. html
[27] http:// www. handle. net/ factsheet. html
[28] http:/ / www. itu. int/ osg/ csd/ emerging_trends/handle_system/ index.html
[29] http:/ / www. handle. net/ HSj/ hdlnet-2-LICENSE.pdf
[30] http:/ / www. handle. net/ service_agreement.html
[31] http:// www. dorepository.org
[32] http:/ / www. dlib. org/dlib/ january10/ reilly/01reilly.html
[33] http:// www. dorepository.org/ documentation. html
External links
• Handle System (http:/ / www. handle. net)
• persistent identifiers (http:// www. paradigm. ac. uk/ workbook/metadata/ pids. html)
High Frequency Internet Protocol
High Frequency Internet Protocol
High Frequency Internet Protocol acronyms: HFIP or HF-IP. Usually associated with Automatic Link
Establishment and HF radio data communications. HFIP provides protocol layers enabling internet file transfer, chat,
web, or email. HFIP commonly uses ionosphere propagation of radio waves to form a wide area network that can
span thousands of kilometers. HF transceivers in HFIP service typically run 20 to 150 Watts for portable or mobile
units, up to approximately 2000 Watts transmitter output for high power base stations with HFIP servers.
STANAG 5066 is a common HFIP standard.
An amateur radio HFIP network called HFLINK
uses Automatic Link Establishment for initiating data
communications, with ARQ 8FSK frequency shift keying and PSK phase shift keying signals.
[1] "HFLINK" (http:// hflink.com). . Retrieved 21-Sep-2010.
The hop count is a measure of distance across an IP-based network. It is a count of the number of routers an IP
packet has to pass through in order to reach its destination.
Hopcount is usually not used by itself, since any in between router or cable may have or be subject to varying data
throughput (bandwidth), load (see: quality of service), reliability (especially of cable), and latency.
Hopcounts are often useful to find faults in a network (see: Time to live), or to discover if routing is indeed correct.
Some common tools that can measure hopcount are:
• ping
• traceroute (tracert on windows)
Host Identity Protocol
Host Identity Protocol
The Host Identity Protocol (HIP) is a host identification technology for use on Internet Protocol (IP) networks, such
as the Internet. The Internet has two main name spaces, IP addresses and the Domain Name System. HIP separates
the end-point identifier and locator roles of IP addresses. It introduces a Host Identity (HI) name space, based on a
public key security infrastructure.
The Host Identity Protocol provides secure methods for IP multihoming and mobile computing.
In networks that implement the Host Identity Protocol, all occurrences of IP addresses in applications are eliminated
and replaced with cryptographic host identifiers. The cryptographic keys are typically, but not necessarily,
The effect of eliminating IP addresses in application and transport layers is a decoupling of the transport layer from
the internetworking layer (Internet Layer) in TCP/IP.
HIP was specified in the IETF HIP working group. An Internet Research Task Force (IRTF) HIP research group
looks at the broader impacts of HIP.
The working group is chartered to produce Requests for Comments on the "Experimental" track, but it is understood
that their quality and security properties should match the standards track requirements. The main purpose for
producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms
may have on applications and on the Internet in the large.
RFC references
• RFC 4423 - Host Identity Protocol (HIP) Architecture (early "informational" snapshot)
• RFC 5201 - Host Identity Protocol base
• RFC 5202 - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol
• RFC 5203 - Host Identity Protocol (HIP) Registration Extension
• RFC 5204 - Host Identity Protocol (HIP) Rendezvous Extension
• RFC 5205 - Host Identity Protocol (HIP) Domain Name System (DNS) Extension
• RFC 5206 - End-Host Mobility and Multihoming with the Host Identity Protocol
• RFC 5207 - NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication
[1] RFC 4423, Host Identity Protocol (HIP) Architecture, Section 4.1
External links
• IETF HIP working group (http:// www. ietf.org/html. charters/hip-charter.html)
• IRTF HIP research group (http:/ / www. irtf.org/charter?gtype=rg&group=hiprg)
• OpenHIP Wiki (http:/ /www. openhip. org/wiki/ )
• How HIP works (http:/ / infrahip.hiit. fi/index.php?index=how) - from InfraHIP site
• HIP simulation framework for OMNeT++ (http:// www.ict-optimix.eu/ index. php/ HIPSim)
Host Monitoring Protocol
Host Monitoring Protocol
Host Monitoring Protocol (HMP) is an obsolete TCP/IP protocol described in RFC 869.
HOTP is an HMAC-based One Time Password algorithm. It is a cornerstone of Initiative For Open Authentication
HOTP was published as an informational IETF RFC 4226 in December 2005, documenting the algorithm along with
a Java implementation. Since then, the algorithms was adopted by many companies worldwide (see below) and
became the world's leading standard for event-based OTP authentication. The HOTP algorithm is a freely available
open standard.
• K be a secret key
• C be a counter
• HMAC(K,C) = SHA1(K ⊕ 0x5c5c… ∥ SHA1(K ⊕ 0x3636… ∥ C)) be an HMAC calculated with the SHA-1
cryptographic hash algorithm
• Truncate be a function that selects 4 bytes from the result of h in a defined manner
Then HOTP(K,C) is mathematically defined by
HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF
The mask is to disregard the most significant bit to provide better interoperability between processors.
For HOTP to be useful for an individual to input to a system, the result must be converted into a HOTP value, a 6–8
digits number that is implementation dependent.
HOTP-Value = HOTP(K,C) mod 10
, where d is the desired number of digits
HOTP can be used to authenticate a user in a system via an authentication server. Also, if some more steps are
carried out (the server calculates subsequent OTP value and sends/displays it to the user who checks it against
subsequent OTP value calculated by his token), the user can also authenticate the validation server.
Both hardware and software tokens are available from various vendors, for some of them see references below.
Hardware tokens implementing OATH HOTP tend to be significantly cheaper than their competitors based on
proprietary algorithms.
As of 2010, OATH HOTP hardware tokens can be purchased for a marginal price.
Currently (February 2011), at least ActivIdentity
, Alladin/SafeNet
, Authenex
, Entrust, Feitian
produce hardware and/or software HOTP tokens. In addition to abovementioned display-based
button-operated tokens, Yubico offers USB token called YubiKey which emulates USB keyboard and sends the
password to the computer as keyboard input.
Software tokens are available for (nearly) all major mobile/smartphone platforms (J2ME
, Android

, BlackBerry
, Maemo
, Windows Mobile
Although the reception from some of the computer press has been negative during 2004 and 2005


, after
IETF adopted HOTP as RFC 4226 in December 2005, various vendors started to produce HOTP compatible tokens
and/or whole authentication solutions (see above/below).
According to a paper on strong authentication (entitled "Road Map: Replacing Passwords with OTP Authentication")
published by Burton Group (a division of Gartner, Inc.) in 2010, "Gartner's expectation is that the hardware OTP
form factor will continue to enjoy modest growth while smartphone OTPs will grow and become the default
hardware platform over time."
[1] Diodati, Mark (2010). "Road Map: Replacing Passwords with OTP Authentication" (http:/ / www.burtongroup.com/ Research/
PublicDocument.aspx?cid=2107). Burton Group. . "Gartner's expectation is that the hardware OTP form factor will continue to enjoy modest
growth while smartphone OTPs will grow and become the default hardware platform over time. ... If the organization does not need the
extensive platform support, then OATH-based technology is likely a more cost-effective choice."
[2] "Security Authentication Tokens - Entrust" (http:// www. entrust.com/ strong-authentication/identityguard/tokens/ ). Entrust. 2011. .
"Priced at $5 per token, the Entrust IdentityGuard Mini Token demonstrates that secure, reliable hardware authentication can be had at an
attractive price. ... OATH and DES/3DES algorithm support"
[3] "ActivIdentity Mini OTP Token" (http:/ / www.actividentity. com/ products/ authenticationdevices/ OTPTokens/). ActivIdentity. 2010. .
"The ActivIdentity Mini OTP Token is designed for high-volume token deployments in consumer and employee authentication. ... Support of
Initiative for Open AuTHentication (OATH) standards"
[4] "SafeNet eToken PASS" (http:/ / www. safenet-inc.com/ products/ data-protection/two-factor-authentication/etoken-pass/ ). SafeNet. 2011. .
"eToken PASS is a compact and portable one-time password (OTP) authenticator that enables strong authentication to both web and
client-based applications. ... OTP security algorithm: OATH compliant (based on HMAC-SHA1)"
[5] "Authenex A-Key® Tokens" (http:// www. authenex. com/ authenex-products/ a-key-tokens.html). Authenex. 2011. . "There are three
different versions of the Authenex OTP product: the OTP token (A-Key 3600 Series), the OTP card (A-Key 3700 Series), and the OTP
software product. Each of them has the capability to generate either event based or time based OTP."
[6] "FEITIAN OTP c100" (http:/ / www. ftsafe. com/ download/ files/ 169.html). Feitian. 2008. . "Lowest Cost OATH HOTP Eventbased OTP
[7] "ZyWALL OTPv2 One-Time Password Authentication" (http:/ / www.zyxel.co. uk/ web/ product_family_detail.
php?PC1indexflag=20040908175941& CategoryGroupNo=96C9CDE6-F2AA-4D84-9D62-311A7CCD996C). Zyxell. 2008. .
"OATH-compliant (Based on HMAC-SHA1)"
[8] "The YubiKey" (http:// www.yubico. com/ yubikey). Yubico. 2011. . "Yubico's core product is the YubiKey®, the unique USB-key for
secure, easy and affordable login to networks and services. The YubiKey works from any computer for any number of applications with no
client software needed."
[9] "DS3 Launches OathToken Midlet Application" (http:// www. ds3global. com/ index.php?option=com_content&task=view& id=71&
Itemid=37). Data Security Systems Solutions. 2006-02-24. . "Singapore, Friday, 24 February 2006 - Data Security Systems Solutions is
pleased to announce the launch of OathToken Midlet application, an extension of DS3 flagship product - Authentication Server."
[10] "Android Token" (http:// code. google. com/ p/ androidtoken/). diamondz... AT googlemail.com (not a full address, no better info on author
could be found). 2009. . "Android Token is a project to create OATH software tokens for the Android platform. Turning a mobile phone into a
One Time Password (OTP) generation device which can be used in the place of hardware tokens. ... The project supports both HOTP (Event
Tokens) and TOTP (Time Tokens) specifications. ... Code license: GNU GPL v3"
[11] "StrongAuth" (http:/ / www.androidzoom.com/ android_applications/ tools/ strongauth_bmeq.html). StrongAuth. 2010. . "Time-based
one-time passcode generator based on HOTP (RFC 4226)."
[12] Cobbs, Archie L. (2010). "OATH Token" (http:// code. google. com/ p/ oathtoken/ ). Archie L. Cobbs. . "OATH Token is a free and
open-source software token for two-factor authentication on the iPhone. OATH Token implements the RFC 4226 HOTP/OATH algorithm
standard and is not tied to any proprietary server software."
[13] "ActivIdentity Soft Tokens" (http:/ / www.actividentity. com/ products/ authenticationdevices/ SoftTokens/). ActivIdentity. 2010. . "All
ActivIdentity Soft Tokens support the Initiative for Open Authentication (OATH) HMAC-Based One-Time Password (HOTP) algorithm. ...
ActivIdentity Mobile Soft Tokens are available on leading handset operating systems, including BlackBerry®, Apple® iPhone®, Windows
Mobile, and many other Java 2 Platform, Micro Edition (J2ME) enabled devices."
[14] Whitbeck, Sean (2011). "OTP Generator for N900" (http:// maemo.org/ packages/ view/ otp/ ). Sean Whitbeck. . "OTP Generator for
Maemo on the Nokia N900. Supports OATH tokens (HOTP,TOTP) as well as the Mobile-OTP algorithm."
[15] Kearns, Dave (2004-12-06). "Digging deeper into OATH doesn't look so good" (http:/ / www. networkworld.com/ newsletters/ dir/ 2004/
1206id1. html). Network World. . "It may be that OATH will amount to something someday, but so far, it appears to be a stalking horse for
VeriSign and that's not a bandwagon we should thoughtlessly jump on."
[16] Willoughby, Mark (2005-03-21). "No agreement on Oath authentication" (http:// www. computerworld.com/ s/ article/99273/
No_agreement_on_Oath_authentication). Computerworld. .
[17] Kaliski, Burt (2005-05-19). "Algorithm agility and OATH" (http:/ / www.computerworld.com/ s/ article/101788/
Algorithm_agility_and_OATH). Computerworld. . "Nevertheless, there is still good reason to question whether HOTP is suitable as a standard
algorithm for OTP generation, and, more generally, whether such a standard algorithm is even necessary at all."
External links
• RFC4226: HOTP: An HMAC-Based One-Time Password Algorithm (http:/ / www.ietf.org/rfc/rfc4226.txt)
• Initiative for Open Authentication (http:/ / www.openauthentication. org/)
• OATH Toolkit (http:/ / www. nongnu. org/oath-toolkit/) is an implementation in C as a shared library, command
line tool and PAM module
HTTP body data
HTTP Body Data is the data bytes transmitted in an HTTP transaction message immediately following the headers
if there is any (in the case of HTTP/0.9
no headers are transmitted).
HTTP message
The request/response message consists of the following:
• Request line, such as GET /logo.gif HTTP/1.1 or Status line, such as HTTP/1.1 200 OK,
• Headers
• An empty line
• Optional HTTP message body data
The request/status line and headers must all end with <CR><LF> (that is, a carriage return followed by a line feed).
The empty line must consist of only <CR><LF> and no other whitespace.
The "optional HTTP message body data" is what this article defines.
Response example
This could be a response from the web server:
HTTP/1.1 200 OK
Date: Sun, 10 Oct 2010 23:26:07 GMT
Server: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g
Last-Modified: Sun, 26 Sep 2010 22:04:35 GMT
ETag: "45b6-834-49130cc1182c0"
Accept-Ranges: bytes
Content-Length: 13
Connection: close
Content-Type: text/html
Hello world!
HTTP body data
[1] http:/ / www. w3. org/Protocols/ HTTP/AsImplemented. html
Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message
Protocol (ICMP) for Internet Protocol version 6 (IPv6) defined in RFC 4443.
ICMPv6 is an integral part of IPv6
and performs error reporting, diagnostic functions (e.g., ping), and a framework for extensions to implement future
Several extensions have been published, defining new ICMPv6 message types as well as new options for existing
ICMPv6 message types. Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6 which replaces
and enhances functions of ARP.
Secure Neighbor Discovery Protocol (SEND) is an extension of NDP with extra
security. Multicast Router Discovery (MRD) allows discovery of multicast routers.
Technical details
ICMPv6 messages may be classified into two categories: error messages and information messages. ICMPv6
messages are transported by IPv6 packets in which the IPv6 Next Header value for ICMPv6 is set to 58.
Packet format
The ICMPv6 packet consists of a header and the protocol payload. The header contains only three fields: type (8
bits), code (8 bits), and checksum (16 bits). type specifies the type of the message. Values in the range from 0 to 127
(high-order bit is 0) indicate an error message, and, when the high-order bit is 1 (128 to 255), it is an information
message. The code field value depends on the message type and provides an additional level of message granularity.
The checksum field provides a minimal level of integrity verification for the ICMP message.
ICMPv6 packet
Bit offset 0–7 8–15 16–31
0 Type Code Checksum
32 Message body
Types of ICMPv6 messages
Type Meaning
ICMPv6 Error Messages
1 Destination Unreachable
2 Packet Too Big
3 Time Exceeded
4 Parameter Problem
100 Private experimentation
101 Private experimentation
127 Reserved for expansion of ICMPv6 error messages
ICMPv6 Informational Messages
128 Echo Request
129 Echo Reply
133 Router Solicitation (NDP)
134 Router Advertisement (NDP)
135 Neighbor Solicitation (NDP)
136 Neighbor Advertisement (NDP)
137 Redirect Message (NDP)
148 Certification Path Solicitation (SEND)
149 Certification Path Advertisement (SEND)
151 Multicast Router Advertisement (MRD)
152 Multicast Router Solicitation (MRD)
153 Multicast Router Termination (MRD)
200 Private experimentation
201 Private experimentation
255 Reserved for expansion of ICMPv6 informational messages
Note that the table above is not comprehensive. The current complete list of assigned ICMPv6 types can be found at
this link: IANA: ICMPv6 Parameters
Message checksum
ICMPv6 provides a minimal level of message integrity verification by the inclusion of a 16-bit checksum in its
header. The checksum is calculated starting with a pseudo-header of IPv6 header fields according to the IPv6
which consists of the source and destination addresses, the packet length and the next header field, the
latter of which is set to the value 58. Following this pseudo header, the checksum is continued with the ICMPv6
message in which the checksum is initially set to zero. The checksum computation is performed according to Internet
protocol standards using 16-bit one's complement summation, followed by complementing the checksum itself and
inserting it into the checksum field.
Message processing
When an ICMPv6 node receives a packet, it must undertake actions that depend on the type of message. The
ICMPv6 protocol must limit the number of error messages sent to the same destination to avoid network
overloading. For example, if a node continues to forward erroneous packets, ICMP will signal the error to the first
packet and then do so periodically, with a fixed minimum period or with a fixed network maximum load. An ICMP
error message must never be sent in response to another ICMP error message.
[1] RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
[2] RFC 3315, § 3
[3] http:/ / www. iana. org/assignments/ icmpv6-parameters
[4] RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, Section 8.1 (Upper-Layer Checksum), S. Deering, R. Hinden (December 1998)
[5] RFC 1071, Computing the Internet Checksum, R. Braden, D. Borman, C. Partridge (September 1988)
External links
• IANA: ICMPv6 Parameters (http:// www. iana. org/assignments/ icmpv6-parameters)
• RFC 2894, Router Renumbering for IPv6
The Ident Protocol, specified in RFC 1413, is an Internet protocol that helps identify the user of a particular TCP
connection. One popular daemon program for providing the ident service is identd.
How ident works
The Ident Protocol is designed to work as a server daemon, on a user's computer, where it receives requests to a
specified port, generally 113. In a query, a client specifies a pair of ports (a local and a remote port). The server will
then send a specially designed response that identifies the username of the user who runs the program that uses the
specified pair of ports.
Usefulness of ident
Dialup hosts or shared shell servers often provide ident to enable abuse to be tracked back to specific users. In the
case that abuse is handled on this host the concern about trusting the ident daemon is mostly irrelevant. Spoofing of
the service and privacy concerns can be avoided by providing varying cryptographically strong tokens instead of real
If abuse is to be handled by the administrators of the service users connect to using the ident providing host, then the
ident service must provide information identifying each user. Usually it is impossible for the administrators of the
remote service to know whether specific users are connecting via a trustable server or from a computer they
themselves control. In the latter case the ident service provides no reliable information.
The usefulness of Ident for proving of a known identity to a remote host is limited to circumstances when:
• The user connecting is not the administrator of the machine. This is only likely for hosts providing Unix shell
access, shared servers using a suEXEC-like construction and the like.
• One trusts the administrators of the machine and knows their user policy. This is most likely for hosts in a
common security domain such as within a single organization.
• One trusts that the machine is the machine it claims to be and knows that machine. This is only easily arranged for
hosts on a local area network or virtual network where all hosts on the network are trusted and new hosts cannot
easily be added due to physical protection. On remote and normal local networks false ident replies can be
accomplished by ip spoofing and, if DNS is used, by all kinds of DNS trickery. The ident daemon may provide
cryptographically signed replies, which in case they can be confirmed solves these last, but not the first, concerns.
The ident protocol is considered dangerous because it allows crackers to gain a list of usernames on a computer
system which can later be used for attacks. A generally accepted solution to this is to set up a generic/generated
identifier, returning node information or even gibberish (from the requesters point of view) rather than usernames.
This gibberish may be turned into real usernames by the ident administrator, when he is contacted about possible
abuse, which means the usefulness for tracking abuse is preserved.
Ident is important on IRC as a large number of people connect to IRC from a server shared by multiple users, often
using a bouncer. Without Ident there would be no way to ban a single user without banning the entire host. The
server administrator may also use this information to identify the abusive user.
On most IRC networks, when the server fails to get an Ident response it falls back to the username given by client,
but marks it as "not verified", usually by prefixing with a tilde; e.g. ~josh. Some IRC servers even go as far as
blocking clients without an ident response, the main reason being that it makes it much harder to connect via an
"open proxy" or a system where you have compromised a single account of some form but do not have root (on
Unix-like systems, only root can listen for network connections on ports below 1024).
However, Ident is next to ineffective when used with personal computers, on which the user has enough privileges to
make the Ident daemon reply whatever the user wants. In fact, most Ident servers for Windows don't even bother
checking the owner of a connection and just reply with a preconfigured username.
• oidentd (for Unix-like systems)
• Retina Scan Identd
(for Windows; supports multiple users in a way similar to Unix identd)
• Windows Ident Server
[1] https:/ / sourceforge.net/ projects/ retinascan/
[2] http:// rndware.info/products/ windows-ident-server.html
• RFC 912 - Authentication Service
• RFC 931 - Authentication Server
• Daniel J. Bernstein: TAP (http:/ / tools. ietf.org/html/ draft-bernstein-tap) - INTERNET DRAFT 1992
• Daniel J. Bernstein: Why TAP? (ftp:/ / ftp.lysator. liu. se/ pub/ ident/ doc/ why-tap. txt) A White Paper, draft 3
• RFC 1413 - Identification Protocol
• RFC 1414 - Identification MIB
• Peter Eriksson: TAPvsIDENT (ftp:// ftp. lysator. liu. se/ pub/ ident/ TAPvsIDENT) 3 Nov 1993
• Damien Doligez: Why encrypt ident/TAP replies? (http:/ / www.geckil. com/ ~harvest/ tcpip-docs/ why-encrypt.
txt) 1994.02.22
IGMP snooping
IGMP snooping
IGMP snooping is the process of listening to Internet Group Management Protocol (IGMP) network traffic. IGMP
snooping, as implied by the name, is a feature that allows a network switch to listen in on the IGMP conversation
between hosts and routers. By listening to these conversations the switch maintains a map of which links need which
IP multicast streams. Multicasts may be filtered from the links which do not need them.
A switch will, by default, flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent).
Multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited.
When purposefully exploited this is known as one variation of a denial-of-service attack. IGMP snooping is designed
to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. It
provides switches with a mechanism to prune multicast traffic from links that do not contain a multicast listener (an
IGMP client).
IGMP snooping allows a switch to only forward multicast traffic to the links that have solicited them. Essentially,
IGMP snooping is a layer 2 optimization for the layer 3 IGMP. IGMP snooping takes place internally on switches
and is not a protocol feature. Snooping is therefore especially useful for bandwidth-intensive IP multicast
applications such as IPTV.
Standard status
IGMP snooping, although an important technique, overlaps two standards organizations namely IEEE which
standardizes Ethernet switches, and IETF which standardises IP multicast. This means that even today there is no
clear owner of this technique. This is why RFC 4541 on IGMP snooping only has the status Informational
actually being referenced in other standards work such as RFC 4903 as normative.
Implementations options
Proxy reporting
IGMP snooping with proxy reporting or report suppression actively filters IGMP packets in order to reduce load on
the multicast router.
Joins and leaves heading upstream to the router are filtered so that only the minimal quantity
of information is sent. The switch is trying to ensure the router only has a single entry for the group, regardless of
how many active listeners there are. If there are two active listeners in a group and the first one leaves, then the
switch determines that the router does not need this information since it does not affect the status of the group from
the router's point of view. However the next time there is a routine query from the router the switch will forward the
reply from the remaining host, to prevent the router from believing there are no active listeners. It follows that in
active IGMP snooping, the router will generally only know about the most recently joined member of the group.
IGMP querier
In order for IGMP, and thus IGMP snooping, to function, an multicast router must exist on the network and generate
IGMP queries. The tables created for snooping (holding the member ports for a each multicast group) are associated
with the querier. Without a querier the tables are not created and snooping will not work. Furthermore IGMP general
queries must be unconditionally forwarded by all switches involved in IGMP snooping.
Some IGMP snooping
implementations include full querier capability. Others are able to proxy and retransmit queries from the multicast
IGMP snooping
[1] RFC 4541
Internet 0
Internet 0 is a low-speed physical layer designed to route 'IP over anything.' It was developed at MIT's Center for
Bits and Atoms by Neil Gershenfeld, Raffi Krikorian, and Danny Cohen. When it was invented, a number of other
proposals were being labelled as "internet 2." The name was chosen to emphasize that this was designed to be a
slow, but very inexpensive internetworking system, and forestall "high-performance" comparison questions such as
"how fast is it?"
Internet 0 was originally intended to network buildings, improve efficiency, and gather data through the control of
HVAC systems (heating, ventilation, and air conditioning). Effectively, it would enable a platform for pervasive
computing -- everything in a building could be on the same network to share data gathering and actuation. A light
switch could turn on a light bulb by sending a packet to it, they can be linked together by the user.
Implementation-wise, a small, low powered, inexpensive web server on a chip could be embedded into many devices
to allow data retrieval from them or control of them over the network -- these small devices could be used to form an
Internet of Things.
The current largest deployment of Internet 0 was at the Venice Biennale Architecture Exhibition, in the year 2008,
by a group leaded by the Institute of Advanced Architecture of Catalonia, directed by the architect Vicente Guallart.
According to talks given, Cisco and Schneider Electric are interested in commercializing the Internet 0 technology.
The design intent is to provide a simple, very inexpensive system that can transmit data slowly over many types of
media, and yet still connect devices to the internet. Connecting to the internet is a crucial part of the design, because
much of the value of a networked device is provided by easy, wide access to it. The higher layers of an Internet 0
network are usually SLIP, IP, and above that, usually UDP or more rarely TCP.
The protocol layers are chosen to need a minimum of code, to keep the expense of the computer low. Internet 0 has
been implemented in small AVR microcontrollers. In most existing implementations, the layers are not distinct,
because small code is more important than elegant design.
A small translation device normally attaches a local network of Internet 0 devices to the serial port of a PC that acts
as a gateway and firewall to the Internet.
Devices can talk directly to each other without requiring a server. The distributed architecture ensures that there is no
central point of failure.
Address assignment and cryptographic key intialization is sometimes performed by closing a contact on the device
while having a master controller broadcast an assignment message. Security is via a simplified encryption system.
Internet 0
Internet 0 is similar to a serial port running at 9600 baud except it sends data by pulse-position modulation, and
accepts up to 30% timing deviations.
A zero bit is a one-microsecond pulse in the center of the first half of a bit time, and a one is a pulse in the second
half of a bit time. Data is sent as 8 bit bytes. A byte is preceded by a bit time that has two pulses (at both 1 and 0
times), and ends with a bit time that has another two pulses.
In some variations, the stop bit-time is optional, and the dual-pulse bit times are treated as byte separators.
The dual-pulse start and stop bit times permit a receiver to synchronize with the beginnings of bytes, and also
measure the baud rate of a sender. Synchronizing on 8-bit bytes permits a 9600 baud internet-0 connection to easily
translate to a standard, low-speed 19,200 baud TCP/IP serial port. The baud rate measurement permits senders and
receivers to use inexpensive low-precision oscillators such as ceramic resonators or resistor-capacitor oscillators.
The most common interface uses the power supply wiring to the device. The circuit is a small surface mounted
capacitor between an AC mains wire or a DC power wire and a single digital pin of a small microcontroller. The
pulses are normally generated by having software toggle a digital I/O pin on the microcontroller. They are received
through another capacitor, by a microcontroller with a pin configured as an interrupt, or as a hardware timer's gate.
The pulse position modulation works in many media. Internet 0 has been tested over RF, IR, ultrasonics, optical, DC
and AC power wiring, and even physical representations such as printed bar codes and engraving on a key.
• Gershenfeld, Neil; Krikorian, Raffi; Cohen, Danny (October 2004), The Internet of Things
, Scientific
External links
• Internet 0 at MIT's Center for Bits and Atoms
• Programming Bits and Atoms
Google TechTalk by Neil Gershenfeld, 27 October 2008
• Internet 0: Inter-device Internetworking
• Internet 0 info
• Hyperhabitat: Reprogramming the World
- Venice Biennale Architecture Exhibition
• Boing Boing - "Internet 0 -- Bringing IP to the Leaf Node
[1] http:/ / www. scientificamerican. com/article. cfm?id=the-internet-of-things
[2] http:// cba.mit.edu/ projects/ I0/
[3] http:/ / www. youtube. com/ watch?v=w8ubXgXM7kk
[4] http:// www. media. mit. edu/ physics/ publications/ papers/ 04. 10. sciam/
[5] http:/ / www. ldeo. columbia. edu/ ~dale/ projects/ Internet-0_info.html
[6] http:// www. hyperhabitat.net/
[7] http:/ / www. boingboing. net/ 2003/ 04/ 25/ internet-0-bringing-.html
Internet chess server
Internet chess server
An Internet chess server (ICS) is an external server that provides the facility to play, discuss, and view the board
game of chess over the Internet. The term specifically refers to facilities for connecting players through a variety of
graphical chess clients located on each user's computer.
In the 1970s, one could play correspondence chess in a PLATO System program called 'chess3'. Several users used
chess3 regularly; often a particular user would make several moves per day, sometimes with several games
simultaneously in progress. In theory one could use chess3 to play a complete game of chess in one sitting, but
chess3 was not usually used this way. PLATO was not connected to internet predecessor ArpaNet in any way that
allowed mass use by the public, and consequently, chess3 was and still is relatively unknown to the public.
In the eighties, chess play by email was still fairly novel. Latency with email was less than with traditional
correspondence chess via paper letters. Often one could complete a dozen moves in a week. As network technology
improved, public, widespread use of a centralised server for live play became a possibility.
Michael Moore, of the University of Utah, and Richard Nash recognised the potential of an Internet chess server and
created its first incarnation. The official opening date of the ICS was January 15, 1992. John Chanak, William Kish,
and Aaron Putnam moved the server to a host machine at Carnegie Mellon University in July 1992, and took over its
operation. Although it was buggy and suffered from lag problems, the server was popular among a small group of
chess enthusiasts. Over time, many features were added to the ICS, such as ELO ratings and support for graphical
clients, and the server was made more stable.
In late 1992, Daniel Sleator, professor of computer science at Carnegie Mellon University, took over management of
the ICS. He addressed, among other issues, the frequent complaint that players would lose blitz games on time due to
Internet lag. In 1994, he copyrighted the code, and began receiving purchase offers from companies wanting to
commercialise the server. There were questions about whether Sleator was right to claim that the ICS was his
intellectual property, since he did not code the original server, although he had made substantial improvements to its
On March 1, 1995, Sleator announced his intentions to commercialise ICS himself, renaming it the Internet Chess
Club, or ICC, and charging a yearly membership fee of $US 49 ($US 59.95 in 2007). This announcement was highly
controversial among existing members. Many volunteers who had contributed in various ways to the flourishing of
ICS were upset that anyone would attempt to profit from their efforts. Active players on the server who were used to
the service being provided without charge were not pleased with the addition of the membership fee.
A handful of programmers who had worked on the original ICS became unhappy with what they saw as the
commoditization of their project. They formed the Free Internet Chess Server (FICS), and continued to allow
everyone to have access to all features for free. In 1996, John Fanning, uncle of Napster founder Shawn Fanning,
started Chess.net,
a commercial Internet chess server to rival ICS. Both services remain operational today.
Internet chess server
Protocol and access
The ICS protocol is a simple, text-based variant of the TELNET protocol. It is sparsely documented and not
standardised, although a few reference implementations and several clients exist.
In theory, an ICS can be accessed from any TELNET client. That said, almost all users choose to play using a
graphical client, called an interface. Currently, the most popular interface is XBoard (and its Windows counterpart,
WinBoard). In recent years, however, it has lost ground to newer interfaces like Pychess and eboard.
In addition to standalone clients, many servers also offer Java interfaces that can be used directly from a Web
browser. These are popular with new users and users of public computers.
Available servers
Over the years, several Internet chess servers have been created. The Internet Chess Club is currently the largest
server but each server has its own strengths and character.
However, Mark Weeks claims that Yahoo! Games
accounts for 44% of the players online, compared to 12% for ICC and 7% for Playchess.
Despite Yahoo! Games
dominance over the online chess market, there are still new online chess servers being developed.
For a list of servers see Category:Internet chess servers.
[1] Tim Mann, "Internet Chess Servers," http:/ / www.tim-mann.org/ ics.html.
[2] Welcome to Chess.net (http:// www.chess. net/ )
[3] Christian Kongsted, How to Use Computers to Improve Your Chess (London: Gambit Publications, 2003), pp. 178-180.
[4] Mark Weeks, "Crossboard Chess Servers," http:// chess. about.com/ od/ otbservers/ .
External links
• Internet chess servers (http:// www. tim-mann. org/ics. html), Tim Mann
• History of the Internet Chess Server 1992–1995 (http:// members. cox. net/ cpetroff/FICS/ ), Chris Petroff
Internet Content Adaptation Protocol
Internet Content Adaptation Protocol
The Internet Content Adaptation Protocol (ICAP) is a lightweight HTTP-like protocol specified in RFC 3507
which is used to extend transparent proxy servers, thereby freeing up resources and standardizing the way in which
new features are implemented. ICAP is generally used to implement virus scanning, and content filters in transparent
HTTP proxy caches. Content Adaptation refers to performing the particular value added service (content
manipulation) for the associated client request/response.
ICAP concentrates on leveraging edge-based devices (proxies and caches) to help deliver value-added services. At
the core of this process is a cache that will proxy all client transactions and will process them through ICAP Web
servers. These ICAP servers are focused on a specific function, for example, ad insertion, virus scanning, content
translation, language translation, or content filtering. Off-loading value-added services from Web servers to ICAP
servers allows those same web servers to be scaled according to raw HTTP throughput versus having to handle these
extra tasks.
ICAP was proposed in late 1999 by Peter Danzig and John Schuster from Network Appliance. Don Gillies took over
the project in the spring of 2000 and enhanced the protocol to allow pipelined ICAP servers and to support all 3
encapsulations of HTTP allowed by HTTP 1.1. Gillies also prototyped the first ICAP client and server for the
NetCache series of internet caches in mid-2000 and produced training materials for vendors. The first demonstration
ICAP Server was written in Perl and employed the Debian word-replacement filters to rewrite web pages, skipping
over the HTML tags, and translate web pages into "swedish chef" or "jive" in real time.
Open source implementations
• ICAP-server.sf.net
(Python, multiplatform)
• Squid 3.0 (C++, multiplatform)
• GreasySpoon
(ICAP server, Java, multiplatform)
• c-icap
(C, multiplatform)
Commercial implementations
• CensorNet ICAP Server
• M86 Security Secure Web Gateway
• McAfee Web Gateway
External links
• ICAP Forum
• http:/ / www. icap-forum.org/documents/ specification/ icap_whitepaper_v1-01.pdf
• RFC 3507 (Informational)
• Using ICAP with [[SafeSquid
] Proxy]
• A page from ICAP Beta Testing translated from Yahoo News into Jive! (Sept 20, 2000)
Internet Content Adaptation Protocol
[1] http:/ / icap-server.sf. net
[2] http:/ / greasyspoon. sourceforge.net/
[3] http:/ / c-icap.sourceforge.net/
[4] http:/ / www. censornet. com/ products/ icap-server/
[5] http:/ / www. mcafee. com/ us/ products/ web-gateway.aspx
[6] http:/ / www. icap-forum.org
[7] http:/ / www. safesquid. com/ html/ portal.php?page=38
[8] http:/ / www. ece.ubc. ca/ ~gillies/ icap/ bombings4. html
Internet Control Message Protocol
The Internet Control Message Protocol (ICMP) is one of the core protocols of the Internet Protocol Suite. It is
chiefly used by the operating systems of networked computers to send error messages indicating, for example, that a
requested service is not available or that a host or router could not be reached. ICMP can also be used to relay query
differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data
between systems, nor is it regularly employed by end-user network applications (with the exception of some
diagnostic tools like ping and traceroute).
ICMP for Internet Protocol version 4 (IPv4) is also known as ICMPv4. IPv6 has a similar protocol, ICMPv6.
Technical details
Internet Control Message Protocol is part of the Internet Protocol Suite as defined in RFC 792. ICMP messages are
typically generated in response to errors in IP datagrams (as specified in RFC 1122) or for diagnostic or routing
purposes. ICMP errors are always reported to the original source IP address of the originating datagram.
An example ICMP error message is the Time To Live Exceeded message. Every machine (such as an intermediate
router) that forwards an IP datagram has to decrement the time to live (TTL) field of the IP header by one. If the
TTL reaches 0, an ICMP Time to live exceeded in transit message is sent to the source of the datagram.
Each ICMP message is encapsulated directly within a single IP datagram, and thus, like UDP, ICMP is unreliable.
Although ICMP messages are contained within standard IP datagrams, ICMP messages are usually processed as a
special case, distinguished from normal IP processing, rather than processed as a normal sub-protocol of IP. In many
cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the
application that generated the original IP packet, the one that prompted the sending of the ICMP message.
Many commonly-used network utilities are based on ICMP messages. The tracert (traceroute), Pathping commands
are implemented by transmitting UDP datagrams with specially set IP TTL header fields, and looking for ICMP
Time to live exceeded in transit (above) and "Destination unreachable" messages generated in response. The related
ping utility is implemented using the ICMP "Echo request" and "Echo reply" messages.
Internet Control Message Protocol
ICMP segment structure
The ICMP header starts after the IPv4 header. All ICMP packets will have an 8 byte header and variable sized data
section. The first 4 bytes of the header will be consistent. The first byte is for the ICMP type. The second byte is for
the ICMP code. The third and fourth bytes are a checksum of the entire ICMP message. The contents of the
remaining 4 bytes of the header will vary based on the ICMP type and code.
ICMP error messages contain a data section that includes the entire IP header plus the first 8 bytes of the packet that
generated the error message. The ICMP datagram is then encapsulated in a new IP datagram.
Bits 0-7 8-15 16-23 24-31
0 Type Code Checksum
32 Rest of Header
• Type - ICMP type as specified below.
• Code - Subtype to the given type.
• Checksum - Error checking data. Calculated from the ICMP header+data, with value 0 for this field. The
algorithm is the same as the header checksum for IPv4.
• Rest of Header - Four byte field. Will vary based on the ICMP type and code.
Padding data
Padding data follows the ICMP header (in octets):
• Windows "ping.exe" adds, by default, 32 bytes of padding
• The Linux "ping" utility adds, by default, 56 bytes of padding
List of permitted control messages (incomplete list)
Type Code Description
0 - Echo Reply
0 Echo reply (used to ping)
1 and 2 Reserved
3 - Destination Unreachable
0 Destination network unreachable
1 Destination host unreachable
2 Destination protocol unreachable
3 Destination port unreachable
4 Fragmentation required, and DF flag set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated
9 Network administratively prohibited
10 Host administratively prohibited
11 Network unreachable for TOS
12 Host unreachable for TOS
13 Communication administratively prohibited
Internet Control Message Protocol
4 - Source Quench 0 Source quench (congestion control)
5 - Redirect Message 0 Redirect Datagram for the Network
1 Redirect Datagram for the Host
2 Redirect Datagram for the TOS & network
3 Redirect Datagram for the TOS & host
6 Alternate Host Address
7 Reserved
8 - Echo Request 0 Echo request
9 - Router Advertisement 0 Router Advertisement
10 - Router Solicitation 0 Router discovery/selection/solicitation
11 - Time Exceeded
0 TTL expired in transit
1 Fragment reassembly time exceeded
12 - Parameter Problem: Bad IP header 0 Pointer indicates the error
1 Missing a required option
2 Bad length
13 - Timestamp 0 Timestamp
14 - Timestamp Reply 0 Timestamp reply
15 - Information Request 0 Information Request
16 - Information Reply 0 Information Reply
17 - Address Mask Request 0 Address Mask Request
18 - Address Mask Reply 0 Address Mask Reply
19 Reserved for security
20 through 29 Reserved for robustness experiment
30 - Traceroute 0 Information Request
31 Datagram Conversion Error
32 Mobile Host Redirect
33 Where-Are-You (originally meant for IPv6)
34 Here-I-Am (originally meant for IPv6)
35 Mobile Registration Request
36 Mobile Registration Reply
37 Domain Name Request
38 Domain Name Reply
39 SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol
40 Photuris, Security failures
41 ICMP for experimental mobility protocols such as Seamoby [RFC4065]
42 through 255 Reserved
(Sources: IANA ICMP Parameters
[7] and Computer Networking - A Top-Down Approach by Kurose and Ross)
Internet Control Message Protocol
[1] Forouzan, Behrouz A. (2007). Data Communications And Networking (Fourth ed.). Boston: McGraw-Hill. pp. 621–630.
ISBN 0-07-296775-7.
[2] Postel, J. (September 1981). Internet Control Message Protocol. IETF. RFC 792.
[3] http:/ / tools. ietf.org/html/ rfc792#page-14
[4] http:// tools. ietf.org/html/ rfc792#page-4
[5] http:// tools. ietf.org/html/ rfc792#page-6
[6] http:// www. iana. org/assignments/ icmp-parameters
[7] http:/ / freebie.fatpipe.org/ ~mjb/ Drawings/ UDP_ICMP_Headers.png
External links
• RFCs
• RFC 792, Internet Control Message Protocol
• RFC 1122, Requirements for Internet Hosts -- Communication Layers
• RFC 1716, Towards Requirements for IP Router
• IANA (http:// www. iana. org/assignments/ icmp-parameters)
• ICMP Sequence Diagram (http:// www. eventhelix. com/ RealtimeMantra/ Networking/Icmp. pdf)
• ICMP ping simulation (http:/ / www.visualland. net/ view. php?cid=1124& protocol=ICMP& title=1.Ping
• ICMP traceroute simulation (http:// www.visualland. net/ view. php?cid=1127& protocol=ICMP&title=6.
Internet Fibre Channel Protocol
Internet Fibre Channel Protocol (iFCP) is a gateway-to-gateway network protocol standard, officially ratified by
the Internet Engineering Task Force, which provides Fibre Channel fabric functionality to fibre channel devices over
an IP network. Currently the most common comes in 1 Gbit/s, 2 Gbit/s, 4 Gbit/s, 8 Gbit/s, 10 Gbit/s variants.
Technical overview
The iFCP protocol enables the implementation of fibre channel functionality over an IP network, within which the
fibre channel switching and routing infrastructure is replaced by IP components and technology. Congestion control,
error detection and recovery are provided through the use of TCP (Transmission Control Protocol). The primary
objective of iFCP is to allow existing fibre channel devices to be networked and interconnected over an IP based
network at wire speeds.
The method of address translation defined and the protocol permit fibre channel storage devices and host adapters to
be attached to an IP-based fabric using transparent gateways.
The iFCP protocol layer's main function is to transport Fibre Channel frame images between Fibre Channel ports
attached both locally and remotely. iFCP encapsulates and routes the fibre channel frames that make up each Fibre
Channel information unit via a predetermined TCP connection for transport across the IP network when transporting
frames to a remote Fibre Channel port.
Internet Fibre Channel Protocol
External links
• RFC 4172 - A Protocol for Internet Fibre Channel Storage Networking (iFCP)
Other Links
• iFCP Information Page
at the SNIA IP Storage Forum.
• iFCP Subgroup
at the SNIA IP Storage Forum.
• Protocol Summary
by javin.com.
[1] http:/ / www. snia. org/forums/ipsf/ programs/ about/ ifcp/
[2] http:// www. snia. org/tech_activities/ ip_storage/ ifcp/
[3] http:/ / www. javvin. com/ protocoliFCP. html
Internet Group Management Protocol
The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent
routers on IP networks to establish multicast group memberships.
IGMP is an integral part of the IP multicast specification. It is analogous to ICMP for unicast connections. IGMP can
be used for online streaming video and gaming, and allows more efficient use of resources when supporting these
types of applications.
IGMP is used on IPv4 networks. Multicast management on IPv6 networks is handled by Multicast Listener
Discovery (MLD) which uses ICMPv6 messaging contrary to IGMP's bare IP encapsulation.
A network designed to deliver a multicast service using IGMP might use this basic architecture:
IGMP is used between the client computer and a local multicast router. Switches featuring IGMP snooping derive
useful information by observing these IGMP transactions. Protocol Independent Multicast (PIM) is then used
between the local and remote multicast routers, to direct multicast traffic from the multicast server to many multicast
Internet Group Management Protocol
IGMP operates above the network layer, though it does not actually act as a transport protocol.
There are three versions of IGMP, as defined by "Request for Comments" (RFC) documents of the Internet
Engineering Task Force (IETF). IGMPv1 is defined by RFC 1112, IGMPv2 is defined by RFC 2236 and IGMPv3
was initially defined by RFC 3376 but has since been superseded by RFC 4604 which defines both IGMPv3 and
MLDv2. IGMPv2 improves over IGMPv1 by adding the ability for a host to signal desire to leave a multicast group.
IGMPv3 improves over IGMPv2 mainly by adding the ability to listen to multicast originating from a set of source
IP addresses only.
Host and router implementations
The IGMP protocol is implemented as a host side and a router side. A host side reports its membership of a group to
its local router, and a router side listens to reports from hosts and periodically sends out queries. The FreeBSD,
and Windows operating systems support IGMP at the host side.
For the server side implementation, the Linux case uses a daemon such as mrouted to act as an IGMP Linux router.
There are also entire routing suites (such as XORP), which turn an ordinary computer into a full-fledged multicast
IGMP is vulnerable to some attacks,



and firewalls commonly allow the user to disable it if not needed.
IGMPv3 packet structure
IGMP messages are carried in bare IP packets with IP protocol number 2.
There is no transport layer used with
IGMP messaging.
Membership Query Message
Membership Queries are sent by multicast routers to determine which multicast addresses are of interest to systems
attached to its network. Routers periodically send General Queries to refresh the group membership state for all
systems on its network. Group-Specific Queries are used for determining the reception state for a particular multicast
address. Group-and-Source-Specific Queries allow the router to determine if any systems desire reception of
messages sent to a multicast group from a source address specified in a list of unicast addresses.
IGMPv3 packet structure
bit offset 0-3 4 5-7 8-15 16-31
0 Type = 0x11 Max Resp Code Checksum
32 Group Address
64 Resv S QRV QQIC Number of Sources (N)
96 Source Address [1]
128 Source Address [2]
. . .
Source Address [N]
Max Resp Code
Internet Group Management Protocol
This field specifies the maximum time (in 1/10 second) allowed before sending a responding report. If the
number is below 128, the value is used directly. If the value is 128 or more, it is interpreted as an exponent
with mantisse.
This is the 16-bit one's complement of the one's complement sum of the entire IGMP message.
Group Address
This is the multicast address being queried when sending a Group-Specific or Group-and-Source-Specific
Query. The field is zeroed when sending a General Query.
This field is reserved. It should be zeroed when sent and ignored when received.
S (Suppress Router-side Processing) Flag
When this flag is set, it indicates to receiving routers that they are to suppress the normal timer updates.
QRV (Querier's Robustness Variable)
If this is non-zero, it contains the Robustness Variable value used by the sender of the Query. Routers should
update their Robustness Variable to match the most recently received Query unless the value is zero.
QQIC (Querier's Query Interval Code)
This code is used for specify the Query Interval value (in seconds) used by the querier. If the number is below
128, the value is used directly. If the value is 128 or more, it is interpreted as an exponent with mantisse.
Number of Sources (N)
This field specifies the number of source addresses present in the Query. For General and Group-Specific
Queries, this value is zero. For Group-and-Source-Specific Queries, this value is non-zero, but limited by the
network's MTU.
Source Address [i]
The Source Address [i] fields are a vector of n IP unicast addresses, where n is the value in the Number of
Sources (N) field.
IGMPv2 packet structure
IGMPv2 packet structure
+ Bits 0 - 7 8 - 15 16 - 31
0 Type Max Resp Time Checksum
32 Group Address
Defined by RFC 2236
• Type is Membership Query (0x11), Membership Report (IGMPv1: 0x12, IGMPv2: 0x16), Leave Group (0x17)
IGMPv3 adds type Membership Report (0x22)
• Max Resp Time specifies the time limit for the corresponding report. The field has a resolution of 100
miliseconds, the value is taken directly. This field is meaningful only in Membership Query (0x11); in other
messages it is set to 0 and ignored by the receiver.
Internet Group Management Protocol
[1] "IGMP, Internet Group Management Protocol" (http:// www. networksorcery.com/ enp/ protocol/ igmp. htm). Network Sorcery. . Retrieved
[2] "Internet Group Management Protocol Overview" (http:/ / www.javvin.com/ protocolIGMP.html). Javvin. . Retrieved 2010-11-18.
[3] IGMPv3 was added to FreeBSD in version 8.0.
[4] IGMPv3 was added in the Linux 2.5 kernel series.
[5] Spoofed IGMP report denial of service (http:// www. securityfocus.com/ bid/ 5020/ info) vulnerability.
[6] Fragmented IGMP packet (http:/ / support. microsoft.com/ default.aspx?scid=kb;en-us;238329& sd=tech) may promote "Denial of Service"
[7] IGMP Security Problem Statement and Requirements (http:/ / www.securemulticast.org/ GSEC/ gsec3_ietf53_SecureIGMP1.
pdf#search="igmp attacks").
[8] Microsoft Security Bulletin MS06-007: Vulnerability in TCP/IP Could Allow Denial of Service (913446) (http:// www.microsoft. com/
technet/ security/ Bulletin/ MS06-007. mspx).
[9] RFC 3376 section 4
[10] http:// tools. ietf.org/html/ rfc2236#section-2
External links
• IPv4 Multicasting Tools and Settings on Microsoft TechNet (http:/ / technet2. microsoft.com/ WindowsServer/
en/ Library/fe09af2c-3deb-4c6c-a79f-35c6953a8c9d1033.mspx)
• Different version and details on IGMP (http:/ / www.commsdesign. com/ article/ printableArticle.
Internet Group Management Protocol with
Access Control (IGMP-AC)
The Internet Group Management Protocol with Access Control (IGMP-AC) has been designed for incorporating
AAA functionality in the existing IP multicast model. It will enforce authentication and authorization of an end user
or receiver before joining or leaving a secured multicast group. To add AAA functionality, an access router or
one-hop router of the receiver will act as a Network access server (NAS).
IGMP-AC is an extended version of Internet Group Management Protocol. It provides a generic client-server
authentication protocol, where the receiver or end user will act as a client, the AAA Server will act as a server and
the access router (one-hop router of the receiver) will perform the forwarding task. Thus, any suitable authentication
protocol (e.g., Extensible Authentication Protocol(EAP)) having client-server entities can be encapsulated over the
IGMP-AC architecture. The IGMP-AC will not disrupt the usual function of the IGMPv3 (to be used for classical
multicast group), and the access control mechanism of IGMP-AC will take place to join/leave a secured or restricted
multicast group only.
Internet Imaging Protocol
Internet Imaging Protocol
The Internet Imaging Protocol, or IIP, is an Internet protocol designed by the International Imaging Industry
Association. IIP is built on top of HTTP to communicate images and their metadata and takes advantage of the
FlashPix image architecture.
It is currently in version 1.05.
External links
• IIP page on the International Imaging Industry Association website
• Internet Imaging Protocol specification, Version 1.05
• Object browsing using the Internet Imaging Protocol
• IIPImage: IIP based open source visualization software
[1] http:/ / www. i3a. org/i_iip. html
[2] http:// iipimage.sourceforge.net/ IIPv105.pdf
[3] http:// www9. org/w9cdrom/ 122/ 122. html
[4] http:/ / iipimage.sourceforge.net
Internet Open Trading Protocol
The Internet Open Trading Protocol (IOTP) is a protocol provides an interoperable, standardized and payment
system independent framework for Internet commerce which tries to replicate real-world trading processes as close
as possible.
External links
• RFC 2801 - Internet Open Trading Protocol (IOTP)
• RFC 2935 - Internet Open Trading Protocol (IOTP) HTTP Supplement
Internet Protocol Control Protocol
Internet Protocol Control Protocol
"IPCP" redirects here. For the Philippine law, see Intellectual Property Code of the Philippines.
In computer networking, Internet Protocol Control Protocol (IPCP) is a network control protocol for establishing
and configuring Internet Protocol over a Point-to-Point Protocol link. IPCP uses the same packet exchange
mechanism as the Link Control Protocol. IPCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase, and any IPCP packets received before this phase is reached should be silently
IP Frame
After the configuration is done, the link is able to carry IP data as a payload of the PPP frame. This code indicates
that IP data is being carried.
PPP header IPCP header Data :::
IPCP header:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Code Identifier Length
Data :::
8 bits.
Specifies the function to be performed.
Code Description References
0 Vendor Specific. RFC 2153
1 Configure-Request.
2 Configure-Ack.
3 Configure-Nak.
4 Configure-Reject.
5 Terminate-Request.
6 Terminate-Ack.
7 Code-Reject.
Identifier. 8 bits.
Used to match requests and replies.
Length. 16 bits.
Size of the packet including the header.
Data. Variable length.
Zero or more bytes of data as indicated by the Length. This field may contain one or more Options.
Internet Protocol Control Protocol
Configuration Options
IPCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. IPCP uses the same
Configuration Option format defined for LCP Link Control Protocol, with a separate set of Options.
IPCP Configuration Options:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
Option Length
Data :::
Option. 8 bits.
Option Length Description References
1 IP-Addresses (deprecated). RFC 1332
2 >= 14 IP-Compression-Protocol. RFC 1332, RFC 3241, RFC 3544
3 6 IP-Address. RFC 1332
4 6 Mobile-IPv4. RFC 2290
129 6 Primary DNS Server Address. RFC 1877
130 6 Primary NBNS Server Address. RFC 1877
131 6 Secondary DNS Server Address. RFC 1877
132 6 Secondary NBNS Server Address. RFC 1877
Length. 8 bits.
Data. Variable length.
Type Length IP-Compression-Protocol Data
1 byte 1 byte 2 bytes variable
Type Length IP address
1 byte 1 byte 4 bytes
• RFC 1332: The Internet Protocol Control Protocol (IPCP)
• RFC 1570: PPP Link Control Protocol (LCP) Extensions
• RFC 1661: The Point-to-Point Protocol (PPP)
Internet Protocol Suite
Internet Protocol Suite
The Internet Protocol Suite is the set of communications protocols used for the Internet and other similar networks.
It is commonly also known as TCP/IP named from two of the most important protocols in it: the Transmission
Control Protocol (TCP) and the Internet Protocol (IP), which were the first two networking protocols defined in this
standard. Modern IP networking represents a synthesis of several developments that began to evolve in the 1960s
and 1970s, namely the Internet and local area networks, which emerged during the 1980s, together with the advent of
the World Wide Web in the early 1990s.
The Internet Protocol Suite consists of four abstraction layers. From the lowest to the highest layer, these are the
Link Layer, the Internet Layer, the Transport Layer, and the Application Layer.

The layers define the
operational scope or reach of the protocols in each layer, reflected loosely in the layer names. Each layer has
functionality that solves a set of problems relevant in its scope.
The Link Layer contains communication technologies for the local network the host is connected to directly, the link.
It provides the basic connectivity functions interacting with the networking hardware of the computer and the
associated management of interface-to-interface messaging. The Internet Layer provides communication methods
between multiple links of a computer and facilitates the interconnection of networks. As such, this layer establishes
the Internet. It contains primarily the Internet Protocol, which defines the fundamental addressing namespaces,
Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) used to identify and locate hosts on the
network. Direct host-to-host communication tasks are handled in the Transport Layer, which provides a general
framework to transmit data between hosts using protocols like the Transmission Control Protocol and the User
Datagram Protocol (UDP). Finally, the highest-level Application Layer contains all protocols that are defined each
specifically for the functioning of the vast array of data communications services. This layer handles
application-based interaction on a process-to-process level between communicating Internet hosts.
The Internet Protocol Suite resulted from research and development conducted by the Defense Advanced Research
Projects Agency (DARPA) in the early 1970s. After initiating the pioneering ARPANET in 1969, DARPA started
work on a number of other data transmission technologies. In 1972, Robert E. Kahn joined the DARPA Information
Processing Technology Office, where he worked on both satellite packet networks and ground-based radio packet
networks, and recognized the value of being able to communicate across both. In the spring of 1973, Vinton Cerf, the
developer of the existing ARPANET Network Control Program (NCP) protocol, joined Kahn to work on
open-architecture interconnection models with the goal of designing the next protocol generation for the ARPANET.
By the summer of 1973, Kahn and Cerf had worked out a fundamental reformulation, where the differences between
network protocols were hidden by using a common internetwork protocol, and, instead of the network being
responsible for reliability, as in the ARPANET, the hosts became responsible. Cerf credits Hubert Zimmerman and
Louis Pouzin, designer of the CYCLADES network, with important influences on this design.
The design of the network included the recognition that it should provide only the functions of efficiently
transmitting and routing traffic between end nodes and that all other intelligence should be located at the edge of the
network, in the end nodes. Using a simple design, it became possible to connect almost any network to the
ARPANET, irrespective of their local characteristics, thereby solving Kahn's initial problem. One popular expression
is that TCP/IP, the eventual product of Cerf and Kahn's work, will run over "two tin cans and a string."
A computer, called a router, is provided with an interface to each network. It forwards packets back and forth
between them.
Originally a router was called gateway, but the term was changed to avoid confusion with other
types of gateways.
Internet Protocol Suite
The idea was worked out in more detailed form by Cerf's networking research group at Stanford in the 1973–74
period, resulting in the first TCP specification.
The early networking work at Xerox PARC, which produced the
PARC Universal Packet protocol suite, much of which existed around the same period of time, was also a significant
technical influence.
DARPA then contracted with BBN Technologies, Stanford University, and the University College London to
develop operational versions of the protocol on different hardware platforms. Four versions were developed: TCP
v1, TCP v2, a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 — the standard
protocol still in use on the Internet today.
In 1975, a two-network TCP/IP communications test was performed between Stanford and University College
London (UCL). In November, 1977, a three-network TCP/IP test was conducted between sites in the US, UK, and
Norway. Several other TCP/IP prototypes were developed at multiple research centres between 1978 and 1983. The
migration of the ARPANET to TCP/IP was officially completed on flag day January 1, 1983, when the new
protocols were permanently activated.
In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer
In 1985, the Internet Architecture Board held a three day workshop on TCP/IP for the computer
industry, attended by 250 vendor representatives, promoting the protocol and leading to its increasing commercial
Layers in the Internet Protocol Suite
The concept of layers
Instantiations of the TCP/IP stack operating on two hosts each
connected to its router on the Internet. Shown is the flow of user data
through the layers used at each hop.
The Internet Protocol Suite uses encapsulation to
provide abstraction of protocols and services.
Encapsulation is usually aligned with the division of
the protocol suite into layers of general functionality. In
general, an application (the highest level of the model)
uses a set of protocols to send its data down the layers,
being further encapsulated at each level.
According to RFC 1122, the Internet Protocol Suite
organizes the functional groups of protocols and
methods into four layers, the Application Layer, the
Transport Layer, the Internet Layer, and the Link
Layer. This model was not intended to be a rigid
reference model into which new protocols have to fit in
order to be accepted as a standard.
The role of layering in TCP/IP may be illustrated by an
example network scenario (right-hand diagram), in
which two Internet host computers communicate across
local network boundaries constituted by their
internetworking routers. The application on each host
executes read and write operations as if the processes
were directly connected to each other by some kind of
data pipe, every other detail of the communication is hidden from each process. The underlying mechanisms that
transmit data between the host computers are located in the lower protocol layers. The Transport Layer establishes
host-to-host connectivity, meaning it handles the details of data transmission that are independent of the structure of
Internet Protocol Suite
user data and the logistics of exchanging information for any particular specific purpose. The layer simply
establishes a basic data channel that an application uses in its task-specific data exchange. For this purpose the layer
establishes the concept of the port, a numbered logical construct allocated specifically for each of the communication
channels an application needs. For many types of services, these port numbers have been standardized so that client
computers may address specific services of a server computer without the involvement of service announcements or
directory services.
The Transport Layer operates on top of the Internet Layer. The Internet Layer is not only agnostic of application data
structures as the Transport Layer, but it also does not distinguish between operation of the various Transport Layer
protocols. It only provides an unreliable datagram transmission facility between hosts located on potentially different
IP networks by forwarding the Transport Layer datagrams to an appropriate next-hop router for further relaying to its
destination. With this functionality, the Internet Layer makes possible internetworking, the interworking of different
IP networks, and it essentially establishes the Internet. The Internet Protocol is the principal component of the
Internet Layer, and it defines two addressing systems to identify network hosts computers, and to locate them on the
network. The original address system of the ARPANET and its successor, the Internet, is Internet Protocol Version 4
(IPv4). It uses a 32-bit IP address and is therefore capable of identifying approximately four billion hosts. This
limitation was eliminated by the standardization of Internet Protocol Version 6 (IPv6) in 1998, and beginning
production implementations in approximately 2006.
The lowest layer in the Internet Protocol Suite is the Link Layer. It comprises the tasks of specific networking
requirements on the local link, the network segment that a hosts network interface is connected to. This involves
interacting with the hardware-specific functions of network interfaces and specific transmission technologies.
Successive encapsulation of application data descending through the protocol stack
before transmission on the local network link.
As the user data, first manipulated and
structured in the Application Layer, is
passed through the descending layers of the
protocol stack each layer adds encapsulation
information as illustrated in the diagram
(right). A receiving host reverses the
encapsulation at each layer by extracting the
higher level data and passing it up the stack
to the receiving process.
Layer names and number of layers
in the literature
The following table shows the layer names
and the number of layers of networking
models presented in RFCs and textbooks in widespread use in today's university computer networking courses.
Internet Protocol Suite
RFC 1122
Arpanet Reference
Model 1982 (RFC 871)
Four layers
Four layers
Four layers Five layers Four+one layers Five layers Three layers
"TCP/IP reference
"Five-layer Internet
model" or "TCP/IP
protocol suite"
"TCP/IP 5-layer
reference model"
"TCP/IP model" "Arpanet reference model"

Application Application Application Application Application Application/Process
Transport Transport Transport Transport Host-to-host or
Internet Internetwork Network Internet Internet
Host-to-network Network
Data link Data link (Network
Network access Network interface
Physical (Hardware) Physical
These textbooks are secondary sources that may contravene the intent of RFC 1122 and other IETF primary
Different authors have interpreted the RFCs differently regarding the question whether the Link Layer (and the
TCP/IP model) covers Physical Layer issues, or if a hardware layer is assumed below the Link Layer. Some authors
have tried to use other names for the Link Layer, such as network interface layer, in view to avoid confusion with the
Data Link Layer of the seven layer OSI model. Others have attempted to map the Internet Protocol model onto the
OSI Model. The mapping often results in a model with five layers where the Link Layer is split into a Data Link
Layer on top of a Physical Layer. In literature with a bottom-up approach to Internet communication,


which hardware issues are emphasized, those are often discussed in terms of Physical Layer and Data Link Layer.
The Internet Layer is usually directly mapped into the OSI Model's Network Layer, a more general concept of
network functionality. The Transport Layer of the TCP/IP model, sometimes also described as the host-to-host layer,
is mapped to OSI Layer 4 (Transport Layer), sometimes also including aspects of OSI Layer 5 (Session Layer)
functionality. OSI's Application Layer, Presentation Layer, and the remaining functionality of the Session Layer are
collapsed into TCP/IP's Application Layer. The argument is that these OSI layers do usually not exist as separate
processes and protocols in Internet applications.
However, the Internet protocol stack has never been altered by the Internet Engineering Task Force from the four
layers defined in RFC 1122. The IETF makes no effort to follow the OSI model although RFCs sometimes refer to
it. The IETF has repeatedly stated that Internet protocol and architecture development is not intended to be
RFC 3439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".
Internet Protocol Suite
Most computer operating systems in use today, including all consumer-targeted systems, include a TCP/IP
Minimally acceptable implementation includes implementation for (from most essential to the less essential) IP,
ARP, ICMP, UDP, TCP and sometimes IGMP. It is in principle possible to support only one of transport protocols
(i.e. simple UDP), but it is rarely done, as it limits usage of the whole implementation. IPv6, beyond own version of
ARP (NBP), and ICMP (ICMPv6), and IGMP (IGMPv6) have some additional required functionalities, and often is
accompanied with integrated IPSec security layer. Other protocols could be easily added later (often they can be
implemented entirely in the userspace), for example DNS for resolving domain names to IP addresses or DHCP
client for automatic configuration of network interfaces.
Most of the IP implementations are accessible to the programmers using socket abstraction (usable also with other
protocols) and proper API for most of the operations. This interface is known as BSD sockets and was used initially
in C.
Unique implementations include Lightweight TCP/IP, an open source stack designed for embedded systems and
KA9Q NOS, a stack and associated protocols for amateur packet radio systems and personal computers connected
via serial lines.
[1] RFC 1122, Requirements for Internet Hosts -- Communication Layers, R. Braden (ed.), October 1989
[2] RFC 1123, Requirements for Internet Hosts -- Application and Support, R. Braden (ed.), October 1989
[3] RFC 1812, Requirements for IP Version 4 Routers, F. Baker (June 1995)
[4] RFC 675, Specification of Internet Transmission Control Protocol, V. Cerf et al. (December 1974)
[5] Internet History (http:// www.livinginternet. com/ i/ ii.htm)
[6] Ronda Hauben. "From the ARPANET to the Internet" (http:/ / www. columbia.edu/ ~rh120/ other/tcpdigest_paper.txt). TCP Digest
(UUCP). . Retrieved 2007-07-05.
[7] IETF, RFC 1122, p.7, "To communicate using the Internet system, a host must implement the layered set of protocols comprising the Internet
protocol suite. A host typically must implement at least one protocol from each layer."
[8] Mark Dye, Mark A. Dye, Wendell, Network Fundamentals: CCNA Exploration Companion Guide, 2007, ISBN 1-58713-208-7
[9] James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 2008, ISBN 0-321-49770-8 (http:/ / www.
pearsonhighered.com/ educator/ academic/ product/0,,0321497708,00+ en-USS_01DBC. html)
[10] Behrouz A. Forouzan, Data Communications and Networking (http:/ / books.google. com/ books?id=U3Gcf65Pu9IC&
printsec=frontcover&dq=forouzan+"computer+networks"& ei=RPZ9SOCvMofctAO02di0AQ& hl=en&
[11] Douglas E. Comer, Internetworking with TCP/IP: Principles, Protocols and Architecture, Pearson Prentice Hall 2005, ISBN 0-13-187671-6
(http:// books. google. com/ books?id=jonyuTASbWAC& pg=PA155& hl=sv& source=gbs_toc_r& cad=0_0&
[12] Charles M. Kozierok, "The TCP/IP Guide", No Starch Press 2005 (http:// books. google. com/ books?id=Pm4RgYV2w4YC& pg=PA131&
dq="TCP/ IP+model+ layers"& lr=&hl=sv& sig=ACfU3U3ofMwYAbZfGz1BmAXc2oNNFC2b8A#PPA129,M1)
[13] William Stallings, Data and Computer Communications, Prentice Hall 2006, ISBN 0-13-243310-9 (http:// books.google. com/
books?id=c_AWmhkovR0C& pg=PA35& dq="internet+layer"+ "network+access+ layer"& ei=-O99SI3EJo32sgOQpPThDw&hl=en&
[14] IETF, RFC 1122, p.7-8, "The protocol layers [...] are as follows [...]:[...] Application Layer [...] Transport Layer [...] Internet Layer [...] Link
[15] Andrew Tanenbaum, Computer Networks, section 1.4.3, "[...] the OSI model has seven layers and the TCP/IP has four layers."
[16] Tanenbaum, Andrew S. (2002). Computer Networks. Prentice Hall. p. 41. ISBN 0130661023. "1.4.2 The TCP/IP Reference Model" Excerpt
at Google Books (http:/ / books. google. com/ books?id=Pd-z64SJRBAC& pg=PA42& vq=internet+layer&dq=networks& hl=sv&
source=gbs_search_s& sig=ACfU3U3DHANeIz0sOsd5NK4VXSrgNFYVAw#PPA42,M1)
[17] IETF, RFC 1122, p.8, "The application layer is the top layer of the Internet protocol suite."
[18] R. Bush; D. Meyer (December 2002). Some Internet Architectural Guidelines and Philosophy (http:// www. isi. edu/ in-notes/ rfc3439.txt).
Internet Engineering Task Force. . Retrieved 2007-11-20
Internet Protocol Suite
Further reading
• Douglas E. Comer. Internetworking with TCP/IP - Principles, Protocols and Architecture. ISBN 86-7991-142-9
• Joseph G. Davies and Thomas F. Lee. Microsoft Windows Server 2003 TCP/IP Protocols and Services. ISBN
• Forouzan, Behrouz A. (2003). TCP/IP Protocol Suite (2nd ed.). McGraw-Hill. ISBN 0-07-246060-1.
• Craig Hunt TCP/IP Network Administration. O'Reilly (1998) ISBN 1-56592-322-7
• Maufer, Thomas A. (1999). IP Fundamentals. Prentice Hall. ISBN 0-13-975483-0.
• Ian McLean. Windows(R) 2000 TCP/IP Black Book. ISBN 1-57610-687-X
• Ajit Mungale Pro .NET 1.1 Network Programming. ISBN 1-59059-345-6
• W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. ISBN 0-201-63346-9
• W. Richard Stevens and Gary R. Wright. TCP/IP Illustrated, Volume 2: The Implementation. ISBN
• W. Richard Stevens. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain
Protocols. ISBN 0-201-63495-3
• Andrew S. Tanenbaum. Computer Networks. ISBN 0-13-066102-3
• David D. Clark, "The Design Philosophy of the DARPA Internet Protocols" (http:/ / groups.csail. mit. edu/ ana/
Publications/ PubPDFs/ The design philosophy of the DARPA internet protocols. pdf), Computer
Communications Review 18:4, August 1988, pp. 106–114
External links
• Internet History (http:// www. livinginternet.com/ i/ ii. htm) -- Pages on Robert Kahn, Vinton Cerf, and TCP/IP
(reviewed by Cerf and Kahn).
• RFC 675 (http:/ / www. ietf.org/rfc/rfc0675.txt) - Specification of Internet Transmission Control Program,
December 1974 Version
• TCP/IP State Transition Diagram (http:/ / www.night-ray.com/ TCPIP_State_Transition_Diagram.pdf) (PDF)
• RFC 1180 A TCP/IP Tutorial - from the Internet Engineering Task Force (January 1991)
• TCP/IP FAQ (http:/ / www. itprc.com/ tcpipfaq/)
• TCP/IP Resources List (http:/ / www. private.org. il/tcpip_rl. html)
• The TCP/IP Guide (http:/ / www. tcpipguide. com/ free/) - A comprehensive look at the protocols and the
procedures/processes involved
• A Study of the ARPANET TCP/IP Digest (http:/ / www.columbia. edu/ ~rh120/other/tcpdigest_paper. txt)
• TCP/IP Sequence Diagrams (http:/ / www. eventhelix. com/ RealtimeMantra/ Networking/ )
• The Internet in Practice (http:// www. searchandgo. com/ articles/ internet/ internet-practice-4.php)
• TCP/IP - Directory & Informational Resource (http:/ / softtechinfo.com/ network/tcpip. html)
• Daryl's TCP/IP Primer (http:/ / www. ipprimer.com) - Intro to TCP/IP LAN administration, conversational style
• Introduction to TCP/IP (http:/ / www. linux-tutorial.info/ MContent-142)
• TCP/IP commands from command prompt (http:/ / blog. webgk.com/ 2007/ 10/
• cIPS (http:/ / sourceforge.net/ projects/ cipsuite/ ) — Robust TCP/IP stack for embedded devices without an
Operating System
Multipurpose Transaction Protocol
Multipurpose Transaction Protocol
Multipurpose Transaction Protocol software is a proprietary transport protocol (OSI Layer 4) developed and
marketed by Data Expedition, Inc. (DEI). DEI claims that MTP offers superior performance and reliability when
compared to the Transmission Control Protocol (TCP) transport protocol.

MTP is implemented using the User Datagram Protocol (UDP) packet format. It uses proprietary flow-control and
error-correction algorithms to achieve reliable delivery of data and avoid network flooding.
Because MTP/IP uses proprietary algorithms, compatible software must be installed on both ends of a
communication path. Use of the UDP packet format permits compatibility with standard Internet Protocol (IP)
network hardware and software. MTP/IP applications may use any available UDP port number.
MTP and the applications which use it have been implemented for several operating systems, including versions of
Microsoft Windows, Mac OS X, Linux, NetBSD, FreeBSD, Solaris, IRIX, HP-UX, AIX, and Android. Hardware
platforms include variations of x86, PowerPC, UltraSPARC, MIPS64, PA-RISC, Itanium, POWER, and ARM.
MTP/IP is marketed by Data Expedition, Inc. Trial versions of applications which use MTP/IP are available on the
company's website.
[1] "A New Data Transport Model" (http:/ / www.embeddedtechmag. com/ component/ content/ article/6177/ ). Embedded Technology
Magazine. July 2008. .
[2] Data Expedition MTP page (http:// www.DataExpedition.com/ MTP/ )
External links
• Network World (http:// www. networkworld.com/ newsletters/ accel/ 2007/ 0108netop2. html) -- "Start-up
proposes alternative to TCP", January 2007
• Network World (http:/ / www. networkworld.com/ newsletters/ accel/ 2007/ 0115netop2. html) -- "Time for new
TCP? Readers respond", January 2007
• Network Performance Daily (http:// www. networkperformancedaily.com/ 2007/01/
proprietary_mtp_an_alternative. html) -- "Proprietary MTP: an alternative to TCP?", January 2007
• Enterprise IT Planet (http:// products. enterpriseitplanet. com/ networking/nos/ 1087415685.html) -- "MTP/IP",
August 2007
• US Patent 7158479 (http:/ / patft.uspto. gov/ netacgi/ nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/
netahtml/ PTO/search-bool. html& r=1&f=G&l=50& d=PALL&RefSrch=yes&Query=PN/7158479)
• US Patent 7313627 (http:/ / patft.uspto. gov/ netacgi/ nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/
netahtml/ PTO/search-bool. html& r=1&f=G&l=50& d=PALL&RefSrch=yes&Query=PN/7313627)
• US Patent 7404003 (http:/ / patft.uspto. gov/ netacgi/ nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/
netahtml/ PTO/search-bool. html& r=1&f=G&l=50& d=PALL&RefSrch=yes&Query=PN/7404003)
• US Patent 7630315 (http:/ / patft.uspto. gov/ netacgi/ nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/
netahtml/ PTO/search-bool. html& r=1&f=G& l=50& d=PALL&RefSrch=yes&Query=PN/7630315)
Transport Sample Protocol
Transport Sample Protocol
Transport Sample Protocol (TSP) is an open source network protocol for sampling data. It is based on TCP/IP and
allows synchronous or asynchronous sample delivery.
Implementations for Linux, Windows, Solaris, OSF1 and VxWorks in C and Java have been released under the GNU
Lesser General Public License (LGPL).
TSP was developed for use in satellite validation benches.
[1] (http:// savannah. nongnu. org/projects/ tsp/ ), Transport Sample Protocol - Summary
External links
• TSP project at Savannah (http:// savannah. nongnu.org/projects/ tsp)
Internet Streaming Media Alliance
The Internet Streaming Media Alliance (ISMA) was Founded in December 2000, by Apple Computer, Cisco
Systems, IBM, Kasenna, Philips, and Sun Microsystems. It is a non-profit corporation whose mission is to accelerate
the market adoption of open standards for streaming and progressive download of rich media over all types of
Internet Protocols (IP). The ISMA is a diverse alliance with representatives from all points of the streaming
While standards already exist for audio and video codecs (e.g. MPEG) and for real time streaming transport over IP
networks (e.g. RTP) putting these together requires selecting profiles, describing payload formats, and resolving
various options. ISMA specifications typically adopt existing specifications in order to form a complete solution.
However, when specifications don't exist, the ISMA will create them. The ISMA also performs interoperability
testing, allowing its members to ensure that their products conform to ISMA standards and interoperate.
The ISMA has released several specifications for the transport of rich media over IP:
• ISMA 1.0 - details how to stream MPEG-4 Part 2 video (Simple Profile and Advanced Simple Profile) over IP
• ISMA 2.0 - details how to stream H.264/MPEG-4 AVC video and HE-AAC audio over IP networks.
• ISMACryp - specifies an end-to-end encryption system for ISMA 1.0 and 2.0 streams.
• ISMA Closed Captioning - specifies how to carry closed caption (line 21) data as a third stream over IP network.
Current work in the ISMA focuses on enabling advanced IPTV systems and creating specifications for transport and
presentation of rich media in enterprises.
Internet Streaming Media Alliance
External links
• ISMA Official Website
[1] http:/ / www. isma. tv/
IP Flow Information Export
Internet Protocol Flow Information Export (IPFIX) is an IETF working group. It was created from the need for a
common, universal standard of export for Internet Protocol flow information from routers, probes, and other devices
that is used by mediation systems, accounting/billing systems, and network management systems to facilitate
services such as measurement, accounting, and billing. The IPFIX standard will define how IP flow information is to
be formatted and transferred from an exporter to a collector. Previously many data network operators were relying on
the proprietary Cisco Systems Netflow standard for traffic flow information export.
The IPFIX standards requirements were outlined in the original RFC 3917. The working group chose Cisco Netflow
Version 9 as the basis for IPFIX. The working group submitted the IPFIX Protocol Specification to the IESG for
approval in 2006.
The following figure shows a typical architecture of information flow in an IPFIX architecture:
Exporter IPFIX Collector
| Observation Point
---- IP Traffic --->
A Metering Process collects data packets at an Observation Point, optionally filters them and aggregates
information about these packets. Using the IPFIX protocol, an Exporter then sends this information to a Collector.
Exporters and Collectors are in a many-to-many relationship: One Exporter can send data to many Collectors and
one Collector can receive data from many Exporters.
Similar to the Netflow Protocol, IPFIX considers a flow to be any number of packets observed in a specific timeslot
and sharing a number of properties, e.g. "same source, same destination, same protocol". Using IPFIX, devices
like routers can inform a central monitoring station about their view of a potentially larger network.
IPFIX is a push protocol, i.e. each sender will periodically send IPFIX messages to configured receivers without
any interaction by the receiver.
The actual makeup of data in IPFIX messages is to a great extent up to the sender. IPFIX introduces the makeup of
these messages to the receiver with the help of special Templates. The sender is also free to use user-defined data
types in its messages, so the protocol is freely extensible and can adapt to different scenarios.
IPFIX prefers the Stream Control Transmission Protocol as its transport layer protocol, but also allows the use of the
Transmission Control Protocol or User Datagram Protocol.
IP Flow Information Export
A simple information set sent via IPFIX might look like this:
Source Destination Packets
------------------------------------------ 235 42
This information set would be sent in the following IPFIX message:
Bits 0..15 Bits 16..31
Version = 0x000a Message Length = 64 Bytes
Export Timestamp = 2005-12-31 23:59:60
Sequence Number = 0
Observation Domain ID = 12345678
Set ID = 2 (Template) Set Length = 20 Bytes
Template ID = 256 Number of Fields = 3
Typ = sourceIPv4Address Field Length = 4 Bytes
Typ = destinationIPv4Address Field Length = 4 Bytes
Typ = packetDeltaCount Field Length = 4 Bytes
Set ID = 256 (Data Set
using Template 256)
Set Length = 28 Bytes
Record 1, Field 1 =
Record 1, Field 2 =
Record 1, Field 3 = 235 Packets
Record 2, Field 1 =
Record 2, Field 2 =
Record 2, Field 3 = 42 Packets
As can be seen, the message contains the IPFIX header and two IPFIX Sets: One Template Set that introduces the
build-up of the Data Set used, as well as one Data Set, which contains the actual data. Because the Template Set is
buffered in Collectors it will not need to be transmitted in subsequent messages.
External links
• IPFIX Status Pages
• IETF IPFIX Charter
• Network World IPFIX Introduction
[1] http:/ / tools. ietf.org/wg/ ipfix/
[2] http:// www. ietf.org/ html. charters/ipfix-charter.html
[3] http:/ / www. networkworld.com/ news/ tech/ 2003/ 0811techupdate.html
IP Managed VAS
IP Managed VAS
IP Managed VAS (value added service) is a relatively new term in the area of telecommunications. It refers to a
wide range of managed services offered by a telecom service provider. Such services are typically managed at the
core of the telecom network and are different from IP VAS services, which are offered as part of Internet access
IP multicast
IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single
transmission. It is often employed for streaming media applications on the Internet and private networks. The
method is the IP-specific version of the general concept of multicast networking. It uses specially reserved multicast
address blocks in IPv4 and IPv6. In IPv6, IP multicast addressing replaces broadcast addressing as implemented in
Technical description
IP multicast is a technique for one-to-many and many-to-many real-time communication over an IP infrastructure in
a network. It scales to a larger receiver population by not requiring prior knowledge of who or how many receivers
there are. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if
it needs to be delivered to a large number of receivers. The nodes in the network (typically network switches and
routers) take care of replicating the packet to reach multiple receivers such that messages are sent over each link of
the network only once. The most common low-level protocol to use multicast addressing is User Datagram Protocol
(UDP). By its nature, UDP is not reliable—messages may be lost or delivered out of order. Reliable multicast
protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission
on top of IP multicast.
Key concepts in IP multicast include an IP multicast group address,
a multicast distribution tree and receiver
driven tree creation.
An IP multicast group address is used by sources and the receivers to send and receive multicast messages. Sources
use the group address as the IP destination address in their data packets. Receivers use this group address to inform
the network that they are interested in receiving packets sent to that group. For example, if some content is
associated with group, the source will send data packets destined to Receivers for that
content will inform the network that they are interested in receiving data packets sent to the group The
receiver joins The protocol typically used by receivers to join a group is called the Internet Group
Management Protocol (IGMP).
With routing protocols based on shared trees, once the receivers join a particular IP multicast group, a multicast
distribution tree is constructed for that group. The protocol most widely used for this is Protocol Independent
Multicast (PIM). It sets up multicast distribution trees such that data packets from senders to a multicast group reach
all receivers which have joined the group. For example, all data packets sent to the group are received
by receivers who joined There are variations of PIM implementations: Sparse Mode (SM), Dense
Mode (DM), Source Specific Mode (SSM) and Bidirectional Mode (Bidir, or Sparse-Dense Mode, SDM). Of these,
PIM-SM is the most widely deployed as of 2006; SSM and Bidir are simpler and scalable variations developed more
recently and are gaining in popularity.
IP multicast operation does not require an active source to know about the receivers of the group. The multicast tree
construction is receiver driven and is initiated by network nodes which are close to the receivers. IP multicast scales
IP multicast
to a large receiver population. The IP multicast model has been described by Internet architect Dave Clark as, "You
put packets in at one end, and the network conspires to deliver them to anyone who asks."
IP multicast creates state information per multicast distribution tree in the network. If a router is part of 1000
multicast trees, it has 1000 multicast routing and forwarding entries. On the other hand, a multicast router does not
need to know how to reach all other multicast trees in the Internet. It only needs to know about multicast trees for
which it has downstream receivers. This is key to scaling multicast-addressed services. It is very unlikely that core
Internet routers would need to keep state for all multicast distribution trees, they only need to keep state for trees
with downstream membership. In contrast, a unicast router needs to know how to reach all other unicast addresses in
the Internet, even if it does this using just a default route. For this reason, aggregation is key to scaling unicast
routing. Also, there are core routers that carry routes in the hundreds of thousands because they contain the Internet
routing table.
There are four forms of IP addressing, each with its own unique properties.
• Unicast: The most common concept of an IP address is in unicast addressing, available in both IPv4 and IPv6. It
normally refers to a single sender or a single receiver, and can be used for both sending and receiving. Usually, a
unicast address is associated with a single device or host, but it is not a one-to-one correspondence. Some
individual PCs have several distinct unicast addresses, each for its own distinct purpose. Sending the same data to
multiple unicast addresses requires the sender to send all the data many times over, once for each recipient.
• Broadcast: In IPv4 it is possible to send data to all possible destinations ("all-hosts broadcast"), which permits the
sender to send the data only once, and all receivers receive a copy of it. In the IPv4 protocol, the address is used for local broadcast. In addition, a directed (limited) broadcast can be made by
combining the network prefix with a host suffix composed entirely of binary 1s. For example, the destination
address used for a directed broadcast to devices on the network is IPv6 does
not implement broadcast addressing and replaces it with multicast to the specially-defined all-nodes multicast
• Multicast: A multicast address is associated with a group of interested receivers. In IPv4, addresses
through (the former Class D addresses) are designated as multicast addresses.
sender sends a single datagram from its unicast address to the multicast group address and the intermediary
routers take care of making copies and sending them to all receivers that have joined the corresponding multicast
group. IPv6 uses the address block with the prefix ff00::/8 for multicast applications.
• Anycast: Like broadcast and multicast, anycast is a one-to-many routing topology. However, the data stream is
not transmitted to all receivers, just the one which the router decides is the "closest" in the network.
Anycast is
useful for global load balancing and is commonly used in DNS communications.
Protocols and applications
IP multicast is widely deployed in enterprises, commercial stock exchanges, and multimedia content delivery
networks. A common use of IP multicast is for IPTV.
Since multicast is a different transmission mode from unicast, only protocols designed for multicast can be sensibly
used with multicast.
Most of the existing application protocols that use multicast run on top of the User Datagram Protocol (UDP). In
many applications, the Real-time Transport Protocol (RTP) is used for framing of multimedia content over multicast;
the Resource Reservation Protocol (RSVP) may be used for bandwidth reservation in a network supporting multicast
IP multicast
On the local network, multicast delivery is controlled by IGMP (on IPv4 network) and MLD (on IPv6 network);
inside a routing domain, PIM or MOSPF are used; between routing domains, one uses inter-domain multicast routing
protocols, such as MBGP.
A number of errors can happen if packets intended for unicast are accidentally sent to a multicast address; in
particular, sending ICMP packets to a multicast address has been used in the context of DoS attacks as a way of
achieving packet amplification.
IP multicast protocols
• Internet Group Management Protocol (IGMP)
• Protocol Independent Multicast (PIM)
• Distance Vector Multicast Routing Protocol (DVMRP)
• Multicast Open Shortest Path First (MOSPF)
• Multicast BGP (MBGP)
• Multicast Source Discovery Protocol (MSDP)
• Multicast Listener Discovery (MLD)
• GARP Multicast Registration Protocol (GMRP)
• Multicast DNS (mDNS)
IP multicast addressing
IPv4 multicast address assignments are not delegated to a regional Internet registry, but addresses are assigned
directly by IANA
, as outlined in the guidelines of RFC 5771.
The IPv4 address space used for multicast falls into the former class D (224/4) range defined in the classful network
model of the early Internet.
IANA generally assigns addresses from three blocks in this range.
• The block is the Local Network Control block. It is used for local subnetwork multicast traffic
that does not extend beyond a link. Packets with these addresses should be dropped by routers. An example use of
this range is for Open Shortest Path First (OSPF) IGP all routers addressing (
• The range is the Internetwork Control Block. It used for traffic that must be routed through the
public Internet, such as for applications of the Network Time Protocol (
• The range to, called the AD-HOC block, is globally routed and is used
for applications that don't fit either of the previously described purposes.
Other blocks are the source-specific multicast range (, the GLOP addressing range
( and the Unicast-Prefix-Based IPv4 Multicast Addresses (
The range is assigned by RFC 2365 as a locally administered address space with local, site, or
organizational scope. It may be used by anyone, without concern for address collisions, for private multicast
domains, similar in role as the RFC 1918 private IP space. The Simple Service Discovery Protocol (SSDP) uses an
address in this space in support of its role in Universal Plug and Play (UPnP) networking.
For IPv6 multicast addressing, the address block with the prefix ff00::/8 is reserved by RFC 4291. Addresses
have the following format:
8 4 4 112 bits
11111111 flags scope group identification
The scope field defines the range of operation of the application, and ranges from interface-local, to globally routable
IP multicast
Each host (and in fact each application on the host) that wants to be a receiving member of a multicast group (i.e.
receive data corresponding to a particular multicast address) must use the Internet Group Management Protocol
(IGMP) to join. Adjacent routers also use this protocol to communicate.
In unicast routing, each router examines the destination address of an incoming packet and looks up the destination
in a table to determine which interface to use in order for that packet to get closer to its destination. The source
address is irrelevant to the router.
However, in multicast routing, the source address (which is a simple unicast address) is used to determine data
stream direction. The source of the multicast traffic is considered upstream. The router determines which
downstream interfaces are destinations for this multicast group (the destination address), and sends the packet out
through the appropriate interfaces. The term reverse path forwarding is used to describe this concept of routing
packets away from the source, rather than towards the destination.
Layer 2 delivery
Unicast packets are delivered to a specific recipient on an Ethernet or IEEE 802.3 subnet by setting a specific layer 2
MAC address on the Ethernet packet address. Broadcast packets make use of a broadcast MAC address
(FF:FF:FF:FF:FF:FF), which includes setting the broadcast/multicast bit in the address. The IANA owns the OUI
MAC address 01:00:5e, therefore multicast packets are delivered by using the Ethernet MAC address range
01:00:5e:00:00:00 - 01:00:5e:7f:ff:ff. This is 23 bits of available address space. The first octet (01) includes the
broadcast/multicast bit. The lower 23 bits of the 28-bit multicast IP address are mapped into the 23 bits of available
Ethernet address space. This means that there is ambiguity in delivering packets. If two hosts on the same subnet
each subscribe to a different multicast group whose address differs only in the first 5 bits, Ethernet packets for both
multicast groups will be delivered to both hosts, requiring the network software in the hosts to discard the unrequired
For IPv6 Multicast addresses, the Ethernet MAC is derived by the four low-order octets OR'ed with the MAC
33:33:00:00:00:00, so for example the IPv6 address FF02:DEAD:BEEF::1:3 would map to the Ethernet MAC
address 33:33:00:01:00:03
Switches that do not understand multicast addresses broadcast traffic sent to a multicast group to all the members of
a LAN; in this case the system's network card (or operating system) has to filter the packets sent to multicast groups
they are not subscribed to.
There are switches that listen to IGMP traffic and maintain a state table of which network systems are subscribed to
a given multicast group. This table is then used to forward traffic destined to a given group only to a limited set of
hosts (ports). This is done through the use of IGMP snooping.
Additionally, some switches with layer 3 capabilities can act as an IGMP querier
. In networks where there is no
router present to act as a multicast router a switch with IGMP snooping enabled can be used to generate the needed
IGMP messages to get users to subscribe to multicast traffic.
IP multicast
Reliable multicast
Multicast, by its very nature, is not a connection-oriented mechanism, so protocols such as TCP, which allows for
retransmission of missing packets, are not appropriate. For applications such as streaming audio and video, the
occasional dropped packet is not a problem. But for distribution of critical data, a mechanism is required for
requesting retransmission.
One such scheme, proposed by Cisco, is PGM (originally Pretty Good Multicasting, but changed for trademark
reasons to Pragmatic General Multicast), documented in RFC 3208. In this scheme, multicast packets have sequence
numbers and when a packet is missed a recipient can request that the packet be re-multicast with other members of
the Multicast group ignoring the replacement data if not needed. An expanded version, PGM-CC, has attempted to
make IP Multicasting more "TCP friendly" by stepping the entire group down to the bandwidth available by the
worst receiver.
Two other schemes documented by the Internet Engineering Task Force (IETF) are NACK-Oriented Reliable
Multicast (NORM), documented in RFC 3940 and RFC 5401, and File Delivery over Unidirectional Transport
(FLUTE), documented in RFC 3926. Open-source, in addition to proprietary, implementations exist for these. Other
such protocols exist, such as Scalable Reliable Multicast, and are defined by a variety of sources. Such protocols
vary in the means of error detection, the mechanisms used in error recovery, the scalability of such recovery and the
underlying ideas involved in what it means to be reliable. A list of reliable multicast protocols from the ACM
SIGCOMM Multicast Workshop, August 27, 1996, documents a number of approaches to the problem.
Independent groups like the Internet Protocol Multicast Standards Initiative (IPMSI) have claimed that the lack of a
truly scalable Secure Reliable IP Multicast protocol like the proposed Secure Multicast for Advanced Repeating of
Television (SMART) have hampered the adoption of IP Multicast in inter-domain routing. The lack of a widely
adopted system that has AES level security and scalable reliability have kept mass media transmissions of sporting
events (like the Super Bowl) and/or breaking news events from being transmitted on the Public Internet.
Reliable IP Multicasting protocols, such as PGM and SMART, are experimental; the only standards-track protocol is
NORM (the standards-track revision of RFC 3941 is specified in RFC 5401, the standards-track revision of RFC
3940 is specified in RFC 5740).
Wireless (802.11) considerations
An 802.11 wireless network will handle multicast traffic differently, depending on the configuration of 802.11
power-save mode, DTIM (Delivery Traffic Indication Message), and beacon interval settings. If power-save mode is
disabled, then access points will deliver multicast traffic after each beacon (default interval = 100ms, but it can be
adjusted). If power-save mode is enabled, the access point will deliver multicast traffic after each DTIM, which by
default is every 1, 2, or 3 beacon intervals in most access points. As a result, the DTIM and beacon interval settings
should be adjusted for optimum performance when implementing multicast in wireless networks.
Pay-TV operators and some educational institutions with significant on-campus student housing have deployed IP
multicast to deliver one-way streaming media such as high-speed video to large groups of receivers. Additionally,
there have been some uses of audio and video conferencing using multicast technologies. These are far less prevalent
and are most often relegated to research and education institutions, which often have a greater degree of network
capacity to handle the demands. Some technical conferences and meetings are transmitted using IP multicast. Until
recently many of the sessions at the IETF meetings were delivered using multicast.
Another use of multicast within campus and commercial networks is for file distribution, particularly to deliver
operating system images and updates to remote hosts. The key advantage of multicast boot images over unicasting
boot images is significantly lower network bandwidth usage.
IP multicast
IP multicast has also seen deployment within the financial sector for applications such as stock tickers and
hoot-n-holler systems.
While IP multicast has seen some success in each of these areas, IP multicast is not widely deployed and is generally
not available as a service for the average end user. There are at least two primary factors for the lack of widespread
deployment, both somewhat related to the other. On the one hand, forwarding multicast traffic, particularly for
two-way communication, requires a great deal of protocol complexity. On the other hand, there are a number of
additional operational concerns in being able to run a multicast network successfully, largely stemming from the
complexity of a widely-deployed implementation, not the least of which is the enabling of additional avenues of
failure, particularly from denial-of-service attacks. Many of these issues are covered in further detail below.
RFC 3170 (IP Multicast Applications: Challenges & Solutions) provides an overview of deployment issues.
History and milestones
IP multicasting was first developed by Steve Deering while at Stanford University for which he received the IEEE
Internet Award
The MBONE was a long-running experimental approach to enabling multicast between sites through the use of
tunnels. While the MBONE is no longer operational, there is renewed interest in tunneling multicast traffic once
again in order to make the service available to a wide array of end users.
IP multicast software
• Media Tools Repository
- a collection of tools for the MBone
• VideoLAN - a free software multicasted video streaming application
• Xorp
- a free software router with multicast (IGMP, PIM) support
• Smcroute
- a simple tool to manipulate multicast routes on the Linux kernel
• SSM-ping
- tool to test multicast connectivity
• Host implementation of IGMPv3 on FreeBSD
• IP multicast software from Xerox
• Java Reliable Multicast Service
• PIM implementation
- an implementation of the PIM protocol, now obsolete
• qpimd - PIM Daemon for Quagga
- PIM module for the Quagga Routing Suite
• GateD
- UNIX implementation of routing protocols, including multicast
• PIM-DM code for GateD
- Nack-Oriented Reliable Multicast from the U.S. Naval Research Laboratory, with an open source
C++ implementation
• ecmh (Easy Cast du Multi Hub)
- IPv6 Multicast Daemon, allows IPv6 multicast to be used without the need
for PIM.
• MRD6 - Ipv6 multicast routing daemon
• UFTP - Encrypted UDP based FTP with multicast
• GStreamer - a free software multimedia framework that supports multicast video streaming
IP multicast
[1] RFC 3171
[2] RFC 3171
[3] Anycast implementations typically operate using the shortest-path metric of BGP routing and not take into account congestion or other
attributes of the path.
[4] RFC 3171, IANA IPv4 Multicast Guidelines (BCP, August 2001)
[5] RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (February 2006, Standards Track)
[6] RFC 2464
[7] eg. Cisco SLM 2008
[8] "802.11 Multicasting" (http:/ / www.wireless-nets. com/ resources/ tutorials/ 802.11_multicasting. html). . Retrieved 2008-10-08.
[9] Speakerbus, a IP Hoot-n-Holler Provider (http:// www.speakerbus. com)
[10] IEEE Internet Award recipients (http:// www.ieee. org/ documents/ internet_rl.pdf)
[11] http:/ / mediatools. cs. ucl. ac. uk/ nets/ mmedia/
[12] http:// www. xorp.org
[13] http:/ / alioth.debian. org/projects/ smcroute/
[14] http:// www. venaas. no/ multicast/ ssmping/
[15] http:/ / www. kloosterhof.com/ ~wilbert/ igmpv3. html
[16] ftp:/ / parcftp.xerox. com/ pub/ net-research/ipmulti/
[17] http:/ / www. experimentalstuff.com/ Technologies/ JRMS/ index.html
[18] http:// netweb. usc. edu/ pim/
[19] http:// www. nongnu. org/qpimd/
[20] http:// www. nexthop. com/ products/ gated. html
[21] http:/ / www. antc. uoregon. edu/ GATED/
[22] http:// cs. itd. nrl.navy. mil/ work/norm/ index. php
[23] http:// unfix.org/ projects/ ecmh/
External links
• RFC3170 - IP Multicast Applications: Challenges & Solutions (http:/ / www.faqs.org/rfcs/rfc3170.html)
• Multicast over TCP/IP HOWTO (http://www. tldp. org/HOWTO/Multicast-HOWTO. html), describes
Multicast in the Linux kernel, although some sections (specially multicast programs) is outdated and does not
cover recent software.
• IETF Reliable Multicast Transport (rmt) Working Group (http:// ietf.org/ html.charters/ rmt-charter.html)
• IETF Multicast & Anycast Group Membership (magma) Working Group (http:/ / ietf. org/html. charters/
magma-charter. html)
• IETF Protocol Independent Multicast (pim) Working Group (http:// ietf.org/ html.charters/ pim-charter.html)
• IETF Source-Specific Multicast (ssm) Working Group (http:/ / ietf.org/html. charters/ ssm-charter.html)
• IETF Multicast Security (msec) Working Group (http:/ / ietf.org/html. charters/msec-charter.html)
• Multicast IP details at sockets.com (http:/ / www.sockets. com/ ch16. htm#Multicast)
• IP-Ethernet multicast (http:// www. firewall.cx/ multicast-intro.php) tutorial.
• Good illustrative video about IP Multicast (http:/ / www.cisco. com/ en/ US/ products/ ps6552/
products_ios_technology_home. html) at Cisco.
• Overview of Reliable Multicast methods, ACM SIGCOMM Multicast Workshop, August 27, 1996 (http:/ /
www-net.cs. umass. edu/ sigcomm_mcast/ talk1.html)
• A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing (the paper defining
Scalable Reliable Multicast) (http:// www. icir.org/floyd/ srm-paper.html)
• "Frequently Asked Questions (FAQ) File for Multicasting" (http:/ / www.multicasttech. com/ faq/). Multicast
Tech. Retrieved 2010-11-18.
IPFC stands for Internet Protocol over Fibre Channel
External links
• RFC 2625 - IP and ARP over Fibre Channel (obsolete)
• RFC 3831 - Transmission of IPv6 Packets over Fibre Channel (obsolete)
• RFC 4338 - Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by
authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for
establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic
keys to be used during the session.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite. It can be used in
protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways
(network-to-network), or between a security gateway and a host (network-to-host).
Some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL), Transport Layer
Security (TLS) and Secure Shell (SSH), operate in the upper layers of the TCP/IP model. Hence, IPsec protects any
application traffic across an IP network. Applications do not need to be specifically designed to use IPsec. The use of
TLS/SSL, on the other hand, must be designed into an application to protect the application protocols.
IPsec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was based on the SP3
protocol that was published by NIST, but designed by the Secure Data Network System project of the National
Security Agency (NSA).
IPsec is officially specified by the Internet Engineering Task Force (IETF) in a series of Request for Comment
documents addressing various components and extensions. It specifies the spelling of the protocol name to be
Security architecture
The IPsec suite is an open standard. IPsec uses the following protocols to perform various functions:

• Authentication Headers (AH) provide connectionless integrity and data origin authentication for IP datagrams and
provides protection against replay attacks.

• Encapsulating Security Payloads (ESP) provide confidentiality, data origin authentication, connectionless
integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.
• Security Associations (SA) provide the bundle of algorithms and data that provide the parameters necessary to
operate the AH and/or ESP operations. The Internet Security Association and Key Management Protocol
(ISAKMP) provides a framework for authentication and key exchange,
with actual authenticated keying
material provided either by manual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2),
Kerberized Internet Negotiation of Keys (KINK), or IPSECKEY DNS records.



Authentication Header
Authentication Header (AH) is a member of the IPsec protocol suite. AH guarantees connectionless integrity and
data origin authentication of IP packets. Further, it can optionally protect against replay attacks by using the sliding
window technique and discarding old packets (see below).
• In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e.
those that might be altered in transit). Mutable (and therefore unauthenticated) IP header fields are DSCP/TOS,
ECN, Flags, Fragment Offset, TTL and Header Checksum.
• In IPv6, the AH protects the AH itself, the Destination Options extension header after the AH, and the IP payload.
It also protects the fixed IPv6 header and all extension headers before the AH, except for the mutable fields:
DSCP, ECN, Flow Label, and Hop Limit.
AH operates directly on top of IP, using IP protocol number 51.
The following AH packet diagram shows how an AH packet is constructed and interpreted:

Authentication Header format
Offsets Octet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header Payload Len Reserved
4 32 Security Parameters Index (SPI)
8 64 Sequence Number
C 96 Integrity Check Value (ICV)

… …
Next Header (8 bits)
Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list of
IP protocol numbers.
Payload Len (8 bits)
The length of this Authentication Header in 4-octet units, minus 2 (a value of 0 means 8 octets, 1 means 12
octets, etcetera). Although the size is measured in 4-octet units, the length of this header needs to be a multiple
of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in
an IPv4 packet.
Reserved (16 bits)
Reserved for future use (all zeroes until then).
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the security association of the
sending party.
Sequence Number (32 bits)
A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay
attacks. When replay detection is enabled, sequence numbers are never reused because a new security
association must be renegotiated before an attempt to increment the sequence number beyond its maximum
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a
4-octet boundary for IPv4.
Encapsulating Security Payload
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin
authenticity, integrity, and confidentiality protection of packets. ESP also supports encryption-only and
authentication-only configurations, but using encryption without authentication is strongly discouraged because it is


Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and
authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated
with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header)
while the outer header remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.
The following ESP packet diagram shows how an ESP packet is constructed and interpreted:

Encapsulating Security Payload format
Offsets Octet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Security Parameters Index (SPI)
4 32 Sequence Number
8 64 Payload data
… …
… …
… … Padding (0-255 octets)
… … Pad Length Next Header
… … Integrity Check Value (ICV)

… …
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the source IP address) to identify the security association of the
sending party.
Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against
replay attacks. There is a separate counter kept for every security association.
Payload data (variable)
The protected contents of the original IP packet, including any data used to protect the contents (e.g. an
Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by
the Next Header field.
Padding (0-255 octets)
Padding for encryption, to extend the payload data to a size that fits the encryption's cypher block size, and to
align the next field.
Pad Length (8 bits)
Size of the padding in octets.
Next Header (8 bits)
Type of the next header. The value is taken from the list of IP protocol numbers.
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a
4-octet boundary for IPv4.
Security association
The IP security architecture uses the concept of a security association as the basis for building security functions into
IP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used to
encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are
secured by a pair of security associations.
Security associations are established using the Internet Security Association and Key Management Protocol
(ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKE
and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records.


In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index
(SPI), an index to the security association database (SADB), along with the destination address in a packet header,
which together uniquely identify a security association for that packet. A similar procedure is performed for an
incoming packet, where IPsec gathers decryption and verification keys from the security association database.
For multicast, a security association is provided for the group, and is duplicated across all authorized receivers of the
group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple
levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing
authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant
standard does not describe how the association is chosen and duplicated across the group; it is assumed that a
responsible party will have made the choice.
Modes of operation
IPsec can be implemented in a host-to-host transport mode, as well as in a network tunnel mode.
Transport mode
In transport mode, only the payload (the data you transfer) of the IP packet is usually encrypted and/or authenticated.
The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header
is used, the IP addresses cannot be translated, as this will invalidate the hash value. The transport and application
layers are always secured by hash, so they cannot be modified in any way (for example by translating the port
numbers). Transport mode is used for host-to-host communications.
A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the
NAT-T mechanism.
Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP packet
with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network
communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access), and
host-to-host communications (e.g. private chat).
Tunnel mode supports NAT traversal.
Cryptographic algorithms
Cryptographic algorithms defined for use with IPsec include:
• HMAC-SHA1 for integrity protection and authenticity.
• TripleDES-CBC for confidentiality
• AES-CBC for confidentiality.
Refer to RFC 4835 for details.
Software implementations
IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE negotiation carried out
from user-space. Existing IPsec implementations often include both.
There exist a number of implementations of IPsec and ISAKMP/IKE protocols. These include:
IPsec, one of the original sources of IPsec code.
• OpenBSD, with its own code derived from a BSD/OS implementation written by John Ioannidis and Angelos D.
Keromytis in 1996.
• The KAME stack, that is included in Mac OS X, NetBSD and FreeBSD.
• "IPsec" in Juniper Operating Systems
• "IPsec" in Cisco IOS Software
• "IPsec" in Microsoft Windows, including Windows XP,

Windows 2000,
Windows 2003,
Vista, Windows Server 2008,
and Windows 7.
• IPsec in Windows Vista and later
• Authentec QuickSec toolkits
• IPsec in Solaris
• IBM AIX operating system
• IBM z/OS
• IPsec and IKE in HP-UX (HP-UX IPsec)
• The Linux IPsec stack written by Alexey Kuznetsov and David S. Miller.
• Openswan on Linux, FreeBSD and Mac OS X using the native Linux IPsec stack, or its own KLIPS stack. KLIPS
offers hardware acceleration and SAref tracking.
• strongSwan on Linux, FreeBSD, Mac OS X, and Android using the native IPsec stack.
Standards status
IPsec was developed in conjunction with IPv6 and is therefore mandatory in all standards-compliant
implementations of IPv6,
but its implementation is an optional extension to IPv4. However, because of the slow
deployment of IPv6, IPsec is most commonly used to secure IPv4 traffic. IPsec protocols were originally defined in
RFC 1825 and RFC 1829, published in 1995. In 1998, these documents were superseded by RFC 2401 and RFC
2412 with incompatible aspects, although they were conceptually identical. In addition, a mutual authentication and
key exchange protocol Internet Key Exchange (IKE) was defined to create and manage security associations. In
December 2005, new standards were defined in RFC 4301 and RFC 4309 which are largely a superset of the
previous editions with a second version of the Internet Key Exchange standard IKEv2. These third-generation
documents standardized the abbreviation of IPsec to uppercase “IP” and lowercase “sec”. It is unusual to see any
product that offers support for RFCs 1825 and 1829. “ESP” generally refers to RFC 2406, while ESPbis refers to
RFC 4303.
Since mid-2008, an IPsec Maintenance and Extensions working group is active at the IETF.

[1] Kent, S.; Atkinson, R. (November 1998). IP Encapsulating Security Payload (ESP). IETF. RFC 2406.
[2] "RFC4301: Security Architecture for the Internet Protocol" (http:// tools. ietf.org/ html/ rfc4301#page-4). Network Working Group of the
IETF. December 2005. p. 4. . "The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other
capitalizations of IPsec [...] are deprecated."
[3] Thayer, R.; Doraswamy, N.; Glenn, R. (November 1998). IP Security Document Roadmap. IETF. RFC 2411.
[4] Hoffman, P. (December 2005). Cryptographic Suites for IPsec. IETF. RFC 4308.
[5] Kent, S.; Atkinson, R. (November 1998). IP Authentication Header. IETF. RFC 2402.
[6] Kent, S. (December 2005). IP Authentication Header. IETF. RFC 4302.
[7] The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
[8] Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE). IETF. RFC 2409.
[9] Kaufman, C., ed. IKE Version 2. IETF. RFC 4306.
[10] Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK). IETF. RFC 4430.
[11] Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS. IETF. RFC 4025.
[12] "Protocol Numbers" (http:// www.webcitation. org/5rXTFZt87). IANA. IANA. 2010-05-27. Archived from the original (http:// www.iana.
org/ assignments/ protocol-numbers/protocol-numbers.xml) on 2010-07-27. .
[13] Bellovin, Steven M. (1996). "Problem Areas for the IP Security Protocols" (http:// www.cs. columbia. edu/ ~smb/ papers/ badesp. ps)
(PostScript). Proceedings of the Sixth Usenix Unix Security Symposium. San Jose, CA. pp. 1–16. . Retrieved 2007-07-09.
[14] Paterson, Kenneth G.; Yau, Arnold K.L. (2006-04-24). "Cryptography in theory and practice: The case of encryption in IPsec" (http://
eprint.iacr.org/2005/ 416) (PDF). Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004. Berlin. pp. 12–29. . Retrieved 2007-08-13.
[15] Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). "Attacking the IPsec Standards in Encryption-only Configurations" (http://
eprint.iacr.org/2007/ 125) (PDF). IEEE Symposium on Security and Privacy, IEEE Computer Society. Oakland, CA. pp. 335–349. .
Retrieved 2007-08-13.
[16] Kent, S. (December 2005). IP Encapsulating Security Payload (ESP). IETF. RFC 4303.
[17] RFC 2406, §1, page 2
[18] RFC 3129
[19] "Information Technology Division, Naval Research Laboratory" (http:/ / www.itd. nrl. navy. mil/ ). NRL ITD. 2009-10-29. . Retrieved
[20] "Best Software Review" (http:/ / ezine. daemonnews. org/ 199812/ security. html). Daemon News. . Retrieved 2010-12-31.
[21] Worldwide. "Internet Protocol Security (IPsec) - JUNOS Software Security Configuration Guide" (http:/ / www.juniper.net/ techpubs/
software/junos-security/junos-security95/ junos-security-swconfig-security/ipsec-chapter.html). Juniper Networks. . Retrieved 2011-05-04.
[22] Worldwide. "An Introduction to IP Security (IPSec) Encryption [IPSec Negotiation/IKE Protocols]" (http:// www.cisco. com/ en/ US/ tech/
tk583/ tk372/ technologies_tech_note09186a0080094203. shtml). Cisco Systems. . Retrieved 2010-12-31.
[23] "Modifying an Internet Protocol security (IPSec) policy from a Windows XP SP1-based or Windows 2000-based client may corrupt the
IPSec policy" (http:/ / support. microsoft. com/ ?kbid=884909). Microsoft Support. 2006-12-25. . Retrieved 2010-12-31.
[24] "L2TP/IPsec NAT-T update for Windows XP and Windows 2000" (http:// support. microsoft. com/ kb/ 818043/ en-us). Microsoft Support.
2006-10-26. . Retrieved 2010-12-31.
[25] (http:/ / www. microsoft. com/ windows2000/ technologies/ communications/ ipsec/ default. mspx)
[26] (http:/ / www. microsoft. com/ windowsserver2003/ technologies/ networking/ ipsec/ default. mspx)
[27] "IPsec" (http:// technet. microsoft. com/ en-us/ network/bb531150. aspx). Microsoft TechNet. . Retrieved 2010-12-31.
[28] "Windows Firewall with Advanced Security Getting Started Guide" (http:/ / technet. microsoft.com/ en-us/ library/cc748991(WS.10).
aspx). Microsoft TechNet. . Retrieved 2010-12-31.
[29] "Products | Toolkits" (http:/ / www.authentec. com/ toolkits. cfm). AuthenTec. . Retrieved 2010-12-31.
[30] "IPsec and IKE Administration Guide" (http:// docs. sun.com/ app/ docs/ doc/ 817-2694?a=expand). Sun Microsystems. 2003-12-09. .
Retrieved 2010-12-31.
[31] Loughney, J., ed (April 2006). IPv6 Node Requirements. IETF. sec. 8.1. RFC 4294.
[32] ipsecme charter (http:// www. ietf.org/ html. charters/ipsecme-charter.html)
[33] ipsecme status (http:/ / tools. ietf.org/ wg/ ipsecme/ )
External links
• All IETF active security WGs (http:// www. ietf.org/html. charters/ wg-dir.html#Security Area)
• IETF ipsecme WG (http:/ / datatracker.ietf.org/wg/ ipsecme/ ) ("IP Security Maintenance and Extensions"
Working Group)
• IETF btns WG (http:/ / www. ietf.org/html. charters/ btns-charter.html) ("Better-Than-Nothing Security"
Working Group) (chartered to work on unauthenticated IPsec, IPsec APIs, connection latching)]
• Securing Data in Transit with IPsec (http:/ / www.windowsecurity. com/ articles/
Securing_Data_in_Transit_with_IPSec. html) WindowsSecurity.com article by Deb Shinder
• IPsec (http:/ / search. dmoz. org/ cgi-bin/search?search=ipsec) at the Open Directory Project
• IPsec (http:/ / www. microsoft. com/ ipsec) on Microsoft TechNet
• Microsoft IPsec Diagnostic Tool (http:/ / www.microsoft. com/ downloads/ details.
aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881&displaylang=en) on Microsoft Download Center
• An Illustrated Guide to IPsec (http:/ / www. unixwiz.net/ techtips/ iguide-ipsec. html) by Steve Friedl
• Security Architecture for IP (IPsec) (http:// www.ict. tuwien.ac. at/ skripten/ datenkomm/ infobase/
L97-IPsec_v4-7. pdf) lecture by Manfred Lindner of Vienna University of Technology
• Creating VPNs with IPsec and SSL/TLS (http:/ / www.linuxjournal.com/ article/9916) Linux Journal article by
Rami Rosen
• RFC 2367: PF_KEY Interface
• RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) Obsolete by RFC 4301
• RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
• RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
• RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 2409: The Internet Key Exchange
• RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
• RFC 2412: The OAKLEY Key Determination Protocol
• RFC 2451: The ESP CBC-Mode Cipher Algorithms
• RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
• RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
• RFC 3947: Negotiation of NAT-Traversal in the IKE
• RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Security Architecture for the Internet Protocol
• RFC 4302: IP Authentication Header
• RFC 4303: IP Encapsulating Security Payload
• RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet
Security Association and Key Management Protocol (ISAKMP)
• RFC 4306: Internet Key Exchange (IKEv2) Protocol
• RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308: Cryptographic Suites for IPsec
• RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload
• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
• RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
• RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
• RFC 4718: IKEv2 Clarifications and Implementation Guidelines
• RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
• RFC 4809: Requirements for an IPsec Certificate Management Profile
• RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
• RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
• RFC 6071: IPsec and IKE Document Roadmap
Intermediate System To Intermediate System (IS-IS), is a routing protocol designed to move information
efficiently within a computer network, a group of physically connected computers or similar devices. It accomplishes
this by determining the best route for datagrams through a packet-switched network. The protocol was defined in
ISO/IEC 10589:2002 as an international standard within the Open Systems Interconnection (OSI) reference design.
Though originally an ISO standard, the IETF republished the protocol as an Internet Standard in RFC 1142. IS-IS
has been called "the de facto standard for large service provider network backbones."
IS-IS (pronounced "i-s i-s") is an interior gateway protocol, designed for use within an administrative domain or
network. This is in contrast to Exterior Gateway Protocols, primarily Border Gateway Protocol (BGP), which is used
for routing between autonomous systems (RFC 1930).
IS-IS is a link-state routing protocol, operating by reliably flooding link state information throughout a network of
routers. Each IS-IS router independently builds a database of the network's topology, aggregating the flooded
network information. Like the OSPF protocol, IS-IS uses Dijkstra's algorithm for computing the best path through
the network. Packets (datagrams) are then forwarded, based on the computed ideal path, through the network to the
The IS-IS protocol was developed by Digital Equipment Corporation as part of DECnet Phase V. It was standardized
by the ISO in 1992 as ISO 10589 for communication between network devices which are termed Intermediate
Systems (as opposed to end systems or hosts) by the ISO. The purpose of IS-IS was to make possible the routing of
datagrams using the ISO-developed OSI protocol stack called CLNS.
IS-IS was developed at roughly the same time that the Internet Engineering Task Force IETF was developing a
similar protocol called OSPF. IS-IS was later extended to support routing of datagrams in the Internet Protocol (IP),
the Network Layer protocol of the global Internet. This version of the IS-IS routing protocol was then called
Integrated IS-IS (RFC 1195
Comparison with OSPF
Both IS-IS and OSPF are link state protocols, and both use the same Dijkstra algorithm for computing the best path
through the network. As a result, they are conceptually similar. Both support variable length subnet masks, can use
multicast to discover neighboring routers using hello packets, and can support authentication of routing updates.
While OSPF is natively built to route IP and is itself a Layer 3 protocol that runs on top of IP, IS-IS is natively an
OSI network layer protocol (it is at the same layer as CLNS). The widespread adoption of IP worldwide may have
contributed to OSPF's popularity. IS-IS does not use IP to carry routing information messages. IS-IS is neutral
regarding the type of network addresses for which it can route. OSPF, on the other hand, was designed for IPv4. This
allowed IS-IS to be easily used to support IPv6. To operate with IPv6 networks, the OSPF protocol was rewritten in
OSPF v3 (as specificed in RFC 2740
IS-IS routers build a topological representation of the network. This map indicates the subnets which each IS-IS
router can reach, and the lowest-cost (shortest) path to a subnet is used to forward traffic.
IS-IS differs from OSPF in the way that "areas" are defined and routed between. IS-IS routers are designated as
being: Level 1 (intra-area); Level 2 (inter area); or Level 1-2 (both). Level 2 routers are inter area routers that can
only form relationships with other Level 2 routers. Routing information is exchanged between Level 1 routers and
other Level 1 routers, and Level 2 routers only exchange information with other Level 2 routers. Level 1-2 routers
exchange information with both levels and are used to connect the inter area routers with the intra area routers. In
OSPF, areas are delineated on the interface such that an area border router (ABR) is actually in two or more areas at
once, effectively creating the borders between areas inside the ABR, whereas in IS-IS area borders are in between
routers, designated as Level 2 or Level 1-2. The result is that an IS-IS router is only ever a part of a single area. IS-IS
also does not require Area 0 (Area Zero) to be the backbone area through which all inter-area traffic must pass. The
logical view is that OSPF creates something of a spider web or star topology of many areas all attached directly to
Area Zero and IS-IS by contrast creates a logical topology of a backbone of Level 2 routers with branches of Level
1-2 and Level 1 routers forming the individual areas.
IS-IS also differs from OSPF in the methods by which it reliably floods topology and topology change information
through the network. However, the basic concepts are similar.
OSPF has a larger set of extensions and optional features. However IS-IS is less "chatty" and can scale to support
larger networks. Given the same set of resources, IS-IS can support more routers in an area than OSPF. This has
contributed to IS-IS as an ISP-scale protocol.
The TCP/IP implementation, known as "Integrated IS-IS" or "Dual IS-IS", is described in RFC 1195.
Related protocols
• Fabric Shortest Path First (FSPF)
• IEEE 802.1aq - Shortest Path Bridging (SPB)
[1] Gredler, Hannes; Goraiski, Walter (2005). The complete IS-IS routing protocol. Springer. pp. 1. ISBN 1852338229.
[2] http:/ / www. ietf.org/ rfc/rfc1195.txt
[3] http:/ / www. ietf.org/ rfc/rfc2740.txt
• RFC 1142 - IS-IS protocol specification (IETF) - Note: this is a copy of DP 10589 (Draft Proposal) and differs in
many significant details from the final version of ISO/IEC 10589
• RFC 1195 - Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
External links
• ISO/IEC 10589:2002 Second Edition (http:// standards. iso. org/ ittf/PubliclyAvailableStandards/
• OSPF and IS-IS: A Comparative Anatomy (http:/ / www.nanog.org/meetings/ nanog19/ presentations/ katz. ppt)
by Dave Katz, Juniper
• Collection of RFCs pertaining to IS-IS (http:/ / www.networksorcery.com/ enp/ protocol/is-is. htm)
• Configuring integrated IS-IS on Cisco Routers (http:/ / www.cisco. com/ en/ US/ docs/ ios/ 11_3/ np1/
configuration/guide/ 1cisis. html)
• IS-IS and OSPF difference discussion (http:// www.nada. kth. se/ kurser/kth/ 2D1490/ 06/ hemuppgifter/
bhatia-manral-diff-isis-ospf-01.txt. html) (Vishwas Manral, Manav Bhatia and Yasuhiro Ohara)
• Sample isisd.conf file (http:/ / svn. dd-wrt.com:8000/dd-wrt/browser/src/ router/quagga/ isisd/ isisd. conf.
sample?rev=7215): used with Quagga
Jughead (search engine)
Jughead is a search engine system for the Gopher protocol. It is distinct from Veronica in that it searches a single
server at a time.
Jughead is officially an acronym for Jonzy's Universal Gopher Hierarchy Excavation And Display, though it was
originally chosen to match that of the FTP search service known as Archie—Jughead Jones being the name of
another character from the Archie Comics.
Jughead was developed by Rhett Jones in 1993 and the University of Utah.
It was released by the original author under the GPL license in 2006, and its source code has been modernized to
better run on current POSIX systems.
Due to trademark issues, the modified version was called Jugtail, and has been made available for download on
GNU Savannah (see external links).
Jughead is meant to index servers quickly so it builds its database in memory. When Jughead uses all of the available
memory, it becomes unacceptably slow, limiting the size the servers it can index. Veronica does not have this
External links
• Jughead Source
• Jugtail Project
Running Jughead Servers
• [gopher://hal3000.cx:3000/7 Hal3000 Multi Gopher Search]
• [gopher://gopher.sm5sxl.net:3000/7 sm5sxl.net Search]
Jughead (search engine)
[1] http:/ / hal3000.cx:70/ Software/Unix/ jughead
[2] http:// savannah. gnu. org/projects/ jugtail
KA9Q, also called KA9Q NOS or simply NOS, was a popular early implementation of TCP/IP and associated
protocols for amateur packet radio systems and smaller personal computers connected via serial lines. It was named
after the amateur radio callsign of Phil Karn, who first wrote the software for a CP/M system and then ported it to
DOS on the IBM PC. As the KA9Q code was open-source, many radio amateurs modified it, so many different
versions were available at the same time.
KA9Q was later maintained by Anthony Frost (callsign G8UDV) and Adam Goodfellow. It was ported to the Acorn
Archimedes by Jonathan Naylor (G4KLX). Until 1995 it was the standard access software provided by British
dial-up internet service provider Demon Internet.
Most modern operating systems provide a built-in implementation of TCP/IP protocol. Especially Linux includes all
the necessary kernel functions and support utilities for TCP/IP over amateur radio systems. Therefore NOS is
regarded as obsolete by its original developer. It still may have its uses for embedded systems that are too small for
Linux .
KA9Q is also a name for the IP-over-IP Tunneling protocol.
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed
under the GFDL.
External links
• Phil Karn's web page on KA9Q NOS
[1] http:/ / www. ka9q. net/ code/ ka9qnos/
KAME project
KAME project
The KAME project was a joint effort of six organizations in Japan which aimed to provide a free IPv6 and IPsec
(for both IPv4 and IPv6) protocol stack implementation for variants of the BSD Unix computer operating-system.
The project began in 1998 and on November 7, 2005 it was announced that the project would be finished at the end
of March 2006.
The name KAME is a short version of Karigome, the location of the project's offices, and it also is
a word for turtles.
The following organizations participated in the project:
• ALAXALA Networks Corporation
• Fujitsu, Ltd.
• Hitachi, Ltd.
• Internet Initiative Japan Inc.
• Keio University
• NEC Corporation
• University of Tokyo
• Toshiba Corporation
• Yokogawa Electric Corporation
FreeBSD, NetBSD and DragonFly BSD integrated IPSec and IPv6 code from the KAME project; OpenBSD
integrated just IPv6 code rather than both (having developed their own IPSec stack). Linux also integrated code from
the project in its native IPSec implementation.
The KAME project collaborated with the TAHI Project [4] (which develops and provides verification-technology for
IPv6), the USAGI Project [5] and the WIDE Project [6].
External links
• the KAME project official site
• ALAXALA Networks Corporation
• Internet Initiative Japan Inc.
[1] http:/ / www. kame. net/ newsletter/ 20051107/
[2] http:/ / playground.iijlab. net/ material/ kazu-kame-presen/mgp00015.html
[3] Roy, Vincent (12 October 2004), Benchmarks for Native IPsec in the 2.6 Kernel (http:/ / www.linuxjournal.com/ article/ 7840), Linux
[4] http:// www. tahi. org/
[5] http:/ / www. linux-ipv6.org/
[6] http:/ / www. wide. ad. jp/
[7] http:// www. kame. net/
[8] http:/ / www. alaxala. com/
[9] http:/ / www. iij. ad. jp/
Layer 2 Tunneling Protocol Version 3 is an IETF standard that related to L2TP that can be used as an alternative
protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications
traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements.
L2TPv3 can be regarded as being to MPLS what IP is to ATM: a simplified version of the same concept, with much
of the goodness achieved with a fraction of the effort, at the cost of losing some technical features considered less
important in the market. In the case of L2TPv3, the features lost are teletraffic engineering features considered
important in MPLS. The protocol overhead of L2TPv3 is also significantly bigger than MPLS. However, there is no
reason why these features could not be re-engineered in or on top of L2TPv3 in later products.
External links
• IETF L2TPEXT working group
• RIPE presentation about L2TPv3
• RFC 3931 - Layer Two Tunneling Protocol - Version 3 (L2TPv3)
• RFC 2661 - Layer Two Tunneling Protocol "L2TP"
[1] http:/ / www. ietf.org/ html. charters/l2tpext-charter.html
[2] http:/ / www. ripe.net/ ripe/ meetings/ ripe-42/presentations/ ripe42-eof-pseudowires2/index.html
[3] http:/ / tools. ietf.org/html/ rfc3931
[4] http:// tools. ietf.org/html/ rfc2661
Layer 2 Tunneling Protocol
In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private
networks (VPNs). It does not provide any encryption or confidentiality by itself; it relies on an encryption protocol
that it passes within the tunnel to provide privacy.
Although L2TP acts like a Data Link Layer protocol in the OSI model, L2TP is in fact a Session Layer protocol,
and uses the registered UDP port 1701. (see List of TCP and UDP port numbers).
History and future
Published in 1999 as proposed standard RFC 2661, L2TP has its origins primarily in two older tunneling protocols
for PPP: Cisco's Layer 2 Forwarding Protocol (L2F) and US Robotics Point-to-Point Tunneling Protocol (PPTP). A
new version of this protocol, L2TPv3, was published as proposed standard RFC 3931 in 2005. L2TPv3 provides
additional security features, improved encapsulation, and the ability to carry data links other than simply PPP over an
IP network (e.g., Frame Relay, Ethernet, ATM, etc).
Layer 2 Tunneling Protocol
The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. It is common to carry
Point-to-Point Protocol (PPP) sessions within an L2TP tunnel. L2TP does not provide confidentiality or strong
authentication by itself. IPsec is often used to secure L2TP packets by providing confidentiality, authentication and
integrity. The combination of these two protocols is generally known as L2TP/IPsec (discussed below).
The two endpoints of an L2TP tunnel are called the LAC (L2TP Access Concentrator) and the LNS (L2TP Network
Server). The LAC is the initiator of the tunnel while the LNS is the server, which waits for new tunnels. Once a
tunnel is established, the network traffic between the peers is bidirectional. To be useful for networking, higher-level
protocols are then run through the L2TP tunnel. To facilitate this, an L2TP session (or call) is established within the
tunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for each
session is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel. MTU should
be considered when implementing L2TP.
The packets exchanged within an L2TP tunnel are categorised as either control packets or data packets. L2TP
provides reliability features for the control packets, but no reliability for data packets. Reliability, if desired, must be
provided by the nested protocols running within each session of the L2TP tunnel.
Tunneling models
An L2TP tunnel can extend across an entire PPP session or only across one segment of a two-segment session. This
can be represented by four different tunneling models, namely [3] [4] [5]
• voluntary tunnel
• compulsory tunnel — incoming call
• compulsory tunnel — remote dial
• L2TP multi-hop connection
L2TP packet structure
An L2TP packet consists of :
Bits 0–15 Bits 16–31
Flags and Version Info Length (opt)
Tunnel ID Session ID
Ns (opt) Nr (opt)
Offset Size (opt) Offset Pad (opt)......
Payload data
Field meanings:
Flags and version
control flags indicating data/control packet and presence of length, sequence, and offset fields.
Length (optional)
Total length of the message in bytes, present only when length flag is set.
Tunnel ID
Indicates the identifier for the control connection.
Session ID
Indicates the identifier for a session within a tunnel.
Layer 2 Tunneling Protocol
Ns (optional)
sequence number for this data or control message, beginning at zero and incrementing by one (modulo 2
) for
each message sent. Present only when sequence flag set.
Nr (optional)
sequence number for expected message to be received. Nr is set to the Ns of the last in-order message received
plus one (modulo 2
). In data messages, Nr is reserved and, if present (as indicated by the S bit), MUST be
ignored upon receipt..
Offset Size (optional)
Specifies where payload data is located past the L2TP header. If the offset field is present, the L2TP header
ends after the last byte of the offset padding. This field exists if the offset flag is set.
Offset Pad (optional)
Variable length, as specified by the offset size. Contents of this field are undefined.
Payload data
Variable length (Max payload size = Max size of UDP packet − size of L2TP header)
L2TP packet exchange
At the time of setup of L2TP connection, many control packets are exchanged between server and client to establish
tunnel and session for each direction. One peer requests the other peer to assign a specific tunnel and session id
through these control packets. Then using this tunnel and session id, data packets are exchanged with the compressed
PPP frames as payload.
The list of L2TP Control messages exchanged between LAC and LNS, for handshaking before establishing a tunnel
and session in voluntary tunneling method are
Layer 2 Tunneling Protocol
Because of the lack of confidentiality inherent in the L2TP protocol, it is often implemented along with IPsec. This is
referred to as L2TP/IPsec, and is standardized in IETF RFC 3193. The process of setting up an L2TP/IPsec VPN is
as follows:
1. Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carried
out over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), public
keys, or X.509 certificates on both ends, although other keying methods exist.
2. Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocol
number for ESP is 50 (compare TCP's 6 and UDP's 17). At this point, a secure channel has been established,
but no tunneling is taking place.
3. Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameters
takes place over the SA's secure channel, within the IPsec encryption. L2TP uses UDP port 1701.
When the process is complete, L2TP packets between the endpoints are encapsulated by IPsec. Since the L2TP
packet itself is wrapped and hidden within the IPsec packet, no information about the internal private network can be
garnered from the encrypted packet. Also, it is not necessary to open UDP port 1701 on firewalls between the
endpoints, since the inner packets are not acted upon until after IPsec data has been decrypted and stripped, which
only takes place at the endpoints.
A potential point of confusion in L2TP/IPsec is the use of the terms 'tunnel' and 'secure channel'. The term 'tunnel'
refers to a channel which allows untouched packets of one network to be transported over another network. In the
case of L2TP/PPP, it allows L2TP/PPP packets to be transported over IP. A 'secure channel' refers to a connection
within which the confidentiality of all data is guaranteed. In L2TP/IPsec, first IPsec provides a secure channel, then
L2TP provides a tunnel.
Windows implementation
Windows Vista provides two new configuration utilities that attempt to make using L2TP without IPsec easier, both
described in sections that follow below:
• an MMC snap-in called "Windows Firewall with Advanced Security" (WFwAS), located in Control Panel →
Administrative Tools
• the "netsh advfirewall" command-line tool
Both these configuration utilities are not without their difficulties, and unfortunately, there is very little
documentation about both "netsh advfirewall" and the IPsec client in WFwAS. One of the aforementioned
difficulties is that it is not compatible with NAT. Another problem is that servers must be specified only by IP
address in the new Vista configuration utilities; the hostname of the server cannot be used, so if the IP address of the
IPsec server changes, all clients will have to be informed of this new IP address (which also rules out servers that
addressed by utilities such as DynDNS).
Layer 2 Tunneling Protocol
L2TP in ADSL networks
L2TP is often used as a tunneling mechanism to resell ADSL endpoint connectivity at layer 2. An L2TP tunnel
would sit between the user and the ISP the connection would be resold to, so the reselling ISP would not appear as
doing the transport.
L2TP in cable networks
L2TP is used by the cable Internet provider as a tunnelling mechanism to sell endpoint connectivity. The L2TP
tunnel sits between the user and the ISP. Again, the reselling cable provider doesn't appear as doing the transport.
[1] IETF (1999), RFC 2661, Layer Two Tunneling Protocol "L2TP"
[2] Cisco Systems, Inc., Cisco Active Network Abstraction Technology Support and Information Model Reference Manual, Version 3.6, Chapter
9 (http:// www. cisco. com/ en/ US/ docs/ net_mgmt/ active_network_abstraction/3. 6/ master_tech/ 9l2tp.pdf), Layer 2 Tunnel Protocol
[3] http:/ / publib.boulder.ibm. com/ infocenter/iseries/ v5r3/index.jsp?topic=/ rzaiy/ rzaiymultihop.htm
[4] http:// www. cisco. com/ en/ US/ tech/ tk827/ tk369/ tk388/tsd_technology_support_sub-protocol_home. html
[5] http:// technet2.microsoft.com/ WindowsServer/ en/ library/04bd5817-0e41-46b7-9dda-d6340fce514f1033.mspx
External links
• Cisco: Cisco L2TP documentation (http:/ / www. cisco. com/ en/ US/ docs/ ios/ 12_0t/ 12_0t1/ feature/guide/
l2tpT.html), also read Technology brief from Cisco (http:// www.cisco. com/ warp/ public/ cc/ pd/ iosw/ tech/
l2pro_tc. htm)
• Open source and Linux: xl2tpd (http:/ / www.xelerance.com/ software/xl2tpd/ ), Linux RP-L2TP (http://
sourceforge. net/ projects/ rp-l2tp/), OpenL2TP (http:// sourceforge.net/ projects/ openl2tp/ ), l2tpns (http://
l2tpns. sourceforge.net/ ), l2tpd (http:// sourceforge.net/ projects/ l2tpd/ ) (inactive), Linux L2TP/IPsec server
(http:/ / www. zeroshell. net/ eng/ vpndetails/ ), FreeBSD multi-link PPP daemon (http:// mpd. sourceforge.net/ )
• Microsoft: built-in client included with Windows 2000 and higher; Microsoft L2TP/IPsec VPN Client (http:/ /
www. microsoft.com/ technet/ prodtechnol/ windows2000serv/ support/ vpnclientag. mspx) for Windows
98/Windows Me/Windows NT 4.0
• Apple: built-in client included with Mac OS X 10.3 and higher.
Internet standards and extensions
• RFC 2341 Cisco Layer Two Forwarding (Protocol) "L2F" (a predecessor to L2TP)
• RFC 2637 Point-to-Point Tunneling Protocol (PPTP) (a predecessor to L2TP)
• RFC 2661 Layer Two Tunneling Protocol "L2TP"
• RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS
• RFC 2888 Secure Remote Access with L2TP
• RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay
• RFC 3145 L2TP Disconnect Cause Information
• RFC 3193 Securing L2TP using IPsec
• RFC 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network
• RFC 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services
• RFC 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)
• RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base
Layer 2 Tunneling Protocol
• RFC 3437 Layer Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
• RFC 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers: Internet Assigned Numbers
Authority (IANA) Considerations Update
• RFC 3573 Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
• RFC 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
• RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
• RFC 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)
• RFC 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
• IANA assigned numbers for L2TP (http:// www. iana. org/assignments/ l2tp-parameters)
• L2TP Extensions Working Group (l2tpext) (http:// www.ietf. org/html. charters/l2tpext-charter.html) - (where
future standardization work is being coordinated)
• Using Linux as an L2TP/IPsec VPN client (http:/ / www.jacco2.dds. nl/ networking/ linux-l2tp.html)
• Configuring L2TP VPN in Windows (http:/ / alivevpn. com/ l2tp_vpn_account_settings)
The Lightweight Directory Access Protocol (LDAP; /ˈɛldæp/) is an application protocol for reading and editing
directories over an IP network.
A directory in this sense is an organized set of records: for example, a telephone
directory is an alphabetical list of persons and organizations with an address and phone number in each "record".
The latest version of LDAP is Version 3, which is specified in a series of Internet Engineering Task Force (IETF)
Standard Track Requests for comments (RFCs) as detailed in RFC 4510.
Origin and influences
Telecommunication companies' understanding of directory requirements was well developed after some 70 years of
producing and managing telephone directories. These companies introduced the concept of directory services to
information technology and computer networking, their input culminating in the comprehensive X.500
a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required
the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight
alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP
protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service
Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The
latter has become popular in enterprises, as LDAP removed any need to deploy an OSI network. Today, X.500
directory protocols including DAP can also be used directly over TCP/IP.
The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, and
Wengyik Yeong of Performance Systems International, circa 1993. Mark Wahl of Critical Angle Inc., Tim Howes,
and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet
Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for
extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993
edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding
features to LDAPv3 has come through the IETF.
In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It
was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include
directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP
predecessor and thus was more easily implemented over the internet due to its relatively modest bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory
(XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the
Service Location Protocol (SLP).
Protocol overview
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by
default on TCP port 389. The client then sends an operation request to the server, and the server sends responses in
return. With some exceptions, the client does not need to wait for a response before sending the next request, and the
server may send the responses in any order.
The client may request the following operations:
• Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
• Bind — authenticate and specify LDAP protocol version
• Search — search for and/or retrieve directory entries
• Compare — test if a named entry contains a given attribute value
• Add a new entry
• Delete an entry
• Modify an entry
• Modify Distinguished Name (DN) — move or rename an entry
• Abandon — abort a previous request
• Extended Operation — generic operation used to define other operations
• Unbind — close the connection (not the inverse of Bind)
In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times
out a connection.
A common alternate method of securing LDAP communication is using an SSL tunnel. This is denoted in LDAP
URLs by using the URL scheme "ldaps". The default port for LDAP over SSL is 636. The use of LDAP over SSL
was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage
has been deprecated along with LDAPv2, which was officially retired in 2003.
LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format BER. It uses textual
representations for a number of ASN.1 fields/types, however.
Directory structure
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:
• A directory is a tree of directory entries.
• An entry consists of a set of attributes.
• An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are
defined in a schema (see below).
• Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name
(RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the
full file path and the RDN as its relative filename in its parent folder (e.g. if C:\foo\bar\myfile.txt were the DN,
then myfile.txt would be the RDN).
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To
reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational
An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
"dn" is the distinguished name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's
RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes
'Domain Component'. The other lines show the attributes in the entry. Attribute names are typically mnemonic
strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also
hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a
referral or continuation reference to a server which holds that part of the directory tree. The client can then contact
the other server. Some servers also support chaining, which means the server contacts the other server and returns
the results to the client.
LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the
entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a
set of attributes, and an attribute is a set of values, and sets need not be ordered.
Expand discussion of referral responses to various operations, especially modify, for example where all
modifies must be directed from replicas to a master directory.
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can
provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection
(which protects the data from tampering). During TLS negotiation the server sends its X.509 certificate to prove its
identity. The client may also send a certificate to prove its identity. After doing so, the client may then use
SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from
credentials provided at a lower level (such as TLS). Though technically the server may use any identity information
established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL")
protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways: 1) upon connect, the client and
server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and 2) the LDAPS
connection must be closed upon TLS closure.
LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined. The use of LDAPS is
deprecated, and modern software should only use StartTLS.
Bind (authenticate)
The Bind operation authenticates the client to the server. Simple Bind can send the user's DN and password in
plaintext, so the connection should be protected using Transport Layer Security (TLS). The server typically checks
the password against the userPassword attribute in the named entry. Anonymous Bind (with empty DN and
password) resets the connection to anonymous state. SASL (Simple Authentication and Security Layer) Bind
provides authentication services through a wide range of mechanisms, e.g. Kerberos or the client certificate sent with
Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, which is the default in the protocol
but not always in LDAP libraries.
Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the current LDAP
Search and Compare
The Search operation is used to both search for and read entries. Its parameters are:
The DN (Distinguished Name) of the entry at which to start the search,
What elements below the baseObject to search. This can be BaseObject (search just the named entry, typically
used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire
subtree starting at the base DN).
Criteria to use in selecting elements within scope. For example, the filter
(&(objectClass=person)(|(givenName=John)(mail=john*))) will select "persons" (elements of objectClass
person) who either have the given name "John" or an e-mail address that begins with the string "john".
Whether and how to follow alias entries (entries which refer to other entries),
Which attributes to return in result entries.
sizeLimit, timeLimit
Maximum number of entries to return, and maximum time to allow search to run.
Return attribute types only, not attribute values.
The server returns the matching entries and potentially continuation references. These may be returned in any order.
The final result will include the result code.
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains
that attribute with that value.
Update Data
Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.
Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add
new values, or replace the current values with the new ones.
Add operations also can have additional attributes and values for those attributes.
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's
DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may
support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand,
LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client
may have updated the entry in the mean time. Servers may implement extensions
which support this, though.
Extended operations
The Extended Operation is a generic LDAP operation which can be used to define new operations. Examples include
the Cancel and Password Modify.
The Abandon operation requests that the server abort an operation named by a message ID. The server need not
honor the request. Unfortunately, neither Abandon nor a successfully abandoned operation send a response. A
similar Cancel extended operation has therefore been defined which does send responses, but not all
implementations support this.
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name
is of historical origin, and is not the opposite of the Bind operation.
Clients can abort a session by simply closing the connection, but they should use Unbind.
Unbind allows the
server to gracefully close the connection and free resources that it would otherwise keep for some time until
discovering the client had abandoned the connection. It also instructs the server to cancel operations that can be
canceled, and to not send responses for operations that cannot be canceled.
An LDAP URL format exists which clients support in varying degree, and which servers return in referrals and
continuation references (see RFC 4516):
Most of the components, which are described below, are optional.
• host is the FQDN or IP address of the LDAP server to search.
• port is the network port of the LDAP server.
• DN is the distinguished name to use as the search base.
• attributes is a comma-separated list of attributes to retrieve.
• scope specifies the search scope and can be "base" (the default), "one" or "sub".
• filter is a search filter. For example (objectClass=*) as defined in RFC 4515.
• extensions are extensions to the LDAP URL format.
For example, "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refers to all user attributes in John
Doe's entry in ldap.example.com, while "ldap:///dc=example,dc=com??sub?(givenName=John)" searches for the
entry in the default server (note the triple slash, omitting the host, and the double question mark, omitting the
attributes). As in other URLs, special characters must be percent-encoded.
There is a similar non-standard ldaps: URL scheme for LDAP over SSL. This should not be confused with LDAP
with TLS, which is achieved using the StartTLS operation using the standard ldap: scheme.
The contents of the entries in a subtree are governed by a schema known as a directory information tree (DIT).
The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold.
It has a number of elements, including:
• Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
• Matching Rules—Provide information about how to make comparisons against attribute values.
• Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
• Attribute Types—Define an OID and a set of names that may be used to refer to a given attribute, and associates
that attribute with a syntax and set of matching rules.
• Object Classes—Define named collections of attributes and classify them into sets of required and optional
• Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
• Content Rules—Define additional constraints about the object classes and attributes that may be used in
conjunction with an entry.
• Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for
which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may
interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema
The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined
in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent -
e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain
values and the list of attributes which may contain values.
For example, an entry representing a person might belong to the classes "top" and "person". Membership in the
"person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain
"userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values,
each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it
represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values which define
the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class definition
and an instance in Object-oriented programming, representing LDAP objectClass and LDAP entry, respectively.
Directory clients may publish the directory schema controlling an entry at a base DN given by the entry's
subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than
user information and is only returned from a search when it is explicitly requested.)
Server administrators can add additional schema entries in addition to the provided schema elements. A schema for
representing individual people within organizations is termed a white pages schema.
A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up
to support a wide variety of scenarios.
For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway
to some other server. Access control is not standardized, though there has been work on it and there are commonly
used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform
operations when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and
responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can
have options that may modify their semantics.
Other data models
As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The
implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed
varies. For example, there is software to access SQL databases through LDAP, even though LDAP does not readily
lend itself to this.
X.500 servers may support LDAP as well.
Similarly, data which were previously held in other types of data stores are sometimes moved to LDAP directories.
For example, Unix user and group information can be stored in LDAP and accessed via PAM and NSS modules.
LDAP is often used by other services for authentication.
Naming structure
Since an LDAP server can return referrals to other servers for requests the server itself will not/can not serve, a
naming structure for LDAP entries is needed so one can find a server holding a given DN or distinguished name, a
concept defined in the X.500 Directory and also used in LDAP. Another way of locating LDAP servers for an
organization would be a SRV RR (resource record) in the DNS.
If an organization has domain name example.org, its top level LDAP entry may use the DN dc=example,dc=org
(where dc means domain component). If the LDAP server is also named ldap.example.org, the organization's top
level LDAP URL becomes ldap://ldap.example.org/dc=example,dc=org.
There are primarily two common styles of naming, in both X.500 [2008] and LDAPv3 which are documented in the
ITU specifications and IETF RFCs. The original form takes the top level object as the country object, such as c=US,
c=FR. The domain component model uses the model described above. An example of country based naming could
be c=FR, o=Some Organization, ou=Some Organizational Unit L=Locality, or in the US. c=US, st=CA, o=Some
Organization ou=Organizational Unit, L=Locality, and CN=Common Name
The LDAP terminology one can encounter is rather cumbersome. Some of this is due to misunderstandings, other
examples are due to its historical origins, others arise when used with non-X.500 services that use different
terminology. For example, "LDAP" is sometimes used to refer to the protocol, other times to the protocol and the
data. An "LDAP directory" may be the data or also the access point. An "attribute" may be the attribute type, or the
contents of an attribute in a directory, or an attribute description (an attribute type with options). An "anonymous"
and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state, so both
terms are being used for both variants.
[1] LDAP: Framework, Practices, and Trends (http:// www2. computer.org/portal