Ethernet – Detecting different Ethernet frames

ethernetprotocol-theory

How can someone distinguish between different packets in the Ethernet protocol? It has no "length" field/area as higher-level protocols use to do so.

Because this protocol has handling in both the physical and the logical scopes, I assume that the distinction is also separated.

Is the logical separation performed using the "EtherType" protocol field? (i.e. obtaining the packet length using the type of the higher-level protocol, that has a length field in it's headers).

Is the physical distinction is simply non-transmission of electrical signals? (To my knowledge, high/low electrical signals are representing 0/1 bits).

Best Answer

Although ytti answered, there are some relevant details you may be interested in...

How can someone distinguish between different packets in the Ethernet protocol? It has no "length" field/area as higher-level protocols use to do so.

Actually ethernet has multiple encapsulations:

Ethernet II (Typically used for IP, as specified in [RFC 894], is the most common encapsulation): Does not have a length field, instead a type field is used...

       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)

802.2 LLC Ethernet: has a length field

       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | Data | FCS |
       +----+----+------+------+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Regardless of the existence of 802.2's length field, you can always detect the end of an ethernet frame on the wire by looking for the 96-bit Interframe Gap.

Is the logical separation performed using the "EtherType" protocol field? (i.e. obtaining the packet length using the type of the higher-level protocol, that has a length field in it's headers).

By logical separation, I assume you mean separation between different protocols carried inside ethernet, such is distinguishing between IPv4, IPv6 or perhaps Spanning-Tree Frames.

Ethernet II normally uses the Type field
802.2 LLC Ethernet normally uses the five-byte 802.2 Ethernet SNAP extension. Protocols are only decoded with the SNAP extension when the 802.2 DSAP / SSAP bytes are 0xAAAA.

Is the physical distinction is simply non-transmission of electrical signals? (To my knowledge, high/low electrical signals are representing 0/1 bits)

Simplistically, yes there is a 96-bit gap between Ethernet frames; however, note that ethernet uses an 8b/10b encoding (FastEthernet) and 64b/66b encoding (GigabitEthernet), so it's not technically correct to say the "non-transmission of electrical signals", since 8b/10b doesn't have a "silent" state.

For the curious, I'm also linking to the original Ethernet Version 2 spec.

Related Solutions

Ethernet – Why was the MTU size for ethernet frames calculated as 1500 bytes

The answer is in draft-ietf-isis-ext-eth-01, Sections 3-5. Ethernet uses the same two bytes different ways in the Ethernet II (DIX) and 802.3 encapsulations:

Ethernet II uses the first two bytes after the Ethernet source mac-address for a Type
802.3 uses those same two bytes for a Length field.

I'm including an annotated diagram below of each frame type, which shows exactly where the conflicting bytes are in the ethernet header:

RFC 894 (commonly known as Ethernet II frames) use these bytes for Type

    +----+----+------+------+-----+
    | DA | SA | Type | Data | FCS |
    +----+----+------+------+-----+
              ^^^^^^^^

    DA      Destination MAC Address (6 bytes)
    SA      Source MAC Address      (6 bytes)
    Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
    Data    Protocol Data           (46 - 1500 bytes)
    FCS     Frame Checksum          (4 bytes)

IEEE 802.3 with 802.2 LLC / SNAP (used by Spanning-Tree, ISIS) use these bytes for Length

    +----+----+------+------+-----+
    | DA | SA | Len  | Data | FCS |
    +----+----+------+------+-----+
              ^^^^^^^^

    DA      Destination MAC Address (6 bytes)
    SA      Source MAC Address      (6 bytes)
    Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
    Data    Protocol Data           (46 - 1500 bytes)
    FCS     Frame Checksum          (4 bytes)

Both Ethernet II and 802.3 encapsulations must be able to exist on the same link. If IEEE allowed Ethernet payloads to exceed 1536 bytes (0x600 hex), then it would be impossible to distinguish large 802.3 LLC or SNAP frames from Ethernet II frames; ethernet's Type values start at 0x600 hex.

EDIT:

I am including a link to pdf copies of the Ethernet Version 1 spec and Ethernet Version 2 spec, in case anyone is interested...

Ethernet SNAP frames – decision of type for upper layer still possible

Can Ethernet frames, with the length field used, still contain e.g. an IP packet?

Yes, you're asking about IP over 802.3 SNAP frames, which is covered in RFC 1042.

A 802.3 SNAP IPv4 frame looks like this...

+----+----+----+----+----+----+----+----+---------+-----+
| DA | SA |  L | DS | SS | CL | OI | ET | Payload | FCS |
+----+----+----+----+----+----+----+----+---------+-----+

DA: Destination Mac Addr (6 Bytes)
SA: Source Mac Addr (6 Bytes)
L: Length (2-Bytes); (Length <= 0x05DC hex, or 1500 decimal)
DS: DSAP (1-Byte); (DSAP == 0xAA hex, or 170 decimal)
SS: SSAP (1-Byte); (SSAP == 0xAA hex, or 170 decimal)
CL: Control (1-Byte); (Control == 0x03 hex, or 3 decimal)
OI: Organizationally Unique Identifier (3-Bytes); (OUI == 0x000000 hex, or 0 decimal)
ET: Ethertype (2-Bytes); (Ethertype == 0x0800 hex, or 2048 decimal)
Payload: Ethernet Payload (Ethernet Payload <= 1492 Bytes); this payload size includes the size of the IPv4 header.
FCS: Frame Checksum (4-Bytes)

If yes, how can a router or PC detect this?

By "detect this", I assume you mean IP over 802.3 SNAP; the SNAP frame is first distinguished from an Ether II / ARPA frame because Type / Length <= 0x05DC hex. Then the router looks at the other fields specified above...

Computers have to be explicitly configured with SNAP encapsulation, to include a lower-than normal MTU (IP MTU <= 1492 bytes). While it's theoretically possible to include 802.3 SNAP IPv4 in the broadcast domain as Ethernet II (ARPA), most people would think you're crazy to do so.

And what will a router typically do with a frame using length instead of Ethertype?

There aren't many 802.3 IP SNAP networks left... Cisco IOS used to process IPv4 over SNAP in the punt path; but I haven't looked at this in depth in a long time.

To test with recent Cisco IOS, I attempted to ping one of my Cisco 3560 switches (debug ip icmp enabled) with an 802.3 SNAP IPv4 frame, but the switch just gave me dumb looks...

[mpenning@tsunami ~]$ sudo python
Python 2.7.3 (default, Jan  2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from scapy.all import SNAP, Dot3, LLC, IP, ICMP
>>> from scapy.all import srp1
>>> pak = Dot3(dst="64:ae:de:ad:be:ef", src="80:ee:73:20:00:00") / LLC() / SNAP() / IP(src="10.0.0.5", dst="10.0.0.1") / ICMP()
>>> pak
<Dot3  dst=64:ae:de:ad:be:ef src=80:ee:73:20:00:00 |
<LLC  dsap=0xaa ssap=0xaa ctrl=3 |<SNAP  code=0x800 |
<IP  frag=0 proto=icmp dst=10.0.0.1 |<ICMP  |>>>>>
>>> srp1(pak)
Begin emission:
Finished to send 1 packets.
...................^C
Received 19 packets, got 0 answers, remaining 1 packets

Christian said: The background for this question is this: I would like to implement a proprietary protocol on top of 802.3 MAC frames and use the length field. So, what will using the length field imply for other hard- and software? E.g. will it be safe to send such frames to cots systems, which will not know about my protocol inside.

I personally would discourage you from implementing a private ethernet protocol; people did this kind of thing all the time twenty or thirty years ago, but it's increasingly rare to find custom protocols today.

Why? It just doesn't make sense for the exactly the reason you're asking. Practically the entire world uses "something" on top of IPv4 or IPv6.

UDP is available if you want a "connectionless" service
TCP or SCTP are good choices for "connection-oriented" services

What happens if you build your own protocol?

It's hard to talk to anything else, even on the same ethernet broadcast domain... because other things invariably are using IP and ethertype (RFC 894) frames.
You've got no routing (i.e. the capability to send traffic across multiple ethernet broadcast domains, such as the networks people build between cities and countries); this also means you could be doing stuff like bridging across the internet, which requires building IP tunnels.
Do you want network services? Guess what you get to build:
- Want file transfers? Build your own FTP or TFTP
- Want name resolution? Build your own DNS
- Want network errors and monitoring? Build your own ICMP protocols
- Want security? Build your own firewalls, encryption, and PKI (ick)
- Want to talk to other computers? Build kernel drivers for those operating systems (see below)

Speaking broadly, custom ethernet protocols require a kernel driver for all operating systems in question; do you really want to build and distribute a kernel driver? If you use IP it's simpler, because you can have services listening on top of an existing IP kernel driver; just bind to a port number and leverage the built-in IP kernel drivers.

However, building with IP comes at the cost of using Ethernet II (ARPA) encapsulation (i.e. no length field in the ethernet frame).

Maybe you still want to use your own custom ethernet protocol; at least by now you understand more about the associated tradeoffs.

Best Answer

Related Solutions

Ethernet – Why was the MTU size for ethernet frames calculated as 1500 bytes

Ethernet SNAP frames – decision of type for upper layer still possible

Related Topic