WildPackets
go
Solutions
Products
Support
Resources
News & Events
Partners
Buy Now
 
 

Resolution Of Physical Addresses

So, a device uses its routing table to determine the destination for a frame. The "destination" from the routing table is either an IP address or the awareness that the frame should be delivered directly. Furthermore, the destination may be perceived to be on the same subnet to begin with and the routing table isn't even consulted. In every case, when a station (be it an end-node or a router) wants to send a frame to some particular IP destination it must first figure out what data link destination address will be used in the frame. This is referred to as the process of Address Resolution.

There are two methods used for address resolution in IP networks. The first method, used in IP Version 4, uses ARP (Address Resolution Protocol); this method has been used since the 1970's and is considered the standard. The new method, in IP Version 6 (IPng, "IP Next Generation"; the final drafts of which came out in January, 1995) which uses ICMP (Internet Control Message Protocol) for address resolution.

ICMP has, as a protocol, been in use since the 1970"s but its use in address resolution is brand new with IP Version 6. In 1996, the deployment of IPng (Version 6) is limited and it will surely be a number of months before the implications of ICMP resolution become significant to most networks. Consequently, in this document only the ARP method of address resolution will be examined in detail.

An ARP frame has four significant fields relative to our discussion. These are:

  • Sender's Hardware Address - The data link address of the sender
  • Sender's Protocol Address - The IP address of the sender
  • Target Hardware Address - The data link address of the target being sought
  • Target Protocol Address - The IP address of the target being sought

Some slight reflection will lead you to correctly conclude that all four of these fields are not filled in by the sender of an ARP frame. If I want to know the data link address being used by 160.6.2.3 then I will put 160.6.2.3 in the Target Protocol Address field and, typically, I will set the Target Hardware Address field to zero's; I don't know the hardware address of 160.6.2.3 - That's what I'm looking for.

I send this ARP Command frame to the Ethernet or Token-Ring broadcast destination - everyone on the cable hears the frame. If 160.6.2.3 hears the frame then it responds with an ARP Reply. In the ARP Reply, 160.6.2.3 supplies its data link (hardware) address. In this way I know the association between the IP address and the data link address; I have resolved the IP address.

The association between IP address and data link address is recorded in a temporary memory table referred to as the ARP Cache. The ARP Cache tells a station what data link destination address to use for every IP destination address.

When a station first boots up it must ARP for the IP address of the Default Gateway. Additionally, prior to sending to any destination IP address, there must be an entry in the ARP Cache associated with that destination IP address. The ARP Cache is dynamic. Entries age out after just a few seconds if they are unused. Consequently, during a typical conversation a station ARPUs for the destination once at the beginning and then the entry remains in the ARP Cache for the life of the connection (assuming the connection is active).

The two tables (the Routing Table and the ARP Cache) form the basis for frame transmission and forwarding. The address mask serves as the guide for interpreting the IP address. The Default Gateway is the destination specified in the routing table to use when no other destination can be ascertained. The idea of a default destination has no corresponding behavior in the ARP Cache.

.
MyPeek Forum Blog Contact Us About WildPackets
Solutions
Application Performance
Lawful Intercept
Deploying & Testing Applications
Distributed Networks
Network Baselining
Network Forensics
Network Performance Analysis
- NetFlow

Network Performance Management
Network Security
Network Troubleshooting
Product Development Support
VoIP Monitoring and Analysis
Video Monitoring and Analysis
Wireless Network Analysis
10 Gigabit Networks
Industry Specific Solutions
Products
WatchPoint
OmniFlow Collector
NetFlow Collector
sFlow Collector
OmniPeek Network Analyzer
Compass Live
OmniEngine Software Probe
OmniVirtual VMware Probe
TimeLine Network Recorder
Omnipliance Network Recorder
OmniAdapter Analysis Cards
Omnipliance Portable
Support
Product Support
Product Activation FAQs
Maintenance Programs
Product Versions
Contact Tech Support
Downloads
Training / Courses
Consulting
Custom Engineering
WildPackets Forums
MyPeek Community Portal
Resources
White Papers
Information Kits
Video How-To's
Product Tips and Tricks
Networking Glossary
Networking Links
Free Utilities
News & Events
Press Releases
Media Coverage
Media Kit
Blog
Peeks Newsletter
Success Stories
Reviews & Awards
Upcoming Events
Webinars & Webcasts
Partners
Technology Partners
Industry Alliances
Channel Partners
Training Partners
Partner Portal
Buy Now
Software
Software Upgrades
Hardware
Training
Maintenance Renewal
Per Incident Support
Sales Policies
Contact Sales

COPYRIGHT © 2012 WILDPACKETS, INC   |   Privacy   |   Sitemap
All registered and unregistered trademarks are the sole property of their respective owners