Random Daodejing

TCP/IP Notes

Intro  /  Network Addressing  /  Network Addressing IPv6  /  Packet Headers  /  Networking and Data Link Layers  /  Transport Layer Protocols  /  Application Layer Protocols  /  IP Routing  /  ICMP  /  DHCP  /  Name Resolution and DNS  /  Security 


Routing protocols define how routers communicate, and can be thought of as algorithms which are used to discover network paths based upon data such as bandwidth, delay, hop count, load and MTU.  Path information is then stored within the routing table and can be updated manually or automatically as conditions change.
IPv4 routing protocols are defined within multiple RFCs (including 791, 922, 1716, 1812, 1930) and fall into three types:  interior gateway using link-state routing, interior gateway using path-vector or distance-vector, and exterior gateway routing.
RIP (Routing Information Protocol)
- RIP is a distance-vector routing protocol which comes in two versions.  The first, called 'version 1,' or RIPv1, is defined in RFC 1058 (https://tools.ietf.org/html/rfc1058), and the second (RIPv2) is defined in RFC 2453 (https://tools.ietf.org/html/rfc2453).  Version 2 adds support for variable length subnets among other improvements.  RIP is UDP-based and uses port 520 for sending and receiving.
When RIPv1 routers are initialized, they send a RIP announcement about their connections and a request to identify other networks in order to build a routing table.  Every 30 seconds RIPv1 routers broadcast network announcements, and each packet can contain information for upwards of 25 networks.  RIPv1 does not support variable length subnet masks, and guesses whether a particular network address is Class A, B or C based on the network portion.

Routing Information Protocol
Command Field - 1 byte.  Identifies whether packet is a request (1) or reply (2).
Version Field - 1 byte.  Indicates whether RIPv1 (1) or RIPv2 (2).
Reserved (Zero) Field - 2 bytes.  Set to 0s (some protocol analyzers do not display these fields).
Address Family Identifier Field - 2 bytes.  Used to define protocol using RIP.
IP Address - 4 bytes.
Metric - 4 bytes.  Contains distance metric for address listed in IP Address field.
RIPv1 does not support variable-length subnet masks, and it is slow.  RIPv2 deals with the first issue, and using OSPF solves the second.

RIPv2 - In addition to variable-length subnet mask support, RIPv2 also provides basic authentication and multicast routing updates using as the multicast IP address.

Routing Information Protocol Version 2
Command Field - 1 byte.  Identifies whether packet is a request (1) or reply (2).
Version Field - 1 byte.  Indicates whether RIPv1 (1) or RIPv2 (2).
Reserved Field - 2 bytes.  Set to zeroes.
Address Family Field - 2 bytes.  Used to define protocol using RIP.  The value 0xFFFF indicates message remainder contains authentication.
Authentication Field - 16 bytes.  Contains plain-text password.  Can be shorter than 16 bytes and padded with 0x00.
Address Family Identifier Field - When field contains '0x02' the next 20 bytes contain a route entry.
Route Tag Field - 2 bytes.  Used to indicate whether route information is internal (from within the routing area) or external (learned through IGP or EGP outside routing area).
IP Address Field - 4 bytes.  Contains IP address being advertised.
Subnet Mask Field - 4 bytes.  Contains subnet mask associated with advertised IP address.
Next Hop Field - 4 bytes.  In RIPv2, this can be used to associate another router with a route entry (in RIPv1 routers only advertise to networks for which packets can be routed).
Metric Field - 4 bytes.  Indicates distance in hops to advertised network (not used in request packets).
For smaller and less complex networks the use of RIPv2 is seen as more common, while larger more complex networks (enterprise-level) will generally use OSPF.
Open Shortest Path First (OSPF)

OSPF is a link-state routing protocol, documented in RFC 2328 (https://tools.ietf.org/html/rfc2328).  The word "Open" refers to this protocol as being non-proprietary.  OSPF-based routers work by sending multicast Hello packets to directly connected links to gain information about neighboring routers.  As the routers hear each other's Hello packets, they include their neighbor's addresses in further Hello packets establishing adjacent relationships sharing copies of all LSAs.  After this is done the routers send further periodic Hello packets using the Dijkstra algorithm to determine the best paths.  This information becomes part of the forwarding table, which is checked by the router before forwarding packets.  Due to processing and memory requirements this architecture is not considered scalable.  To help deal with this, OSPF uses a designated router (DR) on each broadcast segment, chosen by priority number from 0-255.  The router with the second highest priority becomes the backup designated router (BDR).  These two routers establish adjacencies with other OSPF-based routers within a subnet, and all other routers will only establish adjacencies with them.

Open Shortest Path First

The responsibility of the designated router is to inform other routers of LSAs, and the responsibility of the backup designated router is to restore interrupted service in case the first router goes down.  The other routers multicast LSAs to the DR multicast address of
LSAs come in six different types:
Type 1 (Router Links Advertisement)
- Propagated throughout an area containing information about the router's neighbors.  Sent by all routers.
Type 2 (Network Links Advertisement) - Generated by the DR on behalf of the network, listing all routers on the network.  Sent by DRs.
Type 3 (Network Summary Link
Advertisement) - Generated by ABR to define reachable networks outside area.  Sent by ABRs.
Type 4 (AS Boundary Router Summary Links Advertisement) - Describes path cost of sending router to AS boundary router.  Sent by ABRs.
Type 5 (AS External Link Advertisement) - Propagated to all routers throughout entire AS to describe path cost from sending AS boundary to destinations outside AS.  Sent by ASBRs.
Type 6 (Not So Stubby Area Networks Advertisement) - Used to describe external routes passing through stub area, which does not accept Type 5 AS External Lik Advertisements (routers must use default route to access networks outside AS).

OSPF Area Types and Accepted LSAs

Area Types LSA 1 LSA 2 LSA 3 LSA 4 LSA 5 LSA 7
Backbone Area Yes Yes Yes Yes Yes No
Non-Backbone Area Yes Yes Yes Yes Yes No
Stub Area Yes Yes Yes No No No
Totally Stubby Area Yes Yes No No No No
Not-So-Stubby Area Yes Yes Yes Yes No Yes

When routers transmit packets to advertise themselves, they use Type 1 directed towards the SPF router's multicast address of  The DR sends a Type 2 LSA on behalf of the network.  Within local networks, OSPF uses router IDs establishing a master router, while all other routers are designated as slave routers.  The master router periodically sends a Database Description (DD) packet to the slave routers which reply with ACK.  If the acknowledgement is not received, the master router sends a copy of the LSA directly to the slave router.  Upon receipt of the LSA, the OSPF routers establish a link-state database which maps the entire network.  From here the Dijkstra algorithm is used on the database to find the best paths.

OSPF header
Version Number Field - 1 byte.  Contains the OSPF version number.
Type Field - 1 byte.  Defines purpose:
    Type 1 - Hello
    Type 2 - Database Description
    Type 3 - Link-State Request
    Type 4 - Link-State Update
    Type 5 - Link-State Acknowledgement
Packet Length Field - 2 bytes.  Indicates length of packet (includes OSPF header and following valid data excluding packet padding).
Router ID Field - 4 bytes.  Contains ID of transmitting router.
Area ID Field - 4 bytes.  Contains area number expressed in decimal or dotted decimal notation.  A common practice is to assign this as the same value as the network.
Checksum Field - 2 bytes, does not include Authentication field.
AuType Field - 2 bytes.  Defines authentication type.
Authentication Field - 8 bytes.
After the header, the format of the packet depends on the type of LSA.
Enhanced Interior Gateway Routing Protocol (EIGRP)
Cisco Systems developed the Interior Gateway Routing Protocol (IGRP) in the 1980s as a way to more efficiently manage interior gateway communications.  It was updated in the 1990s to become EIGRP.  Although classified as a distance-vector routing protocol, it also combines features of link-state routing.
Border Gateway Protocol (BGP)
Exterior gateway protocols (EGP) aka interdomain routing protocols involve the ability to communicate between autonomous networks.  A current implementation of this type of routing is Border Gateway Protocol (BGP), defined in RFC 1771 (https://tools.ietf.org/html/rfc2328).  Three types of routing operations are handled by BGP:
Inter-Autonomous System Routing - BGP routers in different ASs are configured as peers, exchanging internetwork topology information.
Intra-Autonomous System Routing - BGP routers are within the same AS.
Pass-Through Autonomous System Routing - BGP peer routers exchange routing information across AS which does not support BGP.
IPv6 routing protocols are extensions of IPv4.  They can be grouped into Interior Gateway Protocols (IGP), Exterior Gateway Protocols (EGP), distance vector, and link-state.
RIPng - Based on the implementation used in IPv4 (RIPv2) and defined in RFC 2080 (https://tools.ietf.org/html/rfc2080).  As in RIPv2, RIPng supports 15 hop radius, distance vector, poison reverse, and split horizon.  Areas which have been updated include IPv6 transport, prefixes, and next-hop address.  Uses multicast group address FF02::9 for updates on UDP port 521.
Routing entries within RIPng-based systems include at minimum:
- Destination IPv6 prefix
- Total cost of sending packet from router to destination
- Next hop router IPv6 address
- Route change flags which indicate if routing information has changed.
- Route-based timers.
In directly-connected network, this relies on hop count rather than metrics.  Static routes can also be manually configured, and the use of RIPng assumes that all routers also use the protocol within a given AS. 


- Message type.  Request = 0x01 and reply = 0x02.
Version - Version #.  Only 0x01 currently exists.
Must be Zero - Reserved.
RTC - Routing table entry, contains 20 bytes per entry.
A request message in a request packet is intended to derive some or all of a routing table in a reply.  Response messages can also be sent unsolicited.
RIPng uses two types of RTEs:
Next Hop RTE - Contains IPv6 address of next hop.
IPv6 Prefix RTE - Describes destination address, route tag, prefix length, and routing table metric.  All RTEs contained in the packet include destination prefix, number of significant bits, and cost to reach destination.  The destination prefix is 128 bits, with the IPv6 address prefix stored as 16 octets in the network byte order.
The RTE contains route tag fields which determine specific routes based on assigned value, and can therefore differentiate between internal RIPng routes and external RIPng routes.  These values may also be imported from the ERG or IGP.
OSPFv3 for IPv6 - OSPF for IPv6 is defined in RFC 5340 (https://tools.ietf.org/html/rfc5340), describing updates and modifications from version 2 to version 3.  OSPFv3 runs directly on IPv6 and includes prefixes along with other IPv6-centric attributes such as 128-bit addresses, link-local addresses, and the ability to manage multiple addresses per interface.  It uses IPsec for authentication and can run over a link as opposed to a subnet as with version 2 in IPv4.
Some of the other major differences between these versions include:
- Removing semantic addresses from packets and LSAs.
- Per-link basis as opposed to per-IP-subnet basis.
- Generalized LSA flooding scope.
- IPv6 packet Authentican Header and Encapsulating Security Payload (ESP) manages authentication.


Changes within the packet header itself include:
- Options field increased to 24 bits for Hello and DD packets.
- Authentication and AuType fields have been eliminated.
- Hello packet does not contain address information, instead it contains Interface ID value assigned by originating router.  If the router is a link DR, this value will be used as the network LSA's Link State ID.
- In the Options field, two new bits have been added:  R-bit (for multihomed nodes) and V6-bit, used alongside the R-bit for determining if the OSPF speaker can share topology distribution.
- To allow multiple OSPF instances to run on a single link, Instance ID field has been added.
Changes within LSA format - The LSA header, router LSAs and network LSAs no longer contain addressing semantics.  The router and network LSAs describe routing domain topology independent of network protocol.  There are also additional LSAs to distribute IPv6 address data for next hop resolution.
Additional changes include:
- Options field eliminated from LSA header and put into the body of router LSA, network LSA, link LSA, and inter-area router LSA.  The Options field for these have been increased to 24 bits.
- LSA Type field has been increased to 16 bits, with upper 3 bits encoding flooding scope and managing unknown LSA types.
- Address format is [prefix, prefix length] instead of [address, mask].
- Router LSAs and network LSAs contain no addressing information (network protocol dependent).
- Router interface information can be spread across multiple router LSAs.
- Link LSA uses link-local flooding scope , providing router's link-local address to other routers on the link.
- Network LSA Options field set to options which routers advertise on the link.
Version 2 and Version 3 of OSPF are incompatible, however they can be run on the same link to support a hybrid environment, but in this case each IP routing protocol domain is separate.
EIGRP for IPv6 - EIGRP has not changed significantly for IPv6.
MP-BGP - RFC 4760 (https://tools.ietf.org/html/rfc4760) defines multiprotocol extensions to make BGP version 4 available to other network layer protocols.  Running BGP-4 on IPv6 networks requires backward-compatible extensions for information required in IPv4 (NEXT_HOP, AGGREGATOR, NLRI) as well as the addition of associating the IPv6 protocol with next hop information and NLRI.  For this purpose two new additions have been made in BGP-4 (see:  https://tools.ietf.org/html/rfc4271 & https://tools.ietf.org/html/rfc6286):  Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI).
MP_REACH_NLRI carrys the collection of reachable destinations with next hop information used for forwarding to the destinations, while MP_UNREACH_NLRI carries information about unreachable destinations.  Both of these are considered optional. 
Managing Routing on an In-House Internetwork
An administrator should first decide on policy in regards to users, types of traffic, etc.  For example, different links on a network might require different configuration depending on traffic type.  A dedicated VoIP link might prefer low latency over a larger link with more latency used for FTP and HTTP.  Since RIP is based on hop count and OSPF on metric cost, types of traffic and routing should be taken into account based upon user need.  Load balancing across multiple paths on the same network might also be taken into account.
Routing maintenance and memory utilization should also be examined, as well as a map of the overall network indicating addresses and protocols in use.
Routing on and off a Wide Area Network
For larger networks, various models and protocol combinations may be used:
Several Small Offices - If the network is relatively small (a dozen locations or less), not using a routing protocol might be preferable.  If a protocol is required, RIP may be the simplest solution. 
Hub and Spoke - For a large corporation with a central office and many satellite locations, this model might might be useful for each branch to connect to the central location to support enterprise resource planning using On-Demand Routing (ODR).  In this situation, the router in the hub needs to know how to reach each spoke, but the routers at the spoke locations only need a single location route.

Hub and Spoke WAN

If this environment uses frame relay, distance vector protocols may be advised against, as frame relay and ATM use virtual circuits allowing for logical interfaces residing within the same physical interface.  If distance vector protocols were used, a false routing loop might be detected as per split horizon.
Simultaneous routing of IPv4 and IPv6 traffic is supported by Cisco's EIGRP protocol running on Cisco equipment.
Mobile Users

Mobile users present special challenges for networks, especially configurations which are rearranged in ad-hoc ways.  Many new technologies have emerged in recent times including 802.11 wireless, broadband wireless, and the proliferation of smartphones.  Currently, DHCP is the main tool used to manage these connections from the point of view of IP.  This raises the question of how a host which doesn't 'belong' to a local subnet can function, in which there are various solutions:
Mobile IP - Defined by IETF in multiple RFCs including 2003-2006 and RFC 3220.  Allows an IP host to travel anywhere within the proximity of a Mobile IP agent (router configured with this protocol) to maintain home IP address.  The host uses ICMP Router Discovery to determine which network it's on;  If the network is foreign it registers with a Foreign Agent which routes the packets to the Home Agent (which establishes a tunnel to the Foreign Agent).
Local Area Mobility (LAM) -  Cisco proprietary feature similar to Mobile IP but operates by using the routing table.  It is considered simpler and has less of an impact upon the network.  When the router is configured with LAM, it listens to traffic on the LAN which does not match it's own IP address, installing an ARP entry in the cache and a host route (route entry with 32 bit subnet mask) in the routing table.  This enables other routers to learn and forward the host route traffic.  Hosts within the subnet can communicate with the mobile node via router subnet proxy ARP.
Routing to and from the Internet
BGP is the exterior routing protocol used for the internet.  It requires a major hardware investment, but only a few networks are complex enough to require it (only networks which connect to multiple internet providers should need it; in this case it is preferable to use a default route from each ISP and configure BGP and IGP redistribution to determine this default).  It remains an essential component of the internet backbone.  BGP is a distance vector protocol which tracks hops between pairs of autonomous systems rather than between routers.

As an example of how it works, assume AS 100 advertises a route to network into AS 200 and AS 2000.  When a route is advertised out of an initial AS, the BGP uses the AS number.  As the latter two addresses receive ' 100,' AS 200 then advertises it to AS 300, prepending the AS number giving AS 300 the route of ' 200 100.'  AS 2000 and AS 300 also advertise the route to AS 3000 doing the same, which gives AS 3000 the routes of ' 2000 100' & ' 300 200 100.'  This makes AS 3000 prefer the short path through AS 2000 and AS 100.
Securing Routers and Routing Behavior
Securing routers is similar to securing host systems.  It is recommended to disable unnecessary services, listening ports, and to configure strong access security (as well as physical access), strong passwords and to use encrypted communications to the router, e.g. SSH.
Securing routing protocols is more difficult, as the information contained make internal systems easier to attack.  It is important to consider where routing protocol traffic will be visible.  Communications which cross a network should use OSPF or another secure network routing protocol.
Further Reading

Dijkstra's algorithm

Enhanced Interior Gateway Routing Protocol

Mobile IP
Open Shortest Path First (OSPF)

Border Gateway Patrol (BGP)

Configuring OSPFv3

NAT Router Security Solutions

Router Security and Infrastructure Protection