Integrated Ethernet Internetworking Protocol Mart Molle UCR Department of Computer Science & Engineering

Integrated Ethernet Internetworking Protocol

Mart Molle

UCR Department of Computer Science & Engineering

12 Nov 2010 Version 1.01 (c) Copyright Mart Molle 2010

2

Network Operation Primer

• “Edge” is dominated by IEEE 802 LANs– Primarily 802.3 Ethernet wired connections– Last hop might be 802.11 WiFi or similar– Every network card has a unique 48-bit MAC addr.

• “Core” is dominated by IP routing– A loose federation of Autonomous Systems– Everything works with 32-bit, location-dependent

IPv4 addresses, given by each Service Provider.

• I skipped many key details – we’ll be back!


3

Internet Core is Evolving towards Ethernet Links

• Ethernet has long dominated edge networks• Now core is adopting Ethernet framing too!

– Avoids conversion/encapsulation overhead– Used for ATM LANE, Packet-over-SONET– High speed Ethernet PHYs and carrier-class

features (nested VLAN tags) make it attractive

• Result: IP datagram encapsulated in Ethernet MAC frame will be a universal packet format.


4

So What?

• The world is running out of IPv4 addresses…– Source: Wikipedia, IPv6 (one “/8” = 224 addresses)


5

IPv6 “solves everything” by jumping from 32 to 128 bits

• Indeed, IPv6 assumes:– Fixed-size 64-bit network numbers– 64-bit host addresses (derived from MAC address)

• No need for manual configuration or DHCP• 48-bit addresses are now common in 802 networks

– Ethernet, Token Ring, 802.11, Bluetooth

• 64-bit addressing will be used for future systems– Firewire, 802.15

• Why duplicate host address in every packet?


6

What is Possible if All Internet Traffic becomes “IP over Ethernet”?

• All packets throughout the Internet will have a predictable format:– an IP datagram on the inside, where:

• Source = Alice’s IP address• Destination = Bob’s IP address• Other options…

– an Ethernet frame on the outside, where• Source = MAC address of first device on this VLAN• Destination = MAC address of last device on this VLAN• EtherType = IP


7

“IP over Ethernet” Primer

• Initially, Alice knows her MAC address.– No configuration needed:

• She a “flat” address, supplied by manufacturer• Bridges “learn” packet forwarding by watching traffic

• IP settings are location-dependent– Configuration can be done manually, or via DHCP:

• She needs the IP addresses for herself, the name server, and default gateway (router)

• She also needs the “subnet mask” for determining the locality of other IP addresses


8

Alice wants to send a packet to Bob

• Alice gets Bob’s IP address from a name server• Setup has IP address for name server, so she can’t be stuck!

• Alice tests Bob’s IP against her subnet mask– If they match, Alice sends packet directly to Bob’s

MAC address– Otherwise, Alice sends packet to the MAC address of

her default gateway (IP router)

• Alice sends ARP broadcast request to target IP– ARP response returns target’s MAC address to Alice


9

Local Communications useOnly MAC Addresses

• Alice and Bob are on the same IP Subnet/VLAN– Alice’s stack creates both IP and MAC headers– Alice’s network card sends the MAC frame

– 802 Bridges use (only) MAC addresses for packet forwarding and/or filtering; IP header is just payload.

– Bob’s network card accepts frames to its MAC address– Bob’s stack strips both IP and MAC headers

• IP headers did nothing except occupy space!


10

Inter-Domain Communications use Only IP Addresses

• Inter-domain paths are managed by IP routers– “Next-hop” forwarding decisions use longest prefix matching

between destination IP address and routing table entries– Layer-2 headers are not consulted in IP forwarding

• If Packets from Alice to Bob cross the “Internet Core”– MAC header generated by Alice is stripped by the first IP

router (Alice’s default gateway)– MAC header received by Bob is generated by the last IP

router (Bob’s default gateway)– Only the IP datagram generated by Alice is sent to Bob


11

If Routers X and Y Connect through an Ethernet Link

• Every IP datagram forwarded from X to Y must be encapsulated in an Ethernet frame generated by X:– MAC source = X’s network port on this link– MAC destination = Y’s network port on this link, and – EtherType = IP

