Ethernet over USB
Ethernet over USB has two meanings: Ethernet devices via USB and USB as an Ethernet network.
Ethernet devices via USB
The ability to connect Ethernet devices via USB ports is known as Ethernet over USB. There are many low-cost commercial adapters available to do this. The links below describe the technical details on how the technology works.
Treat USB as an Ethernet network
The USB-eth module in Linux emulates an Ethernet device that uses USB as the physical medium. Once created, this network interface can be assigned an IP address and otherwise treated as though it were ordinary Ethernet hardware. The USB-eth module allows the USB device to "see" a network, ping other IP addresses, and even "talk" DHCP, HTTP, NFS, telnet, and e-mail. In short, any applications that work over real Ethernet interfaces will work over a USB-eth interface without modification, because they can't tell that they aren't using real Ethernet hardware.
On Linux hosts, the corresponding Ethernet-over-USB kernel module is called usbnet. A recently announced usbnet-style driver for Win32 hosts is called the Bahia Network Driver.
The approach allows devices with very limited communications hardware to operate over IP networks. The Linux kernel for the iPAQ uses this communications strategy exclusively, since the iPAQ hardware has neither an accessible legacy (RS-232/RS-422) serial port nor a dedicated network interface.
There are numerous protocols de facto and de jure for Ethernet-style networking over USB. The main motivation for these protocols is to allow application-independent exchange of data with USB devices, instead of specialized protocols such as video or MTP. Even though USB is not a physical Ethernet, the networking stacks of all major operating systems are set up to transport 802.3 frames, without caring much what the underlying transport really is.
The main industry protocols are (in chronological order): Remote NDIS (RNDIS, a Microsoft vendor protocol), Ethernet Control Model (ECM), Ethernet Emulation Model (EEM), and Network Control Model (NCM). The latter three are part of the larger Communications Device Class (CDC) group of protocols of the USB Implementers Forum (USB-IF). They are available for download from the USB-IF (see below). The RNDIS specification is available from Microsoft's web site. Regarding de facto standards, some standards, such as ECM, specify use of USB resources that early systems did not have. However, minor modifications of the standard, so-called subsets, make practical implementations possible on such platforms. Remarkably, even some of the most modern platforms need minor accommodations and therefore support for these subsets is still needed.
Of these protocols ECM is by far the simplest—frames are simply sent and received without modification one at a time. This was a good strategy for USB 1.1 systems (current when the protocol was issued) with 64 byte packets but not for USB 2.0 systems which use 512 byte packets.
The problem is that Ethernet frames are about 1500 bytes in size—about 3 USB 2.0 packets, and 23 USB 1.1 packets. According how the USB system works, each packet is sent as a transfer, a series of maximum-length packets terminated by a short packet or a special ZLP (zero-length packet). After this, there is bus latency, where nothing is sent until another transfer can be initiated. This reduces bus occupancy, meaning that nothing is sent for considerable fractions of bus time. A gap every 23 frames is not noticeable, but a gap every three frames can be very costly to throughput.
As USB has gotten faster, devices have also gotten hungrier for data and so there is now demand for sending large amounts of data, either to be stored on the device, or be relayed over wireless links (see 3GPP Long Term Evolution).
Since the new devices, although faster than before, are still much lower in power than desktop PCs, the issue of careful data handling arises, to maximize use of DMA resources on the device and minimize (or eliminate) copying of data (zero-copy). The NCM protocol has elaborate provisions for this. See link below for careful protocol comparisons.