[sllug-members]: mac address

[Lamont R. Peterson]

On Saturday 15 July 2006 00:15, Shaun Kruger wrote:
> On 7/14/06, brian Beck <brian at planetbeck.com> wrote:
> > on a discussion on another board, the subject of a isp knowing the mac
> > address of computers behind a firewall came up, It was my understanding
> > that the ISP can find out the mac address of computers behind a
> > firewall/router, is it possible or am I misunderstanding the tcp/ip
> > protocols?
>
> You can't find out the mac of a computer that is on the other side of
> a router.  When you have a gateway doing NAT the internal addresses
> (192.168.x.x) are not visible from the outside world.  The mac address
> is just the physical hardware address that becomes associated with a
> particular ip address.  You can see this mapping by doing arp -a in
> windows or cat /proc/net/arp in linux.

Linux has an "arp" command that is capable of seeing and manipulating the arp 
tables.

> Ethernet frames know nothing 
> of IP addressing.  When you send data over ethernet II it has a 6 byte
> destination mac, a 6 byte source mac (I forget order),

In both Ethernet II (RFC 894 [ http://www.faqs.org/rfcs/rfc894.html ]) and 
IEEE 802.3/802.2 IP Encapsulation (described in RFC 1042 
[ http://www.faqs.org/rfcs/rfc1042.html ]) frame formats, the Ethernet frame 
begins with Destination MAC address, then Source MAC address.  The 
destination MAC is first so that switches can make a decision as quickly as 
possible and, therefore, do not have to "store and forward" as much data for 
each frame.

> and a 2 byte 
> protocol type identifier

This is true of Ethernet II (RFC 894).  In IEEE 802.3/802.2 (RFC 1042), there 
are 7 bytes of extra info after the 2 MAC addresses and there the 2 byte Type 
field.  In both cases, the frame's payload follows the Type field.

> (original ethernet used this 2 bytes as a 
> packet length identifier).

That is wrong.

Ethernet II (RFC 894) is older than IEEE 802.3/802.2 IP Encapsulation (RFC 
1042).  In 802.3/802.2 frames, the format is:

    6      6    2 1 1 1  3   2     38-1492       4
----------------------------------------------------
| Dest |  Src |LN|D|S|C|Org|TP| IP packet ... | CRC|
----------------------------------------------------

The numbers are the length of each field in bytes.  Here are the fields names 
(the abbreviations above are mine):

* Dest/Src - These are the MAC addresses.
* LN - Length
* D - "DSAP", which should always be 0xAA for IP packet carrying frames.
* S - "SSAP", which should always be 0xAA for IP packet carrying frames.
* C - "Control Code", which should always be 0x03 for IP packet carrying 
frames.
* Org - "Org Code", which should always be 0x00 for IP packet carrying frames.
* TP - The "Type" of payload this frame carries, which will be 0x0800 for IP 
packet carrying frames..
* IP Packet - *If* the Type is 0x0800, then the payload will be an IP packet.  
It's length can be anything between 38 and 1492 bytes (meaning, the frame has 
to be at least 64 bytes long).
* CRC - A CRC32 "checksum" of the entire frame (of course, omitting the CRC32 
itself).

An Ethernet II (RFC 894) frame is simply:

    6      6    2     46-1500       4
---------------------------------------
| Dest |  Src |TP| IP packet ... | CRC|
---------------------------------------

One other thing about these two frame formats; according to RFC 1122 
[ http://www.faqs.org/rfcs/rfc1122.html ], Ethernet connected devices with IP 
stacks:

1.  MUST be able to send and receive packets using RFC 894 encapsulation.
2.  SHOULD be able to receive RFC 1042 frames intermixed with RFC 894 frames.
3.  MAY be able to send packets using RFC 1042 encapsulation.  If the device 
can send both types of packets, the type of packets sent must be configurable 
and the configuration option MUST default RFC 894 frames.

The long and the short of all that is that since you have to support Ethernet 
II and you have to default to Ethernet II even if you support 802.3/802.2, 
that almost all traffic you will typically see in 10/100 Ethernet networks 
will be Ethernet II (RFC 894) frames.

Of course, with 1000Mbps Ethernet, there are additional frame formats that are 
supported, including so-called "jumbo" frames, which be something like 9000 
bytes long.

> The destination mac lets a machine know it 
> is supposed to receive or ignore the frame.  It then checks to see if
> it has a handler for the protocol type ID.

Essentially correct.

The key thing to remember is that a layer 2 frame only exists from one node to 
another.  When talking about IP routing, when a frame reaches a router (or 
any other node for that matter), the frame is stripped off and the IP packet 
is passed up the stack.  When the routing code notices that the packet is not 
destined for "this" device, it makes a routing decision and sends the packet 
back down the stack where it gets a new frame and sent off to it's next hop.

> If you wanted to find out what machine on an internal network accessed
> a certian site a gateway would have to remember all the external
> addresses that were connected to and what internal addresses requested
> each connection.  It would also have to log the mac address of the
> internal address for each connection (DHCP can assign the same address
> to a new machine with a different mac).
>
> It's not impossible, it's just that no one is doing it.

Since the memory/storage requirements would be so high, as Shaun points out.  
It's not uncommon for me to see several hundred thousand packets traverse my 
DSL line in a single evening at home.

> Shaun
>
> > I.E. a person uses a wireless card to access your wireless lan to lookup
> > porn can the isp tell which computer did the lookup/protection from
> > prosecution

No.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://sllug.org/pipermail/sllug-members/attachments/20060715/f2e5304a/attachment.pgp