• Y discards the Ethernet header without looking at it– Only action is Y’s network interface discarding frames

without its MAC address in destination field

• Local Ethernet headers simply take up space!


12

Why not let Ethernet headers carry the endpoint MAC addresses end-to-end?

• No change, if both endpoints are on same subnet.

• IP Routers need a new MAC header-update rule:– Source MAC = original sender (not previous router)– Destination MAC = final destination (not next router)– Routers forward MAC addresses (act like Bridges)– No change to IP route selection (which ignores contents of

MAC header anyway)

• Result: 48-bit MAC address becomes de facto IP host number, releasing 32-bit IP address for network ID


13

Let’s Define MAC Address to Be the IP Host Number

• Integrated 32-bit IPv4 + 48-bit MAC addresses– Each host is identified by an 80-bit (IP+MAC) address:

• IPv4 header addresses = 32-bit network numbers• Ethernet MAC header addresses = 48-bit host numbers

– Huge increase in Internet address space– No change in packet size or format!

• Total overhead (including MAC header) is 80 bits for each host address, 160 bits per packet

• Address “footprint” is identical to current system, but a single MAC host number does double-duty for two protocol layers

Provision for Networks with 64-bit MAC Addresses

• 48-bit and 64-bit MAC addresses are designed to interoperate– “Well-known” 16-bit extension 0xFF-FE maps

each 48-bit MAC address to a unique, reversible 64-bit MAC address

• Define a new EtherType that “tags” the next two 16-bit values as extensions of the previous 48-bit SRC and DST fields


14


15

Comparison to IPv6 with MAC-based Host Numbers

• IPv6 addresses are 128-bit values partitioned into:– 64-bit network number– 64-bit host number derived from host MAC address

• Same host number is repeated in MAC header

• Total “cost” (including MAC header) is 176 bits for each host address, 352 bits per packet– 120% more overhead than Integrated (IP+MAC) solution– 40% more address space available (for more networks)

Is it Really that Easy?

• Let’s review in detail, the effects on:– End host packet processing– Packet processing at 802.1 bridges– Packet processing at a single IP router– Forwarding through the Internet “core”

• What operational changes are needed?

• What about scalability?


16

“IP and Ethernet” Revisited:Initial Configuration

• Initially, Alice knows only her MAC address.

• Introduce “well-known MAC addresses” for accessing “my provider” of basic services:– Local provider of name resolution service– “Subnet manager” (aka default gateway / router)

• You can get IP network number without needing DHCP• Subnet mask disappears (always “0xFFFFFFFF”)

• Name resolution eliminates ARP broadcasts– Name server returns (IP + MAC) address pair


17

IPv6 has Stateless Address AutoConfiguration (SLAAC)

• Host sends an ICMPv6 router discovery message– Destination address is reserved “IPv6 link-local

multicast address”– Meaningless to layer 2 bridges; requires broadcast

MAC destination address

• Router returns a router advertisement packet with network-layer parameters


18

Alice wants to talk with Bob

• Alice contacts “her” name server through its well-known MAC address– Query is Bob’s domain name– Response is Bob’s (IP + MAC) address

• IP subnet mask test still works, but irrelevant!– If Alice’s IP = Bob’s IP, Bob is on “my” network

• Packet carries both Bob’s IP and Bob’s MAC addresses

– Otherwise, Bob is beyond “my” default gateway• Packet still carries Bob’s IP and Bob’s MAC addresses


19

Packets Traveling Through Alice’s “Local” Subnet/VLAN

• Each packet has Bob’s (IP + MAC) for destination, Alice’s (IP + MAC) for source

• If Alice and Bob are on a single Subnet/VLAN:– 802.1 Bridges see no change, act normally

• MAC address learning/filtering operates normally

• (doesn’t care if source/destination IP addresses match)

– Bob’s protocol stack sees no change either• NIC accepts packet with destination = Bob’s MAC

• Protocol stack finds destination = Bob’s IP as expected

– Only issue: Do host IP stacks “break” with identical neighbor addresses?


20

What Happens when Bob is not on Alice’s Local Subnet/VLAN?

• Bridges broadcast packets with an unknown destination MAC address– Clearly, Alice-to-Bob packet must reach the

default gateway (router)– Assume router “does the right thing”

• When Bob replies, all bridges will learn his location is behind the default gateway– Bridges send further traffic to Bob directly to the

default gateway (and nowhere else).


21

Difficulties for 802.1 Bridges

• Number of entries in MAC address filtering database (CAM) will be much bigger!– Includes all peers across the Internet, not just

hosts on local VLAN– High-capacity CAMs are too expensive to accept

such a design!

• However, every “alien” MAC address is co-located with the default gateway…


22

Solution via Meta-Data

• Bridges already understand forwarding policies not based on MAC addresses– 802.3x PAUSE frames are addressed to a

reserved group address (= my neighbor)– Spanning Tree Protocol control packets

are addressed to another reserved group address

– Link Aggregation control packets also…


23

“Alien” MAC as a Special Case

• Let’s just map “alien” MAC addresses to something easy to process– “well-known MAC” of default gateway– No need for Bridges to learn individual

“alien” MAC addresses• Task is simply to recognize “aliens”• Then the packet is processed as if it carried the

well-known default-gateway MAC instead


24

Advertise “Alien” Status via EtherType Field

• We shouldn’t use existing EtherType for IPv4• What if new EtherType had 4 values, encoding:

– Source MAC address type (“alien”/”local”)– Destination MAC address type (“alien”/”local”)

• “Internet Bridges” can use EtherType to identify “aliens”– “Alien” source addresses are ignored– “Alien” destination addresses are mapped to “well-known MAC”

of default gateway– Size of CAM = number of hosts in VLAN


25

Aside Comment about Optimizing Local Connections

• Host IP stack needs to understand the new multi-valued EtherType encoding

• We can easily compress the IP header by dropping each local IP address– Provides room for local options between host and

default gateway (eg, flow control)– Less overhead for high performance clusters and

large data centers


26

“Null-IP” Layer can be Tied to “local”+ “local” EtherType

• The “local SRC+local DST” EtherType could signal a special-case “null” IP header– EtherType tells you both SRC and DST addresses– Nobody will see any other IP header fields until after

the packet has arrived at Bob– Bob only looks at the next Protocol number (e.g., TCP)

• Keep that field and discard the remaining IP header

• We’ll come back to this concept later!


27

Implications for Designing an “Ethernet Router”

• Destination MAC address = endpoint, not router!– Routers must use promiscuous receive on its “default

gateway” interface• Traffic to gateway carries alien-destination Ethertype• Other traffic to this router carries MAC address of its port• All other traffic can be discarded

• Same Destination MAC address put on next hop– MAC-level packet header manipulation is identical to

well-known behavior of an 802.1 Bridge


28

No Changes to Router Functions Beyond MAC Header Rule

• IP Route selection for each IP destination finds the “best fit” rule from its routing table– Each rule has a “mask” to drop some low-order bits– Mask always drops the host-address field, because rules

are for networks not individual hosts– Dropping more bits creates route aggregation

• one rule covers many networks at once

• (IP+MAC) addresses put all network info in IP field– No loss of function because rules are only for networks


29

Support for Dumb/Fast Switches in the Core

• Several generations of Internet “core” architecture have used dumb switches surrounded by IP routers:– ATM LAN Emulation, Packet-over-SONET– Multi-Protocol Label Switching (MPLS)– IP over Lambda (wavelength couplers)

• Integration of Ethernet and IP offers something similar


30

VLAN-Specific Default Gateways

• Each VLAN Tag has a 12-bit VLAN Identifier (plus 8-level priorities)

• Let “default IP gateway” be VLAN-specific!– One “core cluster” of 802.1 Bridges can connect 4,096 distinct

IP routers

• Fast forwarding path only uses VLAN Tag + EtherType– Management and route-update packets are addressed to the

MAC addresses of the router ports – small CAM is enough!– All other traffic goes straight to the port pointing “downstream”

towards the default gateway for its VLAN


31

Aside Comment about Wasting IP Subnet Numbers in Backbone Links

• IPv4 addressing has two “reserved” host numbers:– “all zeros” identifies the network– “all ones” is reserved for broadcasting to all– All other values represent host connections to this network

• Thus one point-to-point Ethernet link between two IP routers consumes four IPv4 addresses

• RFC 3021 lowers the cost to two addresses per link, but argues that every router port must have a separate IP address on a different IP network for diagnostics and management


32

With (IP+MAC) Addressing, One IP subnet per Router is Enough

• Apply VLAN-tagging to all point-to-point connections between neighboring routers– Assign router “X” to be the default gateway for “VLAN-X”

– Add “VLAN-X” to all point-to-point links that connect to router “X”

• If routers “X” and “Y” are connected by link XY, then– This port on router “X” must have unique (IP+MAC) addresses belonging

to at least two IP subnets (“VLAN-X” and “VLAN-Y”)

– Furthermore, those addresses can include the MAC address for the port, rather than the well-known MAC for a default gateway.

• This lowers the number of IP subnets consumed from O(N2) links to O(N) routers


33

A Word about NAT Gateways

• This whole idea started as a rebuttal to a Network World article slamming NAT

• (IP + MAC) addressing can “promote” all NAT’d hosts to fully IP routable status– Replace all “private” 32-bit IPv4 host addresses by

individual 80-bit (IP+MAC) addresses• 32-bit IP comes from your gateway• 48-bit MAC comes from your NIC

– No need for port mapping at the gateway


34

Partial Deployment of (IP+MAC) Addressing

• Two “worlds” are separated by a “gateway”– Translates between incompatible header formats – Nameserver must also be aware of both worlds– Local connections (obviously!) work as planned

• This is a hard problem in general!– IPv6 gave up trying to make a translating gateway

• Their task is harder because semantics of IP changed

– Only encapsulation of one version of IP inside another is supported (Hosts run both stacks)


35

“Legacy” IPv4 Packets in an80-bit (IP+MAC) “World”

• MAC address in an IPv4 packet can’t be trusted– It is not the source-host MAC address unless the

(IP+MAC) gateway is on the same VLAN

• Want minimal processing at “border gateway”– Hard to split IPv4 into network and host due to CIDR

• Rules are subnet-dependent, and not carried in each packet• Even route updates are unreliable due to route aggregation

– Just set both MAC addresses to a fixed, well-known value = “Legacy IPv4 Host”

• Processing at “border gateway” is trivial (and stateless)


36

Result: Transparent IPv4 “Tunnels” Across (IP+MAC) Networks

• “Legacy” IPv4 networks expect Ethernet headers to change at every subnet– Entry to (IP+MAC) domain fixes them to reserved

“Legacy IPv4” MAC addresses– Exit to another IPv4 domain resumes normal

behavior

• IPv4 route-advertisement protocols shouldn’t notice the presence of (IP+MAC) domains

• Only issue is how to reach the other “world”


37

Why Not “Strip” the Host Field from Legacy IPv4 Addresses?

• Suppose Alice’s IPv4 address is “a.b.c.d/24”– Her subnet mask lets us split the address into:

• “a.b.c.0” = her “legacy” IPv4 network number• “0.0.0.d” = her host number on that network

– Only Alice’s IPv4 network number a.b.c.0 must be in 32-bit IP field under (IP+MAC) addressing

– Suppose we filter out host numbers from IPv4 addresses• Never mind the question of where to store it!

– Can Alice’s individual IPv4 address by “reclaimed” for other purposes in the (IP+MAC) world?


38

One 32-bit IP Value can’t be both an IPv4 Host and an (IP+MAC) Network

• Suppose Alice’s IPv4 address is a.b.c.d/24– (IP+MAC) gateway could map it to a.b.c.0, as long as we created

a separate representation for her host number– Can we then assign a.b.c.x/32 to an (IP+MAC) network?– No! (IP+MAC) network number a.b.c.x is indistinguishable from

host 0.0.0.x on IPv4 network a.b.c.0

• Withdrawing a.b.c.0 from the IPv4 world fixes it:– Don’t care if IPv4 thinks a.b.c.x is a host on network a.b.c.0/24– We just need them to agree it is beyond the (IP+MAC) gateway

• Result: no reason to change Alice’s IPv4 address inside the (IP+MAC) world


39

Access to (IP+MAC) Servicesfrom “Legacy” IPv4 Hosts

• IPv4 hosts don’t understand (IP+MAC) addresses– Alice’s IPv4 DNS server has no means to give her the

MAC field from Bob’s (IP+MAC) address

• Alice cannot distinguish between individual hosts who share Bob’s 32-bit IP network number– Alice sees every (IP+MAC) network as a NAT system,

with “private” MAC-based host addresses inside

• Even if Alice had Bob’s MAC address, she can’t use it on her legacy IPv4 over Ethernet network!


40

Create an IPv4 Proxy Server for Each (IP+MAC) Network

• Let’s define the “role” of IPv4 Proxy Server for packets with destination MAC address = “Legacy IPv4 Host”– Maps “well known” services (web, mail, etc) to internal provider(s)– Maintains state about open connections, like a NAT gateway

• Scalable because burden is distributed across all IP networks, not concentrated at one border crossing between “worlds”

• Supports routing via alternate border crossings– “state” is kept at the endpoint, not the boundary


41

Role of Proxy: “Alice” = IPv4 host, “Bob” = (IP+MAC) host

• Addresses in IPv4 “World”:– Bob’s IPv4 address = Bob’s 32-bit IP network number

– Everyone’s MAC addresses are unimportant

• Alice’s address in (IP+MAC) “World” :– 32-bit IP network = Alice’s IPv4

– MAC address = Reserved “Legacy IPv4 Host”

• Bob’s address in (IP+MAC) “World” (not for native traffic)– 32-bit IP network = Bob’s IP

– MAC address outside Bob’s network = Reserved “Legacy IPv4 Host”

– MAC address inside Bob’s network = Bob’s actual MAC

• Proxy may do port remapping if multiple hosts talk to Alice


42

Simple Translating Gateway From IPv4 to (IP+MAC)

• Suppose Alice wants to connect with Bob– IPv4 Name server returns (only) Bob’s 32-bit IP network number– Alice uses her subnet mask to determine he is not local

• Alice sends packet with separate IPv4, MAC addresses:– SRC: (Alice’s IPv4 address, Alice’s MAC) – DEST: (Bob’s IP network number, Alice’s router MAC)

• Gateway rewrites header(s) into (IP+MAC) format:– SRC: (Alice’s IPv4 address, Reserved “Legacy IPv4 Host”)– DEST: (Bob’s IP network number, Reserved “Legacy IPv4 Host”)

• Reserved MAC values tell Proxy sender is an IPv4 Host


43

Simple Translating Gateway From (IP+MAC) to IPv4

• Proxy for Bob’s network sends (IP+MAC) packet:– SRC: (Bob’s IP network number, Reserved “Legacy IPv4 Host”)– DEST: (Alice’s IPv4 address, Reserved “Legacy IPv4 Host”)

• Gateway rewrites with separate IPv4, MAC addresses:– SRC: (Bob’s IP network number, Gateway port MAC)– DEST: (Alice’s IPv4 address, MAC for Alice or next IPv4 Router)

• Alice receives packet with expected IPv4, MAC addresses:– SRC: (Bob’s IP network number, Alice’s router MAC)– DEST: (Alice’s IPv4 address, Alice’s MAC)


44

Result: Simple Translating Gateway Works -- Mostly

• An (IP+MAC) host can connect to anyone:– Any (IP+MAC) host– Any IPv4 host, through its local IPv4 Proxy

• An IPv4 host can connect to:– Any IPv4 host– “Well-known” services offered by (IP+MAC) networks, through the

IPv4 Proxy for the (IP+MAC) network

• IPv4 tunnels over (IP+MAC) networks are easy• (IP+MAC) tunnels over IPv4 networks unsupported


45

What if Host “Alice” on an IPv4 Network Learns (IP+MAC)?

• IPv6 requires hosts connected to both “worlds” to:– Run both IPv4 and IPv6 protocol stacks– Include nested headers in every packet

• Is (IP+MAC) Addressing more flexible than this?– Let’s assume that “Alice” is a host on an IPv4 network

who understands (IP+MAC) addresssing– Her network doesn’t understand (IP+MAC) addressing– Border crossing is handled by stateless gateways– (IP+MAC) networks have no stateful proxy servers


46

Adding (IP+MAC) Addressing to a Standard IPv4 Datagram

• Alice can get (IP+MAC) addresses from an 80-bit name server– Bob’s 32-bit IP number fits the IPv4 address field

• She needs a “safe” place for Bob’s MAC field• Must be invisible to Ethernet and IPv4 layers

– Cannot allow those layers to change Bob’s address– Alice can’t break her existing network connection

• Must be placed after the MAC and IPv4 headers


47

Recursively Embed a Second Ethernet Header after IPv4

• IETF IP needs to assign a protocol / next header value for (embedded) Ethernet header– No need to add a second CRC error check at end!

• Second Ethernet header has room for two MAC addresses, plus another EtherType

• Allows more Ethernet options before continuing– Optional MAC address extension EtherType lets us

support 64-bit host numbers


48

What Value Should Alice Givefor her Own MAC Field?

• Alice’s true MAC address is useless to Bob– It would be replaced by some intermediate IPv4

router long before the packet reached Alice

• Reserved “Legacy IPv4 Host” MAC is worse!– Tells Bobs she doesn’t understand (IP+MAC)

• Why not use the MAC field to encode Alice’s IPv4 host number?– Knowing the host part makes it easy to isolate the

network part, which might be useful


49

Representation of IPv4 Host Number in MAC Address Field

• IPv4 host numbers are at most 24 bits long (maximum size is for Class A networks)

• For MAC addresses, a single OUI gives you 24 assignable bits– Let’s reserve one OUI for encoding IPv4 host

numbers in an (IP+MAC) network• Uniqueness can’t a problem with valid IPv4 addresses

– Since the OUI is public, the split IPv4 address can easily be reconstructed later


50

Recap on Packet Header as Seen on Legacy IPv4 Networks

• First is standard Ethernet MAC header• EtherType = IPv4

• Second is standard IPv4 header• Includes IP addresses for Alice and Bob• Next protocol = Ethernet

• Third is (embedded) Ethernet header• Source MAC = encoding of Alice’s IP host• Destination MAC = Bob’s MAC• EtherType = ?? (we want to continue after IP)


51

Embedded Ethernet Header Continues with “Null IP”

• “Null IP” skips addresses, preserves next protocol field• Size of “Null IP” header should be about 16-32 bits

• Size of IPv4 “Next protocol” or IPv4 “next header” is only 8 bits

• Incremental cost of embedding (IP+MAC) addressing information inside a standard IPv4 datagram is very low– 2 * 48-bits for MAC addresses– 16 bits for “Null IP” EtherType– Total is less than 132 bits! (basically one IPv6 address)

• Extended host addresses increases the total by 64 bits


52

Alice Sending a Packet to Bob, Revisited Yet Again

• Alice is IPv4 host who understands (IP+MAC)• (IP+MAC) name server gives Bob’s full 80-bit address

• Alice’s packet starts with IPv4, MAC addresses:• SRC: (Alice’s IPv4 address, Alice’s MAC) • DEST: (Bob’s IP network number, Alice’s router MAC)

• Embedded Ethernet header following IPv4 adds:• SRC: Reserved OUI + Alice’s IPv4 host• DEST: Bob’s MAC from his 80-bit address


53

Legacy IPv4 over Ethernet Network(s) See Nothing Odd

• Layer-2 Bridges in each subnet/VLAN • use MAC header to make forwarding decisions

• IPv4 Routers use IPv4 header for route selection• Rewrite MAC headers for each new subnet as usual

• When the packet reaches the border gateway• MAC addresses in Ethernet header are meaningless• IPv4 addresses should not been modified• Embedded MAC addresses were never looked at


54

Revised Packet-Manipulationat Boundary Gateway

• Addresses in IPv4 header are never changed– Alice’s IP is always her complete IPv4 host address– Bob’s IP is always his 32-bit IP network number

• Uses 3 distinct classes of MAC addresses– Individual, globally unique MAC address for a host– Reserved constant value = “Any Legacy IPv4 Host” – Reserved OUI = “Encoded IPv4 Host Field”

• Gateway may need to relocate an address and/or create a replacement of another class


55

Case 1: Move Packet from IPv4 Network to (IP+MAC) Network

• If packet has no embedded Ethernet header– Sender doesn’t understand (IP+MAC) addressing– Set Source MAC = Destination MAC = “Legacy IPv4 Host”

• Otherwise, sender must understand (IP+MAC) addressing– Use sender-supplied MAC values from embedded Ethernet header

• If embedded MAC address for sender is from Reserved OUI– Sender is an intelligent host connected to an IPv4 network

• Otherwise, this packet is exiting from an (IP+MAC) tunnel created by another gateway– Embedded MAC source address is a host in (IP+MAC) “world”


56

Case 2: Move Packet from (IP+MAC) Network to IPv4 Network

• If destination MAC = “Legacy IPv4 Host” – IPv4 target does not understand (IP+MAC) addresses– If Source MAC is not also set to “Legacy IPv4 Host”, we have error– Do not insert an Embedded Ethernet header– This may represent the exit for an IPv4 over (IP+MAC) tunnel or a

dumb IPv4 host and an (IP+MAC) host connected by an IPv4 Proxy

• Else insert MAC addresses into Embedded Ethernet header• If destination MAC address is from Reserved OUI

– Destination is an IPv4 host that understands (IP+MAC) addressing

• Else packet must be entering an (IP+MAC) over IPv4 tunnel


57

Stateless Translating Gateway Can Handle Everything

• Any (IP+MAC) host can connect to anyone:– IPv4 hosts should support Embedded Ethernet headers– Otherwise, connection requires a stateful IPv4 Proxy!

• IPv4 hosts that supports Embedded Ethernet headers can connect to anyone, without a proxy

• All other IPv4 hosts can connect to:– “Well-known” services on (IP+MAC) networks via IPv4 Proxies

• Tunneling is easy and completely transparent– (IP+MAC) traffic over IPv4 networks– IPv4 traffic over (IP+MAC) networks


58

A Word about Denial of Service Attacks

• In a distributed denial of service (DDS) attack, multiple hosts flood a “victim” with traffic

• Such attacks are hard to stop because:– The attackers can be spread over the Internet– They hide their location(s) by spoofing the source address

• If such an attack packet “escapes” from its home network, it is difficult to see anything wrong with it– “Escape” is easy unless the home network uses outbound

ACLs (which are not common)


59

Does (IP+MAC) Addressing affect DDS Attacks?

• Under IPv4, the attacker’s MAC address would be left behind at the first router– Only the (spoofed) IPv4 address carries on

• Under (IP+MAC) addressing, all 80 bits of the source address reach the victim– The attacker cannot use its true MAC address

without revealing its identity– Substituting a false (but static) MAC still leaves a

trail…


60

Randomized IP Addresses Brings You Trouble

• Recall that the new 4-valued EtherType identifies both source or destination IP addresses as “local” or “alien”

• No Host should ever send a packet with an alien source address– This policy violation could be caught at the first

point of connection (bridge) if the EtherType is set– Placing an alien value in the IP-field is a violation

that the gateway router should detect, no matter how the EtherType is set


61

Randomizing MAC Addresses Also Attracts Attention!

• Recall that Bridges learn every MAC address on the network, unless identified as “alien”

• If an attacker randomizes its MAC address:– It cannot set the EtherType to say they are alien

addresses, from the previous slide– Therefore, each bridge will try to learn them all– Result is a series of bridges reporting CAM

overflows caused by the port pointing back to the attacker


62

Conclusion: (IP+MAC) Helps Catch DDS Attackers

• Spoofed IP addresses are easy to detect at the source– Can’t spoof the IP of another host on your

own network – they’re identical!

• Spoofed MAC addresses cannot be changed frequently without CAM errors– Victim will receive many packets with the

same information


63

Conclusion

• (IP+MAC) addressing is an easy, natural evolution of current networking practice

• Uses new multi-valued EtherType• A few reserved MAC addresses are needed

to identify local services– default gateway– Name server

• One reserved OUI is needed for carrying legacy IPv4 host numbers


64

Documents

Integrated Ethernet Internetworking Protocol Mart Molle UCR Department of Computer Science & Engineering